Macromedia rilascia Flash Player 7 per Linux

Ce ne sono, sono i toolkit.
Il problema, secondo me, andrebbe affrontato con una riscrittura (con futura eradicazione) delle xlib, che cominciano a soffrire del tempo.
Soluzioni alternative stanno nascendo (dai una occhiata ad es. a www.y-windows.org ) ma hanno il problema di fondo di non fornire librerie di compatibilità con le xlib, rendendo di fatto impossibile riutilizzare tutte le applicazioni esistenti e impedendo qundi sul nascere la loro diffusione. La grossa fortuna delle xlib è la disponibilità enorme di software, e l'alta portabilità (l'interfaccia xlib su xfree o altri server x è la _stessa_, e io posso usare le xlib del _mio_ computer linux/x86 per "parlare" con il server X di un computer su cui gira Solaris/Sparc, ad esempio). Il fatto che siano complicate non preoccupa nessuno: nessuno è così pazzo da sviluppare direttamente con le xlib. Anche l'introduzione di un layer superiore più "semplice" non è una soluzione, visto che non porta vantaggi rispetto ai toolkit (che quindi non sostituirebbe).
La standardizzazione dei DE è un altro argomento, e potrebbe benissimo essere affrontato anche a livello di protocollo X/xlib, in modo da essere la più generale possibile.

La "soluzione" è semplicemente non reinventarsi la ruota, quando non serve.
Un protocollo standard (xdnd) c'è? Sì, allora perché invertarsene un altro?

Un breve riassunto...

Un paio di mesi fa, poco prima dell'uscita dell'ultima versione stabile di xfree, il copyright holder di xfree, David Dawes, decise di modificare la licenza del programma inserendo alcune clausole. Non voglio qui sindacare come questa decisione fu intrapresa e se fosse giusta o meno; ti basti sapere che molte persone (anche famose, come Alan Cox) che avevano contribuito in un modo o nell'altro al progetto non furono minimamente consultate.
Fatto sta, la nuova licenza fu dichiarata incompatibile con la gpl. In soldoni, questo implica che un programma gpl non può essere linkato con librerie con licenze non compatibili. Anche qui, non voglio sindacare se sia stato corretto o meno. Quello che mi interessa sono le conseguenze.
Nonostante una apparente apertura al dialogo per affrontare il problema, e nonostante le distribuzioni siano scappate (e stiano scappando) in massa dall'ultima vesione di xfree, David Dawes (persona che ha sicuramente grandi meriti, ma con la quale per via del suo carattere preferirei benissimo non avere mai a che fare) non fece una virgola per conciliare le necessità delle diverse parti.
Non è la prima volta che accade una cosa del genere, soprattutto per programmi che hanno licenze cosiddette "bsd-like", quindi non sarebbe stato un dramma. Ma a differenza di altri casi, non ci sono molte valide alternative per xfree al momento, e ciò causò problemi non da poco. Alcune distro hanno ripiegato su versioni di xfree antecedenti al cambio licenza - soluzione ovviamente temporanea - , altre hanno adottato x.org, che nel frattempo era stato aggiornato con le ultime modifiche di xfree pre-cambio licenza effettuando in effetti una specie di fork (staremo a vedere quanto sono bravi quelli di x.org a portarne avanti lo sviluppo).
Il succo è: se in un dato campo non ci sono valide alternative ad una unica soluzione, c'è una debolezza. Soprattutto se in giro ci sono mine vaganti come David Dawes.

necessiterei delucidazioni spiegazioni sulle licenze bsd like e sui loro problemi
per adesso ho dato un' occhiata alla gpl (e notavo che ha un "enforcement" sulla proprietà intellettuale di un programma.. nel senso che l' autore originario del programma, deve essere sempre citato da tutti i "successivi" - quelli che apportano modifiche -, e per il modo in cui la licenza si dovrebbe propagare dal programma originario ai prodotti "derivati", in modo da ampliare la conoscenza .. )
ora, sulla bsd license ne ho letto poco, tranne che , se non erro, porrebbe meno restrizioni nei confronti dei lavori derivativi...

IMHO too



Certo, e` utile. Ma richiede una certa evoluzione e maturita` nel campo per nascere spontaneamente, per essere sentita come esigenza. Non essendoci un'autorita` centrale che impone, questo e` praticamente l'unico modo per avere degli standad: sentirne comunemente l'esigenza. Ma per questo, appunto, ci vuole tempo.



Dunque, personalmente conosco pochi e circoscritti casi in cui il cambio di ABI del gcc ha creato problemi: i moduli binary-only del kernel.
In questi casi c'e` poco da fare, e un'idea del genere IMHO sarebbe semplicemente inattuabile.
In questo caso, IMHO, vengono impietosamente mostrate tutte le debolezze di una soluzione "a-la-windows" (modulo binary only e arrivederci e grazie) fuori
da windows stesso.
Senza voler divulgare le specifiche (mah) una soluzione accettabile potrebbe essere quella di nvidia, ovvero fornire un core binary-only e un'interfaccia da ricompilare, per risolvere questi problemi.

Comunque, ove possibile, l'approccio nativo sarebbe sempre preferibile.



No no mi sono espresso male. Non volevo muoverti alcuna critica in questo senso: questa discussione e` anni luce migliore delle solite sterili flame in cui arriva qualcuno, spara a volonta` ad alzo zero e si parte col napalm.

Volevo intendere, al contrario, che diversamente dal mondo windows, dove o si fa come dice microsoft o si fa come dice microsoft, qui chiunque puo` cambiare in modo significativo le cose: basta avere un'idea tecnicamente valida, metter mano al codice (vedi alla voce patch ) e avere la forza di sostenere la propria posizione di fronte alle prevedibili critiche.

Se la cosa e` buona, i risultati vengono, garantito.
Solo che questa possibilita` mi pare largamente ignorata per non meglio specificati motivi...

Non hanno normalmente problemi, tranne la licenza bsd originale (ormai in disuso da tempo):
http://www.fsf.org/philosophy/bsd.html

Non è quello il punto; la licenza gpl sancisce precisi doveri a chi "campa" (modifica e ridistribuisce) del lavoro degli altri.
Ad alcuni non piace questa licenza; a me, da "sviluppatore" che spesso uso il "lavoro degli altri" distribuito sotto gpl, sembra una buona cosa. In sintesi, mi obbliga a fornire a chi usa il mio lavoro gli stessi diritti che ho ricevuto utilizzando il lavoro di altri (_se_ il mio lavoro è basato sul lavoro di altri). Mi sembra ragionevole (e anche logico), ma taluni sono riusciti a chiamarla "virus".

x ilsensine: grazie per le informazioni. A questo punto, però, visti i problemi avuti con la recente versione di XFree, non sarebbe il caso di puntare su una nuova soluzione, scritta secondo le ipotesi avanzate sopra? Tanto più che alternative non ce ne sono, visto il cambio di licenza, e certamente continuare a usare versioni di XFree pre-cambio licenza non è una strada percorribile all'infinito...

x Ikitt_Claw: le debolezze dei moduli "binary-only" riguardano, però, solamente Linux, perché sono legate alla filosofia su cui si basa ("source-only". In altri sistemi, Windows incluso, ciò non è detto che si verifichi...

E' per questo che parlo della necessità di fissare delle regole: regole che dovrebbero consistere in una sorta di "contratto con il passato", al fine di garantire continuità e garantire l'innovazione.

Sarebbe un compromesso che magari rallenterebbe un po' lo sviluppo di soluzioni alternative allo standard, ma sarebbe indubbiamente utile, e poi il grosso del lavoro sarebbe da fare all'inizio, progettando le variazioni rispetto allo standard in modo da poter garantire compatibilità, dopo, ad ogni cambiamento della propria implementazione, si tratterebbe di rimappare le nuove funzioni sulle vecchie, le quali garantivano compatibilità con lo standard.






E allora riferiamo il ragionamento ai toolkit, anzi estendiamolo a tutto quello che potrebbe trarre giovamento da una standardizzazione oculata che lasciasse ampio spazio all'innovazione anche più radicale, previa stipula e rispetto di questo "contratto con il passato".






Sono d'accordo, però in un certo senso sarebbe un po' come stravolgere, o almeno limitare, la filosofia di linux.

Come (mi pare) tu stesso hai scritto altrove (non vorrei sbagliare, ma tuttosommato non ha importanza), in linux, per sua stessa natura, può esistere uno standard (affiancato ad altri standard), non lo standard (in senso assoluto), poichè ci sarà sempre quqlcuno che vorrà cambiare le cose, o perchè ha avuto la geniale idea di sostituire la ruota di legno con una in gomma riempita d'aria, o semplicemente perchè vuole fare le cose a modo proprio.

Fissando le regole per poter innovare garantendo retrocompatibilità con lo standard di base accettato da tutti dovrebbe poter consentire di salvare capra e cavoli.

Ovvio che ci vorrà del tempo, però, come ho già detto, l'importante è cominciare e avere la volontà di andare avanti in questa direzione





In quel caso si può solo filtrare e cercare di non lasciarsi trascinare
Il tifo da stadio esisterà sempre, solo che c'è modo e modo di sostenere la propria "squadra". Entro certi limiti, tra amici può essere anche piacevole "scannarsi" allegramente durante una partita (facendo gli sboroni quando vinci ), però qui spesso si superano i limiti. Il tifoso sfegatato ci può stare, l'ultra, che lancia uno scuter dagli spalti o fa il tiro al bersaglio contro i giocatori, e se ne va in giro armato, magari di bazooka (mi viene in mente un film di Boldi, tifoso milanista costretto a fingersi romanista per aver dato un passaggio a due personcine non proprio a modo , ma non ricordo il titolo), quello proprio no!

Ciao

In teoria è giusto, peccato però che si affidi molto all'onestà di chi riceve i sorgenti, perchè un plagio, in questo settore, è tanto semplice da fare quanto difficile da dimostrare, se non ricordo male in termini giuridici si parla di identicità dei sorgenti, per cui basta cambiare i nomi delle variabili, delle funzioni, modificare qualche ciclo e praticamente il gioco è fatto. Lo fanno spesso le software house per riciclare il proprio stesso codice, a volte sottobanco, come quando producono una certa applicazione su commissione e contrattualmente (situazione comunque rara) la proprietà del sorgente va attribuita al committente.

Se chi ottiene i sorgenti di un tuo programma lo plagia "bene" e lo spaccia per una sua creazione, può farti una concorrenza sleale e spietata, non avendo sostenuto i tuoi stessi costi di sviluppo (ovviamente mi riferisco a software open source ma non freeware). Ogni medaglia ha sempre due facce e purtroppo non sempre sono entrambe positive. Ma questo è un discorso complesso nel quale non voglio addentrarmi più di tanto.

Vorrei però capire una cosa, possibilmente senza dovermi "spulciare" tutto il testo della gpl/lgpl: se decidi di vendere il tuo programma, con licenza gpl, e io modifico e ridistribuisco, sempre a pagamento, il tuo programma, sono obbligato dalla gpl stessa (o eventualmente puoi obbligarmi tu mediante una specifica integrazione) a darti una parte dei miei profitti, oppure in teoria potrei anche distribuire la mia versione gratuitamente? Altra cosa: com'è possibile creare un ibrido binary core - interfaccia open source tipo i driver nvidia, se un programma che sfrutta del codice coperto da gpl diviene automaticamente gpl? E demandare parte del lavoro ad una libreria condivisa equivale a integrarne il codice? se si, come fa un programma binary-only a interfacciarsi col sistema? Grazie in anticipo

Ciao