Link alla notizia: http://news.hwupgrade.it/12527.html

Meglio tardi che mai... con circa 6 mesi di ritardo sulla versione per Windows, Macromedia rilascia Flash Player 7 per Linux

Click sul link per visualizzare la notizia.

ottima notizia:) si intravede che il monopolio di winxx stà per vacillare:D

Se lo dici tu...

Ora speriamo in un'uscita su piattaforme Linux anche dei prodotti di Macromedia tipo Flash, Dreamweaver e Fireworks!!

Serve anche FreeHand, manca un vero programma di impaginazione professionale per il pinguino.

Speriamo anche che l'installazione sia meno problematica!
Ricordo di aver avuto difficoltà disumane per configurare il flash e farlo funzionare con Firefox.. Ho dovuto creare un milione di link simbolici e ogni volta che modificavo qualcosa smetteva di funzionare..
BYez!

Mi sembra una cosa piuttosto ovvia il fatto che il vento stia cambiando. I punti deboli di linux sono stati sempre la difficoltà di utilizzo, la mancanza di applicazioni professionali e la mancanza di driver.

Se il primo punto è alle strette il secondo e il terzo non lo sono. Ma se comincia il porting di applicazioni professionali su piattaforma linux allora anche i costruttori rilasceranno driver per questo sistema operativo

Purchè in comunità si decidano a creare uno standard di base per applicazioni e hardware, non si può incasinare tutto con ogni distribuzione che va per conto suo

Originariamente inviato da Crisidelm
Se lo dici tu...

Originariamente inviato da Super-Vegèta
Purchè in comunità si decidano a creare uno standard di base per applicazioni e hardware, non si può incasinare tutto con ogni distribuzione che va per conto suo

Spara qualche esempio.

Bè resta il fatto che la difficoltà di utilizzo, rapportata a windows, renda linux per quasi tutti gli utonti praticamente un'utopia, che quindi continuerà a limitarlo. E' anche vero che se linux dovesse diventare "facile" e "comune" come windows, sarebbe segno della sua caduta.

Un sistema di gestione dei pacchetti che va per conto suo in ogni distro? (per non parlare della gestione delle dipendenze!)...

Originariamente inviato da Ikitt_Claw
Spara qualche esempio.

Originariamente inviato da Super-Vegèta
Purchè in comunità si decidano a creare uno standard di base per applicazioni e hardware, non si può incasinare tutto con ogni distribuzione che va per conto suo
Se lo dici tu che hai tanta esperienza in materia... ;)

Perdonami ma non mi sembra di aver scambiato mai delle opinioni con te, tali da poter definire la reciproca esperienza. Quindi non so su quale base tu possa valutare la mia esperienza o non esperienza.

Non mi definisco Linus Trovalds ma certe cose sono ovvie a tutti quanti e difficilmente contestabili "alla prova dell'utente finale". Non porto avanti la bandiera di nessuno se non quella di ciò che è meglio per l'utente.

Poi ognuno è liberissimo di pensarla come vuole, tanto i fatti restano quelli che sono.


Originariamente inviato da ilsensine
Se lo dici tu che hai tanta esperienza in materia... ;)

Originariamente inviato da Super-Vegèta
Perdonami ma non mi sembra di aver scambiato mai delle opinioni con te, tali da poter definire la reciproca esperienza. Quindi non so su quale base tu possa valutare la mia esperienza o non esperienza.

Per lavoro programmo spesso (sia in kernel space che in user space) per dispositivi embedded, non basati su processori x86. Ovviamente questi dispositivi montano linux.
Credo di avere imparato qualcosa sugli standard su cui è basato.

Beh io mi diletto se così vogliamo dire su controller programmabili in codice macchina, anche se operano direttamente sulla gestione elettronica della componentistica elettronica e quindi non utilizzano purtroppo alcun linguaggio evoluto ;)

Per quel che ho detto prima basterebbe rileggere ciò che ho scritto prima in cui ho chiaramente parlato di maggiori uniformità per la gestione hardware e software. E ho parlato di linee generali non delle basi per la realizzazione di applicazioni (sbaglio o ci sono forti discordanze tra desktop diversi per le applicazioni ad interfaccia grafica?)

Nessuno può negare l'enorme diversità che c'è per ogni distribuzione. E non parlo del tool di turno che ti gestisce la sezione X, ma anche della semplicissima gestione dei pacchetti e delle dipendenze. Ognuno va per conto suo e chiaramente l'utente non esperto si confonde

All'utente finale non importano gli standard di base su cui creare i software per linux ) ma importa come gestire il suo sistema operativo

Originariamente inviato da Super-Vegèta
Per quel che ho detto prima basterebbe rileggere ciò che ho scritto prima in cui ho chiaramente parlato di maggiori uniformità per la gestione hardware e software.
Per la gestione sw uno standard diffuso c'è ed è l'rpm, ed è disponibile con strumenti più o meno sofisticati su parecchie distro.
Il vero problema che spesso limita il riciclo degli rpm da una distro all'altra è che sono in genere programmi _precompilati_: linux ha una eccezionale compatibilità a livello di codice _sorgente_, una buona compatibilità a livello di codice binario in c, una scarsa compatibilità a livello di codice binario c++, una pressocché nulla compatibilità a livello di _driver_ _binari_ (e questo è un _pregio_, non farmi spiegare i dettagli ma ci sono ;) )


E ho parlato di linee generali non delle basi per la realizzazione di applicazioni (sbaglio o ci sono forti discordanze tra desktop diversi per le applicazioni ad interfaccia grafica?)
Puoi benissimo usare le applicazioni per kde sotto gnome o IceWM. Non confondere il window manager (la "pelle" del tuo sistema grafico) con i programmi grafici.


Nessuno può negare l'enorme diversità che c'è per ogni distribuzione.
Io la nego. Dietro una distro linux c'è ben più che il programmuccio di turno per gestire i programmi installati o la configurazione di sistema.


All'utente finale non importano gli standard di base su cui creare i software per linux ) ma importa come gestire il suo sistema operativo
Una distro linux normalmente installa migliaia di programmi che non si pestano i piedi l'un l'altro. Non male, per un sistema che ha - come dici tu - così tanti problemi ;)

1) Per la gestione sw uno standard diffuso c'è ed è l'rpm, ed è disponibile con strumenti più o meno sofisticati su parecchie distro.
Il vero problema che spesso limita il riciclo degli rpm da una distro all'altra è che sono in genere programmi _precompilati_: linux ha una eccezionale compatibilità a livello di codice _sorgente_, una buona compatibilità a livello di codice binario in c, una scarsa compatibilità a livello di codice binario c++, una pressocché nulla compatibilità a livello di _driver_ _binari_ (e questo è un _pregio_, non farmi spiegare i dettagli ma ci sono ;) )

1) L'rpm è UNO STANDARD NON LO STANDARD. Ed appunto ti ritrovi RPM che da una red hat ad una mandrake non vogliono saperne di funzionare. Non tutte le distribuzioni lo usano e questo è un'handicap per Linux, sempre di fronte al neofita. Che poi il sistema debian di fronte ad rpm per scelta personale sia migliore ha ben poca importanza. Ma uno tra loro deve prevalere in senso assoluto e senza discordanze da una distro all'altra. Il pregio che vedi nella diversificazione per i driver binari NON LO E' per l'utente inesperto. Ma sarà l'utente inesperto che continuerà a far avanzare robaccia come XsPy a scapito di linux


2) Puoi benissimo usare le applicazioni per kde sotto gnome o IceWM. Non confondere il window manager (la "pelle" del tuo sistema grafico) con i programmi grafici.

2) Questa confusione io non l'ho assolutamente fatta. E allo stesso modo ci sono operazioni che da un desktop all'altro generano problemi. Tanto per dire tempo fa avevo provato un'applicazione cad per elettronica (se me la ricordo posto anche il nome) con cui c'erano disguidi sul drag & drop passando da KDE a Gnome. Sentito l'autore mi disse che dipendeva dalla diversa gestione di questo sistema da parte dei due desktop. Considerando l'enormità di desktop esistenti non vedo perchè non creare uno standard per una fesseria come questa tanto per dire (chissà quante altre ce ne sono)

3) Io la nego. Dietro una distro linux c'è ben più che il programmuccio di turno per gestire i programmi installati o la configurazione di sistema.

3) Sei solo o quasi nel negarla. E ancora minore importanza ha questa opinione di fronte a milioni di potenziali utilizzatori che non lo sono assolutamente. Sono loro a determinare vita e morte di un'OS.
A me non è mai piaciuto restringere linux ad una fetta microscopica di gente che lo sa usare mentre tutti gli altri si attaccano. Se uno vuole le cose in questi termini si installa una debian e tanti saluti.
Gli standard servono eccome. All'utente finale non importa cosa ha fatto il programmatore dietro, importano solo le cose semplici.


4) Una distro linux normalmente installa migliaia di programmi che non si pestano i piedi l'un l'altro. Non male, per un sistema che ha - come dici tu - così tanti problemi ;

4) Non si pestano i piedi per il semplice fatto che è un'OS ben fatto da questo punto di vista. I problemi Linux li ha. E' uno di questi (salvo la complessità) è proprio la diversificazione troppo spinta. La modularità se non viene opportunamente "circoscritta" entro gli standard diventa un punto debole.

Originariamente inviato da Super-Vegèta
Un sistema di gestione dei pacchetti che va per conto suo in ogni distro?

rpm e` standard lsb alla mano (a meno di cambiamenti della ultima ora)
Curiosita`, te quante distro usi alla volta?

(per non parlare della gestione delle dipendenze!)...
Qual'e` il problema?

PS: il top-quoting su un forum ancora mi mancava...

Originariamente inviato da Super-Vegèta
1) L'rpm è UNO STANDARD NON LO STANDARD.

Gia`...
http://www.linuxbase.org/modules.php?name=specrev&url=http://www.linuxbase.org/spec/booksets/LSB-Core/LSB-Core.html
Applications shall either be packaged in the RPM packaging format as
defined in this specification, or supply an installer which is LSB conforming (for
example, calls LSB commands and utilities).


Ed appunto ti ritrovi RPM che da una red hat ad una mandrake non vogliono saperne di funzionare. Non tutte le distribuzioni lo usano e questo è un'handicap per Linux, sempre di fronte al neofita.

E perche` il neofita dovrebbe usare 2+ distro contemporaneamente?


Considerando l'enormità di desktop esistenti non vedo perchè non creare uno standard per una fesseria come questa tanto per dire (chissà quante altre ce ne sono)

E infatti, vedasi freedesktop.org...

Sei solo o quasi nel negarla.


Infatti, non sono in molti che hanno ben chiaro cos'e` una distribuzione linux, forse qualcosa di piu` di un marchio, un nome e un po` di pacchetti.

E ancora minore importanza ha questa opinione di fronte a milioni di potenziali utilizzatori che non lo sono assolutamente. Sono loro a determinare vita e morte di un'OS.

Alla faccia, per dire, dei tizi di OpenBSD e FreeBSD. Sono morti e non lo sanno...


A me non è mai piaciuto restringere linux ad una fetta microscopica di gente che lo sa usare mentre tutti gli altri si attaccano.

E chi sarebbe che opera questa restrizione?


La modularità se non viene opportunamente "circoscritta" può essere anche un punto debole

Interessante punto di vista...

Originariamente inviato da Super-Vegèta
Non mi definisco Linus Trovalds ma certe cose sono ovvie a tutti quanti e difficilmente contestabili "alla prova dell'utente finale".

Mi domando spesso come mai cose cosi` tanto ovvie non siano ovvie per tutti...

Forse ti sfugge e anche ampiamente, il significato di ciò che ho affermato, ma soprattutto la RAGIONE per cui l'ho fatto. Ti rigiro la domanda.
Quante distribuzioni ci sono? Quanti sistemi di gestione pacchetti usano? Quanti utenti possono installarne una diversa dall'altra?

Te invece vieni a dirmi quante ne uso io sul mio pc per volta... o si è ciechi o non si vuol vedere non c'è nulla da fare. Mi pare più che sufficiente per determinare caos. Ce ne fosse una il problema non ci sarebbe neppure. Guardate l'utente FINALE E INESPERTO non chi conosce e sa usare linux.

Se si continuerà a pensare a linux in questi termini non sarà mai altro che un'OS di nicchia.

A me sembra puntualmente che CHI OSA criticare Linux nei suoi punti deboli debba sempre essere visto come chi non capisce un fischio (senza neppure sapere con chi si parla), di chi è a favore del monopolio ecc. Le cose sono un pò diverse. Questo si che è un bel punto debole di Linux e dell'open source in generale.


Originariamente inviato da Ikitt_Claw
rpm e` standard lsb alla mano (a meno di cambiamenti della ultima ora)
Curiosita`, te quante distro usi alla volta?


Qual'e` il problema?

PS: il top-quoting su un forum ancora mi mancava...

Forse perchè vivi su un pianeta in cui NON TUTTI si chiamano come te.

Beh è un grosso problema considerando il fatto che non siamo la maggioranza come definizione di gente che apprezza linux.

Se vuoi diffondere una cosa rendila alla portata di tutti.


Originariamente inviato da Ikitt_Claw
Mi domando spesso come mai cose cosi` tanto ovvie non siano ovvie per tutti...

Originariamente inviato da Super-Vegèta
Forse ti sfugge e anche ampiamente,

Ancora complimenti per il top-quoting.

Quante distribuzioni ci sono?

157 all'ultimo conteggio

Quanti sistemi di gestione pacchetti usano?

Almeno 5, ma sicuramente di piu`. Ogni distribuzione
ne usa uno alla volta.


Quanti utenti possono installarne una diversa dall'altra?

Non ho capito l'italiano.


Mi pare più che sufficiente per determinare caos.
A me no, sara` che uso linux da 4 anni e ci sono abituato.
Di quale caos lamenti?

Ce ne fosse una il problema non ci sarebbe neppure.
Una sola distro? Ok, quali abbiattiamo, perche`?


Se si continuerà a pensare a linux in questi termini non sarà mai altro che un'OS di nicchia.
Proponi, proponi pure alternative migliori


A me sembra puntualmente che CHI OSA criticare Linux nei suoi punti deboli

A me sembra puntualmente che chi critica linux manchi sistematicamente il punto e, sopratutto, lo faccia senza proporre migliorie.


debba sempre essere visto come chi non capisce un fischio (senza neppure sapere con chi si parla), di chi è a favore del monopolio ecc.
Su internet si e` quello che si scrive. Se si scrive senza argomentare, proporre, spiegare, ben che vada si passa da gente "che non capisce un fischio"

Questo si che è un bel punto debole di Linux e dell'open source in generale.

Proponi, proponi pure. Siamo tutt'orecchi.

Originariamente inviato da Super-Vegèta
Forse perchè vivi su un pianeta in cui NON TUTTI si chiamano come te.

Togli pure il "forse"


Se vuoi diffondere una cosa rendila alla portata di tutti.

Domanda: chi, e perche`, vuole diffondere linux?

Originariamente inviato da Super-Vegèta
1) L'rpm è UNO STANDARD NON LO STANDARD.
...e aggiungo io: PER FORTUNA che non è l'unico standard! Se non capisci questo, ti sfugge qualcosa su linux.
nb puoi installare rpm anche sotto debian

Tanto per dire tempo fa avevo provato un'applicazione cad per elettronica (se me la ricordo posto anche il nome) con cui c'erano disguidi sul drag & drop passando da KDE a Gnome. Sentito l'autore mi disse che dipendeva dalla diversa gestione di questo sistema da parte dei due desktop.
Non è né un kde bug né uno gnome bug. E' un programmer bug.
Lo standard dnd di linux esiste e si chiama xdnd: è gestito direttamente da xfree, e non dipende dal wm utilizzato. Se l'autore del programma ha scelto di utilizzare una cosa tipica di kde, prenditela con lui.


3) Sei solo o quasi nel negarla. E ancora minore importanza ha questa opinione di fronte a milioni di potenziali utilizzatori che non lo sono assolutamente. Sono loro a determinare vita e morte di un'OS.
A me non è mai piaciuto restringere linux ad una fetta microscopica di gente che lo sa usare mentre tutti gli altri si attaccano.
Fammi un favore, a questa "fetta microscopica" aggiungi anche mia suocera, che conosce 0 di informatica e non sa installare neanche un programma su windows.
Forse proprio grazie al suo "mancato indottrinamento" non ha avuto difficoltà ad abituarsi ad un ambiente "diverso" da quello cui sei abituato.
Ora usa la Mandrake, ma stai certo che se mai passerà alla Suse saprà dove trovare i programmi che usa ;)


4) Non si pestano i piedi per il semplice fatto che è un'OS ben fatto da questo punto di vista. I problemi Linux li ha. E' uno di questi (salvo la complessità) è proprio la diversificazione troppo spinta. La modularità se non viene opportunamente "circoscritta" entro gli standard diventa un punto debole.
La fortuna di linux è stata proprio la sua continua diversificazione. E' difficile da spiegare, non si può apprezzare se non usandolo per anni. Su linux DEVI avere parecchie scelte, altrimenti linux MUORE.

L'avrò scritto un miliardo di volte. Se lo scopo è portare linux alla portata di tutti il discorso è estremamente semplice.

Non c'è altro da proporre che creare STANDARD per l'utente finale. Standard basilari non uniformazioni.

Poi quale sistema usare o perchè usarlo (nei diversi ambiti) è scelta che si dovrà fare in seno alla comunità valutando pr e contro (io magari userei anche il sistema debian per i pacchetti affiancato da semplificazioni grafiche)

Questo è tutto

PS
su internet importa poco di come girano le cose ed in ogni caso uno non deve scrivere un poema solo per dire il suo pensiero. Nel mondo reale la faccenda è un pò più complicata ed è la gente che non capisce un fischio a portare avanti le cose

ma perchè queste news deve sempre finire in un flame tra detrattori di linux linux VS win e così via? :muro:

IMHO il fatto che grandi sw houses vedano con occhio diverso linux, che manca onestamente del parco applicativi professionali di Win, è un'ottima notizia...anche se và presa con le molle e di certo non ci si può aspettare che da un gg all'altro cambino le cose.

Ma è un primo passo perchè linux diventi un'alternativa alle piattaforme MS anche nei campi dove ora risulta sicuramente "menomato" e parlo di cad, parlo di editing video/audio soprattutto.

P.S.: n ho mica capito il quoting finale senza commento...è perfettamente inutile :D

Originariamente inviato da DioBrando
ma perchè queste news deve sempre finire in un flame tra detrattori di linux linux VS win e così via? :muro:

Non era un flame, ma un piccolo scambio di vedute OT... ;)

Infatti, da parte mia era solo un'affermazione di ciò che penso anche perchè sono un grandissimo estimatore (e utilizzatore) di Linux

PS
Qualcuno sa di più del bug sulla fedora core 2? Non mi ha dato problemi con il dual boot :eek: :eek: :eek: :eek:

Originariamente inviato da ilsensine
Non era un flame, ma un piccolo scambio di vedute OT... ;)

Perfettamente d'accordo :)

vabbè m'avete convinto :ave:

cmq ho messo le mani avanti così da esorcizzare il pericolo :D

P.S.: la Fedora merita? Rispetto ad una gentoo?

"Credo che l'ostacolo più rilevante alla costruzione di un ambiente desktop semplice, usabile e coerente per Linux sia l'inaccettabile livello di frammentazione dei progetti che costituiscono la galassia del Free Software."
Marco Pesenti Gritti, membro della GNOME Foundation e maintainer del browser Epiphany.

IMHO linux prima di entrare come soluzione desktop per utonti ha strada da fare...ma non perchè non sia abastanza semplice o non sia bbastanza "unificato" ma perchè per i non addetti ai lavori ci sono tanote differenze non facile da metabolizzare.
Sto parlando dei pacchetti, dei permessi, del file system della console.
Chiunque utonto che vede un pc e vede la console pensa al dos e ad un ritorno al passato (mi è successo con amici econ mio padre tra l'altro).
Vedendo scrivere da console i comandi pensa "ma che sta scrivendo questo x installare un programma".
Mio padre ancora non ha capito come sono le cartelle dov'è c e dove è il cdrom...Credo che il problema maggiore di linux sia la scarsa alfabetizzazione informatica...io usavo windows e adesso dopo 4distro uso debian ed ho provato i tgz gli rpm di fedora e di mandrake...Ma io sto studiando ing informatica e so cosa si intende x risparmiare risorse(immaginate la mia faccia nel vedere i requisiti di longhorn) a molta gente interessa fare quello che deve fare senza perdere tempo e se ne sbatte se lo può fare con un pc meno potente o se lo può fare risparmiando un giga di hd. Non lo sa e non gli interessa...Non conosco nessuno a parte i miei colleghi che ha linux a casa siamo solo gli "addetti ai lavori" che lo utilizziamo le pubbliche amministrazioni x motivi economici e le aziende x efficienza dei server e motivi economici...Qualcuno ci definisce dei pazzi...e se ne infischia se col suo vecchio p133 con 64 MB di ram si può vedere i divx mettendo il cd di una distro live

Originariamente inviato da suppostino
"Credo che l'ostacolo più rilevante alla costruzione di un ambiente desktop semplice, usabile e coerente per Linux sia l'inaccettabile livello di frammentazione dei progetti che costituiscono la galassia del Free Software."
Marco Pesenti Gritti, membro della GNOME Foundation e maintainer del browser Epiphany.
To', qualcuno che la pensa esattamente come. Con la differenza che fa parte della comunità Linux, e che non è un utente qualunque... ;)

x juggler3: "Non dire gatto se non ce l'hai nel sacco". :) I requisiti di Longhorn lasciali stare per adesso: ne riparliamo a prodotto finito. Tant'è che le build che circolano attualmente sono usabilissime anche con computer un po' più vecchiotti di quelli che abbiamo oggi... ;)

Originariamente inviato da juggler3
Chiunque utonto che vede un pc e vede la console pensa al dos e ad un ritorno al passato (mi è successo con amici econ mio padre tra l'altro).

Una rilevantissima fetta degli utenti XP non ha mai visto il DOS e non sa nemmeno cos'e`, non scordiamoci di quella piccolissima porzione di utenza che ha iniziato ad usare il PC (meglio: windows) dopo il 1996/97...

Originariamente inviato da suppostino
"Credo che l'ostacolo più rilevante alla costruzione di un ambiente desktop semplice, usabile e coerente per Linux sia l'inaccettabile livello di frammentazione dei progetti che costituiscono la galassia del Free Software."
Marco Pesenti Gritti, membro della GNOME Foundation e maintainer del browser Epiphany.

Da un punto di vista tecnico-pragmatico (anche se non saprei bene come definirlo) ha ovviamente ragione, la frammentazione non aiuta in questo senso.
Il punto irrisolto, pero`, rimane: quindi? Quali proposte?

Beh allora mi pare di non aver proprio parlato al vento nonostante qualche punto di vista diverso dal mio, c'è qualcuno di spessore che crede che la troppa diversificazione sia un male.

D'altro canto io credo che nell'esporre il mio pensiero non abbia chiaramente indicato lo scopo, ossia LA DIFFUSIONE ALL'UTENTE INESPERTO del sistema operativo Linux.

Linux è modulare, assolutamente giusto, nessuno deve toccare la modularità. Ma perchè non creare delle basi sulle quali questa modularità possa svilupparsi in modo da non confondere l'utente e rendergli la vita facile?

Secondo me non si crea uno standard perchè ognuno vorrebbe che fosse "il suo" standard a prevalere. Non dovremmo fare la guerra in comunità, anzi...


Originariamente inviato da suppostino
"Credo che l'ostacolo più rilevante alla costruzione di un ambiente desktop semplice, usabile e coerente per Linux sia l'inaccettabile livello di frammentazione dei progetti che costituiscono la galassia del Free Software."
Marco Pesenti Gritti, membro della GNOME Foundation e maintainer del browser Epiphany.

Originariamente inviato da suppostino
"Credo che l'ostacolo più rilevante alla costruzione di un ambiente desktop semplice, usabile e coerente per Linux sia l'inaccettabile livello di frammentazione dei progetti che costituiscono la galassia del Free Software."
Marco Pesenti Gritti, membro della GNOME Foundation e maintainer del browser Epiphany.
Detta dal mantainer dell'ennesimo browser in circolazione, mi risulta difficile prenderla come verità assoluta ;)
Se qualcuno conosce Marco Pesenti Gritti gli faccia cortesemente presente da parte mia che a me gnome e gtk NON PIACCIONO, e che mi arrogo il diritto di usare altri frammentari toolkit nelle mie applicazioni :cool:

I rami secchi muoiono da soli tramite selezione naturale, come in natura.

Nessuno ti obbliga a usare Gnome, ma certamente una piattaforma comune (API e linee guida di programmazione) per una GUI e gli applicativi su di essa basati sarebbe una Buona Cosa. Aggiungiamoci pure il divieto di forking, e la soluzione è servita.

Il caso di AmigaOS l'avrò citato n volte: API ben consolidate, a cui si appoggiano tutte le altre GUI che sono state create (una su tutti: la stupenda Magic User Interface, MUI).

Originariamente inviato da cdimauro
Nessuno ti obbliga a usare Gnome, ma certamente una piattaforma comune (API e linee guida di programmazione) per una GUI e gli applicativi su di essa basati sarebbe una Buona Cosa. Aggiungiamoci pure il divieto di forking, e la soluzione è servita.


Beh, allora si deve riscrivere da zero (!!!) ancora un'altro desktop environment, perche` ne GNOME, ne KDE ne alcun altro DE attualmente in circolazione lo permettono: sono GPL :)
In caso di un clamoroso quanto improbabile cambio di licenza in questo senso quasi sicuramente si avrebbe un fork stile XFree86/Xorg (e ci starebbe proprio tutto!) e risaremmo punto a capo...

Personalmente, continuo a trovare eccessiva questa preoccupazione per i fork.

Originariamente inviato da cdimauro
Aggiungiamoci pure il divieto di forking
killall -TERM gpl ?

killall -BAN cdimauro :D

Originariamente inviato da cdimauro
Il caso di AmigaOS l'avrò citato n volte: API ben consolidate, a cui si appoggiano tutte le altre GUI che sono state create (una su tutti: la stupenda Magic User Interface, MUI).
...e le API delle Xlib, su cui si appoggiano tutti i window manager e toolkit grafici in circolazione, e che solo le stesse da svariati anni, non sono la stessa cosa?

Originariamente inviato da ilsensine
...e le API delle Xlib, su cui si appoggiano tutti i window manager e toolkit grafici in circolazione, e che solo le stesse da svariati anni, non sono la stessa cosa?

E anche l'API posix non e` che cambi poi cosi` velocemente :)

Originariamente inviato da Ikitt_Claw
Beh, allora si deve riscrivere da zero (!!!) ancora un'altro desktop environment, perche` ne GNOME, ne KDE ne alcun altro DE attualmente in circolazione lo permettono: sono GPL :)
In caso di un clamoroso quanto improbabile cambio di licenza in questo senso quasi sicuramente si avrebbe un fork stile XFree86/Xorg (e ci starebbe proprio tutto!) e risaremmo punto a capo...
Ma stavolta si comincerebbe bene, no? ;)
Personalmente, continuo a trovare eccessiva questa preoccupazione per i fork.
Non sono l'unico a pensarla così: io vedo più vantaggi che svantaggi... :)

Originariamente inviato da ilsensine
...e le API delle Xlib, su cui si appoggiano tutti i window manager e toolkit grafici in circolazione, e che solo le stesse da svariati anni, non sono la stessa cosa?
Quindi le Xlib gestiscono i seguenti livelli:

1) interfaccia con l'hardware video (tramite driver)
2) gestione delle risorse (bitmap, font, canvas, pennelli, ecc.)
3) gestione layer (per la sovrapposizione delle finestre)
4) gestione primitive/oggetti grafici (finestre, pulsanti, menù, messaggi e interazioni fra di essi)
5) interfaccia con la clipboard

?

Se è così, siamo a cavallo: le GUI dovrebbero implementare solamente il livello successivo (il render grafico, le impostazioni di default dei vari oggetti), ma ognuno solamente col look & feel che più gli aggrada.

Originariamente inviato da cdimauro
Ma stavolta si comincerebbe bene, no? ;)

Sì certo, chiamiamolo "windows XP manager" :ahahah:

Originariamente inviato da Ikitt_Claw
E anche l'API posix non e` che cambi poi cosi` velocemente :)
Forse perché è un mammut... ;)
Il kernel di Amiga, Exec, e l'AmigaDOS invece sono cambiati molto col passare delle release, ma hanno offerto delle funzionalità sempre nuove/migliori (vabbé che già in partenza le API erano molto avanzate... :D)

Originariamente inviato da cdimauro
Quindi le Xlib gestiscono i seguenti livelli:

1) interfaccia con l'hardware video (tramite driver)
Sì. Per il 3d c'è bisogno anche di un piccolo kernel driver.

2) gestione delle risorse (bitmap, font, canvas, pennelli, ecc.)
Alcune sì alcune non so. I font di sicuro.
Non ho mai tenuto ad approfondire troppo le xlib cmq.

3) gestione layer (per la sovrapposizione delle finestre)
Mi sembra di sì, dovrebbe avere il concetto di "asse z"

4) gestione primitive/oggetti grafici (finestre, pulsanti, menù, messaggi e interazioni fra di essi)
Solo finestre e messaggi, non so/non credo per gli altri oggetti. I menu sicuramente no, sono prerogativa del wm, ma il protocollo è standard (ovvero: il modo di disegnare i menu è lo stesso, per questo puoi eseguire una appl gnome sotto xfce e viceversa).

5) interfaccia con la clipboard
Sì

Originariamente inviato da ilsensine
Sì certo, chiamiamolo "windows XP manager" :ahahah:
No, qualcosa di simile ad AmigaOS... :cool:

Originariamente inviato da ilsensine
Sì. Per il 3d c'è bisogno anche di un piccolo kernel driver.

Alcune sì alcune non so. I font di sicuro.
Non ho mai tenuto ad approfondire troppo le xlib cmq.

Mi sembra di sì, dovrebbe avere il concetto di "asse z"

Solo finestre e messaggi, non so/non credo per gli altri oggetti. I menu sicuramente no, sono prerogativa del wm, ma il protocollo è standard (ovvero: il modo di disegnare i menu è lo stesso, per questo puoi eseguire una appl gnome sotto xfce e viceversa).

Sì
Allora non è messo molto male: manca poco per realizzare una stratificazione che permetta di astrarre completamente le funzionalità base delle GUI...
Non capisco allora tutte queste differenze/problemi che leggo fra chi usa KDE, Gnome o altro: se i programmatori usano le Xlib, le applicazioni dovrebbero rispondere in modo "omogeno". Boh.

P.S. Vado a nanna: domani mi aspetta l'esame finale di Fisica2... :D

Originariamente inviato da cdimauro
Allora non è messo molto male: manca poco per realizzare una stratificazione che permetta di astrarre completamente le funzionalità base delle GUI...
Non capisco allora tutte queste differenze/problemi che leggo fra chi usa KDE, Gnome o altro: se i programmatori usano le Xlib, le applicazioni dovrebbero rispondere in modo "omogeno". Boh.

Le xlib sono delle primitive...molto primitive. Usarle direttamente è un panico. Inoltre, il protocollo X standardizza delle funzionalità specificamente demandate al wm. Non capisco cosa per te ci sia di sbagliato nel demandare la parte del look'n'feel e una maggiore programmabilità ai wm. Il problema non è il numero di wm e toolkit a disposizione: è un bene, ce ne sono di tutti i gusti e per tutte le potenze di calcolo.

Il problema vero non è l'abbondanza di scelta per i wm, ma la scarsissima scelta per il server X. Non hai seguito le ultime vicende su xfree, vero? Lì è uscito fuori come, per linux, una scarsità di scelta equivale ad una debolezza.

AmigaOS & Co non sono linux. Linux è unico OS che trae vita dalla pluralità di voci. I recenti problemi con xfree lo hanno dimostrato.

Originariamente inviato da ilsensine
Le xlib sono delle primitive...molto primitive. Usarle direttamente è un panico. Inoltre, il protocollo X standardizza delle funzionalità specificamente demandate al wm. Non capisco cosa per te ci sia di sbagliato nel demandare la parte del look'n'feel e una maggiore programmabilità ai wm. Il problema non è il numero di wm e toolkit a disposizione: è un bene, ce ne sono di tutti i gusti e per tutte le potenze di calcolo.



Premetto che non ho una grandissima familiarità con linux e in particolare con le peculiarità dei wm, quindi il mio intervento vuol'essere da un lato propositivo, dall'altro una richiesta di chiarimenti.

L'omogeneità, IMHO, dovrebbe stare nell'interfaccia con le API del WM, prevedendo dei sistemi di wrapping per le funzionalità aggiuntive e/o diverse dallo standard, che sia esso xlib o una versione meno "primitiva".

Mi spiego: credo che sarebbe opportuno standardizzare (o ristandardizzare, laddove l'implementazione nelle xlib sia troppo complicata da usare) l'implementazione di base della maggior parte delle funzionalità, delegando al WM la sola cura della veste grafica, o al più parte dell'implementazione, purchè siano fissati i nomi delle librerie, delle funzioni, e i tipi dei parametri e dei valori di ritorno. Fatto questo, si può sempre garantire agli sviluppatori di WM la possibilità di aggiungere funzionalità allo standard e/o di modificare o anche sovvertire lo standard, purchè si mantenga un'implementazione parallela dello standard, con le sue intarfacce fisse, e si circoscrivano le modifiche e le aggiunte in librerie a parte, avendo cura di produrre delle librerie di wrapping con gli stessi nomi di quelle non standard che implementino le stesse funzioni (con gli stessi nomi e parametri) appoggiandosi alle API standard (cioè risolvendosi in una serie di chiamate opportune alle funzioni standard), in modo che il programmatore di applicazioni possa decidersi se appoggiarsi, per la sua interfaccia, allo standard, o se sfruttare la programmabilità, comunque mantenuta, di uno specifico WM, sapendo che la sua applicazione avrà comunque un comportamento omogeneo con tutti i WM, poichè gli vengono comunque fornite delle interfacce di wrapping che la sua applicazione (non conforme allo standard) installerà sulle macchine che presentano un diverso WM.

In questo modo si dovrebbe ottenere una omogeneità di comportamento delle applicazioni a prescindere dal WM installato, senza limitare né la pluralità dei WM, né la loro programmabilità e libertà di innovazione rispetto ad uno specifico standard, rendendo semplicemente più "dolce" la transizione da uno standard a un altro. Insomma, penso a qualcosa di simile a quello che si fa con grosse applicazioni di front-end per la gestione di database: si prevede una classe (libreria o quant'altro) di wrapping in modo che l'applicazione possa interrogare il database secondo le proprie necessità e/o peculiarità "infischiandosene" di come vada realmente interrogato il database, così se cambio il database che c'è sotto dovrò solo modificare la mia libreria di interfaccia, lasciando inalterato il resto del front-end.

Ciao a tutti ;)

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... :D

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 :D. 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... :D

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

Originariamente inviato da xeal
Mi spiego: credo che sarebbe opportuno standardizzare (o ristandardizzare, laddove l'implementazione nelle xlib sia troppo complicata da usare) l'implementazione di base della maggior parte delle funzionalità, delegando al WM la sola cura della veste grafica, o al più parte dell'implementazione, [...]


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

Originariamente inviato da xeal
Credo che con opportune librerie di wrapping si potrebbero risolvere anche problemi di compatibilità che a volte sento dire si verificano

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.


accompagnata da un occhio di riguardo alla retrocompatibilità potrebbe essere una strada interessante da seguire e una sfida in più, no?

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

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.

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...

Originariamente inviato da Ikitt_Claw
Originariamente inviato da xeal
Mi spiego: credo che sarebbe opportuno standardizzare (o ristandardizzare, laddove l'implementazione nelle xlib sia troppo complicata da usare) l'implementazione di base della maggior parte delle funzionalità, delegando al WM la sola cura della veste grafica, o al più parte dell'implementazione, [...]

--------------------------------------------------------------------------------

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



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 :D

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

datatypes, autoconfig, arexx... :sbav:

Originariamente inviato da jappilas
io andrei oltre, delegando anche la veste grafica al toolkit, in modo tale che:

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


1) TUTTE le applicazioni venissero portate a condividere lo stile grafico a livello dei widget, con maggiore omogeneità

Nel mondo opensource e` praticamente impossibile...


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

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) ;)

Originariamente inviato da Ikitt_Claw
hai appena reinventato i ToolKit per X (gtk, qt, fltk, fox)...

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 forte e decisa standardizzazione di base, che garantisca omogeneità e allo stesso tempo non soffochi la pluralità mediante il meccanismo della "ridondanza" delle implementazioni (standard + alternativa).


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.


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.


Se nessuno lo fa, e` perche` nessuno ne sente il bisogno;)
...
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...


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 :D:D:D)

Ciao.

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

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


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

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.


Non voglio reinventare i toolkit, penso al massimo alla possibilità/opportunità di riprogettarli (se necessario)

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

e spingere verso una forte e decisa standardizzazione di base, che garantisca omogeneità e allo stesso tempo non soffochi la pluralità mediante il meccanismo della "ridondanza" delle implementazioni (standard + alternativa).

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.


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.

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

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?

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.

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.

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.

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,
No, semplicemente e` un'ABI diversa.

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,
Oddio, teoricamente e` interessante ma in pratica mi sembra un po` un'overkill...


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

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 ;)


[...]
(se uno poi si mette in testa di essere ignifugo il discorso cambia :D:D:D)


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! :D

Originariamente inviato da cdimauro
Francamente non vedo per quale motivo non sia sempre possibile mantenere la compatibilità all'indietro.

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. :rolleyes:

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...

Originariamente inviato da cdimauro
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. :rolleyes:

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...

Originariamente inviato da xeal
L'omogeneità, IMHO, dovrebbe stare nell'interfaccia con le API del WM
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 ;)

Originariamente inviato da Ikitt_Claw
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

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


Ni. Sempre (anche) a causa della gioventu` del complesso, a volte ci sono stravolgimenti anche grossi tra una major release e l'altra.
...
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.

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.


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

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.


Perfettamente inutile lamentarsi e basta, e` provato sul campo. Anzi, fa solo irritare gli sviluppatori, se fa qualcosa

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 :D) chiedi sempre delle proposte a chi critica linux "tout-court" (chiedo mercè per il mio francese :D). Io non critico, propongo e basta :). Spunti di riflessione, quanto meno, o almeno ci provo :)


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

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 :D) :)

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.


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 ;

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 :rolleyes:... 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... :)

Originariamente inviato da xeal
X ilsensine:
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
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.

Originariamente inviato da xeal
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.
La "soluzione" è semplicemente non reinventarsi la ruota, quando non serve.
Un protocollo standard (xdnd) c'è? Sì, allora perché invertarsene un altro?

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

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.

Originariamente inviato da ilsensine
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 ;) :ave:
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...

Originariamente inviato da xeal
Beh, allora stanno prendendo la direzione giusta, IMHO.

IMHO too ;)


Insomma, penso ad un meccanismo che produca un compromesso tra spinta innovativa e ancoramento a dei punti di riferimento.

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.


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.

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.


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

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. :rolleyes:

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...

Originariamente inviato da jappilas
necessiterei delucidazioni spiegazioni sulle licenze bsd like e sui loro problemi
Non hanno normalmente problemi, tranne la licenza bsd originale (ormai in disuso da tempo):
http://www.fsf.org/philosophy/bsd.html

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 .. )
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...

Originariamente inviato da ilsensine
Soluzioni alternative stanno nascendo (dai una occhiata ad es. a 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.


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.



Anche l'introduzione di un layer superiore più "semplice" non è una soluzione, visto che non porta vantaggi rispetto ai toolkit (che quindi non sostituirebbe).


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".



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


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.

Originariamente inviato da Ikitt_Claw
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


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


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


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 :D), 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 :D, ma non ricordo il titolo), quello proprio no!

Ciao :)

Originariamente inviato da ilsensine
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

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

Originariamente inviato da xeal
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
Vero, ma ancor più vero nel campo closed source. Stai sicuro che le illegalità lì sono maggiori, e ancor più difficili da dimostrare.
Cmq ci sono state parecchie condanne per violazione della gpl.


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?
Puoi farne quello che vuoi, senza particolari obblighi verso chi ti ha fornito il codice. In questo sta la tua _libertà_. Il tuo univo obbligo è conferire a chi riceve il programma da te (anche a pagamento), gli stessi diritti che hai ricevuto tu.


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?
Il discorso non è tanto banale, ma semplificato all'osso è così:

- User space:
lgpl + binary core = possibile, seguendo semplici regole
gpl + binary core = impossibile, tranne casi particolari specificati in clausole addizionali (ad es. libstdc++ )

- Kernel space
Modulo proprietario inserito staticamente nel kernel = impossibile
Modulo proprietario standalone (parte binaria + eventuale codice di interfaccia) = in teoria non possibile ma nella pratica è "tollerato", se risulta ovvio che la parte binaria non costituisce opera derivata.

Originariamente inviato da ilsensine
Il discorso non è tanto banale, ma semplificando all'osso è così:
...


Capito, più o meno. Una libreria/programma lgpl può linkare una libreria gpl o in tal caso diventerebbe anch'essa gpl? E le librerie di sistema (quelle che devi chiamare per forza per le system call, per creare sottoprocessi, thread ecc.) sono coperte da gpl o da lgpl?

Ciao.

Originariamente inviato da xeal
Capito, più o meno. Una libreria/programma lgpl può linkare una libreria gpl o in tal caso diventerebbe anch'essa gpl?
Credo che non possa linkare, ma non sono sicuro.

E le librerie di sistema (quelle che devi chiamare per forza per le system call, per creare sottoprocessi, thread ecc.) sono coperte da gpl o da lgpl?

Le syscall non sono librerie, ma interfacce con il kernel. Chiunque può usarle direttamente.