Linux progettato male?!

[izerav]

Nei forum e nei newsgroup, si leggono spesso interventi che fanno riferimento alla cattiva programmazione di alcune parti dei sistemi Linux: c'è chi è veramente convinto di questo, chi tace, e chi dice che tutto sommato non è proprio così, ma spesso non c'è nessuno che effettivamente neghi la situazione....

Mi sorge dunque il dubbio: Linux è realmente progettato male? E quali sono i componenti più critici sotto questo punto di vista?

E poi, se anche ci fosse qualche componente sviluppata male, ma una buona e ben studiata architettura di base, non basterebbe dare una sistemata (o eventualmente riscrivere) solamente questi componenti? Oppure l'intera struttura è un po' traballante? Da come parla certa gente, sembrerebbe realmente necessario un bel colpo di straccio...

[Leron]

scusa ma cosa significa "linux è progettato male" ?


cosa intendi per "linux" ?

GNU-Linux inteso come kernel?

il kernel vanilla?

un qualche altro tipo di kernel?

qualche tipo di gui?

qualche programma?

il tipo di concezione?

un qualche tipo di distribuzione fra le migliaia esistenti?

cosa intendi per "progettato" ?

come hanno scritto il codice?

il codice di cosa in particolare? (dato che "linux" come parola vuol dire tutto e niente)
sinceramente mi sa assurda come affermazione


posso capirlo di un programma

di un tipo di concezione

di un tipo di kernel


ma dire "linux è progettato male" che significato ha?

[pinok]

Originariamente inviato da izerav

Da come parla certa gente, sembrerebbe realmente necessario un bel colpo di straccio...

Più che altro, lo si dovrebbe dire dopo averlo provato.
"certa gente" a volte si chiama Microsoft e non ci si può fare affidamente come stai facendo. Stai usando i paroloni e i dubbi che si usano in azienda per scoraggiare una soluzione rispetto ad un'altra

[izerav]

Innanzitutto, sia chiaro che non voglio generare flame. Mi scuso inoltre se qualche volta posso sembrare impreciso nel spiegare la situazione, ma questo è semplicemente dovuto al fatto che non esprimo delle "mie" considerazioni, ma ciò che ho interpretato da pareri di altre persone.

Con Linux intendo in primis il kernel: alcune persone dicono essenzialmente che il codice è tutto una toppa, e che sarebbe meglio dargli una rivisitata globale. Inoltre, ma questo non è sintomo di cattiva programmazione, si dice che l'approccio sfruttato è obsoleto. Un intervento per tutti è quello di Tanner, nella discussione su BeOS:

Originariamente inviato da Tanner

[....] E ora vediamo con Linux... Quante cose dovete fare in confronto? Non sto spalando letame su un OS che a conti fatti ha una storia fantastica, un'evoluzione avventurosa.... Sto solo cercando di capire se è stato sopravvalutato o meno, soprattutto in questo periodo di incertezze e di lamentele da parte di tutti per quanto riguarda il codice incasinato del kernel e il lavoro di patchwork che affligge tutto lo sviluppo di Linux e relative distro.Vedi Liam, c'è un problema. Noi tutti *crediamo* di avere linux e windows che vanno "una spada" con il multimedia. [....]

Ho lasciato volutamente intendere Linux in un'accezione più generale (anche quando ho scritto "sistemi Linux") in quanto anche altre componenti, non strettamente legate al kernel, non sono esenti da critiche: in particolare, ho sentito molto discutere in merito alle librerie grafiche, in merito a X (anche qui si dice che sarebbe opportuno riscriverlo da zero) , ed altro ancora.

Ma non voglio focalizzare la discussione su uno di quasti problemi. Mi piacerebbe sentire il vostro parere in merito a questo "malcontento": se è o meno motivato, da cosa è causato e quali potrebbero essere le soluzioni per porvi rimedio.

Uno dei miti relativi a Linux (ed in generale al software free o open) è che questo è necessariamente di alta qualità, in quanto rivisto e migliorato da un nutrito gruppo di persone. Quello che vorrei sapere è se questa affermazione è vera di per sè: ovvero, per ottenere una alta qualità del codice, è sufficiente la modalità di sviluppo ora adottata (definita spesso scherzosamente anarchia illuminata) o è anche strettamente necessaria un'intensificazione dell'opera di standardizzazione, di organizzazione e strutturazione del lavoro, che talvolta gli sviluppatori non sono molto desiderosi di accollarsi?

Ripeto: non voglio generare flame ne far ripetere le stesse cose all'infinito... se non mi conoscete molto o se non ho tanti messaggi, è perchè sono il primo a dire che, quando non si conoscono le cose, è meglio star zitti ed ascoltare. Io ho ascoltato parecchio, eppure so che ho ancora molto da imparare: quanto ho scritto qui non vuole essere un'accusa o un giudizio, ma sono una richiesta di chiarimento su un'argomento che resta sempre molto vago, in quanto scaturisce facilmente in flame. Perciò vi prego di rispondere in maniera il più possibile obiettiva, senza farvi turbare da termini o imprecisioni che, se anche sembrano posti per surriscaldare gli animi, non sono utilizzati volontariamente a questo scopo.

[hilo]

Originariamente inviato da izerav

Con Linux intendo in primis il kernel: alcune persone dicono essenzialmente che il codice è tutto una toppa, e che sarebbe meglio dargli una rivisitata globale. Inoltre, ma questo non è sintomo di cattiva programmazione, si dice che l'approccio sfruttato è obsoleto. Un intervento per tutti è quello di Tanner, nella discussione su BeOS:

piu' passa il tempo e piu' se ne parla di kernel monolitico e microkernel; ma sono ragionamenti di adesso; ora probabilmente non ci sarebbe piu' un grosso gap prestazionale; ma con i 386, probabilmente, un microkernel sarebbe stato troppo penalizzante

[Leron]

io non ho ancora capito cosa intendi per "linux"

[LiLL0]

Sinceramente e' un argomento molto oscuro, di certo quelli che ne parlano male sono molto spesso gli utenti BSD.
Quello che penso io e' che la base del SO, la struttura, sia fatta molto bene e insieme alla base c'e' un comparto di driver che per compatibilita' con il nuovo hardware deve alle volte arrangiarsi (perche' non vengono rilasciate le specifiche) creando malgrado qualche problema prima di raggiungere la piena stabilita'

[jappilas]

Originariamente inviato da Leron

io non ho ancora capito cosa intendi per "linux"

imho intendeva il design del kernel Linux in sè

ho sentito molto discutere in merito alle librerie grafiche, in merito a X (anche qui si dice che sarebbe opportuno riscriverlo da zero) , ed altro ancora.

il loop input->response nel sistema grafico X11 deve necessariamente attraversare un tot di livelli per ogni operazione... livelli che potenzialmente aggiungono latenza e riducono il livello di interattività del sistema in caso la macchina su cui gira non abbia un certo livello di prestazioni
non è un caso che recentemente, l' impegno sullo sviluppo di X.org sia rivolto a mascherare sempre di più tali latenze (intrinseche alla struttura a livelli che prevede la gestione degli eventi e il widget drawing in un pezzo separato dal "generatore di primitive grafiche" ),aggiungendo estensioni che danno al server maggiori funzionalità locali, o reimplementando la Xlib in forma di API asincrona, multithreaded e diretta sulla IPC locale invece che sui socket...

BEOS è sempre citato come l' archetipo del sistema operativo desktop: uno dei (molti e vari) fattori che concorrono alla responsività della sui GUI è il suo app_server
ora, un application server si occupa praticamente di un po' di tutto, gestire l' input, muovere le finestre, (ri)disegnarle, disegnare i widget... logico che se una singola entità fa quello che su altri sistemi è fatto da più, i code path possono essere più brevi e le applicazioni vengono coinvolte meno, inoltre uniforma il look and feel delle applicazioni, e la api a livello del toolkit da usare per programmarle
lo svantaggio è però una minore flessibilità: sotto linux basta cambiare il WM, o il toolkit , o il tema corrente del toolkit, per avere un nuovo look & feel di un' applicazione o di tutto il desktop
con un app_server , dipende tutto da lui e da come si presta ad essere configurato

Originariamente inviato da hilo

piu' passa il tempo e piu' se ne parla di kernel monolitico e microkernel; ma sono ragionamenti di adesso; ora probabilmente non ci sarebbe piu' un grosso gap prestazionale;

veramente se ne palava di più una volta (anni 90) mi pare ...
allo stato attuale mi sembra che a farla da padroni siano kernel in un certo senso ibridi, tendenzialmente monolitici ("tutto in kernel space") ma modularizzati...

ma con i 386, probabilmente, un microkernel sarebbe stato troppo penalizzante

non così scontatamente... basta vedere i kernel della famiglia L4

Originariamente inviato da LiLL0

Sinceramente e' un argomento molto oscuro, di certo quelli che ne parlano male sono molto spesso gli utenti BSD.

perchè "quelli di BSD", seguono una filosofia diversa...nell' uso antepongono l' eleganza e la robustezza alle implicazioni sociopolitiche del sw, nello sviluppo il design a tavolino all' ampiezza di funzioni, device supportati e al coinvolgimento di milioni di persone
mentre linux mi pare faccia (o almeno abbia fatto) l' opposto, prendere quello che c'è e aggiungere quello che serve, apportando modifiche alla struttura generale solo se strettamente necessarie...
certo, in una quindicina d' anni "è cambiato tutto e al tempo stesso non è cambiato nulla" (linux si chiama sempre linux anche se è una "bestia" diversissima da com' era una volta, diversa più negli internals che nella struttura generale e nella API), ma proprio perchè tanti anni di modifiche via via apportate (e cumulatesi le une sulle altre) hanno indotto la radicale evoluzione del sistema nel suo insieme

Quello che penso io e' che la base del SO, la struttura, sia fatta molto bene e insieme alla base c'e' un comparto di driver che per compatibilita' con il nuovo hardware deve alle volte arrangiarsi (perche' non vengono rilasciate le specifiche) creando malgrado qualche problema prima di raggiungere la piena stabilita'

quello che penso io è che linux sia uno dei rari casi in cui aumentare il numero di "code monkeys" all' opera su un problema diminuisce il tempo necessario a risolverlo
assunto che in altri settori del SW design non si può dare per valido quasi mai...

[/\/\@®¢Ø]

[vagamente OT] ()

Originariamente inviato da jappilas

WARNING: my avatar is no more representative of my true essence: Jappilas is and will always be a green haired, foolish young Elf.
The portrait is an homage to a true work of love, a wonderful and moving anime series: Haibane Renmei went straight to my heart.
Rakka has an halo and grey wings. But she is not an angel. She's an Haibane.

gran bell'anime
[/vagamente OT]

[The Katta]

direi massimo rispetto per jappilas.

[jappilas]

x The Katta: tnx

Originariamente inviato da /\/\@®¢Ø

[vagamente OT] ()

gran bell'anime
[/vagamente OT]

[MOLTO OT]
ma davvero tanto... sarò sentimentale, ma mi si è incastonato da qualche parte tra i ricordi delle cose più belle che ho visto...
<- /me commosso

tra l' altro dopo la prima volta, alle successive visioni acquista una luce tutta nuova... e una vena di malinconia se possibile

"Tutto finisce prima o poi. Ed è proprio questo a renderne il ricordo così prezioso."
[/MOLTO OT]

[jappilas]

Originariamente inviato da izerav

Mi sorge dunque il dubbio: Linux è realmente progettato male? E quali sono i componenti più critici sotto questo punto di vista?

E poi, se anche ci fosse qualche componente sviluppata male, ma una buona e ben studiata architettura di base, non basterebbe dare una sistemata (o eventualmente riscrivere) solamente questi componenti? Oppure l'intera struttura è un po' traballante? Da come parla certa gente, sembrerebbe realmente necessario un bel colpo di straccio...

quello che ho imparato a comprendere come il lato positivo del modello evolutivo dello sviluppo del kernel linux, è che gli assunti validi per una certa versione, possono non essere (e con buona probabilità non sono) altrettanto validi per quella successiva...
negli anni 90 linux era uno unix- like sì multitasking, ma che a lungo non ha potuto girare su sistemi diversi da X86, non scalava col numero di processori, non supportava il clustering, aveva una gestione dei thread lacunosa, non aveva supporto real time, le sessioni critiche imponevano un lock globale al kernel... ora le routine di basso livello (quelle machine dependent) sono state portate su più piattaforme (architetture, cioè ISA e subarchitetture, cioè implementazioni) che non NetBSD, lo stesso kernel source tree scala dal supporto per sistemi embedded senza MMU fino a macchine con 16 e passa processori (tranne forse i sistemi "big iron" , per cui sono previste "fork" di parti del kernel), esistono 3 diverse patch per il clustering, il supporto real time è previsto in più modi (scheduler trasparente o host scheduler ), per i thread è previsto un modello 1:1 a cui DragonFlyBSD vuole ora migrare dall' attuale m:n (troppo complesso per via del doppio scheduler, kernel + userland), le mutue esclusioni sono quasi tutte a granularità fine...
per dirne alcune...

il lato positivo del modello evolutivo, quando messo in pratica da una forza lavoro potenzialmente di milioni di persone, che usano, o lavorano su, lo stesso codice, è che potenziali bug annidati in qualche code path, si ha una elevata probabilità statistica che vengano prima o poi trovati (per la legge dei grandi numeri) e quindi fixati ... quindi se qualcosa che non funziona, lo si fa funzionare... (atteggiamento pragmatico... )

il colpo di straccio sembra necessario agli occhi di quelli che vorrebbero un sistema con caratteristiche totali o parziali di "invarianza" e "identificabilità"... cioè che vorrebbero poter associare univocamente al nome un ben determinato insieme di caratteristiche e specifiche, dare un altro nome a qualcosa che si discosti da quell' insieme, e poter individuare e separare nel sistema, i componenti dedicati alle varie funzioni
linux rompe questa visione... da una parte è appunto il modello di sviluppo a portare alla progressiva sostituzione e adattamento alle necessità contingenti , del codice (un po' come il continuo ricambio cellulare in un organismo vivente), codice che pure resta sempre sotto lo stesso nome
dall' altra appare poco "strutturato" e più "amalgamato" di altri OS che fanno della "compartimentazione" dei blocchi costituenti i sosttosistemi, una priorità di design, per via dell' atteggiamento verso le interfaccie formali e binarie che non le vede invarianti per principio (se davvero necessario, si possono modificare - ora per fortuna questo è molto meno applicato, ma anni fa c'è stato un periodo in cui variavano ogni piè sospinto... probabilmente era anche la prospettiva di dover patchare e ricompilare tutto ad ogni aggiornamento a dare l' idea di un sistema accrocchiato)
una cosa che credo sia innegabile e sempre valida è che linux e il modo in cui si evolve, è un po' caotico, quindi sarà sempre "inferiore" e fatto male agli occhi di chi vuole l' ordine e la pulizia a tutti i costi... ma ciò non vuol dire che il codice non funzioni e laddove ora io possa dire "funziona male o in modo inadeguato" non possa magari essere pesantemente smentito dalla versione del prossimo anno...

[jappilas]

Originariamente inviato da izerav

Con Linux intendo in primis il kernel: alcune persone dicono essenzialmente che il codice è tutto una toppa

come dicevo prima: a suon di toppe, lo hanno reso una cosa quasi del tutto diversa da com 'era quando è nato

, e che sarebbe meglio dargli una rivisitata globale.

se dai una rivisitata globale ottieni praticamente un altro sistema operativo

Inoltre, ma questo non è sintomo di cattiva programmazione, si dice che l'approccio sfruttato è obsoleto. Un intervento per tutti è quello di Tanner, nella discussione su BeOS:

se con quel quote intendevi l' "approccio" come il design implementato (cioè kernel + server X11 + toolkit indipendente) il design è logica conseguenza della volontà di ricostruire fedelmente unix (nonostante GNU volesse dire Gnu's Not Unix in realtà il progetto non mi pare sia mai stato davvero agnostico), pezzo per pezzo con quello che c' era
imho, il vero nocciolo della questione è: un' implementazione unix è idonea come risposta ai miei problemi di computing in ambito desktop e multimediale, o un' altro design può costituire una soluzione migliore anche a fronte di eventuali svantaggi?
come sempre per tutti gli strumenti, bisogna valutare pro e contro...

Ma non voglio focalizzare la discussione su uno di quasti problemi. Mi piacerebbe sentire il vostro parere in merito a questo "malcontento": se è o meno motivato, da cosa è causato e quali potrebbero essere le soluzioni per porvi rimedio.

io sono tra quelli che sinceramente speravano che a diventare l' OS desktop del nuovo millennio non fosse un OS che dà ancora il meglio di sè sui server, ma qualcosa di ad hoc, magari un po' più leggero
a parte ciò, bisogna dare a cesare quel che è di cesare...

Uno dei miti relativi a Linux (ed in generale al software free o open) è che questo è necessariamente di alta qualità, in quanto rivisto e migliorato da un nutrito gruppo di persone.
Quello che vorrei sapere è se questa affermazione è vera di per sè: ovvero, per ottenere una alta qualità del codice, è sufficiente la modalità di sviluppo ora adottata (definita spesso scherzosamente anarchia illuminata) o è anche strettamente necessaria un'intensificazione dell'opera di standardizzazione, di organizzazione e strutturazione del lavoro, che talvolta gli sviluppatori non sono molto desiderosi di accollarsi?

imho non è sinonimo, ed anzi il kernel linux è uno dei pochi casi positivi di SW sopravvissuto a questo criterio... come si parlava un po' di tempo fa anche in altre sezioni, il modello di sviluppo caotico pone dei rischi inerenti sul fronte di: sicurezza, affidabilità, testing, correttzza formale dell' algoritmo e della implementazione...
c'è il vantaggio che chiunque può fare code review, a differenza di una SW house che può contare solo sul proprio team, quindi è più facile scovare eventuali bug... ma se *chiunque* potesse apportare una modifica o aggiungere un pezzo di codice, vorrebbe dire affidarsi all' ultimo coder arrivato, che può essere chiunque e ovunque nel mondo, avere capacità tecniche buone come assolutamente carenti, ed un livello di onestà non accertabile

se non ricordo male, delle volte che una patch era accettata fidandosi, a distanza di tempo magari si scopriva che conteneva qualche privilege escalation o backdoor, o magari capitava direttamente che "non funzionasse" o "rompesse" qualcosa altrove... motivo per cui lo sviluppo dello stesso kernel è da qualche tempo molto più strutturato e meno anarchico...

[dupa]

Linux e le varie distribuzioni ad esso collegate non possono essere "progettate male" per il semplice fatto che non sono mai state progettate. Se per progettare si intende una seria analisi di requisiti, definizione delle specifiche, diagrammi UML ecc. ecc. e infine la programmazione vera e propria.
Linux e le varie distro ad esso associate sono un po` di righe di codice messe assieme che sembrano funzionare discretamente bene.

Saluti.

[izerav]

Grazie a tutti per gli interventi, ma in particolare grazie a jappilas, che mi ha dato una risposta ben al di sopra di tutte le mie più rosee apettative: la definirei quasi illuminante, se non fosse per il fatto che alcuni concetti mi sono alcuanto oscuri... col tempo li capirò....

Linux e le varie distro ad esso associate sono un po` di righe di codice messe assieme che sembrano funzionare discretamente bene.

Ma non si sente la necessità di organizzare centralmente il lavoro? Così non si riuscirebbe a sfruttare meglio lo sforzo dei programmatori?

[jappilas]

Originariamente inviato da izerav

alcuni concetti mi sono alcuanto oscuri... col tempo li capirò....

stavo scrivendo alle 2 di notte... la possibilità che che non mi sia espresso nel migliore dei modi è concreta, se servono chiarimenti, sono qui

[dupa]

Originariamente inviato da izerav

Ma non si sente la necessità di organizzare centralmente il lavoro? Così non si riuscirebbe a sfruttare meglio lo sforzo dei programmatori?

Se un giorno dovesse uscire un sistema operativo open-source ben progettato e con il relativo codice ben documentato, credo sarei la persona più felice del mondo e magari potrei farci anche un pensierino a contribuire allo sviluppo del codice.

Sinceramente credo che Linux (e le distro ad esso legate) siano troppo legate a retro-compatibilità varie per poter mai pensare di riprogettarlo per bene da zero.

Insomma serve un punto di rottura, un po' come fece la microsoft passando dai sistemi operativi che non si potevano neanche definire tali (es: windows 95) a qualcosa di più serio (windows NT)

[NA01]

Originariamente inviato da dupa

Sinceramente credo che Linux (e le distro ad esso legate) siano troppo legate a retro-compatibilità varie per poter mai pensare di riprogettarlo per bene da zero.

Insomma serve un punto di rottura, un po' come fece la microsoft passando dai sistemi operativi che non si potevano neanche definire tali (es: windows 95) a qualcosa di più serio (windows NT)

ti consiglio la lettura di "alla ricerca della stupidita`". parte del libro descrive proprio quanto sia poco saggio fare quello che proponi tu osservando casi reali.

tra l'altro parla di casi ben meno complessi della realizzazione di un sistema operativo
comunque se vuoi qualcosa di piu` moderno per quanto concerne l`architettura interna (e probabilmente piu` facilmente estendibile) puoi sempre dare una mano a quelli di Hurd

ciao

[VICIUS]

Originariamente inviato da dupa

Linux e le varie distribuzioni ad esso collegate non possono essere "progettate male" per il semplice fatto che non sono mai state progettate.

Questo come fai a saperlo? hai seguito personalmente lo sviluppo di tutte le distribuzoni?

Originariamente inviato da dupa

Se per progettare si intende una seria analisi di requisiti, definizione delle specifiche, diagrammi UML ecc. ecc. e infine la programmazione vera e propria.

Il waterfall non è l'unico modo per progettare un software. Probabilmente è pure quello che si adatta meno allo sviluppo di un software.

Originariamente inviato da dupa

Linux e le varie distro ad esso associate sono un po` di righe di codice messe assieme che sembrano funzionare discretamente bene.

Saluti.

Ti assicuro che per riuscire a scrivere il codice di un filesystem come XFS o un encoder MPEG4 ci vogliono anni di studi e progetto dietro. Non ci si puo alzare alla mattina e dire oggi scrivo Reiser5.

ciao

[cerbert]

[OT]
@jappilas: mi piange un po' il cuore a dirtelo, in quanto dopo la raccomandazione di Fred Gallagher (autore di megatokyo, che gli dedica un omaggio qui: http://www.megatokyo.com/index.php?strip_id=731 ) "Haibane Renmei" è uno degli OAV che DEVO vedere.
Ma, ecco, la tua sign è un po' irregolare: una immagine+una riga di testo.

[/OT]