Torvalds: non cambiamo lo sviluppo del kernel

In un messaggio, il padre di Linux risponde ad alcuni dei più comuni dubbi avanzati dalla comunità e riguardanti i metodi di sviluppo e rilascio del kernel

Roma - Con l'annuncio dell'inizio dello sviluppo del nuovo kernel di Linux, diversi esponenti della comunità open source, come anche molti nostri lettori sul forum della notizia pubblicata ieri, hanno avanzato critiche vecchie e nuove sull'attuale metodo di sviluppo e rilascio dei nuovi kernel di Linux.

Il padre di Linux, Linus Torvalds, offre una risposta concisa ad alcuni di questi interrogativi in un messaggio di risposta a Mike Fedyk, un membro della comunità Linux che rivolge a Torvalds alcuni dubbi espressi da tanta parte del mondo open source.

Qui di seguito riportiamo la libera traduzione del messaggio di Torvalds.
(Le parti tratte dal messaggio di Fedyk e quotate da Torvalds sono in corsivo).
"Personalmente, penso che la 2.4 sia stata rilasciata troppo presto. È stato quando lo hype su Internet era al massimo e a nessuno (compreso me stesso) poteva venir fatta una colpa del fatto di essere stato travolto da quest'onda.

Credo non sia questo il problema.

(Il kernel) 2.4.0 era appropriato per quel tempo. Il problema con qualsiasi grosso rilascio è che la gente che tu vorresti veramente effettuasse il test non lo fa fino a che questo non diviene stabile, e tu non puoi renderlo stabile fino a che non hai un grande numero di tester. In breve, è il classico problema dell'uovo e della gallina.

Puoi trovare la stessa cosa (in dimensione ridotta) con le pre-patch, dove un sacco di persone finiscono per testare le patch finali, e inevitabilmente ci sono problemi più sentiti con le versioni "reali" che con le pre-patch. Statisticamente, dovresti semplicemente renderti conto che questo non è vero ;)

1) Sviluppa la 2.5 fino a che non è pronta per essere la 2.6 e passala immediatamente ad un altro manutentore e inizia la 2.7

Vorrei farlo, ma in effetti non funziona molto bene. Semplicemente perché non appena si arriva alla stabilità, ci saranno sicuramente delle cose che chi è a capo dello sviluppo non noterà, o non realizzerà quanto possano essere importanti per la gente nel mondo reale.

Quindi - secondo te Mike - io dovrei rilasciare là fuori una 2.6 e partire con la serie 2.7, ma questo porterebbe con sé due problemi veramente gravi.

(a) Non mi piace affatto dare qualcosa di malfatto a chiunque sia il manutentore del kernel stabile. Semplicemente non funziona in questo modo: chiunque voglia manutenere un kernel stabile di questo tipo sarebbe un idiota e un vero masochista.

(b) Anche se io trovassi un masochista abbastanza intelligente per essere un buon manutentore, l'albero dello sviluppo ha troppo bisogno di partire da un "punto conosciuto come ragionevolmente buono". Non deve essere perfetto, ma deve essere "conosciuto".

Nel bene o nel male, ora abbiamo che con la 2.4.x il sistema sembra essere piuttosto stabile, con giusto qualche problema di poco conto per il quale si conosce la soluzione e che non è difficile da gestire. Quindi il rilascio 2.5.x è un buon punto di partenza, cosa che semplicemente non sarebbe stata se io fossi partito direttamente dalla 2.4.0.

La vera soluzione è quella di fare pochi cambiamenti fondamentali fra kernel stabili, e questa è una soluzione che io credo diventerà sempre più realistica mano a mano che il kernel diventerà più stabile. Io credo che già la 2.5 avrà molti meno cambiamenti fondamentali di quanto l'albero della 2.3.x abbia mai avuto: gli sforzi per la scalabilità SMP e la page-cachification fra la 2.2.x e la 2.4.x sono stati un cambiamento piuttosto grosso.

Ma devi anche capire che "meno cambiamenti fondamentali" è indizio di un sistema che si sta evolvendo non troppo velocemente e che sta raggiungendo la mezza età. Probabilmente non siamo ancora arrivati a questo punto ;)

Linus"
65 Commenti alla Notizia Torvalds: non cambiamo lo sviluppo del kernel
Ordina
  • come da topic... ragazzi ho messo su la RH7.2 e:
    kernel 2.4.9: NTFS compilation error
    kernel 2.4.9-2.4.12: Sound modules compilation error
    kernel 2.4.9+: quando il sistema gira con sti kernel la rete la devo impostare a mano ogni avvio con ifconfig e route.. col kernel della rh grezzo va, ma se nn lo ricompilo lo sfrutto molto l'athlon..

    L'unica cosa positiva: server mio su RH7.1 con kernel 2.4.7, uptime da 87 giorni e tutto ok

    tatao
    non+autenticato
  • Io col 2.4.9 non ho mai incontrato problemi, compilato su una Red Hat 7.1, ci gira un server linux destinato prevalentemente a Oracle; tuttavia ti suggerisco il 2.4.12; oppure il 2.4.16 che dovrebbe essere in max un 2.4.15 privo di errori di programmazione.
    non+autenticato
  • - Scritto da: MADagency
    > L'unica cosa positiva: server mio su RH7.1
    > con kernel 2.4.7, uptime da 87 giorni e
    > tutto ok

    Cosa ne dici di ricompilare il kernel stock? Così sfrutti l'Athlon e hai quello testato da Red Hat... fai anche meno fatica a configurarlo, dato che ci sono i file di configurazione che hanno usato loro.

    P.S. Cmq anche compilando il kernel, le differenze non è che siano così evidenti, otterresti molto di più ricompilando tutto (o almeno le glibc).
    non+autenticato


  • - Scritto da: MADagency
    > come da topic... ragazzi ho messo su la
    > RH7.2 e:
    > kernel 2.4.9: NTFS compilation error

    si questo e' vero. il driver NTFS non compila. Sarebbe anche ora che lo rendessero decente quel modulo. Ancora oggi hai l'accesso solo in lettura, e in scrittura hai il 90 % di sputtanare la partizione NTFS (oddio... non che sia una gran perdita...)

    > kernel 2.4.9-2.4.12: Sound modules
    > compilation error

    questo no. L'ho provato e va.

    > kernel 2.4.9+: quando il sistema gira con
    > sti kernel la rete la devo impostare a mano
    > ogni avvio con ifconfig e route.. col kernel
    > della rh grezzo va, ma se nn lo ricompilo lo
    > sfrutto molto l'athlon..

    mi sa strano... sei sicuro di aver messo i moduli giusti? al limite mandami il tuo .config (lo trovi in /usr/src/linux) che ci do un'occhiata

    > L'unica cosa positiva: server mio su RH7.1
    > con kernel 2.4.7, uptime da 87 giorni e
    > tutto ok

    io ho dovuto reboottare una settimana fa, dopo 70 giorni. Causa: la ventola dell'alimentatore che cigolava. Per cambiarla ho dovuto aprire l'alimentatore e dato che non sono molto in confidenza con la 220....

    non+autenticato
  • Un paio di commenti interessanti da linuxtoday.com (solo inglese, scusate...)

    """
    What part of "Release Early, Release Often" did people forget? We went through similar issues back in 2.2.x and it wasn't that big of a deal back then. Guess people have selective memories...


    _It's always been like this_. Throughout the history of Linux stable and devel branches there have been "paperbag" releases and renamed kernels on the ftp sites. It was the same with 2.0.x, 2.2.x, and now 2.4.x.


    Also, are you paying him to do QA? Good QA for something like this could takes weeks and access to resources such as machines and people. He does what he likes and he admits he sucks at QA and maintaining, which is why he always hands off the stable branch when he feels hes nailed all the obnoxious bugs. You don't like the job hes doing, then either fork over some cash (aka use a distribution that does QA), do it yourself, or don't use Linux. _It's always been that way and will continue to be that way_.


    People think they are entitled to something now that Linux is popular or something, what BS.


    Linux is Linux. It isn't going to change because some pompous asses think things should change for them. If you don't want to do QA yourself, then fork over a few bucks for a copy of Redhat. It works wondersOcchiolino


    I have several Redhat 7.1 and Redhat 7.2 boxes running with 80-120+ days uptime (squid cluster, oracle database, various webservers) serving 3,000 or so users with 0 probs. Back in the 2.2.x days I tracked kernel issues and compiled my own kernels due to the lack of reiserfs support (yummy... squid+reiserfs) in the main tree, etc. These days I don't have to do that. I use Redhat's kernels in RH 7.1 and 7.2 and they have proven themselves to be well tested and very stable even under high oracle loads.


    If your not competent enough to track kernels and test them yourself then use your distributions kernel. Or switch to solaris (heh, their kernel patch lists are scary themselves... had a few workstations where the original solaris 8 kernel panic'd every week or two) or to a *BSD which have slower development pace due to the decision to tie in the kernel with the rest of the system and have a -STABLE release every six months or so.
    """

    - - 8< - - -

    """
    The truth about kernel releases is that they can be classified
    in at least 6 stages.

    1) Heavy development, i.e. 2.3.0 - 2.3.x
    (unreliable by definition)
    2) Pre test release, i.e. 2.3.99
    ("suicide" mode)
    3) Alpha test releases, i.e. 2.4.0testxx
    (risk mode)
    4) Beta test releases, i.e. 2.4.0 - 2.4.15 (until Linus manages them directly)
    (moderate risk mode)
    5) Maintenance releases, i.e. 2.4.16 - 2.4.30 (3 - 10 versions per year)
    (safe mode)
    6) Freeze mode releases, i.e. > 2.4.30 (max. 1 - 2 versions per year)
    (known safe mode)

    At the end of this process, last kernel may be considered really stable.
    """
    non+autenticato
  • [censura]

    Mi censuro da soloSorpresa)

    SVEGLIA TORVALDS!!!!
    non+autenticato
  • ..Linus non vuol rovinare il suo pinguino
    andando troppo di fretta...

    certo che aspettare 10+ mesi per una nuova versione e' triste ://
    non+autenticato
  • io questi discorsi non li capisco... perchè è triste? Vuoi un software probabilmente buggato? Bene, ti scarichi un software in beta! Vuoi un software ragionevolmente sicuro? Bene, ti scarichi una versione stabile! Il grosso problema è quando un software viene fatto passare per stabile quando in realtà richiederebbe ancora tempo per essere sviluppato; questo problema, come chiunque può confermare, è tipico di prodotti commerciali, dove qualcuno ha investito grosse somme di denaro per ottenere dei risultati e prima o poi si ritrova scontento per la lentezza dello sviluppo. Ora, chiunque abbia sviluppato software o distribuzioni particolari in ambito commerciale sa che questo avviene REGOLARMENTE: prima o poi, probabilmente in una fase di sviluppo avanzata, arriverà il tuo capo e ti romperà i maroni perchè tu rilasci una versione completa, poco importa se non troppo stabile. Questo per due motivi: 1) (PALESE) il capo vuole iniziare a vendere il progetto, ergo devi sbrigarti a tirar fuori una versione completa
    2) (SUBDOLO) se tiri fuori una versione buggata ma completa e riesci a venderla lo stesso, guadagnerai anche con gli aggiornamenti e con le manutenzioni.
    Io credo che chiunque lavori in ambito commerciale sappia questo... o almeno a me sembra un discorso limpido...
    Per quanto riguarda prodotti non commerciali, tipo il kernel di linux, l'approcio a problemi relativi a bug è completamente diverso poichè non devi certo affrettarti a tirar fuori un nuovo kernel solo per venderlo, visto che NON è in vendita. Scaricare un kernel in sviluppo significa automaticamente essere consci di poter riscontrare dei problemi + o - grossi ed essere pronto a contribuire per migliorare il prodotto... ma questo discorso nel mondo linux non vale solo per prodotti instabili, e chi non ha recepito questo discorso allora non ha recepito la filosofia di fondo... saluti
    non+autenticato

  • > Per quanto riguarda prodotti non
    > commerciali, tipo il kernel di linux,
    > l'approcio a problemi relativi a bug è
    > completamente diverso poichè non devi certo
    > affrettarti a tirar fuori un nuovo kernel
    > solo per venderlo, visto che NON è in
    > vendita. Scaricare un kernel in sviluppo
    > significa automaticamente essere consci di
    > poter riscontrare dei problemi + o - grossi
    > ed essere pronto a contribuire per
    > migliorare il prodotto... ma questo discorso
    > nel mondo linux non vale solo per prodotti
    > instabili, e chi non ha recepito questo
    > discorso allora non ha recepito la filosofia
    > di fondo... saluti

    Rileggiti il messaggio di torvalds.
    Lui stesso ammette di aver rilasciato il 2.4 sotto l'effetto dell'hype prodotto dalla comunita'.
    Eppure l'smp continua a funzionare a smozzichi e bocconi, pur essendo stato introdotto dal kernel 2.2.

    Evidentemente, anche gli sviluppatori open source sono esseri umani, fatti di ossa, muscoli e peli,
    che hanno emozioni...Sorride

    Ciao
    non+autenticato


  • - Scritto da: maks

    > Rileggiti il messaggio di torvalds.
    > Lui stesso ammette di aver rilasciato il 2.4
    > sotto l'effetto dell'hype prodotto dalla
    > comunita'.

    Rileggitelo tu, amigo...
    la parte che inizia con "credo che la 2.4" è di Fedyk.
    Torvalds risponde che lo riteneva maturo e che il problema è il numero dei tester...
    Eppure è scritto chiaro che le parti quotate sono in corsivo ;P

    > Evidentemente, anche gli sviluppatori open
    > source sono esseri umani, fatti di ossa,
    > muscoli e peli,
    > che hanno emozioni...Sorride

    Bè, questo si è sempre saputo, semmai a parer di metallo e plastica sono quelli che stanno dall'altra parte della barricata IMHO
    alhoa!
    non+autenticato
  • > > Rileggiti il messaggio di torvalds.
    > > Lui stesso ammette di aver rilasciato il
    > 2.4
    > > sotto l'effetto dell'hype prodotto dalla
    > > comunita'.
    >
    > Rileggitelo tu, amigo...
    > la parte che inizia con "credo che la 2.4" è
    > di Fedyk.
    > Torvalds risponde che lo riteneva maturo e
    > che il problema è il numero dei tester...
    > Eppure è scritto chiaro che le parti quotate
    > sono in corsivo ;P
    >

    anche per te figliuolo

    http://slashdot.org/comments.pl?sid=24146&threshol...

    It all fine and good to say that more people should help testing a development release, but kernel 2.4 is not a development release. If your point is that the 2.3 tree was not sufficiently tested, I agree. However, I'm not a kernel hacker, and anyone who installed a 2.4 "stable" kernel should have been able to expect stability. Experiments are for the development kernels; there were too many experiments included in the 2.4 kernel to make me comfortable with it. I'll wait for the experiments to end and the kernel to stabilize.


    > > Evidentemente, anche gli sviluppatori open
    > > source sono esseri umani, fatti di ossa,
    > > muscoli e peli,
    > > che hanno emozioni...Sorride
    >
    > Bè, questo si è sempre saputo, semmai a
    > parer di metallo e plastica sono quelli che
    > stanno dall'altra parte della barricata IMHO
    >

    noooo
    quelli sono quelli che cedono piu' facilmente alla tentazione del vil denaro, che fanno project planning, che si danno delle scadenze...
    sono piu' umani di tutti...

    a mio avviso dei pazziSorride

    ciao
    non+autenticato


  • - Scritto da: maks
    > anche per te figliuolo

    anche per me, cosa?
    Scusa ma non capisco

    >
    > http://slashdot.org/comments.pl?sid=24146&thr
    >
    > It all fine and good to say that more people
    > should help testing a development release,
    > but kernel 2.4 is not a development release.
    > If your point is that the 2.3 tree was not
    > sufficiently tested, I agree. However, I'm
    > not a kernel hacker, and anyone who
    > installed a 2.4 "stable" kernel should have
    > been able to expect stability. Experiments
    > are for the development kernels; there were
    > too many experiments included in the 2.4
    > kernel to make me comfortable with it. I'll
    > wait for the experiments to end and the
    > kernel to stabilize.

    Mah... capisco il punto di Pichter ma le distro esistono apposta per avere dei kernel iperstabili.
    Poi le modifiche delle distro, di solito, tornano nell'albero del Kernel ed il cerchio si chiude.


    >
    > > > Evidentemente, anche gli sviluppatori
    > open
    > > > source sono esseri umani, fatti di
    > ossa,
    > > > muscoli e peli,
    > > > che hanno emozioni...Sorride
    > >
    > > Bè, questo si è sempre saputo, semmai a
    > > parer di metallo e plastica sono quelli
    > che
    > > stanno dall'altra parte della barricata
    > IMHO
    > >
    >
    > noooo
    > quelli sono quelli che cedono piu'
    > facilmente alla tentazione del vil denaro,
    > che fanno project planning, che si danno
    > delle scadenze...
    > sono piu' umani di tutti...
    >
    > a mio avviso dei pazziSorride

    Pazzi non direi, ma non mi dirai che con la loro sicurezza di "Noi non possiamo sbagliare! Noi facciamo quello che è giusto" non ricordino in certi momenti più Terminator che i GhostbusterOcchiolino
    Alhoa
    non+autenticato


  • - Scritto da: Martino
    > ..Linus non vuol rovinare il suo pinguino
    > andando troppo di fretta...
    >
    > certo che aspettare 10+ mesi per una nuova
    > versione e' triste ://

    Tu sei gia' sicuro che la nuova versione avra' caratteristiche a te indispensabili?

    Sinceramente io non capisco la fretta... come al solito mentre procede la fare di sviluppo della serie 2.5.x verranno piano piano fatte le aggiunte e sistemata la serie 2.4.x... avere una 2.6.0 in 5 mesi, con aggiunte minime non mi sembra particolarmente attraente, tanto vale continuare come si e' sempre fatto e rilasciare una major quando "c'e' veramente una marcia in piu'" e non quando cambia qualcosina... sti giochini da marchettari cose lasciamole a qulcun'atro!Sorride

    bye
    non+autenticato


  • - Scritto da: Martino
    > ..Linus non vuol rovinare il suo pinguino
    > andando troppo di fretta...
    >
    > certo che aspettare 10+ mesi per una nuova
    > versione e' triste ://

    Ti giro la domanda: Ma a che cacchio serve una nuova versione????
    Mi spiego, che necessità hai di avere una nuova versione?
    Hai precepito la non ottimizzazione della VM durante l'esecuzione di un tuo programmino?
    Hai vermanete necessità di operare con archivi > di 2 Terabyte?
    Dell'attuale 2.4, cosa veramente ti serve rispetto al 2.2?
    A parte l'USB... chi di voi aveva necessità di far funzionare 2+ processori in modo ottimizzato?

    Cio di cui necessita veramente Linux, non è un nuovo kernel, che per inteso, è giusto sviluppare e progredire, sono un supporto dei driver da parte delle aziende.
    Se anche domani mattina, Linus sfornasse la 2.10, io non noterei differenza, e così la maggior parte degli utilizzatori.
    Pochi hanno la possibilità di avere bisogno delle ultime innovazioni dei Kernel, altrimenti, nessuno userebbe NT/2000/XPSorride

    Quindi, inutile polemizzare sulla lentezza dello sviluppo del kernel. Le modifiche che si stanno facendo, sono molte di + di quelle che non hanno fatto Gates & CO in 5 anni di sviluppo di NT/2000/XP.

    A meno che, non pensi che con una nuova versione del Kernel, si avranno colori migliori sul desktop, e tutte le menate di Winzoz... Perchè vuol dire che se si parla di linux, non sai nemmeno a cosa si riferisce..
    non+autenticato
  • Torvalds: "Nel bene o nel male, ora abbiamo che con la 2.4.x il sistema sembra essere piuttosto stabile, con giusto qualche problema di poco conto per il quale si conosce la soluzione e che non è difficile da gestire"

    poi vado su slashdot e leggo:

    released Kernel 2.4.16. Download it here, and you can read the changelog here. This hopefully fixes the error that 2.4.15 had of corrupting filesystems on unmount

    e meno male che il buon torvalds ci assicura che la 2.4.x ha solo errori di poco contoSorride

    hopefully (dal garzanti) significa:

    1 fiduciosamente, con buone speranze
    2 se tutto va bene.

    ergo, neanche sono sicuri di averlo risolto

    senza offesa linus....

    ciao
    non+autenticato


  • - Scritto da: maks
    > Torvalds: "Nel bene o nel male, ora abbiamo
    > che con la 2.4.x il sistema sembra essere
    > piuttosto stabile, con giusto qualche
    > problema di poco conto per il quale si
    > conosce la soluzione e che non è difficile
    > da gestire"
    >
    > poi vado su slashdot e leggo:
    >
    > released Kernel 2.4.16. Download it here,
    > and you can read the changelog here. This
    > hopefully fixes the error that 2.4.15 had of
    > corrupting filesystems on unmount
    >
    > e meno male che il buon torvalds ci assicura
    > che la 2.4.x ha solo errori di poco contoSorride
    >
    > hopefully (dal garzanti) significa:
    >
    > 1 fiduciosamente, con buone speranze
    > 2 se tutto va bene.
    >
    > ergo, neanche sono sicuri di averlo risolto
    >
    > senza offesa linus....

    diamo la 2.4.16 da testare a cossiga e tutta la sua ciurma...

    non+autenticato
  • 2.4.15 e una versione instabile scemo..


    > Torvalds: "Nel bene o nel male, ora abbiamo
    > che con la 2.4.x il sistema sembra essere
    > piuttosto stabile, con giusto qualche
    > problema di poco conto per il quale si
    > conosce la soluzione e che non è difficile
    > da gestire"
    >
    > poi vado su slashdot e leggo:
    >
    > released Kernel 2.4.16. Download it here,
    > and you can read the changelog here. This
    > hopefully fixes the error that 2.4.15 had of
    > corrupting filesystems on unmount
    >
    > e meno male che il buon torvalds ci assicura
    > che la 2.4.x ha solo errori di poco contoSorride
    >
    > hopefully (dal garzanti) significa:
    >
    > 1 fiduciosamente, con buone speranze
    > 2 se tutto va bene.
    >
    > ergo, neanche sono sicuri di averlo risolto
    >
    > senza offesa linus....
    >
    > ciao
    non+autenticato
  • > 2.4.15 e una versione instabile scemo..
    >

    asi'?
    adesso hanno cambiato tutto?
    perche' per me 2.5.x e' unstable
    2.4.x DEVE ESSERE STABLE!!!

    scusa, ma lo scemo qua sei tu...

    comunque raga'.. mancate di senso dell'umorismo
    totalmente!

    ciao
    non+autenticato
  • > > 2.4.15 e una versione instabile scemo..
    > >
    >
    > asi'?
    > adesso hanno cambiato tutto?
    > perche' per me 2.5.x e' unstable
    > 2.4.x DEVE ESSERE STABLE!!!
    mea culpa...ma vista l'ora...
    ;-0)

    > scusa, ma lo scemo qua sei tu...
    >
    > comunque raga'.. mancate di senso
    > dell'umorismo
    > totalmente!
    non direi...comunque ero a pezzi...

    >
    > ciao
    non+autenticato
  • - Scritto da: blah
    > 2.4.15 e una versione instabile scemo..

    Non mi risulta.

    Ciao
    Diego
    non+autenticato
  • perchè gli altri come ms, scrivono di meglio quando installi un hotfix o un service pack?
    vai un pò a leggere..Sorride
    non+autenticato
  • > perchè gli altri come ms, scrivono di meglio
    > quando installi un hotfix o un service pack?
    > vai un pò a leggere..Sorride

    si dice: mal comune, mezzo gaudio...
    cmq era solo una battuta... ma nessuno ha saputo
    dare una risposta divertente
    tranne il tizio che ha proposto di far collaudare il 2.4.16 a CossigaSorride

    non e' che davanti a queste cose non sapete cosa rispondere, se non che windows (o meglio i suoi applicativi) ha piu' bug?

    ciao
    non+autenticato

  • Ciao,

    > non e' che davanti a queste cose non sapete
    > cosa rispondere, se non che windows (o
    > meglio i suoi applicativi) ha piu' bug?
    >
    > ciao

    No, semplicemente io non farei un'analisi linguistica sul significato di uan parola inglese, quanto mi andrei a leggere il Changelog per vedere quali bug hanno fissato e come. Poi, fatto questo, se i fix penso mi possano andare bene, mi compilo il kernel e lo testo. Poi magari scrivo al mantainer del kernel e gli dico secondo me cosa c'e' che non va.
    Poi i problemi di windows sono di chi usa windows, non miei di certoSorride)

    P.S. A Cossiga gli sta bene windows e mi auguro di non vederlo mai usare os open-sourceCon la lingua fuoriP
    non+autenticato
  • - Scritto da: Amon
    > perchè gli altri come ms, scrivono di meglio
    > quando installi un hotfix o un service pack?
    > vai un pò a leggere..Sorride

    Cosa c'entra MS? Possibile che ogni volta che si parla di Linux debba essere fatto il confronto con MS, e viceversa?

    Ciao
    Diego

    Guarda te che mi tocca fare un post a favore di MicroSoft! Incredibile!
    non+autenticato
  • - Scritto da: Diego
    > Cosa c'entra MS?

    Non ho preso l'esempio di una macelleria, ma del colosso nr 1 dell'informatica, e stiamo parlando di s.o. e relative patch.

    > Possibile che ogni volta
    > che si parla di Linux debba essere fatto il
    > confronto con MS, e viceversa?

    Si è possibile. Perchè se tale ms con quello che guadagna con windows non riesce a dare un minimo di garanzia per gli hotfix ed i service pack, non vedo perchè meravigliarsi tanto se non possono darne di più entità che a confronto in cifra d'affari sono una goccia d'aqua nell'oceano...

    Vuoi fare confronti con altri sistemi? Ben venga, io ho preso l'estremo, quello che secondo me è più significativo.
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 6 discussioni)