Macromedia rilascia Flash Player 7 per Linux

Anche le librerie che gestiscono i vari livelli citati, in AmigaOS, offrono una caterva di primitive, ma più si sale di livello, più sono presenti funzioni avanzate/complesse, tanto che Intuition, che sta alla base della/e GUI, offre anche un sistema object-oriented per gli oggetti grafici. Il fatto di integrare tutte queste funzionalità a questi livelli, anziché delegarne una parte a quelli più alti, costituisce un innegabile vantaggio: è presente una piattaforma unica e omogenea per gestire tutto, e i livelli successivi (che implementano GUI e altre funzionalità diventano più snelli e anche più facile da scrivere/gestire.
Chi scrive delle GUI/toolkit aggiuntivi (rispetto a quelli di sistema offerti da Intuition), si trova un sacco di lavoro già fatto, e si può occupare dei dettagli che più gli interessano (un'interfaccia migliore con l'utente).
Oltre a ciò, con questo modello si minimizzano i possibili problemi: generalmente si verificano nei livelli superiori, ma nel caso in cui si dovessero trovare in quelli inferiori, fixandoli tutte le GUI e toolkit lo sarebbero di conseguenza.

Di GUI/toolkit per Amiga posso garantirti che ne esistono tantissimi, pur essendo AmigaOS un s.o. proprietario e chiuso (ma enormemente modulare: in teoria si può cambiare qualunque funzione/funzionalità di sistema, e in tempo reale!). MUI è quella che ha fatto storia, in quanto ha offerto fin dall'inizio un look & feel straordinario. Eppure è basata interamente sugli oggetti di sistema.

Non seguo il mondo di Linux, quindi non conosco i problemi di XFree: mi spiace, ma non riesco a capire a cosa ti riferisca.

Quanto ad AmigaOS, forse anche tu non l'hai conosciuto abbastanza: è un s.o. per il quale, pur essendo chiuso, sono state sviluppate migliaia di applicazioni, fra le più disparate. Di certo non mancava la pluralità di voci da te citate, ma il tutto si svolgeva secondo le regole del gioco (quelle fissate dalla Commodore).
Tant'è che, ripeto, non ho visto ancora nessun s.o., anche open source, dotato dell'enorme flessibilità e modularità di AmigaOS: cambiare al volo lo scheduler di sistema, le routine di allocazione della memoria, di creazione dei processi, ecc. ecc. sono solo degli esempi di ciò che si poteva realizzare con questo stupendo s.o...

Dimenticavo: programmare con le primitive offerte da AmigaOS, a qualunque livello, non era da panico, ma da urlo...

x xeal: hai centrato perfettamente il nocciolo del problema!

Credo che con opportune librerie di wrapping si potrebbero risolvere anche problemi di compatibilità che a volte sento dire si verificano (ok, si tratterà di casi sporadici, per le applicazioni più importanti/migliori si fa sempre il porting ecc.) con release diverse del kernel, per cui occorre riscrivere o ricompilare il programma, magari con versioni diverse del compilatore, perchè quella più vecchia linka il programma a librerie vecchie che potrebbero aver cambiato nome e/o funzioni.

Per chi me lo chiedesse: non mi vengono in mente esempi specifici, però mi pare di aver letto qualcosa al riguardo anche tra i commenti di vecchie notizie. Sono d'accordo che la natura stessa di Linux porta a cambiamenti anche radicali in tempi brevi, però la ricerca dell'innovazione più spinta accompagnata da un occhio di riguardo alla retrocompatibilità potrebbe essere una strada interessante da seguire e una sfida in più, no? In fondo, in molti casi tutto potrebbe ridursi al mantenimento nelle librerie di vecchie funzioni, dichiarate in modo identico, che non fanno altro che chiamare le nuove con i parametri opportuni.

x cdimauro: non so praticamente niente di AmigaOS, però da come lo descrivi sembra veramente un OS con i cosiddetti . P.S. Come t'è andato l'esame?

Ciao

Anche AmigaOS è interamente basato sul concetto di libreria condivisa, e perfino tutte le funzioni del kernel (Exec) risiedono nell'apposita libreria (exec.library ). Dalla versione 1.0. alla 3.x sono state aggiunte tantissime nuove funzionalità a qualunque libreria, ma la compatibilità all'indietro è sempre stata garantita. Ovviamente alcune funzioni sono state dichiarate obsolete col passare del tempo, ma hanno sempre continuato a funzionare; anche per altre che hanno aggiunto nuovi flag, stesso discorso.

AmigaOS è un s.o. veramente fantastico, che IMHO ha fatto storia (e per me continuerà a farla, visti i problemi che saltano fuori con gli altri). Secondo me, tempo permettendo, sarebbe una bella esperienza vedere com'è strutturato, quali sono le funzionalità che offre e in che modo. Inoltre era così semplice da programmare, che utilizzavo quasi sempre l'assembly per qualunque tipo di programma: dall'applicativo "DOS" (command line), a quello interamente grafico...

P.S. L'esame è andato bene. Ormai mi manca soltanto calcolo numerico: fra 9 giorni c'è lo scritto. Spero che fili tutto liscio...

hai appena reinventato i ToolKit per X (gtk, qt, fltk, fox)...

Nope, quando la compatibilita` viene interrotta di solito il cambio e` troppo radicale per essere compensato con un wrapper. Mi viene in mente il cambio di ABI di gcc.



Se nessuno lo fa, e` perche` nessuno ne sente il bisogno



Ove e` ragionevole (e richiesto) lo si fa di gia...
Questo e` l'opensource: se c'e` abbastanza richiesta (e soldi/tempo/abilita`), si fa, altrimenti un'altra voce nel mucchio delle Cose Carine da Fare...

io andrei oltre, delegando anche la veste grafica al toolkit, in modo tale che:
1) TUTTE le applicazioni venissero portate a condividere lo stile grafico a livello dei widget, con maggiore omogeneità

2) il WM avrebbe il solo scopo di presentare il desktop ed eventualmente barra delle applicazioni e "systray", un "crash del wm influenzerebbe solo lo sfondo del desktop corrente

ora, cdimauro se nota questo post ricorderà che il primo concetto era presente in amigaos... di cui era una delle mie caratteristche preferite

@ xeal: http://en.wikipedia.org/wiki/AmigaOS

datatypes, autoconfig, arexx...

La veste grafica (widget, stile) e` gia quasi completamente a carico del toolkit...



Nel mondo opensource e` praticamente impossibile...


Il pannello (con relativo systray) e/o il dock/systray e il WM sono gia` programmi separati in tutti i DE che conosco (KDE, xfce, GNOME)

Allora perchè saltano fuori problemi del tipo "qesta applicazione mi fa fare il drag and drop correttamente con KDE ma non con Gnome"?

Evidentemente i WM hanno qualche libertà di troppo. Quello che dico è: non potrebbe avere senso creare uno standard unico che tutti si impegnino a rispettare sempre e comunque, mantenendo la libertà di creare standard alternativi, purchè sia garantita la compatibilità con lo standard di base su quei sistemi/distro/varianti/chi_più_ne_ha_più_ne_metta (il bello dell'open source, no?) che non supportino quell'implementazione alternativa, bensì lo standard di base + eventualmente altre implementazioni alternative?

Penso a qualcosa di simile alla ridondanza di codice che i compilatori producono per implementare ottimizzazioni relative a particolari SIMD, mantenendo sezioni equivalenti ed alternative da far girare su macchine che non abbiano quelle simd, basate su istruzioni generiche e standard.

Non voglio reinventare i toolkit, penso al massimo alla possibilità/opportunità di riprogettarli (se necessario) e spingere verso una [i]forte e decisa standardizzazione di base[/i], che garantisca omogeneità e allo stesso tempo non soffochi la pluralità mediante il meccanismo della "ridondanza" delle implementazioni (standard + alternativa).





Beh, si può sempre tentare: ho cambiato il nome e/o i parametri di alcune funzioni? dichiaro una funzione identica che chiama una o più funzioni nuove per effettuare quel compito. ho cambiato il nome e il contenuto di una/più libreria/e? ne scrivo una con lo stesso nome e le stesse funzioni che a loro volta richiamano altre librerie, con la nuova implementazione.

In fondo, la modifica delle api del sistema operativo dovrebbero consistere in delle migliorie al modo di fare determinate cose, cambiando anche radicalmente il modo in cui si fanno, ma sempre quelle stesse cose deve fare, no? Al limite possono essere aggiunte nuove funzionalità, oppure essere posti limiti alla libertà di un programma. Mi viene da pensare, ad esempio, alla gestione del multiprocessing/mutlithreading: potrebbe essere limitata, ad esempio, la possibilità di impostare la priorità dei sottoprocessi per non interferire con la nuova implementazione, più rigida, dello scheduler, però un modo, volendo, si può sempre trovare.

Ovviamente possono esserci dei casi in cui la compatibilità non può essere mantenuta (salvo prefissarlo come obbiettivo primario nella progettazione delle release successive), però un tentativo, secondo me, si può, e si dovrebbe, comunque fare. Ma io mi spingerei anche oltre: laddove sia previsto/possibile il riconoscimento immediato di un programma che utilizzi vecchie api, come nel caso di applicazioni compilate con una vecchia versione di gcc, nel qual caso mi pare di aver capito che l'esecuzione viene bloccata immediatamente, si potrebbe introdurre un tool, una sorta di JIT, che analizza gli import del programma, ed eventualmente il resto del codice per le funzionalità del s.o. che vengono espletate anche mediante programmi e pipe, per individuare quelle funzioni per le quali non è stato possibile/non si è riusciti in tempo a mantenere la compatibilità, generando magari un file da associare al programma con l'esito del controllo per non doverlo ripetere. Credo che una cura particolare a dettagli come questi possa giovare molto a Linux.





Ok, però io credo che si debba tener conto anche di fattori esterni, oltre che della spinta interna alla comunità open source.

Personalmente non avrei grossi problemi a digitare "kill id_processo 9" (spero che la sintassi sia corretta) per spezzare le gambine con uno spadone cimmerico ad un processo che mi rompe le scatole, come non ne avrei a digitare "taskkill id_processo /F" dal prompt dei comandi di windows (di solito uso il task manager). Non tutti però trovano semplice usare un'interfaccia a linea di comando, come non tutti hanno la capacità di ricompilare il kernel quando serve. Ma, essendo composta l'utenza di linux in gran parte da persone che non hanno problemi a interagire con il s.o. anche attraverso i canali meno user-friendly, se si tenesse conto solo dei bisogni/richieste dei soli utenti probabilmente non riuscirebbe mai ad attirare l'attenzione di chi magari potrebbe gradire dei meccanismi più semplici per usare/configurare il sistema.

Molto è stato fatto in questa direzione, molto si può ancora fare (si può sempre migliorare, nella vita vale per tutto), e ciò forse vuol dire che può aver senso muoversi in direzioni che non corrispondano esattamente alle immediate necessità della comunità di linux.

Personalmente ritengo che, accanto alla ricerca di interfacce grafiche sempre più user friendly e all'apertura, perchè no, al "doppio click selvaggio", possa giovare, al fine di favorire la diffusione di linux, anche prestare una particolare attenzione ad aspetti come una standardizzazione di base sempre più accentuata, la quale lasci comunque sopravvivere la pluralità che è il cuore di linux e dell'open source in genere, e una ricerca più spinta di compatibilità (anche retrocompatibilità a 360° e di omogeneità (di comportamento delle applicazioni, ecc.) tra le varie distribuzioni.

So che avrebbe poco senso installare due diverse distribuzioni contemporaneamente, soprattutto per un newbie (un esperto potrebbe volerle confrontare e creare due diverse partizioni bootabili), però potrebbe capitare che il newbie, approdato a linux su consiglio di un amico, potrebbe voler provare, sempre su consiglio di un amico più esperto, un programma, che però usa un meccanismo di installazione che, diavolo a farlo apposta, crea dei problemi con la sua distro, anche risolvibili in qualche modo con una conoscenza più approfondita del sistema; oppure il nostro newbie potrebbe decidere di installare due distro diverse su due macchine diverse (magari un desktop e un portatile), perchè ha cominciato a usare linux su una delle due macchine, si è trovato bene, ha cominciato ad appassionarsi, e, sempre su consiglio di un amico, ha deciso di provare un'altra distro, o per provare a cimentarsi con qualcosa di più complicato e "professionale", o per provare qualcosa di più semplice e intuitivo, e malauguratamente si trova ad avere qualche problema di troppo a usare gli stessi programmi sulle due macchine, oppure su una riesce a configurare tutto l'hardware mentre sull'altra ha problemi con qualche periferica, pur esistendo dei driver compatibili, perchè la distro in questione non comprende proprio quei driver (comunque ottenibili grazie all'opera della comunità e lui non è ancora in grado di procurarseli autonomamente tramite i molteplici canali che comunque il mondo di linux gli mette a disposizione (so che in questi casi spesso la colpa è dei produttori di hw, però voglio focalizzare la mia attenzione su una eventuale differenza tre due distribuzioni: una si è preoccupata di inserire anche i driver, diciamo, dell'ultim'ora, l'altra no).

Risultato: c'è il rischio di alimentare le "dicerie" sulla (reale o presunta) eccessiva frammentarietà/difficoltà d'uso di linux, "dicerie" in alcuni casi, e per certi aspetti, fondate, in altri più simili a leggende metropolitane che alla realtà, ma in ogni caso, IMHO, dannose all'immagine di linux. Se una maggiore attenzione alla compatibilità, alla standardizzazione e all'omogeneità, accanto alla pluralità, potesse favorire una maggiore diffusione di Linux, allora potrebbe valere la pena di percorrere strade non immediatamente corrispondenti alle richieste interne, e di valutare diversamente le Cose Carine da Fare... In fondo da una maggiore diffusione di sistemi operativi alternativi a windows, in tutti i campi, gioverebbe a tutti, anche ai "fedelissimi" di Windows. Certo che la disponibilità materiale di risorse, non solo economiche, può costituire un vincolo decisivo al di la di tutta la buona volontà di questo mondo, però di solito tentare non nuoce (se uno poi si mette in testa di essere ignifugo il discorso cambia )

Ciao.