Torvalds: 'Linux non è stato un fallimento su desktop. Lavorerò per conquistare il mercato'

[pabloski]

Originariamente inviato da Nicodemo Timoteo Taddeo

Scusa cosa intendi per "Fantastica gestione del desktop"?

Gnome 3 settato a puntino e per l'uso da parte di chi ha necessita' di usare un PC e non un grosso smartphone

[Nicodemo Timoteo Taddeo]

Originariamente inviato da pabloski

Gnome 3 settato a puntino e per l'uso da parte di chi ha necessita' di usare un PC e non un grosso smartphone

Ne ho appena discusso da un'altra parte:
http://www.hwupgrade.it/forum/showth...4#post43618664

[Flying Tiger]

Originariamente inviato da zappy

il problema di win10 è che 'na schifezza anche a livello estetico. e lì ci puoi fare ben poche "modifiche".

Beh è una opinione personale per altro rispettabile, per esempio per quanto mi riguarda posso dire la stessa cosa di ubuntu con la sua unity , oppure della KDE plasma 5 che è un vero e proprio mattone anche su hardware recentissimo come un sistema X99 piuttosto che altro, sempre opinioni personali sono e come sempre sono soggettive e mai oggettive...

Personalmente, dopo aver provato molte distro e altrettanti DE , preferisco la Cinnamon di Mint come fruibilità ,ecc.. anche se a leggere i vari forum dedicati all' argomento questo DE non è visto diciamo di buon occhio rispetto ad altri DE come ad esempio Gnome 3 , tra l' altro parlando di Cinnamon dovrebbe uscire a breve , si parla di maggio/giugno , Mint 18 Sarah che includerà la nuova versione 3.0 e dagli screen fin' ora visti pare davvero niente male, vedremo quando esce...

Per windows il discorso di 10 è legato a molti fattori e secondo me è un discorso abbastanza complesso già solo considerando quello inerente la convergenza desktop-mobile , ecc.. , poi per me quello di win 7 in quanto a fruibilità , estetica e quant' altro rimane innarrivabile e rimane la vera ultima gui desktop di windows...

[cdimauro]

Originariamente inviato da pabloski

Il problema e' che le discussioni continuano ad esserci, perche' non e' chiaro dove tracciare la linea rossa che separa monolitico da microkernel.

Mi pare che le due definizioni siano abbastanza chiare.

Mach e' microkernel? Per i suoi creatori si, per i puristi no.

Non conosco Mach, ma se per i "puristi" di cui parli non lo è, potrebbe trattarsi di un kernel ibrido.

Certamente. E' un tentativo di esportare in user space tutto cio' che e' prono ai bug e non inficiato pesantemente dalle latenze introdotte dalla gestione in userspace degli interrupt.

E' un lavoro da alchimista pero', da fare col bilancino. Se non erro, MS porto' i driver della gpu in userspace, per poi ritornare indietro per problemi di prestazioni.

Sì, certe scelte sono spesso dettate dalle prestazioni.

Nel caso di Microsoft, ha portato parte dei driver grafici in user space, lasciando il resto in kernel space. Si sarà fatta i suoi conti e avrà visto quale fosse il miglior compromesso.

E mi pare di capire che il risultato di tali alchimie sia difficile da gestire. Almeno i progettisti di microkernel accettano incondizionatamente una riduzione delle prestazioni, cercando di ridurla il piu' possibile, ma partendo dal presupposto che la modularita' e la robustezza sono le priorita' assolute.

Ed essendo io fissato con la modularita', manutenibilita' e pulizia dell'architettura di un software, ammetto di avere una netta preferenza per i microkernel.

Idem. Purtroppo gli ideali da soli non bastano: bisogna anche essere pragmatici. Per questo non disdegno nemmeno i kernel ibridi.

Vero ed e' l'argomento principale dei denigratori dei microkernel. Non conosco quale impatto abbia la gestione degli interrupt nei moderni microkernel, ma mi pare di capire che la soluzione di generare messaggi ( da inviare ai driver interessati ), unita ad un'accurata politica di scheduling dei driver stessi, dia risultati non troppo penalizzanti.

Ho letto varie cose su Minix, L4, QNX e mi pare di capire che si parla di un 2-10% di perdita prestazionale.

Francamente non ne ho idea, perché tra l'altro questi risultati dipendono anche dalla (micro) architettura utilizzata per i test.

Ci sono architetture che hanno un costo elevato per il context switch, mentre altre sono molto veloci. Oppure per la gestione degli interrupt (vedi ARM con la modalità fast interrupt, ad esempio).

E poi ci sarebbe da fare una seria riflessioni sulle implicazioni per la sicurezza. Microkernel + IOMMU formano un bel "firewall" contro periferiche malevoli. Ed e' imprudente non cominciare a considerare i pericoli che avremo se e quando i malware cominceranno ad insinuarsi nei firmware delle piu' svariate periferiche.

Concordo in linea di massima, ma bisogna anche vedere quanto ciò sarà possibile.

Mi chiedo pero' quanto sarebbe costato. Sony ha vagonate di dollari, ingegneri e la possibilita' di fare accordi ( come farsi produrre un driver per la gpu da AMD ). Android Inc. non penso avesse le stesse possibilita'.

Non so, perché di sistemi dotati di comparto video (e audio) per ARM ne esistono da tantissimi anni, e con buon supporto.

Le console portatili prosperavano già da ben prima che Android nascesse.

Senza contare che FreeBSD non supportava ARM all'epoca. E non c'era nulla in termini di driver per tale piattaforma.

Vero. Questo lascia fuori FreeBSD.

[cdimauro]

Originariamente inviato da Bellaz89

A me sembrava di essere stato chiaro nel mio messaggio precedente.

Quella che hai evidenziato è una tua opinione, non un impegno (formale) della Linux Foundation.

Esattamente come accade per Windows e MacOSX.

No, perché su Windows e MacOS X puoi tranquillamente non rilasciare mai i sorgenti dei tuoi driver.

Poi c'e' sempre la possibilita' da parte delle aziende di pagare e diventare membro e ottenere un supporto ancora piu' rapido.

Quindi oltre a rilasciare i sorgenti si dovrebbe pure pagare. Ma a questo punto almeno il supporto sarebbe realmente assicurato? E con quali tempistiche?

Scusami, ma a me sembra una conclusione riduttiva e arbitraria a fronte di quello che e' stato scritto nel thread. Nella realta' moltissime aziende hardware, tra cui quella per cui lavori, supportano e sviluppano il kernel Linux e il suo ecosistema e questo e' stato gia' detto e ridetto.

Ritieni che la tua azienda non sia capace di fare una corretta analisi costi/benefici?

Ritengo di sì, ma rilasciare qualcosa per Linux non significa che sia automaticamente più conveniente che farlo per Windows o MacOS X.

Tant'è che, come già detto altre volte, Intel non rilascia tutto per Linux. Eppure le competenze per farlo e mantenerne pure lo sviluppo non le mancano di certo.

Misteri del management...

Questo a riprova che questa presunta non convenienza del "modello linux" sia solo un discorso sui massimi sistemi. Possiamo continuare a discutere su questo punto, ma francamente quello che osservo nel mondo reale contraddice la tua tesi.

Abbiamo esperienze diverse, visto che continuo a lavorare a roba di cui non sono disponibili i sorgenti, pur essendo rilasciata anche per Linux.

PS: una lista dei membri della linux foundation(che non copre ovviamente tutti gli sviluppatori HW che supportano linux) si trova qua http://www.linuxfoundation.org/about/members. Come si puo' vedere e' presente la maggior parte dei piu' importanti produttori HW.

Sì, ma che vuol dire? Ad esempio c'è pure nVidia, e dovresti conoscere cosa ne pensa Torvalds.

Posto che tutto questo (il problema dell'endianness e del bus PCI) e' partita dalla domanda:

E' possibile fare un device driver per linux architecture indipendent a livello sorgente?

La cui risposta a questo punto mi pare di capire sia generalmente affermativa tranne pochi casi di periferiche molto vecchie (e per alcune periferiche come VESA abbiamo detto ci sono workaround).

Quando dico bus Architecture Independent intendo un bus su cui si possono realizzare periferiche che non necessitano di una determinata architettura per funzionare. Poi la gestione corretta dei segnali, come e' stato scritto, dipende ovviamente dall' implementazione del controller PCI e del sottosistema PCI del sistema operativo, nonche' del driver se non ci sono meccanismi d'astrazione come ad esempio ci sono in linux.

Purtroppo proprio gli esempi che ho riportato dimostrano che tale bus non può essere architecture independent.

Infatti, guarda qui:

"PCI devices are inherently little-endian, meaning all multiple byte fields have the least significant values at the lower addresses. This requires a big-endian processor, such as a Power PC, to perform the proper byte-swapping of data read from or written to the PCI device, including any accesses to the Configuration Address Space."

Che poi queste problematiche possano essere risolte lato s.o. e/o driver, è un altro paio di maniche.

Ok, quindi comunque se mi parli di WinModem, mi par di capire comunque si parli di roba molto vecchia, risalente a un periodo di transizione tra ISA e PCI, che anche all'epoca era una scelta di compromesso anche su windows.

I WinModem erano disponibili anche su USB, e presentavano gli stessi problemi.

Comunque non so se oltre ai WinModem ci sia altro. Come già detto, non ho tool per verificare il tipo di memoria presente nei dispositivi PCI, ma è certo che possano integrare codice:

"As indicated in section 6.3.3.1. ROM Header Extensions (PCI Local Bus Specification v2.3), offset 0x3h is "Entry point for INIT function. POST does a FAR CALL to this location.", this field's length is 3 bytes."

Mai affermato che fosse una prerogativa di linux. Come gia' detto questa era una risposta alle tue obiezioni riguardo alla fattibilita' di fare un device driver a livello sorgente indipendente dall'architettura.

Difficoltà, più che altro.

Sei tu che ti ponevi il problema, non io ...

Sì, ma erano solo dubbi e, considerato che non ci sviluppo, non ho voglia di chiedere. Tutto qui.

Questi mi sembrano piu' problemi che riguardano il rapporto dipendente-azienda. Non e' che se un dipendente fa la stessa cosa con programmi o con middleware closed source cambia la situazione.

Inoltre vorrei ricordare che per determinare se c'e' un'infrazione della licenza, uno deve sottoporsi a un iter giudiziario che verifica se e' stato commesso un reato o meno e che assegna le responsabilita' alle parti in gioco. Se un dipendente ruba (indipendentemente dalla licenza) codice altrui all' insaputa dell'azienda, anche l'azienda e' parte lesa nei confronti dello sviluppatore scorretto.

Non è detto che rubi: può trovarlo da qualche parte, senza indicata alcuna licenza, e pensando che fosse di pubblico dominio (in assenza di licenza...) integrarlo in un progetto aziendale.

Per la questione linee a casaccio su internet mi sembra uno scenatio teorico piu' che altro.

A me è capitato e non sono l'unico. Soltanto che adesso faccio molta attenzione, e preferisco riscrivere completamente il codice dopo aver compreso la soluzione trovata al mio problema.

Tra le altre cose che vengono valutate per determinare una violazione della licenza e' verificare se la parte copiata e' un lavoro originale o no.Non e' che vengo condannato se trovano un 'Hello world' sotto GPL che e' uguale a quello nel mio codice.

Chiaro.

(posto che e' veramente difficile determinare se in un progetto closed source 'poche' righe di codice sono state copiate da un determinato progetto. Le denuncie, quando vengono fatte, partono per casi di violazione palesi )

Ci sono tool appositi per stabilirlo, come già detto.

Inoltre come esplicitamente scritto nella GPL tutti i file coperti da GPL devono avere il preambolo e deve essere indicata la provenienza. Se un terzo mette su internet codice GPL senza preambolo o senza indicare che quel codice e' preso da un progetto GPL e' egli stesso passibile di denuncia per violazione della licenza. Chi senza saperlo prende codice da queste fonti e' da considerarsi parte lesa e si puo' rifare su quest'ultimo.

Se si tratta di un impiegato, quanto potrebbe cavarci? Mentre i danni per violazione della licenza potrebbero essere ben più gravi.

Per quanto non sia una fonte attendibile al 100% , io ti ho postato Wikipedia, non il sito di FSF. Se hai altri link a definizioni da fonti autorevoli e possibilmente neutrali ben vengano.

Ho solo detto che quella voce mi sembra scritta da fan della FSP.

Comunque, ecco qui:

"The GPL license is ‘viral,’ meaning any derivative work you create containing even the smallest portion of the previously GPL licensed software must also be licensed under the GPL license."

Quanto alla fonte:

"New Media Rights is an independently funded non-profit program of California Western School of Law (a 501c3 non-profit) that provides one-to-one legal services to creators, entrepreneurs and internet users whose projects require specialized internet, intellectual property, privacy, media, and communications law expertise. "

Mi sta bene se devo fare una libreria, se devo fare un'applicazione non vedo il motivo di utilizzarla visto che tanto le stesse restrizioni sui lavori derivati che anche tu citi si applicano con GPL e LGPL indipendentemente.

Mi parrebbe strano il contrario visto che sono state entrambe prodotte da FSF.

Non è la stessa cosa, perché se usi la LGPL puoi sempre circoscrivere i suoi effetti.

Metti il caso che m'interessi un pezzo del codice della tua applicazione, non correrei il rischio di dover rilasciare tutto il mio codice con la LGPL. Con la GPL, invece, sì.

Ripeto, io uso la GPL e non rubo niente a nessuno. Sei sicuro di utilizzare i termini in maniera corretta?

Direi di sì. E non sono l'unico a pensarla così.

Inoltre anche se venisse verificato in tribunale una violazione della GPL, dubito che l'organo di giudizio condannerebbe all'apertura dell'intero software proprietario l'entita' che ha commesso il crimine. Al piu' l'azienda/sviluppatore verrebbe costretta a rimuovere il codice incriminato dal proprio software e a risarcire la parte lesa. Quindi di che ruberie si sta parlando?

EDIT: una spiegazione piu' dettagliata di quello che ho detto circa le violazioni della GPL si puo' trovare in questo articolo del 2003 di LWN.net (http://lwn.net/Articles/61292/)

Rilancio: Pigs are flying low: Why Microsoft open-sourced its Linux drivers

Queste due frasi che hai scritto mi sembrano in contraddizione.

Sono una constatazione di come vanno le cose.

Come detto in numerosi post passati: differenti esigenze, differenti soluzioni.

No, le esigenze sono esattamente le stesse. Sono le soluzioni a essere differenti.

E comunque ci sono sempre i tool grafici.

Sono tutti uguali o hanno reinventato la ruota anche lì?

Non e' che citando 6 pacchetti a caso che falsifichi quello che dico. Se vogliamo essere precisi, XORG e Wayland sono sviluppati in seno a freedesktop.org quindi mi aspetto un riutilizzo di componenti tra i due progetti per quanto possibile.

Può essere, ma bisognerebbe vedere. Intanto mi pare di capire che MIR sarebbe a sé stante. E non credo che la situazione sia tanto diversa per gli altri casi.

Nella pratica quando devo scaricare un programma o driver per Windows devo tirar giu' centinaia di MB se non GB, mentre per linux da gestore dei pacchetti solitamente pochi MB perche' la maggior parte delle dipendenze sono gia' installate in quanto utilizzate da altri programmi.

Modelli di distribuzione diversi. Per evitare il famigerato DLL hell Microsoft ha caldamente consigliato di infilare le DLL di un'applicazione nella stessa cartella.

In ogni caso versioni diverse della stessa libreria se ne trovano anche su Linux.

[s-y]

semplifico leggerissimamissamente ma non ho tempo
penso anche di averlo gia' scritto tempo fa

probabilmente la gpl e' allo stesso tempo un vantaggio e uno svantaggio. consente a gnu/linux (in particolare) di 'prosperare', ma allo stesso tempo ne limita l'adozione (in generale)

io non ho una particolare posizione al riguardo, o meglio ce l'ho ma non essendo oggettiva non conta

[adapter]

Originariamente inviato da pabloski

Gnome 3 settato a puntino e per l'uso da parte di chi ha necessita' di usare un PC e non un grosso smartphone

Esatto!

[zappy]

Originariamente inviato da adapter

...
Per macchine più datate, meglio affidarsi a versioni più leggere come Linux Mint con DE Mate che richiedono meno risorse e sono senza dubbio più reattive....

MATE è abbastanza mattonoso, prova XFCE, che è più reattivo.

[zappy]

Originariamente inviato da Flying Tiger

Beh è una opinione personale per altro rispettabile, per esempio per quanto mi riguarda posso dire la stessa cosa di ubuntu con la sua unity , oppure della KDE plasma 5 ...

certo, la differenza è che win10 ha quella interfaccia punto, mentre in linux si può scegliere, e semmai il problema è che ci sono troppe scelte tutte con piccole differenze una dall'altra ma (IMHO) nessuna perfetta.

[Syk]

Originariamente inviato da zappy

.

in questa discussione ho visto spesso cose eccellenti


Com'è il vostro Windows 8.1? Modding e consigli per la personalizzazione

[Flying Tiger]

Originariamente inviato da zappy

certo, la differenza è che win10 ha quella interfaccia punto, mentre in linux si può scegliere, e semmai il problema è che ci sono troppe scelte tutte con piccole differenze una dall'altra ma (IMHO) nessuna perfetta.

Si concordo, se avere una unica interfaccia puo essere una limitazione per coloro che desiderano personalizzarla secondo le proprie esigenze , può esserlo anche averne troppe che si differenziano di poco , probabilmente anche questo fattore, a mio avviso per niente trascurabile a livello di importanza visto che è con la gui che ci si rapporta con il sistema operativo , incide sul discorso diffusione di linux su desktop , per capirci tante distro con tanti DE tanto che pensare che un utente medio li provi tutti per scegliere quello che più si confà alle sue esigenze anche estetico/funzionali è a mio avviso pura utopia...

In genere , e da quanto ho potuto riscontrare anche direttamente , si sceglie la distro con il DE di default , cioè unbuntu con unity piuttosto che mint con cinnamon , e se non confà alle esigenze ,gusti , ecc.. si cassa per passare ad un altra , sceglierne di alternativi rimanendo con la stessa distro a mio avviso è un passo successivo....

[adapter]

Originariamente inviato da zappy

MATE è abbastanza mattonoso, prova XFCE, che è più reattivo.

Beh ma per vecchio parlo comunque di un core duo due.
Una via di mezzo come mate, personalmente va più che bene.

[cdimauro]

Originariamente inviato da Bellaz89

Non sono per niente opinioni personali. Mi sembra una banalita' dire che se una azienda vuole certe feature nel proprio driver in tempi determinati da lei stessa deve farlo di tasca propria indipendentemente dal fatto che sia open source o no. Poi nel caso di Linux abbiamo che se hai un driver open-source la community ti supporta nello sviluppo e si impegna a trasportare il driver nelle successive versioni del kernel. Non mi sembra cosi' complicato. Se fidarsi o meno e' una scelta dell'azienda (che ha sempre la possibilita' di diventare membro ripeto).

Con la differenza che sugli altri s.o. hai API/ABI stabili e non sei costretto a rilasciare il tuo codice.

Mi sembra ovvio che se uno stipula un contratto di supporto con LF abbia un supporto assicurato nei limiti delle clausole contrattuali.

Non ho trovato nulla nel sito, né riguardo ai membri né per gli sviluppatori.

Dove l'avrei detto?

Non ho detto che l'hai detto tu. E' una mia constatazione.

Te hai scritto che a seguito delle tue assunzioni che generalmente non e' conveniente il modello linux di sviluppo driver. Io ti ho scritto che questo discorso e' generalmente falso in base a quello che si verifica nella realta'.

Se devi rilasciare i tuoi sorgenti e pure mantenerli, con API/ABI che cambiano, non c'è convenienza. Soprattutto paragonato agli altri s.o..

(Comunque dal famoso rant di linus NVIDIA ha iniziato a supportare il progetto nouveau, per dire...)

Ma si tengono ben stretti i loro driver closed: chissà perché.

Cosa peraltro non rara. Vedi Broadcom che rilascia blob per i Raspberry, per cui sei costretto a tenerti quella distribuzione (o una che supporta gli stessi blob). Tanto per fare un altro esempio ben noto.

Fare device fatti con questa filosofia e' una porcheria. L'unico motivo valido per farlo e' se si hanno standard legacy da supportare. E' una filosofia figlia di un'epoca in cui mettere un microcontroller o una logica riprogrammabile sulla scheda era un costo improponibile, problema che adesso e' ampiamente risolto visti i costi degli IC.

Questi device generalmente si possono anche aggiornare.

Comunque mi sono già espresso prima: un firmware in una periferica sarebbe comodo se esponesse un'interfaccia essenziale (e abbastanza generica) per interfacciarsi col s.o..

Fare device del genere presenta enormi problemi di prestazioni, latenza, mantenibilita' del device, sicurezza, e ovviamente portabilita' su altre architetture. In ogni caso anche se non conoscevo tale, feature (che rimane legata al mondo legacy), rimane l'insensatezza di usare tale tecnica. (ho disponibile la versione 3.0 dello standard e a quanto leggo la parte che parla di questa roba e' stata sostituita. la versione 2.3 e' a pagamento). Chiunque sano di mente non fa device di questo tipo da decine di anni se non obbligato.

Non penso che abbiano rimosso questa caratteristica, visto che esistono ancora schede grafiche che integrano il BIOS VGA.

EDIT 1(Tra le altre cose penso che i WinModem USB e PCI condividano solo il nome commerciale. Penso che il loro funzionamento sia radicalmente differente e che i primi non 'scarichino' codice eseguibile sulla memoria come fanno i secondi. I WinModem USB sono inapplicabili al discorso)

EDIT 2(Ricercando sul web ho visto che anche per la maggior parte WinModem PCI il problema non sembra essere il fatto che scarichino codice eseguibile sull'host, cosa che non accade, quanto che a suo tempo non furono fatti altri driver che per windows, a riprova del fatto che anche a suo tempo lo 'scaricare il driver sull' host dal device' era una porcheria. L'unico legato a x86 per Linux pare essere quello per alcuni winmodem con chip della Lucent Technologies https://wiki.debian.org/it/martian_dev, gli altri chip non mi stupirebbe se fossero supportati per la maggior parte OOB dal kernel linux su qualsiasi piattaforma)

OK, ricordavo male.

Ripeto, se trovi codice senza licenza ed era GPL, puoi chiedere i danni a chi l'ha messo online senza licenza. Poi bisognerebbe vedere che professionalita' ha uno sviluppatore che, pagato dalla sua a zienda, fa copia-incolla di roba a casaccio su internet senza prestare attenzione alle fonti. E questo indipendentemente dalla GPL.

Dipende dall'azienda: non sono tutte uguali. Ci sono tante aziende medio-piccole che assumono "gente che scrive codice", e per le quali nemmeno si pongono certe problematiche.

Nelle grandi corporazioni non si lavora così, e usualmente se scrivi codice sei anche obbligato a seguire dei corsi di formazione appositi che trattano proprio queste tematiche.

Non parlavo dell' azienda, ma di chi ritiene che il proprio progetto GPL sia stato violato. Mi sembra banale dire che trovare una violazione in un binario sia estremamente piu' complicato che in un sorgente. Anche solo per le ottimizzazioni che il compilatore fa sul codice generato non puo' esistere un tool che ti da la sicurezza al 100% sull'eseguibile generato.

Certamente. Ciò non di meno non sono affatto rare le cause di aziende che detengono IP e trascinano in tribunale altre per violazione di brevetti et similia. Il tutto senza sorgenti alla mano, ovviamente (in questi casi di va di reverse engineering).

Esistono i tribunali a questo scopo. Ovvero ad assegnare le responsabilita' e a emettere un giudizio in linea teorica equo. Pero' si sta parlando sempre di problemi che non riguardano la GPL nello specifico.

Sì, è un discorso generico, ma vale quanto già detto: rivalerti sul dipendente che ha sbagliato può benissimo non essere sufficiente a coprire le spese per il danno fatto.

A me sembra che dica le stesse identiche cose della pagina di Wiki nella sezione Scope.

E entrambe le fonti dicono ovviamente cose differenti rispetto al tuo primo post a riguardo in cui affermavi che la viralita' della GPL permette di rubare codice altrui, che e' falso.

Allora, visto che è da un pezzo che lo ripeti lo chiariamo una volta per tutte: il termine rubare l'hai tirato fuori soltanto tu finora.

Io ho parlato di mettere le mani e far man bassa, che NON è certo la stessa cosa.

Il concetto è semplice: prima il codice era SOLO MIO, e a causa di poche righe di codice coperte da licenza virale non lo è più, e sono costretto a rilasciarlo e chiunque può metterci le mani.

Che poi è quello che hanno gli altri link affermano.

Quotando dalla fonte che tu stesso mi hai mandato.

Quindi se prendi 'un pezzo del codice' di un progetto LGPL, che sia un programma o un'applicazione, devi rilasciare il codice che ne fa uso sotto LGPL in quanto lavoro derivato.

OK, quindi anche link statico è virale con la LGPL. L'unico modo è quello dinamico.

Un'altra buona ragione per evitare anche la LGPL.

Ma hai letto l'articolo che hai postato? Perche' da nessuna parte afferma che con la 'GPL si possa rubare codice altrui'. E' faticoso leggere gli articoli, ti prego di non postarmi roba a caso.

Che si possa rubare il codice altrui è, infatti, soltanto un tuo pensiero che riporti spesso, ma NON è quello che ho detto io. Vedi sopra.

MM Ok, e quindi?

Microsoft è stata sostanzialmente costretta a rilasciare il codice del suo hypervisor a causa di una violazione della licenza GPL.

L'alternativa sarebbe stata quella di essere condannata.

Continuo a non capire...

Voglio dire che Linux viene sviluppato secondo il modello cattedrale, dunque con una ben precisa direzione. Esattamente come avviene con gli altri s.o..

Questo non pregiudica altri di farne un fork, ma Linux di per sé rimane sviluppato così.

Il resto lo taglio per evitare di peggiorare il Post-Loop

OK

[PaulGuru]

Originariamente inviato da zappy

certo, la differenza è che win10 ha quella interfaccia punto, mentre in linux si può scegliere, e semmai il problema è che ci sono troppe scelte tutte con piccole differenze una dall'altra ma (IMHO) nessuna perfetta.

Si la puoi scegliere ma questo ti LIMITA dal punto di vista della compatibilità con gli applicativi !

[Max_R]

Per quei pochi limiti multiboot

[!fazz]

Originariamente inviato da battilei

lascia perdere
per te è meglio questa

14g

[PaulGuru]

Originariamente inviato da Max_R

Per quei pochi limiti multiboot

O magari basterebbe piazzare una GUI unica e basta.

[pabloski]

Originariamente inviato da PaulGuru

O magari basterebbe piazzare una GUI unica e basta.

Magari piazziamo un singolo sistema operativo, dai mainframe ai tostapane. Poi piazziamo un solo modello di auto, tanto le varianti creano solo confusione. E potrei continuare all'infinito.

Scelta e' evoluzione. E' il meccanismo grazie al quale siamo usciti dalle caverne. L'appiattimento non ha mai portato a nulla di buono.

E comunque non vedo il problema nell'avere questo o quel DE. E non capisco cosa intendi per incompatibilita' con le applicazioni, dato che posso far girare applicazioni KDE sotto Gnome, Xfce, i3, senza problemi.

[andy45]

Originariamente inviato da pabloski

E comunque non vedo il problema nell'avere questo o quel DE. E non capisco cosa intendi per incompatibilita' con le applicazioni, dato che posso far girare applicazioni KDE sotto Gnome, Xfce, i3, senza problemi.

Forse intende il discorso dipendenze, usare una applicazione di kde in xfce ad esempio corrisponde al dover installare quasi l'intero kde, se non tutto...cosa che si può fare tranquillamente, ma che in genere viene evitata perchè solitamente poco conveniente, magari l'applicazione in se occupa pochi mb e ha invece centinaia di mb di dipendenze...certo se ti serve quel particolare programma installi e basta, senza starci a pensare.

[PaulGuru]

Originariamente inviato da andy45

Forse intende il discorso dipendenze, usare una applicazione di kde in xfce ad esempio corrisponde al dover installare quasi l'intero kde, se non tutto...cosa che si può fare tranquillamente, ma che in genere viene evitata perchè solitamente poco conveniente, magari l'applicazione in se occupa pochi mb e ha invece centinaia di mb di dipendenze...certo se ti serve quel particolare programma installi e basta, senza starci a pensare.

Esattamente.