Alfonso Maruccia

Linux, verso una release acchiappa-bug

Linus Torvalds annuncia il rilascio di una nuova versione del kernel FOSS, e per il futuro promette una release di transizione in cui i lavori di sviluppo saranno dedicati tutti alla correzione di bug nel codice

Roma - La versione 4.0 di Linux sarà una release tutta dedicata al bug-hunting, o almeno è questa la proposta che fa Linus Torvalds sulla mailing list del Pinguino: il padre del kernel FOSS annuncia la finalizzazione dei lavori su Linux 3.12, e contemporaneamente apre il dibattito sulla ipotetica fase di transizione senza l'aggiunta di nuove caratteristiche o funzionalità.

Torvalds non la manda a dire ed è noto per il suo atteggiamento tirannico (iperprotettivo?) nella gestione dei lavori sul codice di Linux, ma almeno questa volta il tecnologo finlandese si dice aperto ai commenti degli sviluppatori linari sulla proposta di dedicare una release esclusivamente alla correzione di bachi vecchi e nuovi.

L'idea, spiega Torvalds, era stata originariamente perorata da Dirk Hohndel durante la conferenza LinuxCon EU e lui l'aveva accolta con la solita reazione colorita (negativa) lamentando la scarsa soglia dell'attenzione di "molto di noi" (riferito agli sviluppatori di Linux) rispetto alle energie necessarie al compito proposto.
Ma se per ipotesi si sapesse in anticipo lo scopo definito di una release futura e fissa nel tempo, sostiene ora Torvalds, agli sviluppatori potrebbe anche venire la voglia di impegnarsi per lo scopo comune. La scelta della versione 4.0 per la caccia ai bachi? L'occasione perfetta per introdurre un nuovo periodo dello sviluppo del Pinguino, commenta Torvalds.

La proposta di una release dedicata ai soli bug nel codice coincide come detto con la pubblicazione di Linux 3.12, versione del kernel che tra le altre cose porta in dote svariate novità soprattutto sul fronte delle prestazioni con l'hardware AMD (APU e GPU discrete), un supporto migliorato alla tecnologia NVIDIA Optimum per i sistemi con doppia GPU (integrata nel dye della CPU+discreta), e vari miglioramenti ai file system EXT4, F2FS, XFS e Brtfs.

Non contento di aver "partorito" un nuovo Pinguino e di aver messo sul tavolo l'idea della release acchiappa-bug, Torvalds ha infine trovato il tempo anche per commentare la distribuzione gratuita di Mavericks da parte di Apple: che Cupertino dia gratis il suo OS agli utenti non significa nulla, dice Torvalds, perché l'obiettivo principale di Apple è sfruttare il software per vendere il suo costoso hardware. Il cambio di policy è semplicemente ininfluente nei confronti del codice open source di Linux e degli OS basati su di esso, chiosa Torvalds.

Alfonso Maruccia
Notizie collegate
  • TecnologiaLinux e le parolacce di LinusScrezi sulla mailing list. Al centro della polemica la tendenza di Torvalds a usare il turpiloquio. Che chiude ogni polemica e affibbia un soprannome alla versione 3.11 del kernel
  • TecnologiaApple regala tuttodi D. Galimberti - Mavericks, iWork e iLife diventano un accessorio compreso nel prezzo. E poi ci sono nuovi iPad, nuovi MacBook e finalmente il Mac Pro. Tanta carne a cuocere allo Yerba Buena Center di San Francisco
123 Commenti alla Notizia Linux, verso una release acchiappa-bug
Ordina
  • Linux sta diventando un kernel troppo ciccione, dovrebbero fare un sistema operativo, mentre tutto gira a livello kernel con rischi seri per la sicurezza
    non+autenticato
  • - Scritto da: karmando
    > Linux sta diventando un kernel troppo ciccione,
    > dovrebbero fare un sistema operativo, mentre
    > tutto gira a livello kernel con rischi seri per
    > la
    > sicurezza

    Meglio se vai a dare un'occhiata all'architettura modulare e poi ritorni a postare. Per il momento non ne hai presa mezza.
  • - Scritto da: PinguinoCattivo
    > Meglio se vai a dare un'occhiata all'architettura
    > modulare e poi ritorni a postare.

    praticamente invece che un bisonte hai tante mucche, il peso non cambia!
    non+autenticato
  • - Scritto da: Martino
    > - Scritto da: PinguinoCattivo
    > > Meglio se vai a dare un'occhiata
    > all'architettura
    > > modulare e poi ritorni a postare.
    >
    > praticamente invece che un bisonte hai tante
    > mucche, il peso non
    > cambia!

    Sì, ma alcune mucche invece che portarle al pascolo puoi lasciarle nella stalla (ovvero non caricare i moduli inutili all'avvio), oppure puoi proprio lasciarle al mercato del bestiame (ovvero: ti compili un kernel su misura, più snello e adatto alle tue esigenze!)
    non+autenticato
  • Quelli in cui c'erano le minor release pari stabili e quelle dispari, sperimentali.

    Dicevano di avere raggiunto il giusto grado di stabilità, le hanno tolte e adesso si trovano con qualche "debolezza strutturale" da rimettere in piedi (diversamente non saprei definire uno scheduler NUMA sperimentale che non funziona).

    Vabbè ... ben vengano le release così, un po` di reingegnerizzazione non fa mai male, specialmente a quelli che usano troppo disinvoltamente le experimentale, cioè il 90% delle distribuzioni.
    non+autenticato
  • sai qual'è il vero problema? è che, a distanza di 20 anni, ha avuto ragione Tanenbaum

    a me, l'idea di ficcare di tutto e di più in kernel space non è mai piaciuta, proprio per i motivi che poi spingono a dover rivedere massicciamente il codice

    non che linux abbia chissà quali terribili bug ( lo uso ogni santo giorno e di certo non mi è ancora crollato il soffitto in testa ), però si accumulano troppo velocemente

    non avendo modo d'imporre una specifica direzione allo sviluppo del kernel ( che porterebbe solo ad un rallentamento e minerebbe la flessibilità del kernel stesso ), l'unica sarebbe di adottare l'architettura a microkernel, in modo da imporre una netta separazione tra i vari componenti
    non+autenticato
  • - Scritto da: collione
    > sai qual'è il vero problema? è che, a distanza di
    > 20 anni, ha avuto ragione
    > Tanenbaum
    >
    > a me, l'idea di ficcare di tutto e di più in
    > kernel space non è mai piaciuta, proprio per i
    > motivi che poi spingono a dover rivedere
    > massicciamente il
    > codice
    >
    Eppure lo fanno TUTTI, chissà come mai?A bocca aperta
    non+autenticato
  • - Scritto da: Dr Doom
    > - Scritto da: collione
    > > sai qual'è il vero problema? è che, a
    > distanza
    > di
    > > 20 anni, ha avuto ragione
    > > Tanenbaum
    > >
    > > a me, l'idea di ficcare di tutto e di più in
    > > kernel space non è mai piaciuta, proprio per
    > i
    > > motivi che poi spingono a dover rivedere
    > > massicciamente il
    > > codice
    > >
    > Eppure lo fanno TUTTI, chissà come mai?A bocca aperta

    Forse perché è semplicemente più facileOcchiolino
  • - Scritto da: Albedo 0,9
    > - Scritto da: Dr Doom
    > > - Scritto da: collione
    > > > sai qual'è il vero problema? è che, a
    > > distanza
    > > di
    > > > 20 anni, ha avuto ragione
    > > > Tanenbaum
    > > >
    > > > a me, l'idea di ficcare di tutto e di
    > più
    > in
    > > > kernel space non è mai piaciuta,
    > proprio
    > per
    > > i
    > > > motivi che poi spingono a dover rivedere
    > > > massicciamente il
    > > > codice
    > > >
    > > Eppure lo fanno TUTTI, chissà come mai?A bocca aperta
    >
    > Forse perché è semplicemente più facileOcchiolino
    O da prestazioni nettamente migliori?
    non+autenticato
  • - Scritto da: Dr Doom
    > - Scritto da: Albedo 0,9
    > > - Scritto da: Dr Doom
    > > > - Scritto da: collione
    > > > > sai qual'è il vero problema? è
    > che,
    > a
    > > > distanza
    > > > di
    > > > > 20 anni, ha avuto ragione
    > > > > Tanenbaum
    > > > >
    > > > > a me, l'idea di ficcare di tutto e
    > di
    > > più
    > > in
    > > > > kernel space non è mai piaciuta,
    > > proprio
    > > per
    > > > i
    > > > > motivi che poi spingono a dover
    > rivedere
    > > > > massicciamente il
    > > > > codice
    > > > >
    > > > Eppure lo fanno TUTTI, chissà come mai?
    >A bocca aperta
    > >
    > > Forse perché è semplicemente più facileOcchiolino
    > O da prestazioni nettamente migliori?


    Le prestazioni sono migliori, vero, però restano tali a livello kernel.

    Quello che guadagni la maggior parte degli utenti poi lo butta quando installa pachidermi come KDE4 o simili..

    Anche lato rete, pure Apache è usato troppo.
    Molte applicazioni web girerebbero benissimo anche con Lighttpd o Nginx, ma di default i più usano Apache.

    Un microkernel aiuterebbe di sicuro in affidabilità e modularità (es: driver proprietari di ditte esterne), mentre una ottimizzazione del parco software attuale è pur sempre auspicabile... ma questa è e resta una pura utopia.
  • - Scritto da: _bubu_
    > - Scritto da: Dr Doom
    > > - Scritto da: Albedo 0,9
    > > > - Scritto da: Dr Doom
    > > > > - Scritto da: collione
    > > > > > sai qual'è il vero problema? è
    > > che,
    > > a
    > > > > distanza
    > > > > di
    > > > > > 20 anni, ha avuto ragione
    > > > > > Tanenbaum
    > > > > >
    > > > > > a me, l'idea di ficcare di
    > tutto
    > e
    > > di
    > > > più
    > > > in
    > > > > > kernel space non è mai
    > piaciuta,
    > > > proprio
    > > > per
    > > > > i
    > > > > > motivi che poi spingono a
    > dover
    > > rivedere
    > > > > > massicciamente il
    > > > > > codice
    > > > > >
    > > > > Eppure lo fanno TUTTI, chissà come
    > mai?
    > >A bocca aperta
    > > >
    > > > Forse perché è semplicemente più facile
    >Occhiolino
    > > O da prestazioni nettamente migliori?
    >
    >
    > Le prestazioni sono migliori, vero, però restano
    > tali a livello
    > kernel.
    >
    > Quello che guadagni la maggior parte degli utenti
    > poi lo butta quando installa pachidermi come KDE4
    > o
    > simili..

    Quindi buttiamole via anche nel kernel, giusto?

    > Anche lato rete, pure Apache è usato troppo.
    > Molte applicazioni web girerebbero benissimo
    > anche con Lighttpd o Nginx, ma di default i più
    > usano
    > Apache.

    Sono i "programmatori" phporcari quelliA bocca aperta
    non+autenticato
  • - Scritto da: _bubu_

    > Quello che guadagni la maggior parte degli utenti
    > poi lo butta quando installa pachidermi come KDE4
    > o
    > simili..

    non c'è bisogno di scomodare kde4, basta valutare l'impatto delle librerie dinamiche e del versioning in librerie di sistema come la libc

    non è possibile perdere un 30% di performance solo perchè vogliamo fare i fighi e linkare tutto dinamicamente

    che poi il ragionamento alla base di tale follia era quello di avere un unico shared object condiviso da tanti eseguibili

    il risultato pratico è stato che ogni eseguibile si appoggia a qualche versione di un certo shared object, così abbiamo millemila .so sotto linux, la directory winsxs con decine di gigabyte di .dll sotto windows, ecc...
    non+autenticato
  • ... e (domanda da profano) perchè si è arrivati a ciò ? Non era possibile includere volta per volta nei pacchetti d'installazione le librerie necessarie al funzionamento del singolo programma ? Motivi di spazio ?
  • - Scritto da: Joe Tornado
    > ... e (domanda da profano) perchè si è arrivati a
    > ciò ? Non era possibile includere volta per volta
    > nei pacchetti d'installazione le librerie
    > necessarie al funzionamento del singolo programma
    > ? Motivi di spazio ?

    Scuole di pensiero, quando venne trovato un baco nel formato zip su linux basto' sistemare la libreria relativa, su mac e' stato necessario aggiornare ogni singolo programam visto che su mac si usa molto di piu' inserire tutte le librerie nel pacchetto.
    krane
    22544
  • - Scritto da: Joe Tornado
    > ... e (domanda da profano) perchè si è arrivati a
    > ciò ? Non era possibile includere volta per volta
    > nei pacchetti d'installazione le librerie
    > necessarie al funzionamento del singolo programma
    > ? Motivi di spazio
    > ?

    ovviamente è lo spazio uno dei problemi, tant'è che il concetto stesso di libreria condivisa si basa sulla convinzione che si possa tenere una sola copia di quei componenti usati da decine o centinaia di applicazioni

    il ragionamento era: "se tutti i programmi che girano su un computer usano la libc, perchè dovrei includere le funzioni usate da ognuno nel relativo eseguibile? in questo modo avrei N copie di determinate funzioni"

    e il discorso filerebbe pure, se tutti i programmi usassero una certa versione di una data libreria, oppure se le librerie fossero back e forward compatibili

    nella pratica ciò è impossibile ( nonchè drammatico per i poveri sviluppatori delle librerie ) e ci ritroviamo con 10-20 programmi in esecuzione sul pc, ognuno dei quali richiede una specifica versione di una certa libreria

    risultato? occupiamo lo stesso spazio che occupavamo prima ( sia in ram che su disco ), in più i programmi sono del 10-15% più lenti su x86 e del 3-5% su x86_64
    non+autenticato
  • Leggendo queste notizie uno non troppo smaliziato e smanettone si chiede: ma é piú sicuro linux o windows???
    non+autenticato
  • - Scritto da: Mario
    > Leggendo queste notizie uno non troppo smaliziato
    > e smanettone si chiede: ma é piú sicuro linux
    > o
    > windows???

    Windows di sicuro non è sicuro.
    non+autenticato
  • - Scritto da: mario

    > Windows di sicuro non è sicuro.


    Pare che anche linux non lo sia poi cosí tanto!
    non+autenticato
  • anche tu confondi bug con vulnerabilità
    non+autenticato
  • - Scritto da: collione
    > anche tu confondi bug con vulnerabilità

    E qual'é la differenza? Un bug non "risolto" diventa una vulnerabilitá.
    non+autenticato
  • - Scritto da: ciccio
    > - Scritto da: collione
    > > anche tu confondi bug con vulnerabilità
    >
    > E qual'é la differenza? Un bug non "risolto"
    > diventa una
    > vulnerabilitá.

    No che non lo diventa. Se io scrivo un programma che vuole cambiare lo sfondo facendolo diventare blu e lo fa diventare verde, spiegami dove è la vulnerabilità.
    non+autenticato
  • - Scritto da: ciccio
    > - Scritto da: collione
    > > anche tu confondi bug con vulnerabilità
    >
    > E qual'é la differenza? Un bug non "risolto"
    > diventa una
    > vulnerabilitá.

    no, le vulnerabilità sono bug, ma non tutti i bug rappresentano delle vulnerabilità

    un bug che genera una divisione per zero crasherà il programma, ma non sarà mai e poi mai sfruttabili per eseguire comandi e codice iniettati dall'esterno
    non+autenticato
  • - Scritto da: collione
    > - Scritto da: ciccio
    > > - Scritto da: collione
    > > > anche tu confondi bug con vulnerabilità
    > >
    > > E qual'é la differenza? Un bug non "risolto"
    > > diventa una
    > > vulnerabilitá.
    >
    > no, le vulnerabilità sono bug, ma non tutti i bug
    > rappresentano delle
    > vulnerabilità

    Nella maggioranza dei caso, ma volendo anche andare a sottilizzare, potremmo anche dire che non tutte le vulnerabilità sono per forza bug, visto che in alcuni rari casi potrebbero essere state inserite volontariamente: se so per esempio che c'è un malware che sfrutta una tale vulnerabilità in un programma di rete potrei averne creato apposta uno che ha quella vulnerabilità per poi "sniffare" esternamente l'attività in rete del malware che tenta di usarla.

    > un bug che genera una divisione per zero crasherà
    > il programma, ma non sarà mai e poi mai
    > sfruttabili per eseguire comandi e codice
    > iniettati
    > dall'esterno

    Già. Un programma che non parte neanche per un errore di programmazione è paradossalmente più sicuro di uno che parte, ma di certo non possiamo definirlo bug-free. A bocca aperta
    non+autenticato
  • - Scritto da: Mario
    > Leggendo queste notizie uno non troppo smaliziato
    > e smanettone si chiede: ma é piú sicuro linux
    > o
    > windows???


    Tra i due è Linux... ma ancora meglio è FreeBSD.
    Ti aggiungo inoltre che pochi giorni fa è uscito il nuovo OpenBSD 5.4 http://www.openbsd.org/
    Senza dubbio è l'OS più sicuro che ci sia, benché questo vada a discapito di feature e velocità. E' stato da sempre creato e sviluppato pensando solo alla sicurezza e nient'altro. Per esempio credo che sia stato il primo OS in assoluto a inventare l'idea del W^X (copiata poi anche da altri). Se quello che ti serve c'è là, allora dal punto di vista della sicurezza "pura" è la scelta "più ovvia" ma anche detta "perché no?".
    Con questo non intendo dire che FreeBSD non sia sicuro, ma OpenBSD ha alcune feature che (più da un punto di vista teorico-paranoico che pratico) possono contrastare alcuni exploit.
    Linux con il pax e selinux è a sua volta sufficientemente sicuro per molti utilizzi (...anche server intendo).

    Open/FreeBSD, Linux (con patch kernel), (abisso), Linux, Mac, (abisso), Windows
    non+autenticato
  • Tutto vero, ma di programmi compatibili ne trovi ben pochi, a differenza di linux.
    non+autenticato
  • se ti riferisci a freebsd, a parte qualche caso, i programmi che servono si trovano tutti

    openbsd è invece un grosso problema in questo senso, perchè hanno sacrificato supporto hardware e software per focalizzarsi sulla sicurezza
    non+autenticato
  • ma diciamoci la verita' , oramai LInux ha stancato ha perso il senso della novita, winzozz non ne parliamo,velo pietoso
    rimane solo Bsd, ma non sarebbe ora che qualcuno se ne uscisse fuori con un sistema operativo veramente nuovo e performante ?
    non+autenticato
  • bsd è sostanzialmente in linea con linux, ovvero l'ennesimo unix monolitico

    sono d'accordo che ci vorrebbe qualcosa di nuovo ma, come fa notare Rob Pike, ormai si sputa sopra la ricerca sul software di base

    siamo tutti concentrati a creare l'ennesima cazzatina facebook-compatibile

    haiku c'ha provato, però, imho, la scelta di un kernel cosidetto ibrido non è stata una mossa brillante

    inoltre stanno scantonando troppo verso il mondo gnu e linux, portandosi in casa tecnologie che andrebbero quantomeno rielaborate
    non+autenticato
  • - Scritto da: collione
    > bsd è sostanzialmente in linea con linux, ovvero
    > l'ennesimo unix
    > monolitico
    >
    > sono d'accordo che ci vorrebbe qualcosa di nuovo
    > ma, come fa notare Rob Pike, ormai si sputa sopra
    > la ricerca sul software di
    > base
    >
    > siamo tutti concentrati a creare l'ennesima
    > cazzatina
    > facebook-compatibile
    >
    > haiku c'ha provato, però, imho, la scelta di un
    > kernel cosidetto ibrido non è stata una mossa
    > brillante
    >
    > inoltre stanno scantonando troppo verso il mondo
    > gnu e linux, portandosi in casa tecnologie che
    > andrebbero quantomeno
    > rielaborate

    E allora aspettate Hurd e Singularity, che magari fra 20 anni potrete usare un computer. Rotola dal ridere
    non+autenticato
  • - Scritto da: contrario

    > E allora aspettate Hurd e Singularity, che magari
    > fra 20 anni potrete usare un computer.
    > Rotola dal ridere

    io non aspetto niente, uso quel che c'è di meglio attualmente

    volevo collaborare al progetto haiku, ma hanno preso una direzione che non condivido

    tutti gli altri progetti del genere sono ennesimi cloni unix, i pochi rivoluzionari hanno pochi seguaci

    hurd è un progetto interessante ma manca una leadership capace

    singularity era un progetto interessante, ma reso inutile dai miglioramenti prestazionali dei processori correnti
    non+autenticato
  • Adesso ci vuole addiruttura una nuova release "bug hunting".

    Ma allora anche linux è vulnerabile eh?   Occhiolino   Rotola dal ridere
    non+autenticato
  • - Scritto da: uncle Bill
    > Adesso ci vuole addiruttura una nuova release
    > "bug hunting".

    > Ma allora anche linux è vulnerabile eh?   Occhiolino
    > Rotola dal ridere

    Certo, ma almeno non tiene aperte di default 1000 porte inutiliA bocca aperta
    krane
    22544
  • - Scritto da: krane

    > Certo, ma almeno non tiene aperte di default 1000
    > porte inutili
    >A bocca aperta

    inutili? fanno girare l'economia del cybercrime, ergo non sono inutiliA bocca aperta
    non+autenticato
  • - Scritto da: uncle Bill
    > Adesso ci vuole addiruttura una nuova release
    > "bug hunting".
    >
    >
    > Ma allora anche linux è vulnerabile eh?   Occhiolino
    > Rotola dal ridere

    Eh, eh! Rotola dal ridereRotola dal ridereRotola dal ridere
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 8 discussioni)