Macromedia rilascia Flash Player 7 per Linux

Perche` i due DE usano
1) ToolKit (GTK vs QT)
2) librerie di supporto (gnomelibs vs kdelibs)
3) IPC (orbit/corba vs kparts)
diverse



Lo stanno facendo, vedi freedesktop.org. Ma non e` un processo ne` facile ne` veloce, sopratutto dato che bisogna conciliare esigenze diverse, idee diverse, sviluppatori diversi e tener conto dell'evoluzione di due DE radicalmente diversi.



Riprogettarli e` un lavoro enorme, comporta la riscrittura quasi totale e anche di quello che ci sta sopra. Non e` un lavoro da nulla.



Ripeto: stanno andando in quella direzione, inevitabili litigi a parte.
Semplicemente, tutto il comparto Desktop/GUI avanzata e` molto giovane sotto *nix (episodi tipo CDE a parte), ha circa 8-10 anni (da zero a GNOME, voglio dire). E` ovvio che le cose siano meno mature rispetto al mondo windows/mac.



GNOME garantisce una cosa di questo tipo per alcune (tutte?) le API deprecate,
ma non sempre e` possibile.



Ni. Sempre (anche) a causa della gioventu` del complesso, a volte ci sono stravolgimenti anche grossi tra una major release e l'altra.
Sto pensando al cambio radicale del modo di funzionamento di alcuni widget (listview e treeview se ben ricordo) tra gtk 1.x e 2.x.
In questi casi e` molto, molto arduo preservare la compatibilita` all'indietro.



Si, certo. Ma tieni comunque conto che il monfo F/OSS e` necessariamente piu` dinamico di quello closed; la spinta al cambiamento/adattamento fa parte del gioco.


No, semplicemente e` un'ABI diversa.


Oddio, teoricamente e` interessante ma in pratica mi sembra un po` un'overkill...



Beh che questi fattori esterni facciano sentire la loro voce, molto semplicemente.
Perfettamente inutile lamentarsi e basta, e` provato sul campo. Anzi, fa solo irritare gli sviluppatori, se fa qualcosa



Onestamente, con tutto quest'ultimo discorso non ho capito bene dove volevi
andare a parare...

Francamente non vedo per quale motivo non sia sempre possibile mantenere la compatibilità all'indietro. Ripeto: dalla versione 1.0 dell'AmigaOS alla 3.9 sono state introdotte tante e tali migliorie (quelle che citava il buon Jappilas ne sono soltanto un esempio ) che elencarle qui significherebbe intasare il forum (ad esempio: dalla versione 2.0 sono stati introdotti anche i componenti object oriented per le GUI).

Eppure TUTTI i programmi che sono stati scritti rispettando le linee guida rilasciate dalla Commodore ai programmatori, hanno sempre funzionato alla perfezione anche nelle versioni successive del s.o...

Non posso credere che se i componenti listview e treeview hanno bisogno di nuove funzionalità non li si possa modificare preservando la compatibilità: forse è troppo comodo pensare di buttare via tutto e riscrivere, fregandosene del passato. Probabilmente è una questione di mentalità della comunità open source (= aggiornamento continuo). Che non condivido assolutamente.

Dimenticavo: date un'occhiata al link gentilmente fornito da jappilas e guardate quante cose sono state introdotte con le varie versioni di AmigaOS, oltre a dare un'idea di come funzionava il s.o...

P.S. Non sapevo che avesse influenzato la creazione di una versione di BSD... Amiga Power!

Non conosco gli internals abbastanza da darti riferimenti precisi.

Comunque, tecnicamente, la cosa ha senso e non credo affatto sia solo una questione di mentalita`, che pure indubitabilmente influisce, a volte parecchio, forse troppo (i cambiamenti di ABI in gcc, sebbene giustificati, ad esempio sono stati un po` troppo frequenti nel recente passato...).

In ogni caso, un punto sottovalutato e` che la comunita` la fanno gli utenti. Se per poche (o nessuna) persona all'interno della medesima
problemi come questi non sono sentiti, nessuno prendera` provvedimenti.
La soluzione, se questi accorgimenti interessano, e` entrare a far parte e far valere le proprie ragioni con argomentazioni tecniche.
In questo caso, come la storia dimostra, qualcosa si smuove sempre.

Guarda, oggettivamente è difficile cercare di far cambiare mentalità a chi è abituato da troppo tempo a pensare e agire in un certo modo. Specialmente nel mondo open source, la libertà è diventata un'arma "di difesa", in tal senso.

Una società come Commodore, invece, era praticamente obbligata a fornire compatibilità col passato. Ha fatto degli enormi cambiamenti, che le sono costati molto in termini di tempo e risorse impiegate, ma a tutto vantaggio della comunità...

Non so: mi sembra quasi un'utopia pensare che le esigenze (di libertà dei programmatori open source e quelle della comunità beneficia dei loro prodotti possano convergere fino a questo punto...

Non ti credere. Vero e` che ci sono forti individualita`, ma vero e` anche che di fronte a dimostrazioni di bonta` comprovare da fatti (e da una certa popolarita` basata su questi) si possono avere sorprese.
Mi vengono in mente reiserfs nel 2.4.1, il supporto LVM, ma anche la svolta di GNOME2, la fine della querelle sulle QT col beneplacito di RMS in persona...

Non esiste e non può esistere una "API del wm", in quanto il wm è un programma che si occupa di gestire decorazioni ed eventi che non vengono gestiti da xfree. Il modo in cui deve funzionare è standard; le applicazioni non si devono curare del wm in esecuzione (non è neanche necessario usare un wm, anche se l'usabilità delle finestre lascerebbe un pò a desiderare). Le applicazioni non "parlano" _mai_ direttamente con il wm, ma solo con xfree/xlib.

I wm più avanzati (kde e gnome) offrono alcune funzionalità che vanno oltre il semplice lavoro di background del wm: questi sono detti de, desktop environment, ed in effetti in questo campo una vera standardizzazione non c'è, anche se si sta discutendo da diverso tempo eventuali soluzioni. Qui sì, c'è una mancanza, ma non tale da impedirmi di usare applicazioni gnome su kde.

Il succo è: puoi eseguire qualsiasi applicazione dentro qualsiasi window manager, e fintantoché l'applicazione non fa uso specifico di alcune caratteristiche di un particolare de (ad es. drag'n'drop di kde -- vorrei tanto sapere cosa c'è che non va nel xdnd di xfree boh) non ti accorgerai della differenza.

Infine, le librerie che offrono astrazione rispetto le xlib ce ne sono in abbondanza, e sono sì differenti. Un male? No, non vedo perché. Tra l'altro anche la "concorrenza" (windows) funziona così: quanti toolkit esistono per windows? owl, mfc, vcl/clx, wxWidget...e chissà quanti altri!

Per la cronaca, mi è capitato tempo fa di usare un compilatore che generava applicazioni con un drag'n'drop non compatibile con le altre applicazioni di windows. Era anche un compilatore famoso (non ricordo se uno dei Borland oppure Optima), ma non ho gridato allo scandalo

Beh, allora stanno prendendo la direzione giusta, IMHO. Certo, può essere difficile, però l'importante è cominciare e metterci le migliori intenzioni




Se si fissasse uno standard e delle regole per innovare mantenendo compatibilità con lo standard si potrebbe cercare di salvare capra e cavoli... Credo che il meccanismo si possa estendere anche ad altri aspetti, non solo ai desktop environment. Credo che potrebbe giovare. Insomma, penso ad un meccanismo che produca un compromesso tra spinta innovativa e ancoramento a dei punti di riferimento.




Bhe, era solo un'idea, e poi non dovrebbe entrare in funzione sempre, ma solo al primo avvio di un'applicazione per la quale il sistema individua comunque una possibile incompatibilità, come quando (se non ho capito male) controlla la versione di gcc usata. Poi, registrando il risultato in un file, o assegnando un qualche attributo al programma (anche se in questo modo si andrebbe a toccare la gestione dei file, quindi sarebbe più complicato e più "lento", in termini di tempo di sviluppo, da implementare), si bypasserebbe il controllo. Si potrebbe anche pensare ad integrare questo meccanismo nell'installazione dei programmi, nel senso che il programma di installazione potrebbe verificare che il kernel sia uno di quelli per i quali è noto il corretto funzionamento, in caso contrario potrebbe richiamare questo tool per verificare se per le funzioni/utilità sfruttate dall'applicazione da installare sia stata garantita la retrocompatibilità, generando automaticamente il "flag" (lasciamelo chiamare così che avviserebbe il sistema di lasciar eseguire tranquillamente il programma. Comunque, ripeto, è solo un'idea.




Lungi da me volermi lamentare di qualcosa. Anche a volerlo fare, prima dovrei acquisire una competenza specifica che non ho e provare a metterci le mani, data la natura di linux...

Come ho scritto nel primo post, il mio intento è quello di confrontarmi per capire qualcosa in più e, contemporaneamente proporre una mia riflessione strettamente personale, o almeno provare a formularne una, su come si potrebbe cercare di migliorare un sistema già comunque molto valido.

Proprio tu (correggimi se sbaglio, non vorrei confonderi con qualcun altro adesso ) chiedi sempre delle proposte a chi critica linux "tout-court" (chiedo mercè per il mio francese ). Io non critico, propongo e basta . Spunti di riflessione, quanto meno, o almeno ci provo




Era solo una mezza battuta, fine a se stessa, per sdrammatizzare un po' dopo pagine di discorsi seri ("di solito tentare non nuoce...", nei limiti del buon senso )

Ciao

X ilsensine:

Diciamo che mi riferivo alle caratteristiche specifiche dei DE e alle librerie di astrazione delle primitive di xlib, in particolare per quanto riguarda l'utilizzo delle implementazioni alternative allo standard delle primitive eventualmente fatte da un DE e che si decidono di sfruttare.

Mi chiedevo semplicemente se non possa giovare (nel caso specifico a linux, ma in generale il discorso può valere per tutti i sistemi e per tutti i "settori" creare una libreria di interfaccia con le xlib (che poi demanda il demandabile al wm), visto che a quanto pare l'uso diretto delle xlib risulta complicato, standard, implementata dallo stesso sistema operativo o almeno presente in tutte le distro per comune volere, al fine di creare un punto di riferimento (non so come stiano effettivamente le cose, quindi mi muovo nel campo delle ipotesi).

Fatto questo, si possono sempre creare delle librerie alternative, che si appoggino sempre allo standard xlib e consentano ai programmi che ne fanno uso di integrare il codice che implementa le chiamate alle primitive di xlib (chiaramente mi riferisco a tutti quei casi in cui si usino delle librerie condivise che potrebbero non essere presenti sul sistema, non ha molto senso se parliamo di un linkaggio statico).

A questo punto si può anche garantire ai DE di allontanarsi dallo standard xlib, purchè sia fornita una implementazione conforme allo standard e un meccanismo per riconoscere la presenza del DE specifico sul sistema e, in caso contrario, poter rimappare le caratteristiche specifiche e alternative, mediante librerie (dinamiche) di wrapping, sullo standard (sempre presente), per garantire il corretto funzionamento di quelle applicazioni che sfruttino l'implementazione non standard.

Insomma, creiamo uno standard di base e fissiamo delle regole chiare e precise per poter innovare rispetto allo standard mantenedo compatibilità con esso. Non parlo di una standardizzazione che elimini le alternative, soffocando l'innovazione, ma di un meccanismo che garantisca l'omogeneità e la compatibilità e dia al contempo nuova linfa all'innovazione, inquadrandola in un contesto ben preciso e ancorandola a dei punti di riferimento in modo che ogni innovazione possa convivere "pacificamente" con tutto il resto.




Vedi il post di prima: non grido allo scandalo, dico solo che si può prendere spunto da "problemucci" come questo per riflettere su possibili soluzioni. E ne approfitto per confrontare le mie idee con quelle degli altri, possibilmente con qualcuno che conosce la situazione specifica meglio di me. In fondo, non è questo lo spirito del forum? (trolleggiamenti vari a parte ... per quelli possiamo solo filtrare...)

Ciao.

x Ikitt_Claw: lo spero per la comunità Linux/open source.

x ilsensine: Lavoro con i prodotti Borland da quasi 6 anni, ma non mi sono mai accorto di problemi del genere. Comunque, qualche bug può capitare a chiunque: basta, poi, fixarlo...