Newsgroup: it.comp.os.dibattiti
Titolo: Ha senso non avere una windows library di sistema sotto Linux ?

Una domanda: supponiamo di avere attivi su Linux
sia KWrite che Gimp.
Poichè entrambe le applicazioni usano due diversi
toolkit (QT e GTK+), significa che avremo un memoria
due diverse CreateWindow.
C'è una quantità di codice enorme che viene duplicato
tra un toolkit e l'altro, e sotto Linux devo tenermelo
tutto in memoria. Poi, se ho in memoria una applicazione
che usa QT, una che usa GTK, ed una che usa Motif
(senza contare Athena), la cosa diventerebbe semplicemente
tragicomica (ah vero, ho scordato wxWidget).
Tutto questo sopra a quel mostro di efficienza e velocità che
è notoriamente X-Window.
Ha un qualche senso tutto questo secondo voi ?
Non è che per caso gli sviluppatori di SkyOS con la loro
interfaccia grafica SkyGI, gli sviluppatori QNX che propongono
Photon, gli sviluppatori Haiku che propongono Tracker,
e Redmond che propone GDI, hanno ragione e gli unixisti
hanno torto ?

Pegasus ha scritto:

chi sono questi unixisti?
E cosa sostengono perché tu asserisca che hanno torto?

 hanno torto ?
Hai dimenticato OS X :P
Sinceramente, che ci fosse una convergenza, MAGARI! Ma mica solo per i
widget, ma per *tutto*.
Ma qui devi renderti conto che non c'è IL_TEAM_DI_SVILUPPO_DI_GNU_LINUX ma
c'è
1) Linux
2) Progetto GNU
3) Xorg
4) GTK/Gnome
5) Trolltech -> QT
6) KDE
7) Compiz
8) e tanti tanti altri magnifici amici
E tutti questi tra loro sono fondamentalmente scoordinati...
Linux "e i suoi fantastici amici" (cit.) è un territorio fertile per la
sperimentazione (lo è sempre stato, credo). 
Se ti piace l'idea ti adatti...
Se non ti piace l'idea, ma vuoi adattarti lo stesso, lo fai.
Se non ti piace l'idea e non vuoi adattarti, o
1) ti compri un Mac :P, o
2) ti crei la tua distro, e crei dei tool ad-hoc e cerchi di rendere il
tutto più coerente possibile, o infine
3) mandi tutto a cagare, e ti trasferisci su un'isoletta del Pacifico,
piena di sole e belle donne
in conclusione, perdonami, ma *la domanda* in sé IMO non ha in verità molto
senso :P perché la situazione è questa, e per ora non si decide a cambiare
ci sono stati tanti miglioramenti in questi ultimi anni, ma l'anno di
linux... :/ mah...
ciao :)
-- 
NoWhereMan (e.v.)
-- 
http://www.nowhereland.it
-- 
http://flatpress.nowhereland.it

 Ha un qualche senso tutto questo secondo voi ?
Si. Kde e Gnome, come del resto Gtk e QT, non sono Linux. Sono progetti a
se. E non vedo minimamente l'esigenza di ricreare da zero un nuovo set di
librerie solo per definirne una standard. Nessuno potrebbe imporla. Come
del resto non si può imporla nemmeno in Windows. Se mi installo Gimp su
Windows devo installarmi anche le Gtk. Se voglio usare applicazioni KDE su
Windows devo installarmi le QT e tutte le librerie necessarie. KDE4 si
potrà installare anche su Windows proprio per facilitare l'installazione
delle applicazioni pure su quel sistema.
Quindi, imho, a non avere senso è la tua domanda.
-- 
Ciao.
Blue

 tragicomica (ah vero, ho scordato wxWidget).
wxWidget sotto Linux usa GTK, pertanto eliminalo
dalla lista.
C:\>iao Angelo

 Ha un qualche senso tutto questo secondo voi ?
NO
Ti stavi riferendo al tuo post, vero?
Saluti,
The Librarian

 hanno torto ?
Se non c'e` un OS ogni persona fa come cazzo le pare. Linux non e` un 
OS, ed e` un dato di fatto che vi siano tanti diversi sistemi grafici.
SkyOS, OSX, Windows, ..., sono tutti OS, progettati per essere tali, e 
quindi stabiliscono chiaramente quali sono le librerire grafiche di 
sistema. Nulla ti impedisce di usarne una diversa, tipo le Qt, se devi 
fare un programma che compili su piu` piattaforme, per esempio.
Tendo a farti notare come UNIX abbia sempre avuto IL suo sistema 
grafico, non mille. Tutto nacque moooolto dopo UNIX, ed e` sentito nel 
mondo linux piu` di tutti. Quindi 'unixisti' e` un poco avventato come 
termine.
-- 
Sensei <senseiwa at Apple's mac dot com>
If you get this in less than 10 seconds, then you are a certified geek.
"FEATUR"
(License plate seen on an old Volkswagen Beetle)

 quello che GTK/QT fanno è disegnare i widget.
No, non fanno solo quello, altrimenti sarebbe una skin diversa e non un 
toolkit ;)
-- 
Sensei <senseiwa at Apple's mac dot com>
$ cd /pub
$ more beer

 Ha un qualche senso tutto questo secondo voi ?
Mettetevi in testa che qt+kdelibs o gtk+gnomelibs è come dire cocoa o cose
equivalenti.
A livello desktop KDE e Gnome sono praticamente due "sistemi operativi"
differenti con il vantaggio che puoi lanciare le applicazioni di uno sotto
l'altro senza troppi problemi.
-- 
Vide

 è notoriamente X-Window.
ma per favore...
http://icps.u-strasbg.fr/~marchesin/nvdri/fosdem1.pdf

 Ha un qualche senso tutto questo secondo voi ?
Ma perche' riproponi sempre, e sempre tu, gli stessi argomenti
triti e ritriti e gia' superdiscussi tempo fa su ICOD? :-) (E
non dire che non sei Vegeta...)
bye G.L.
-- 
Renaissance, aka Gian Luca Sole
Per rispondere, togli nospam letto al contrario, e cambia nazione.
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 grafico, non mille.
a cosa ti riferisci, cde?

Ottavio Campana wrote:


Suppongo parlasse di motif. :-)
Con cde hanno provato a introdurre un nuovo standard, ma
era ed e' un DE IMHO abbastanza scadente...


 sistema. 
Ma hai idea di quante librerie grafiche diverse ci sono sotto OS X?
Il fatto che poi quelle direttamente di Apple siano gestite in modo da
integrarsi ed essere relativamente ardue da distinguere, è solo un
merito di Apple.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 hanno torto ?
Forse. Se la gente avrà voglia di portare la roba su SkyGI.
Altrimenti...
Io una cosa del genere la vedo presso i miei amici amighisti. Il nuovo
OS Amiga è un OS piuttosto moderno, ben fatto, user-friendly e che
occupa *megabyte* di RAM [ non centinaia di ].
Eppure tutti a volere un port di GTK perchè il software in pratica non
esiste. 



Il problema vero di questa storia è che non si vogliono riconoscere le
magagne ingegneristiche che stanno dietro a Linux.
Ecco perchè non ho nemmeno risposto agli altri: mi sono reso conto
che è inutile.
Qui esiste un problema di fondo: come già detto più volte, io posso
cambiare come voglio l'implementazione di una libreria. Se mantengo
inalterato il prototipo, le applicazioni continueranno a funzionare.
Il problema quindi, non è tanto quello di avere n toolkit. Il problema è
che questi toolkit dovrebbero semplicemente tradurre le loro chiamate
in chiamate native per la GUI del sistema operativo.
Le GTK di SkyOS richiamano i widget nativi di SkyOS. Le wxWidget,
invece, non usano i widget di Gnome, ma i propri, quindi anche se
wrappano GTK, è per ridere.
Poi si sta trascurando (colpa mia che non l'ho spiegato bene), che GTK
è solo una piccola parte di Gnome. Per fare una applicazione che si
integra in ambiente Gnome, serve richiamare tutto Gnome core, non solo
le GTK (ed infatti SkyOS ha GTK ma non Gnome).
Windows ha una situazione simile, ma tanto per fare un esempio, le librerie
a 16 bit per le applicazioni Win16 convertono internamente le loro chiamate
in chiamate a 32 bit per il sottosistema Win32. Il risultato è che per 
Windows
NT, le cose vanno come se ci fossero solo applicazioni Win32 nel sistema.
Questo meccanismo ha il vantaggio di uniformare il comportamento dei
vecchi applicativi alle nuove esigenze dell'OS. Un esempio clamoroso si ha
installando sotto XP il vecchio Word 95 a 16 bit. Quando si va su
File/Stampa, nel punto dove prima appariva il Print Manager di
Windows 3.x, adesso compare la cartella Stampanti (sotto Win95),
oppure il Manager Stampanti e Fax in Windows XP.
Se Linux fosse fatto in questo modo, avremmo un set di widget molto
potente, pulito e veloce basato su X (io direi qualcosa di meglio ma
vabbè), e poi le librerie di KDE si occuperebbero semplicemente di
tradurre le chiamate KDE in qualcosa di compatibile con questo nuovo
protocollo unificato, idem per Internet Explorer che gira nel sottosistema
Wine, idem per Evolution che gira nel sottosistema Gnome, idem per
VI che gira nel sottosistema Terminal e così via.
La memoria necessaria diventerebbe un quarto, tutti i miglioramenti
apportati allo strato comune sarebbero immediatamente disponibili
per tutte le applicazioni (nuovi algoritmi, bug fixes),  e sarebbe anche
più facile da mantenere per gli sviluppatori.

 VI che gira nel sottosistema Terminal e così via.
Guarda che accade già questo. Oppure io non ho capito quello che vuoi
dire.


 funziona. Suona nessuna campanella ?
Sì, che non se lo caga nessuno e che continua ad essere poco più di
vaporware
-- 
Vide

 ha scritto nel messaggio 
news:f2jnmm$ef7$1...@aioe.org...

Certo però che per fare certe sparate ce ne vuole
faccia di bronzo.....
SkyOS vaporware ? Ma vai in bagno Vide va....

 SkyOS vaporware ? Ma vai in bagno Vide va....
Spiegami, ma se io lo volessi provare, esistono delle 'demo' gratuite
oppure devo pagare per provare l'n-esimo sistema alternativo che per ora
non mi da nessuna garanzia di non chiudere i battenti nei prossimi t
mesi?
Che io capisco che tu mi dici che non chiude i battenti e che avrà
successo e quello che vuoi. Però se io devo cacciare soldi per una cosa
che non mi serve (e che sarebbe a livello di curiosità) ci penso un
mucchio di volte.
Che anche Zeta prometteva bene e poi guarda come è finito, eh.


 SkyOS vaporware ? Ma vai in bagno Vide va....
Senti, nell'anno del signore 2007 un nuovo sistema operativo assolutamente
classico (ovvero totalmente lato client) per cui devo pagare per provare
una beta e che non mi da nulla di più di quello che mi possa dare windows
(90% degli utenti), osx (fico, integrato e con una visione unica) o linux
(gratis, libero, smanettabile e personalizzabile al 100%) io lo
definisco "inutilware" (anche se vaporware si addice dato che si aspetta
una release ufficiale pubblica da *anni* ormai).
-- 
Vide

 definisco "inutilware"
Ovvio. Sei in grado di fare il 90% di quello che fai con la tua Ubuntu
con un processore a 400 Mhz e 64 Mb di Ram ?

 con un processore a 400 Mhz e 64 Mb di Ram ?
Se parli di sistemi "embedded" (a parte che esiste il neonato progetto
Ubuntu Embedded) che cazzo c'entra? Non è un desktop con tastiera, mouse e
schermo da >=17", ergo non ci vado a mettere sopra lo stesso tipo di OS e
applicazioni desktop. Se parli di hardware desktop con quelle
caratteristiche, ROTFL (il porting di OpenOffice e Firefox dopo ci gira
*benissimo*, sicuramente).
Salto il resto del post/sbroccata fiume sui "linuxisti" visto che l'ho
confrontato con *3* sistemi operativi differenti e di Linux in sto discorso
non me ne può fregar di meno.
-- 
Vide

 era ed e' un DE IMHO abbastanza scadente...
Che bei tempi andati!!
Adesso c'e` Looking Glass no? :D
-- 
Sensei <senseiwa at Apple's mac dot com>
$ cd /pub
$ more beer

 merito di Apple.
Si, io ho idea di come funziona OSX. Fondamentalmente la scelta di 
apple e` di far usare Cocoa. Tutto il resto e` affar tuo (io uso le qt 
ad esempio). Che poi sotto vi siano altre cose, a te non importa, come 
non importa che sotto le qt vi sia X oppure un altro sistema. Il fatto 
e` semplice: un OS deve essere coerente e dare la scelta di sistema, se 
non la dai... non sei un os.
-- 
Sensei <senseiwa at Apple's mac dot com>
Research (n.): a discovery already published by a chinese guy one month
               before you, copying a russian who did it in the 60s.

 *benissimo*, sicuramente).
Firefox 1.5 gira benissimo su Windows 98 e su SkyOS con 128 Mb
di Ram, processore K6-3 400 Mhz (ma l'ho fatto girare anche con
64 Mb, un poco meno reattivo ma funziona tutto sommato bene).
Su Linux Suse è inutilizzabile. Suona nessuna campanella ?

 Su Linux Suse è inutilizzabile. Suona nessuna campanella ?
Sí, che da Trony c'è un CoreDuo 2 a 499 euro che consuma meno del tuo K6-3.
-- 
Vide

 il supporto tecnico...... Canonical te lo dà gratis?
SkyOS *deve* dare gratuitamente in visione il suo OS. LiveCD, faccia 
qualcosa. O si aspetta che la gente usi emule?
Fossi in loro io licenzierei i manager. Tutti.
-- 
Sensei <senseiwa at Apple's mac dot com>
We know Linux is the best, it can do infinite loops in five seconds.
(Linus Torvalds)

 Fossi in loro io licenzierei i manager. Tutti.
Manager? Ma se è praticamente solo una persona che fa tutto da solo, AFAIK.
-- 
Vide

 io lo definisco "inutilware"
rotfl!!! :-D

 garanzie, mentre SkyOS no.
considerando che nonostante questi problemi c'è chi ci lavora e porta a
casa la pagnotta.

 sardo che vive tra le pecore lo capisca.
Hey usiamo le nuove tecnologie ora, anche li! :)
-- 
Sensei <senseiwa at Apple's mac dot com>
There is no reason for any individual to have a computer in his home.
(Ken Olsen, President, Digital Equipment, 1977)

 Su Linux Suse è inutilizzabile. Suona nessuna campanella ?
Io faccio parte di un'associazione che fa recupero hardware e installa linux su
macchine con configurazioni del tutto simili a quella che hai appena menzionato.
Se ci provi vectorlinux o una slackware NUOVA linux va molto veloce.
Quindi la campanella penso che tu l'abbia nel tuo cervello.

 con un processore a 400 Mhz e 64 Mb di Ram ?
Ubuntu magari no, altre distro fatte apposta per quelle macchine con software
nuovo e aggiornato si.

 toolkit ;)
ok, magari ho detto una solenne stronzata :D ma forse semplicemente non mi
sono spiegato bene (ma propendo per la stronzata :D :D)
Quello che intendevo dire è che i toolkit *essenzialmente* disegnano i loro
propri widget sulla finestra; ovviamente, forniscono la possibilità di
interagire con essi in vari modi, sennò non servirebbero a una cippa :P 
Poi il fatto che nella fattispecie questi toolkit forniscano routine
(multimediali, di I/O ecc) che vadano al di là di questo, d'accordo.
questo non impedisce comunque il confronto con i toolkit di Java, Firefox e
OOo, perché il punto rimane: se hai in memoria questi tre hai certamente
tre toolkit, tre framework o come cavolo volete chiamarli che implementano
una certa quantità di codice che fa la stessa cosa, e senza dover chiamare
in casua per forza leenuxx
Corregetemi però se ho detto cavolate :P
ciao
-- 
NoWhereMan (e.v.)
-- 
http://www.nowhereland.it
-- 
http://flatpress.nowhereland.it

 casa la pagnotta.
Mentre SkyOS si è scritto da solo....

 Hey usiamo le nuove tecnologie ora, anche li! :)
azz..., il nuraghe con la fibra!.....

 Mentre SkyOS si è scritto da solo....
ma non è usato.


Ok, qui c'č una serie di review di SkyOS:
http://www.techimo.com/articles/i148.html
http://osnews.com/story.php/8586/Overview-of-SkyOS-Beta8
http://mattst88.no-ip.com:8181/skyos/?page=dma
Sti tizi secondo te come lo hanno avuto il software ?

 
http://softwarestore.skyos.cz/
inutili senza l'os.

 apple e` di far usare Cocoa.
Non è vero. Cocoa per alcune cose, Carbon per altre. 
Loro stessi non sviluppano certo tutto in Cocoa.


 bene , io ripropongo la cosa dell'altro thread
io una più semplice; Pegasus, te l'hai comprato?
sono solo curioso...


 Corregetemi però se ho detto cavolate :P
In media chi usa linux ha almeno 2 toolkit in memoria. E questi fanno 
sostanzialmente la stessa identica cosa.
-- 
Sensei <senseiwa at Apple's mac dot com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)

 Loro stessi non sviluppano certo tutto in Cocoa.
No, ma Cocoa e` la scelta per le applicazioni.
Carbon non e` la scelta primaria per performance e porting di 
applicazioni su OSX, Cocoa per l'applicazione in se con widget grafici. 
Possono essere usate entrambe, basta provare a vedere con otool quali 
framework usano, e molti usano Carbon e Application Kit (parte di 
Cocoa).
Per me c'e` un ostacolo grande, l'Objective-C. Fossi io farei Cocoa in 
C++, ma vabbe`...
PS. Per chi vuole vedere qualcosa di piu` approfondito:
http://developer.apple.com/carbon/overview.html
http://developer.apple.com/cocoa/overview.html
-- 
Sensei <senseiwa at Apple's mac dot com>
$ cd /pub
$ more beer



Sono rari i posti in cui trovo la fibra, almeno nella mia provincia, 
magari a Cagliari e Sassari e` diverso.
-- 
Sensei <senseiwa at Apple's mac dot com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)

 C++, ma vabbe`...
Cosa c'è di ostacolo in ObjectiveC? E' estremamente più facile e comodo di
C++. Tra l'altro per qualcuno che conosce la programmazione ad oggetti, il
linguaggio si impara in meno di una settimana.
Per il resto pensare di fare Cocoa in C++ è come volere fare un gioiello
con dei mattoni. La bellezza di Cocoa deriva direttamente dalla dinamicità
di Objective C, dalla sua potenza ed espressività.
Cocoa in effetti è ben accessibile da Python e da Ruby, ma questo accade
perchè sono *più* dinamici di Objective C. I binding in Java sono stati
deprecati e quelli in C# sono sostanzialmente una beta.
-- 
Consistently separating words by spaces became a general 
custom about the tenth century A.D., and lasted until 
about 1957, when FORTRAN abandoned the practice. 
(Sun FORTRAN Reference Manual)

 sono solo curioso...
io scommetto di no.

 deprecati e quelli in C# sono sostanzialmente una beta.
Vedi su.
-- 
Sensei <senseiwa at Apple's mac dot com>
Beware of bugs in the above code; I have only proved it correct, not tried it.
(Donald Knuth)

 Adesso c'e` Looking Glass no? :D
Mah, io uso raramente linux in grafica, quindi non saprei
cogliere. :-)
bye G.L.
-- 
Renaissance, aka Gian Luca Sole
Per rispondere, togli nospam letto al contrario, e cambia nazione.
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

 di vista commerciale, e non spaventa eventuali nuovi 'acquirenti', 
C++ non si avvicina *comunque* ad Objective C. Il modo in cui è
concepita e progettata Cocoa è un incubo da fare in C++. Cocoa è pensata
in modo dinamico: delegazioni 'al volo' e compagnia. Per usare C++ in
quel modo bisogna pervertirlo pesantemente.
Praticamente significherebbe riscriversi a mano parte del runtime in C++
applicazione per applicazione. Che chiaramente ammazzerebbe la
produttività.


 produttività.
No, basta una cosa a signal/slot che e` proprio dinamica. Sarebbe una 
mossa non certo di funzionalita`, ma di immagine. Il C++ ha preso 
piede, l'objective c no, e` ormai un dato di fatto.
-- 
Sensei <senseiwa at Apple's mac dot com>
If you get this in less than 10 seconds, then you are a certified geek.
"FEATUR"
(License plate seen on an old Volkswagen Beetle)

 sistema, se non la dai... non sei un os.
???
Questa è la prima volta che la sento.
-- 
 Daniele Giglio               Dona i tuoi cicli di clock alla ricerca!
 d·g·i·g·l·i·o·@·i·o·l·.·i·t  
http://boinc.berkeley.edu/
                          --------------------
           This signature was automatically generated with
           Signify v1.14.  For this and other cool products,
           check out 
http://www.debian.org/

 piede, l'objective c no, e` ormai un dato di fatto.
Quanto conosci di Cocoa? Io abbastanza. Posso dirti che, come dicevo, a
meno di scrivere una buona parte del runtime di Objective C in C++, non
ce ne esci: praticamente devi reimplementare Objective C in C++ [ cosa
fattibilissima, per carità, solo veramente scomoda ]. Tanto per
cominciare.
A questo punto butti buona parte del comportamento dentro NSObject. A
questo punto derivi tutto da NSObject. Bene: già qui stai usando il C++
nel modo peggiore possibile. Usando polimorfismo dinamico invece che
polimorfismo statico. Non solo, rinunci in buona sostanza ad uno dei
punti di forza di C++, ovvero il paradigma RAII.
Tra l'altro con il fatto che in C++ le eccezioni si usano anche
parecchio, diventa in buona sostanza un *macello* mantenere la stessa
semantica di allocazione e deallocazione degli oggetti.
Per cui devi convincere i programmatori C++ a scrivere codice stronlgly
exception safe anche per le più grandi banalità [ e questo è costoso ],
oppure a *non* usare le eccezioni.
Su tutto hai il problema del messaggiamento dinamico. Al che hai due
soluzioni:
1) inventi una nuova sintassi e fai passare tutto per un preprocessore.
Bene: a questo punto non stai già più programmando in C++
2) usi cose tipo obj.send("setShadowOffset", shadowOffset)
che se permetti fa un po' schifo.
3) riscrivi tutto pensando in C++. Bene, hai una nuova libreria.
Quello che posso dirti è: Cocoa è pensata e creata tenendo presente la
dinamicità di ObjectiveC. È una libreria costruita *attorno* al
linguaggio. Al suo modo di procedere, ai suoi pattern.
Tu dici di portarla in C++. Sarebbe *costosissimo* e condurrebbe ad una
libreria differente, oppure alternativamente ad un linguaggio che *non*
sarebbe C++.
Sul tutto che usare C++ per applicazioni grafiche è come dicevo quasi
sempre un'inutile esagerazione. Inutilmente costoso nella migliore delle
ipotesi.
Sarebbe insomma un passo indietro sotto tutti i punti di vista, senza
*nessun* vantaggio concreto. Perchè non è certo ObjectiveC che tiene
lontani gli sviluppatori. Anzi: da quando si sviluppa principalmente in
ObjectiveC il numero di sviluppatori e di applicazioni si è praticamente
decuplicato.
I programmatori C++ hanno diverse strade per fare quello che vogliono
con il loro linguaggio preferito. Lasciamo che per una volta che c'è un
linguaggio davvero bello (anche se non tanto quanto Python o Ruby) che è
un cittadino di prima classe su una piattaforma, beh, lasciamocelo.


 un cittadino di prima classe su una piattaforma, beh, lasciamocelo.
Purtroppo anche un linguaggio davvero bello puo` essere un ostacolo. 
L'Objective C e` un 'in piu`' da imparare per scrivere programmi su 
macosx. Io per mossa commerciale farei il passo, o almeno proverei a 
vedere la risposta dei possibili altri compratori.
E no, non conosco prima si osx come erano le cose, ma so che stavano 
sotto ad un treno. Da poco a decuplicare si fa prima che da questo 
punto in poi.
-- 
Sensei <senseiwa at Apple's mac dot com>
There are 10 types of people in the world:
those who understand binary, and those who don't.

 Questa è la prima volta che la sento.
Come e` la prima volta che senti che quando hai 10000 prodotti, in 
realta` ne devi scegliere uno?
-- 
Sensei <senseiwa at Apple's mac dot com>
Java is the most distressing thing to happen to computing since MS-DOS.
(Alan Kay)

 con un processore a 400 Mhz e 64 Mb di Ram ?
ragazzo mio, su un cesso simile al massimo installaci Xubuntu, quello 
con XFCE.
Vedrai che andrà egregiamente.

 punto in poi.
C'era Carbon e C++. 
C'era CodeWarrior (che molti considerano uno dei migliori IDE in
circolazione). 


 sostanzialmente la stessa identica cosa.
Anche in Windows (non so se vale per gli ultimi a 64 bit)
ci sono più librerie per gestire la grafica GUI:
Win32,
le librerie per la compatibilità con le applicazioni OS/2
win16.
Sono d' accordo sul fatto che l' avere un entità forte
dietro a un OS
faccia sì che un toolkit prevalga sugli altri, altrimenti è anarchia..
questo imho è stato vero anche per l' hardware...
Il PC si è standardizzato quando un tempo gli home computer erano un 
pullulare di bus diversi ecc.
Nela vecchia documentazione MS leggo di
PC 97 Hardware Design Guide
PC 98 System Design Guide
Insomma anche nella PC Industry ci sono diverse aziende ma
entità forti come Intel e M$ hanno fatto sì che non ci fosse
una anarchia totale
(altrimenti avremmo tutte motherboard differenti dove un sistema operativo
deve esser ottimizato_o_addirittura sviluppato per esse,
con possibili problemi di compatibilità fra gli OS ecc...;
mentre ad oggi, giusto per diversificare la fauna ;),
rimangono Amiga one/Genesi e altri :) ).