Microsoft Windows Vista: rilasciata la preview di novembre

[fek]

Originariamente inviato da Criceto

Solo ce ci vuoi "giocare"... Dicesi DEMO.

No, e' una versione FULL del compilatore C++. Ed e' gratuita.

WebObject

Ti avevo detto di stare attento alla risposta: WebObject e' per caso un framework che permette di condividere oggetti creati con linguaggi differenti e implementa un object model? Non credo proprio. Allora non c'entra nulla con .NET. E' solo un framework per scrivere WebService. Volendo trovare un parallelo per forza con .NET, sarebbe equivalente solo una parte dei suoi servizi di remoting.

In disuso non direi, è usato per fare applicazioni OS X Cocoa (le più "native" tra quelle native), come prima da NeXT. Anche C# è usato solo per .NET, o sbaglio?

C# non e' "usato" per .NET. C# e' uno dei linguaggi che permette di scrivere oggetti consumabili dal framework. Ed e' usato per scrivere una marea di applicazioni enterprise sotto piattaforma Win32.

Mi fai un esempio di applicazione enterprise scritta in ObjectiveC?

Ruby/Python/Eiffel e lo stesso Java (per ora) non sono confrontabili...

Non sono confrontabili a cosa? A ObjectiveC? Certo, sono tutti linguaggi decisamente piu' evoluti e produttivi.

[Criceto]

Originariamente inviato da fek

Ti avevo detto di stare attento alla risposta: WebObject e' per caso un framework che permette di condividere oggetti creati con linguaggi differenti e implementa un object model? Non credo proprio. Allora non c'entra nulla con .NET. E' solo un framework per scrivere WebService. Volendo trovare un parallelo per forza con .NET, sarebbe equivalente solo una parte dei suoi servizi di remoting.

Non vedo il vantaggio nel mischiare linguaggi differenti. E comunque le API di OS X sono utilizzabili sia dall'Objective C che da Java (l'object model, se non ho capito male, è uguale), quindi se vuoi pasticciare, puoi farlo...

[Criceto]

Originariamente inviato da fek

Mi fai un esempio di applicazione enterprise scritta in ObjectiveC?

Eh! Non è il mio campo, ma NeXT sopravviveva solo con quello prima che se la comprasse Apple!!!

EOF significa "Enterprise Object Framework" ed è il cuore di WebObjects!
iTunes (il negozio) è fatto con WebObjects, come lo era il primo sito Dell, Disney e molti altri. Certo, ora ci sono molte altre opzioni ed è meno usato, ma è stato il primo a permettere di fare certe cose.

[Criceto]

Originariamente inviato da fek

Non sono confrontabili a cosa? A ObjectiveC? Certo, sono tutti linguaggi decisamente piu' evoluti e produttivi.

Sono interpretati...

[fek]

Originariamente inviato da Criceto

Non vedo il vantaggio nel mischiare linguaggi differenti.

Perche' non hai mai programmato

E' abbastanza indifferente che tu non veda il vantaggio, la cosa che conta e' che questo e' lo scopo di .NET mentre lo scopo di WebObjects e' scrivere Web Service. Sono due cose totalmente differenti. Ergo, affermare che .NET sia stato copiato da Apple quando Apple non ha nulla di anche solo vagamente paragonabile mi sembra un po' errato.

Sarebbe anche errato dire che .NET ha copiato da Java, ma almeno ci sarebbe qualche argomento per sostenere tale tesi (il bytecode da una parte e il CIL dall'altra).

Originariamente inviato da Criceto

Sono interpretati...

Java non e' interpretato. Anche per Python e Ruby cominciano ad apparire le prime macchine virtuai JIT.

[Criceto]

Originariamente inviato da fek

Perche' non hai mai programmato

E' abbastanza indifferente che tu non veda il vantaggio, la cosa che conta e' che questo e' lo scopo di .NET mentre lo scopo di WebObjects e' scrivere Web Service. Sono due cose totalmente differenti. Ergo, affermare che .NET sia stato copiato da Apple quando Apple non ha nulla di anche solo vagamente paragonabile mi sembra un po' errato.

Diciamo che .NET, per quello che ho capito, include la funzionalità di API object oriented per windows, più gli oggetti distribuiti. Insomma racchiude con un unico nome tecnologie che su NeXT prima, e su OS X poi ci sono da sempre ma hanno 2 nomi.
Per quanto riguarda il "multilinguaggio" le API di OS X, come detto, possono essere utilizzate indifferentemente in Objective C e in Java e ci sono sistemi per poter utilizzare oggetti del C++ (con un estensione del linguaggio chiamata Objective C++). Non mi sembra che con .NET si possa usare il C++ liscio, quindi problemi di interoperabilità non ottimale (se si hanno librerie in questo liguaggio) sembrerebbero equivalenti.

Originariamente inviato da fek

Sarebbe anche errato dire che .NET ha copiato da Java, ma almeno ci sarebbe qualche argomento per sostenere tale tesi (il bytecode da una parte e il CIL dall'altra).

Il "bytecode" per come è implementato su Java sembra comportare più svantaggi che vantaggi per ora. Vedremo se Microsoft con Vista riuscirà a realizzare un'implementazione migliore...
Ma non è detto che nel momento che Vista uscirà Leopard non avrà qualcosa di equivalente e potenzialmente ancora più interessante...
http://www.osnews.com/story.php?news_id=12715

Originariamente inviato da fek

Java non e' interpretato. Anche per Python e Ruby cominciano ad apparire le prime macchine virtuai JIT.

Infatti lo avevo escluso (il "per ora" era per gli interessanti sviluppi che potrebbe comportare la notizia di cui il link precedente).

[fek]

Originariamente inviato da Criceto

Diciamo che .NET, per quello che ho capito, include la funzionalità di API object oriented per windows, più gli oggetti distribuiti. Insomma racchiude con un unico nome tecnologie che su NeXT prima, e su OS X poi ci sono da sempre ma hanno 2 nomi.

No. .NET non e' quello, ma e' un insieme di tecnologie che permettono di scrivere un componente con un linguaggio e questo componente e' consumabile da qualunque linguaggio conforme alle specifiche del CLR (Common Language Runtime).

.NET non e' altro che il successore della piattaforma COM. Su questa piattaforma sono state esposte anche una serie di API ad oggetti che semplificano la programmazione di interfacce utente Windows (WinForms), una serie di API per il remoting e oggetti distrubuiti (l'equivalente di CORBA, DCOM), una serie di API per l'accesso ai dati (l'equivalente di ODBC, JDBC, etc).

Non c'e' nulla di equivalente in MacOSX.

Per quanto riguarda il "multilinguaggio" le API di OS X, come detto, possono essere utilizzate indifferentemente in Objective C e in Java e ci sono sistemi per poter utilizzare oggetti del C++ (con un estensione del linguaggio chiamata Objective C++). Non mi sembra che con .NET si possa usare il C++ liscio, quindi problemi di interoperabilità non ottimale (se si hanno librerie in questo liguaggio) sembrerebbero equivalenti.

No, sono due cose differenti. Le API di OSX sono esposte in due linguaggi, come ad esempio le API native Win32 sono esposte in C++ e sono esposte in Delphi, ad esempio, per mezzo di wrapper.

In .NET il concetto e' profondamente diverso: le sue API sono esposte in CIL ed ogni linguaggio conforme alle sue specifiche puo' consumarle. Se, ad esempio, uscisse un linguaggio futuro, chiamiamo XXX, questo non potrebbe consumare le api di MacOSX a meno che qualcuno non si prenda la briga di scrivere un wrapper apposito, mentre se questo linguaggio e' conforme alle specifiche del CIL puo' consumare le API di .NET direttamente. E' una differenza sostanziale.

L'interoperabilita' fra .NET e C++, per dirla con il termine usato da Microsoft, "Just works". Non e' solo ottimale, e' nativa, codice C++ funziona in ambiente managed senza alcuna modifica e puo' consumare oggetti CIL per via delle estensioni managed.

Il "bytecode" per come è implementato su Java sembra comportare più svantaggi che vantaggi per ora. Vedremo se Microsoft con Vista riuscirà a realizzare un'implementazione migliore...

Il bytecode di Java non e' interpretato, e' compilato "just in time" e poi ogni metodo e' sempre eseguito nativo.

Ma non è detto che nel momento che Vista uscirà Leopard non avrà qualcosa di equivalente e potenzialmente ancora più interessante...
http://www.osnews.com/story.php?news_id=12715

E' una copia del CLR per usare un'espressione a te cara

Per ora sotto OSX non esiste nulla di paragonabile, mentre .NET e' una realta' gia' da anni.

[sari]

Originariamente inviato da Criceto

Non vedo il vantaggio nel mischiare linguaggi differenti.

Se Fek ha risposto dicendo che non hai mai programmato io ti chiedo il permesso di usare questa battuta :P. Basti solo pensare a cosa si può fare mischiando tra loro C e C++, o C e bash script.

Edit : Ho citato quei due perchè sono gli unici due esempi che conosco e che uso, ma sono sicuro che c'e' ne sono molti altri, anche più utili ed interessanti. Sto giusto giusto vedendo ora se sia possibile integrare codice C++ o python in proggetti Java, se qualcuno lo sa me lo dica e mi dia qualche indicazione.

[tomminno]

Originariamente inviato da Criceto

Il fatto che Vista stia rincorrendo OS X è oggettivo e si può vedere in 1000 dettagli del "nuovo" OS di M$, dai più profondi ai più esteriori, perfino ridicoli nella goffagine (l'ultimo che ho visto in ordine di tempo è il nome del programma di posta elettronica che ora in vista non si chiama più Outlook Express ma "guadacaso" Mail... )

E OS X è MOOOOOOLTO più che una bella grafica.
E' lo stato dell'arte degli OS da pressochè tutti i punti di VISTA

Si certo come server Web è imbattibile
Come supporto HW pure
Mi piacerebbe vedere una rete costituita da soli Mac.
Comunque non diamo alla Apple meriti che non ha. Mac OSX è UNIX (tra l'altro non capisco perchè non abbiano scelto integralmente FreeBSD), la Apple lo compila e ci mette un pò di grafichetta, che a me personalmente non piace nè esteticamente nè come usabilità, ho visto programmi che aprono 4 finestre "agganciate" ai 4 angoli dello schermo che devono essere ridotte una per una, roba da matti. Sinceramente non vedo tutta questa superiorità del sistema...
Per non parlare della ristrettezza HW a cui deve far fronte un utente Mac.

Ciao!

[matteos]

Originariamente inviato da tomminno

Si certo come server Web è imbattibile
Come supporto HW pure
Mi piacerebbe vedere una rete costituita da soli Mac.

fonti per dire questo?
spero non il solito test fatto con MySQL perchè è stato ripetuto fino alla noia che è un problema di macosx con MySQL.

Comunque non diamo alla Apple meriti che non ha. Mac OSX è UNIX (tra l'altro non capisco perchè non abbiano scelto integralmente FreeBSD), la Apple lo compila e ci mette un pò di grafichetta, che a me personalmente non piace nè esteticamente nè come usabilità, ho visto programmi che aprono 4 finestre "agganciate" ai 4 angoli dello schermo che devono essere ridotte una per una, roba da matti. Sinceramente non vedo tutta questa superiorità del sistema...
Per non parlare della ristrettezza HW a cui deve far fronte un utente Mac.

Ciao!

se per te prendere una base bsd rielaborarla metterci su l'interfaccia grafica e altre aggiunte non è merito di apple di chi dovrebbe essere? dello Spirito Santo?
la ristrettezza HW se compri un apple lo sai...e non vedo persone spaccarsi la testa per questo motivo...poi ristrettezza...bisogna vedere cosa intendi...
per piacere evita di fare certi interventi che ormai sono insopportabili.

[tomminno]

Originariamente inviato da matteos

fonti per dire questo?
spero non il solito test fatto con MySQL perchè è stato ripetuto fino alla noia che è un problema di macosx con MySQL.

Io parlo di Mac utilizzati come Server in una Server Farm, quelli devo ancora vederli, io ho sempre visto x86 multiprocessore e qualche Alpha veramente grosso, mai un Mac.

se per te prendere una base bsd rielaborarla metterci su l'interfaccia grafica e altre aggiunte non è merito di apple di chi dovrebbe essere? dello Spirito Santo?

La stabilità è ereditata però, non è merito loro. In ogni caso la base è più Mach che FreeBSD.

la ristrettezza HW se compri un apple lo sai...e non vedo persone spaccarsi la testa per questo motivo...poi ristrettezza...bisogna vedere cosa intendi...
per piacere evita di fare certi interventi che ormai sono insopportabili.

Cosa intendo per ristrettezza? La limitazione HW rispetto a quello che posso montare su una macchina x86.
Ad esempio si parla di grafica professionale nel mondo Mac, ma una Wildcat per quella piattaforma non c'è e spero bene che per grafica professionale si intenda chi utilizza questo tipo di schede e non una misera NVidia.
Sul lato SW poi la differenza è ancora più marcata, l'Open Source è decisamente più sviluppato sotto x86.

Interventi insopportabili solo perchè faccio notare i limiti di una architettura HW+SW?

Ciao!

[matteos]

Originariamente inviato da tomminno

Io parlo di Mac utilizzati come Server in una Server Farm, quelli devo ancora vederli, io ho sempre visto x86 multiprocessore e qualche Alpha veramente grosso, mai un Mac.

qualcuno che li usa ci sarà se no glixserver che le vendono a fare.

La stabilità è ereditata però, non è merito loro. In ogni caso la base è più Mach che FreeBSD.

no vedo dove vuoi arrivare....se lo hanno scelto è proprio perchè hanno capito che era una buona base su cui costruire un SO.

Cosa intendo per ristrettezza? La limitazione HW rispetto a quello che posso montare su una macchina x86.
Ad esempio si parla di grafica professionale nel mondo Mac, ma una Wildcat per quella piattaforma non c'è e spero bene che per grafica professionale si intenda chi utilizza questo tipo di schede e non una misera NVidia.

per il fatto che non ci siano le wildcat su mac non credo che la colpa sia di apple ma di chi produce le schede che non è interessato al settore mac.
comunque io su una quadro fx4500 non ci sputerei sopra....

Sul lato SW poi la differenza è ancora più marcata, l'Open Source è decisamente più sviluppato sotto x86.

questa è grossa...
vedi che parli "per luoghi comuni" o "per sentito dire"...la parte open source su mac è molto sviluppata visto che oltre quella dedicata esclusivamente a macosx può appoggiarsi a quella di linux con x11.
se non ci credi vai su versiontracker.com

Interventi insopportabili solo perchè faccio notare i limiti di una architettura HW+SW?
Ciao!

sono insopportabili...per il motivo che ti ho detto qui sopra

[dr.strange]

beh nessuno ha parlato del fatto che le opengl sembrano destinate a scomparire su windows...
Saranno anche queste emulate da directx....
Penso che sia una vergogna.

[Criceto]

Originariamente inviato da fek

No. .NET non e' quello, ma e' un insieme di tecnologie che permettono di scrivere un componente con un linguaggio e questo componente e' consumabile da qualunque linguaggio conforme alle specifiche del CLR (Common Language Runtime).

E' vero, ho dei problemi a capire cos'è .NET
Forse non sono il solo, perchè quando fu annuciato per mesi nessuno lo aveva ben capito. Ma a parte la (discutibile?) novità di poter programmare la stessa applicazione in più linguaggi cosa farebbe che OS X non può fare?!

Originariamente inviato da fek

.NET non e' altro che il successore della piattaforma COM. Su questa piattaforma sono state esposte anche una serie di API ad oggetti che semplificano la programmazione di interfacce utente Windows (WinForms), una serie di API per il remoting e oggetti distrubuiti (l'equivalente di CORBA, DCOM), una serie di API per l'accesso ai dati (l'equivalente di ODBC, JDBC, etc).

Se è solo questo, continuo a non vedere cosa abbia di diverso dall'accoppiata Cocoa + WebObjects... cose che OS X aveva fin dall'inizio.
Se puoi spiegare......

Originariamente inviato da fek

No, sono due cose differenti. Le API di OSX sono esposte in due linguaggi, come ad esempio le API native Win32 sono esposte in C++ e sono esposte in Delphi, ad esempio, per mezzo di wrapper.

Sì c'è un wrapper per Java, ma avendo un object model compatibile con Objective C (un caso, o deriverà dal fatto che chi ha sviluppato Java prima aveva lavorato per lo sviluppo dell'Objective C ?) questo ha zero penalità, quindi alla fine è equivalente.

Originariamente inviato da fek

In .NET il concetto e' profondamente diverso: le sue API sono esposte in CIL ed ogni linguaggio conforme alle sue specifiche puo' consumarle. Se, ad esempio, uscisse un linguaggio futuro, chiamiamo XXX, questo non potrebbe consumare le api di MacOSX a meno che qualcuno non si prenda la briga di scrivere un wrapper apposito, mentre se questo linguaggio e' conforme alle specifiche del CIL puo' consumare le API di .NET direttamente. E' una differenza sostanziale.

Se leggi la mail dello sviluppatore dell'LLVM (che ora lavora per Apple) ci sarebbero pro e contro con questo approccio. Secondo lui sono più i contro...

Originariamente inviato da fek

L'interoperabilita' fra .NET e C++, per dirla con il termine usato da Microsoft, "Just works". Non e' solo ottimale, e' nativa, codice C++ funziona in ambiente managed senza alcuna modifica e puo' consumare oggetti CIL per via delle estensioni managed.

Mah, sentivo parlare di "estensioni managed" del C++ da parte di M$, che funzionano solo con compilatori M$ in puro e caratteristico stile "extend and estinguish"...

Originariamente inviato da fek

Il bytecode di Java non e' interpretato, e' compilato "just in time" e poi ogni metodo e' sempre eseguito nativo.

Si, però qualche problema da qualche parte ce lo deve avere, evidentemente, visti i risultati...

Originariamente inviato da fek

E' una copia del CLR per usare un'espressione a te cara

Di uguale vedo solo il JIT, che non è certo un'invenzione M$. E' quello che si vuole ottenere che è differente: da una parte M$ vuole un layer per "virtualizzare" i linguaggi di programmazione (tutti, ovviamente, proprietari o con estensioni proprietarie) delle sue API. Stesso OS, stesso processore.

Dall'altra parte si vuole virtualizzare il PROCESSORE e allo stesso tempo OTTIMIZZARE il codice per ogni variante di esso durante tutta la vita dell'applicazione. E credo anche si possano virtualizzare i famosi 32/64 bit (anche se non è esplicitamente detto, ma così sembrerebbe dalla descrizione del processore virtuale).

E tutto ciò senza inventare nuovi linguaggi proprietari o sviluppare nuove API ma funzionando (con una ricompilata) con tutte le attuali applicazioni sviluppate con Xcode.

Come ciliegina... tutto ciò è open source e utilizzabile (in prospettiva) anche da Linux!

Beh, se ci riescono... Wow!

[cdimauro]

Originariamente inviato da jo.li.

Il macOSx aveva già dalla versione 10.2 (jaguar) l'indicizzazione del disco per effettuare delle ricerche rapide anche del contenuto dei file.

Direttamente dalla guida di Windows (F1):

"attributo

Per i file, informazioni che indicano se un file è di sola lettura, nascosto, pronto per l'archiviazione (backup), compresso o crittografato e se il contenuto di tale file deve essere indicizzato per consentire la ricerca rapida."

E' dai tempi di NT che esiste l'indicizzazione del contenuto dei file.

mentre la apple in questi anni ha continuato a sfornare aggiornamenti del suo OS a raffica.

Dopo essere rimasta in letargo per 20 anni, era il caso che si svegliasse...

[cdimauro]

Originariamente inviato da Leron

più che altro tutte le cose dopo un po' stufano, Vista compreso

sul mio desktop i temi di default non sono rimasti più di un paio di mesi (anche su osx nonostante sia quello che è durato di più e che sinceramente ritengo tuttora anni luce avanti alle "pacchianate" che abbiamo visto nei progetti d vista)

Io sono più "sedentario": in tutte le mie macchine uso ancora il tema "iTunesB" che mi hai passato tempo fa. Funziona benissimo anche su XP x64.

[cdimauro]

Originariamente inviato da Criceto

Il fatto che Vista stia rincorrendo OS X è oggettivo

Chi ha interesse a rincorrere una piattaforma che arriva al 2,5% del mercato?

E OS X è MOOOOOOLTO più che una bella grafica.
E' lo stato dell'arte degli OS da pressochè tutti i punti di VISTA

Se mi parli a livello di usabilità, ne possiamo parlare. Per il resto, ne abbiamo già discusso: è meglio lasciar perdere.

La pietra filosofale nel campo dei s.o. non esiste.

[cdimauro]

Originariamente inviato da Criceto

Apple può inseguire M$ dal punto finanziario (forse, se questo è il suo obbiettivo), ma dal punto di vista tecnico è SEMPRE stata M$ ad inseguire...

Ma se ci sono voluti vent'anni ad Apple per avere un s.o. che non andasse in crash al minimo traballamento di un'applicazione...

E per giunta non è nemmeno farina del suo sacco, visto che ha dovuto appoggiarsi a soluzioni sviluppate da altri (Mach e BSD).

[cdimauro]

Originariamente inviato da Criceto

Non è compito di chi fa l'OS scrivere drivers. Apple lo fà per il suo hardware e per le periferiche "generiche" (dischi IDE, USB, ecc), perchè oltre all'OS produce computer, ma poi basta. M$ non ha hardware quindi ne scrive ancora meno...

MS vende anche hardware, e comunque tanti driver se li è scritti lei. Il che è normale, visto che deve dar conto al 95% del mercato.

E che M$ abbia smesso di copiare Apple (e molti altri)

Come il Fast User Switch?

e abbia inziato ad INNOVARE.

Come .NET?

Non l'ha mai fatto e non lo farà mai: molto più semplice e redditizio per lei copiare o distruggere i suoi avversari facendosi forte dei suoi $$ infiniti e del suo monopolio.

Monopolio che non esiste. Poi se ha tanti soldi, non vedo cosa ci sia di male: l'importante è che non li usi per commettere atti illeciti.

[cdimauro]

Originariamente inviato da Criceto

Ma se ti diverti a provare programmini è molto più pratico farlo con OS X: niente casini con le installazioni (di solito basta un "drag&drop"), niente files di registro che si spu**anato alla decima installazione/disinstallazione, niente rischio di beccarsi virus, niente rallentamenti con 1000 programmi installati, ecc...
Insomma, non c'è storia!!

Infatti: quella che hai riportato non è storia, ma la classica leggenda metropolitana...