Ciao, premesso che mi fa molto piacere vedere ancora un pur minima attività su questa lista, sarò un po' cinico: dove può pensare di andare IllumOS od OpenIndiana o Nexenta e ogni altra distro ex-OpenSolaris based?
Anni fa, stufo dei primi linux 2.6 tornai a FreeBSD che avevo abbandonato in favore dei primi linux 2.4 per il troppo ridotto supporto hw, un po' di cose erano cambiate, la FreeBSD 6 e poi 7 erano assai più avanti di FreeBSD 4 e rispetto a GNU/Linux si andava assai meglio. Di acqua ne è passata sotto i ponti, stanco di scelte non troppo gestibili di FreeBSD (fare qualcosa come SourceJuicer o cmq fare una fottuta struttura di pkg binari ragionevolmente in sync coi port no eh!?) mi buttai su Solaris prima, su SXCE poi ed infine su Indiana. Oggi FreeBSD con la 9 non è significativamente migliorata come fece dalla 4 alla 5 e le scelte di cui mi lamentavo sempre lì sono; intanto GNU/Linux si scosta sempre di più, GNome tanto per dirne una vuole eliminare tutti i port non GNU/Linux, troppo faticoso mantenerli, idem KDE, idem persino parti del team X.Org (Mesa, ad esempio). Ora Linux è un pessimo kernel se lo paragoniamo ad IllumOS, IllumOS ha lo zfs, ha dtrace, ha le zones, l'smf ecc. ma *non ha* abbastanza sviluppatori per potersi evolvere e per poter avere una pletora di produttori interessati a supportarlo. GNU/Linux sfonda ma è un'ammasso di codice sempre meno evolvibile, è certo messo assai meglio di OSX od Windows ma è pursempre su una via assai poco carina. In altri termini gli UNIX classici che sino a poco fa grazie alla SUN potevano tornare a vivere in gloria sono in via di estinzione. Sono per tanti aspetti superiori ad ogni altro OS sulla piazza ma non sono a quanto pare in grado di adattarsi e Darwin non perdona... Non perdonò le vecchie Alpha, non perdonò IriX ed ora cala la scure anche sulla ex-SUN... Ritengo sia tempo di un UNIX 2.0 che riproponga la rivoluzione di UNIX al passo coi tempi: la struttura di "UNIX 1.0" era caratterizzata dalla facilità di scrittura del software, il C rispetto all'assembly è come oggi il Python rispetto al C, da una facilità di integrazione di ogni applicazione grazie a delle ottime IPC ecc. Oggi queste IPC sono comode ma non bastano, il C è quello che allora era l'assembly, troppo di basso livello per permettere tempi di sviluppo e gestibilità umane a progetti complessi come i moderni sistemi operativi; non c'è più la facilità di scrivere software anche perché non c'è più l'integrazione di un tempo: nei primi UNIX la libreria standard del C era sufficiente alla maggior parte dei compiti ed il resto era codice personale; oggi servono n-mila librerie ognuna fatta a modo suo, documentata a modo suo, con suoi tipi di dato, sue convenzioni di sviluppo ecc. Un buon esempio è stato detto da Miguel de Icazia tempo fa, non si può scrivere qualcosa del tipo: import imagemagick import gtk magic_wand_btn = gtk.button() magic_wand_btn.bind(imagemagick.selection.fuzzy) Un tempo, per le necessità di un tempo un #include e un po' di codice lo permettevano... Questo manca, questo porta a n-mila altri problemi incluso lo sviluppo di mostri che su altri mostri si reggono, di torri di Babele sempre più stratificate da cui i piccoli "appassionati di codice" scappano; pensate a sage solo come esempio, un bel cas, del tutto impossibile da gestire con n-mila backend n-mila problemi d'uso e una dimensione enorme. Sogno, e per ora mi limito a quello uno UNIX reimplementato in Python o un linguaggio simile (al GSoC è iniziato lo sviluppo di un fe a gcc per il Python) dove sia prassi standard scrivere software con un core in un package, una UI che usa tale core in un altro e ogni software possa import-are classi e quant'altro dai vari core disponibili... Mi sa che anche Java degli albori sognava una cosa di simile, distribuita in rete ecc. e non è finita molto bene... -- Kim Allamandola _______________________________________________ ug-itlosug mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/ug-itlosug
