Parola di James Rayner, uno dei mantainer del kernel per la distribuzione Arch Linux. James ha annunciato in ML che abbandona la manutenzione del pacchetto relativo al kernel.
Il motivo? Semplice: “non ho più il tempo e la motivazione“, e rincara: “Sono stanco del kernel. È una merda. Ad ogni versione non funziona qualcosa di diverso. Il ramo stabile non è stabile“ (T.d.felipe)
Dichiarazioni forti ma che – a sorpresa? – raccolgono il favore di alcuni, a cominciare da Eugenia, blogger a volte controversa ma sempre molto acuta. Io non mi azzardo ad esprimere alcuna opinione, mi limito a riportare il fatto che non compilo più un kernel da anni, e non sento l’urgenza di farlo, preferendo demandare tutto il lavoraccio al kernel team di Ubuntu o di qualsiasi altra distribuzione io usi, che si prendono cura di sistemare eventuali noie per conto mio :)
Questa della eccessiva “mobilità” del kernel Linux è una delle classiche argomentazioni nei flame contro BSD, per dirne una, e forse non è del tutto infondata. Continuando di questo passo – e dando per scontato che il processo sia davvero così mobile – finirà che solo i distributori più “potenti” potranno permettersi una decente certificazione di qualità per il kernel e in generale il software? E gli altri?
Finirà che Sun tenterà di far passare Solaris anche in virtù di un modello di sviluppo più ordinato?
[via pollycoke :)] <- ha! :D
ecco perchè la slackware si tiene ben stretto il vecchio kernel?
il Kernel + avanza e + si ingrassa e si appesantisce. E’ quello anche il problema.
OT a proposito di kernels.
UBUNTUstudio non verra’ rilasciata che a Maggio… ulteriore ritardo come si legge nella loro pagina principale… :( sigh sob.
NOT YET RELEASED May 2007
No beh felipe, se segui il mondo linux da anni non ti saranno sfuggiti molti screzi riguardo a molte parti costruite in maniera pessima e mantenuta peggio.Ci sono voluti anni per arrivare ad un layer comune per l’ATA eppure le dimensioni del sorgente sono sempre aumentate.Non parliamo del desiderio/polemica dell’ “stable api nosense” che aggiungono riflessioni profonde sul modello di sviluppo.Il kernel 2.6 e’ forse il peggiore ed e’ arrivato ad un punto di immantenibilita’. Non e’ il primo sfogo,nel recente passato, ne abbiamo sentiti altri forse di persone molto piu’ conosciute come Alan Cox per esempio.
Solaris al momento non ha nulla a che fare,anzi forse il kernel del BSD con la debian KFreeBSD sarebbe gia’ piu’ matura per una sostituzione rapida.
E’ qantomai difficile vedere in crisi un modello di sviluppo open applicato al progetto piu’ importante e piu’ famoso,ma forse diciamocela tutta anche il meno indicato a tale approccio.Posso capire un’applicazione come OpenOffice,ma un kernel e’ altra cosa ci vogliono poche persone cazzute e competenti e senza interferenze esterne.
Per la cronaca James non manteneva il kernel di default di Arch, ma una versione con patch sperimentali (ck, suspend2, gensplash, vesatng and so on).
Sono convinto che, qualsiasi codice sorgente, di progetti software sufficientemente evoluti, anche se di piccole dimensioni, raggiunga molto presto l’incasinamento totale, spesso arrivando a sfiorare l’ingestibilità, senza per questo precluderne la… compilazione!
Fa parte del modo in cui, da poco più di 40 anni si programmano i sistemi… fin quando tutto questo non cambierà radicalmente, sarà così.
Io non mi preoccuperei troppo.
Nota – parlo del software Open Source in generale –
La politica di rilascio enunciata da Torvalds “release early, release often” mi ha sempre lasciato perplesso. In fondo il mondo del software si sta muovendo verso l’extreme programming, dove è di fondamentale importanza scrivere i test per il software PRIMA di scrivere il software stesso. Sparare fuori release piene di bug lasciando ormai migliaia, milioni di persone a sacramentare perchè questo/quello non funziona non mi sembra un gran modello di ‘business’. Ormai l’open source non è più solo usato da smanettoni, disposti eventualmente anche a farsi un po’ di debugging ‘per piacere’, specialmente gli utenti Linux desktop ormai vogliono stabilità, se qualcosa ha alte probabilità di non funzionare NON SI METTA nella distro e si aspetti, pace. Oppure si dovrebbe dire a chiare lettere ‘Hai scelto di usare la webcam xzy345: il supporto al momento è solo sperimentale, considerati un beta-tester, i bug si spediscono qui, se sei un utente normale te ne sconsigliamo l’uso’.
Altrimenti passa solo la filosofia non scritta “Beh, in fondo è gratis, di che ti lamenti?”
Marò Felì verifica prima di sparare la notizia:
“The beyond stable tree is a patchset based on the CK patchset and gentoo’s genpatches. It aims to include a variety of popular features and updates developed by others that have not yet made it to the vanilla kernel, while remaining relatively stable.”
E cmq io tutto sto crap nel kernel vanilla non ce lo vedo, sarò stato fortunato?
a dire la verità manteneva il kernel beyond..
Io, da buon slackwarista, ho compilato decine e decine di vanilla kernel (anche con patch -ac, se serviva) e non ho mai avuto nessun errore, magari non uso abbastanza driver/moduli esotici, anche la sospensione a disco/ram mi funzionava (quando la usavo).
Ovviamente se uno inizia a patchare a destra e a manca qualcosa scoppia, è matematico. Ma non capisco perchè non si possa usare il kernel vanilla, unico buono e stabile.
Quanto di piu unstable ci possa essere quando l’usavo addirittura comparivano di defaul schedulers per il disco supplementari e poi se fossero solo ck + gentoo beh sarebbe alquanto stabile, cmq il kernel linux piu o meno e stabile, ci sono stati momenti peggiori vedi da 2.6.8 alla 2.6.17 è cambiato il mondo, come mai debian non si lamenta mai?
Tu non compili da anni perché qualcun altro lo fa per te, ma se questo qualcun altro domani si stufasse di compilare per te “perché non ha più il tempo e le motivazioni” come la prenderesti? Voglio inoltre far notare che non mantenendo il ramo stabile del kernel si trovava molto più spesso di fronte a problemi per via delle patch che doveva includere dentro il kernel, che non sempre erano stabili veramente e che venivano rilasciate con tempi diversi rispetto al kernel e rispetto ad altre patch che lui includeva .. un lavoraccio!
e poi una piccola polemica .. e17 è in cantiere da anni e ci si lamenta dei tempi di sviluppo lunghi, una nuova versione del kernel linux viene rilasciata _circa_ ogni mese e ci si lamenta .. sempre a lamentarsi!
@10. Dr_gogeta86: lo puoi ridire prendendo fiato e in italiano pliz?
@Waxblood
non funziona così.. per prima cosa il mondo NON va verso l’extreme programming, ma semmai ne prende ciò che c’è di buono e solo quando serve (in pratica non cambia niente). inoltre non è che appena esce una nuova versione del kernel viene inclusa automaticamente nelle distro, ma viene prima testata e ritestata finchè non è stabile (come si fa con qualsiasi software) e quindi non è vero che il kernel è instabile di per se. poi se parli di moduli sperimentali.. li usi solo se li include la distro normalmente e quindi il kernel ancora non ci azzecca molto.
infine volevo fare una piccola considerazione.. da quante righe di codice è composto il kernel? non mi ricordo ma più o meno 5 milioni.. ecco secondo voi c’è differenza tra la manutenzione di 1 milione , 5 milioni o 10 milioni di righe di codice? IMHO arrivati a quelle cifre non fa più nessuna differenza, quindi non credo che la situazione possa peggiorare con l’ingrandimento del kernel, anche perchè resta il fatto che il codice è modulare.
Riscrivere daccapo il kernel Linux secondo extreme programming … AIUTO!!! ma ci vorrebbe qualcuno che iniziasse a farlo (magari HURD…)
IMHO il problema non riguarda la compilabilità del kernel, perché alla fine tutti i pezzi del codice sono messi assieme in modo che funzionino senza problemi.
Il problema vero, quello che noterebbe un qualunque programmatore un po’ sgamato è la disorganizzazione del codice, la complessità a volte eccessiva del codice sorgente di Linux.
E soprattutto la mancanza di una API stabile, che favorirebbe _*MOLTISSIMO*_ la scrittura e il mantenimento di driver da parte di terzi.
Mi dispiace per Linux e soprattutto la sua comunità, il 99% della colpa è di Torvalds e le sue politiche elitarie del cavolo, che frena la diffusione di questo fantastico sistema operativo.
Sembra che molti vogliano boicottare i due sistemi più discussi di questi tempi (Windows e Linux) a favore di Mac per il desktop e Solaris per i server.
@ziabice:
eh? Verificare ancora di più? Ho perfino tradotto degli stralci direttamente dall’annuncio
styley il fatto che non ci sia un’api stabilie avra’ il vantaggio come dici tu di favorire la scrittura di driver di terze parti si, pero’ agevola anche chi i driver li vuole mantenere proprietari, mi piacerebbe sapere quanti driver ora open lo sarebbero stati se l’api di linux non fosse cambiata negli ultimi 5 anni
penso pochi
Ma si autoincendiasse
Non capisco qual’è il problema. Se Rayner se ne va, ovviamente ci sarà qualche altro mantainer che si occuperà del kernel. Di fatto se per una determinata distribuzione non c’è più nessuno che compila, che “patcha”, che aggiorna, quella distribuzione muore. Per fortuna esistono le alternative. Se tutti i mantainer (caso assurdo) facessero la stessa pensata di abbandonare tutto, GNU/Linux ritorna ad essere il s.o. dei geek e dei server. Al giorno d’oggi non si può pensare che un semplice utente si metta a compilare un kernel, se si vuol far diventare GNU/Linux un vero concorrente di Windows o Mac nei sistemi desktop.
@visik7
E’ proprio questo atteggiamento che hai esposto nel commento che elitario (senza offesa, s’intende :).
All’utente non gliene frega un emerito cavolo se il driver è closed source od open source.
Vuole che funzioni e basta, “out of the box”.
Linux vuole passare al desktop? Beh, allora si adegui.
“preferendo demandare tutto il lavoraccio al kernel team di Ubuntu o di qualsiasi altra distribuzione io usi” complimenti. Sempre qualcuno lo compila e sempre di un kernel linux si tratta.
Per altro, il kernel beyond non è quello di default, come giustamente riportava mOLOk… Magari prima di sparare min***te informiamoci.
PS. un consiglio, non dire che non esprimi pareri personali suvvia…
styley, dipede da quali sono gli obiettivi che si sta cercando di raggiungere. Se si vuole solo una diffusione di Linux sempre maggiore non c’e’ nessun problema a includere driver closed-source, software proprietari o comuqnue a scendere a compromessi. Questo potrebbe anche essere la massima aspirazione di Linus (anche se ho dei dubbi in proposito), ma certamente non e’quello che sta cercando di ottenere Stallman e la FSF. Non e’ importante quante persone usano GNU/Linux, e’ importante che il software sia libero. S
Se poi si riesce a rendere consapevoli gli utenti dei vantaggi del software libero rispetto a quello chuso, allora avremo anche piu’ utenti, ma non penso che questo debba essere l’obiettivo principale.
[scusate il post splittato, ma mi e’ scappato l’invio]
dai, James, c’e’ qualcosa sotto! Ti hanno offerto un altro lavoro? Stai costruendo un kernel tutto tuo (non penso proprio!)? La cosa piu’ bella di questo post e’ la foto: bel cagnolino!
Sono OT e come primo intervento in questo blog potrei anche vergognarmi, ma qualcuno ha scritto che UbuntuStudio non è disponibile… io lo sto scaricando dal sito ufficiale che tra l’altro è una meraviglia, adesso che han qualcosa da metterci dentro.
Sul kernel posso solo dire che non è un punto di vista ma è il KERNEL! O funzia per tutti ugualmente e le patch vengono condivise e ridistribuite per tutte le distro oppure è meglio lasciar perdere: quelli come me, poveri mortali, ritorneranno a Win o a MacOS con le orecchie basse. Per competere alla grande bisogna offrire un Kernel a prova di bomba anche e soprattutto a livello di coordinamento e condivisione tra gli sviluppatori. Utopia o no, questa è l’unica via.
@ma-lui-mantiene-il-kernel-vattelappesca:
E chi ha parlato di vattelappesca, beyond, patchset, versioni modificate, ecc? Ho solo riportato che James Rayner ha espresso un parere sul KERNEL LINUX così come lo rilascia Linus, con tanto di citazione letterale. Poi che lui ci facesse ulteriore lavoro …chi stracazzo se ne frega ai fini di questa notizia? In ogni caso, la critica era rivolta al Kernel Vanilla, ed era del mantainer, non mia.
Scusate se mi infervoro ma leggo commenti che fanno cadere le braccia -.-
Ricordate che qui su pollycoke i commenti diventano sempre più importanti, a volte anche più dei miei stessi post, e se richiedete a me un’attenzione altissima (infatti lo fate, e ve ne sono grato), sappiate che altrettanta ne richiedo a voi :)
@felipe
Scommetto che il cane si chiama James Rayner..! :-)
tornare al vecchio sistema delle release pari e dispari?
o meglio, fare UN kernel stabile ma meno aggiornato, con tutte le correzioni applicate tempestivamente e rilasciare spesso dei kernel aggiornati al nuovo hw per chi ha i portatili o pc nuovi o necessita di nuove cose
ad esempio distribuzioni che fino a gennaio scorso avevano il 2.6.9 mi pare avevano pachato tutti i bachi di quel kenel o no? o dovevo sempre prendermi l ultimo kernel per avere le patch di sicurezza per esempio e rischiare malfunzionamenti?
forse io sbagliavo a fare cosi, non so, tanto ormai faccio altro per prendere lo stipendio
Non ne capisco molto di kernel, so solo che gestisce la macchina.
In Ubuntu edgy inserivo il mio HD esterno, lo facevo riconoscere al sistema e andava.
Con Feisty invece, me lo prende per HD interno (credo) e quando devo smontarlo mi dice che è impossibile, però lo fa. Poi, me lo riattacca ma non lo rimonta (perchè non glielo faccio rimontare io levando il montaggio automatico da periferiche esterne). Oltre al fatto che sia Xgl che main-menù(il menù compatto) impazziscono e mi fregano un casino di ram (toccano anche 180MB!!!). Il main-menù anche senza attivare gli effetti grafici. Cavolo con Edgy questo non succedeva.
Mi facevo un mazzo tanto per codec, firefox, java, ecc., ma cavolo funzionava.
E’ libero di fare tutte le critiche che vuole il tipo, solo che deve capire che se manda a puttane il mantenimento di quel pacchetto, chi ne risente sono gli “utonti” che non sono in grado di ricompilarselo.
A me non da problemi perché io me lo compilo sempre per i miei computer, non penso sia uguale per chi usa distribuzioni orientate al dekstop….
Io credo che il grosso problema dello sviluppo del kernel linux è che si è abbandonata la filosofia del ramo di sviluppo e di quello stabile per accellerare i rilasci.
fino all’anno scorso avevano fatto delle relase di “pulizia” dedicate solo al riordinamento e bugfixing…. ora sembra si stiano dimenticando di ste robe.. ma vabbè… prima o poi la scatola esploderà e allora toglieremo tutta la cacca…
comunque davvero non accetto che eugenia si metta ad esprimere commenti di questo tipo, finchè si tratta di usabilità beh, allora posso accettare…
ma quando passa a parlare di cose che sono distanti da lei migliaia di miglia.. beh… un manrovescio se fosse daventi a me se lo prenderebbe (lui / lei non fa differenza, non siate faziosi)
Io sono contrario all’Api stabile.
A noi interessa che Linux si evolva a livello commerciale? Perchè?
Linux deve poter essere una piattaforma che possa evolversi a livello “tecnologico”.
Sistemi operativi con infiniti layer di retrocompatibilità, e castrati nello sviluppo, come windows, ce l’abbiamo già. A me francamente avere un Windows non interessa. C’è già.
p.s. e poi che male ci sarebbe che il testing lo facciano anche e sopratutto le compagnie che Linux lo vendono?
Sono loro a dover garantire la maggior qualità dei loro prodotti. Per questo vengono pagate.
(ovviamente non intendo dire che per questo il kernel vanilla debba rimanere una merda…)
James manteneva solo il pacchetto del kernel con il suo patchset beyond, non quello di default, comunque :P
il kernel è cambiato troppo dal rilascio della 2.6.0… bisognerebbe innanzitutto aprire il ramo di sviluppo 2.7… e poi la compatibilità binaria tra le major releases stabili (ad esempio tra tutte la serie 2.6, 2.8)…
Così i produttori di hardware sarebbero invogliati a rilasciare driver binari senza doverli ricompilare per ogni kernel e per ogni distro… I driver binari sono meglio di nessun driver :-)
Probabilmente non ha piu voglia di andare avanti o ha trovato la figa…ma dire che il kernel sia una merda…
PER Nexso
il problema dello smonta/rimonta del disco non c’entra niente con il kernel. Quelli di Ubuntu hanno incasinato qualche file che gestisce le politiche dei dischi esterni. Io ho risolto cancellando un file non so dove (letto sul forum di ubuntu)
Per Zakk
la compatibilità binaria è una cazzata. Inoltre sono sempre più convinto che un sistema operativo os debba avere driver os. I driver binari sono solo un cerotto sul problema.
@Mercurio
L’API stabile non e’ sempre un discorso prettamente commerciale.E’ anche sintomo di buona programmazione e di rispetto nei confronti di altri che usufruiscono delle tue interfacce.Non stiamo mica giocando a nascondino,eh!
Poi,bisogna a tutti i costi aggravare una situazione che lo e’ gia’ di suo perche’ dobbiamo sfuggire all’ipotetica invasione del commerciale? Ma ci rendiamo conto di quello che diciamo? Siamo prossimi ad un certo grado di fanatismo,dove opensource non ha nulla a che fare.
@Anonimo
Da quel che ho letto dalle e-mail di Torvalds, non è che le ABI & API le cambino apposta: semplicemente non vogliono sviluppare il kernel avendo le mani legate da questo punto di vista.
RedHat, Novell, Wind River, Montavista e parenti, nelle loro versioni commerciali del kernel prendono (giustamente) un kernel di due anni prima, lo testano, e lo usano per altri 4 anni (giustamente). Lo stesso.
Loro è giustissimo che si comportino così (nonostante le lamentele dei linuxari per il kernel “vecchio”), ma chi sviluppa il kernel perché deve legarsi le mani?
Il vantaggio di Linux e dell’FOSS è di essere una fucina di alta tecnologia, non “Windows gratis”.
Credo siano più fanatici quelli che pretendono che Linux si sostituisca a Windows
Cioé, ribadisco, non si vede la differenza tra gli sviluppatori del kernel e i distributori?
Nel mondo OSS lo sviluppo è “aperto”, ma questo non vuol dire che gli utenti debbano usare la versione aggiornata all’ultimo x. Questo vale anche per i programmi, in cui ci riesce di criticare la versione pre-alpha di un interfaccia grafica.
Volete una abi stabile? usate lo stesso kernel per 4 anni, come si fa in Windows, e come fa chi linux lo usa sul serio.
concordo con te mercurio, io ho il mio ricompilato, è bellissimo e iper fashion :D, lo uso da 6 mesi e zero scazzi
per esperienza personale ( visto che il kernel lo compilo ) mi trovo d’accordo con chi dice che il kernel vanilla è una “MERDA”.
Provate a fare questo esperimento : un bel lspci , annotate e poi configurate un kernel che abbia le sole componenti hardware che avete in dotazione e le parti necessarie a farle funzionare ; nella mia “convinzione” personale è palese che le cose comincino a non funzionare quando si aggiungono nuove features non quando si tolgono quelle che non servono ; probabilmente sarò una schiappa e dovrei darmi all’agricoltura però la prima considerazione che mi viene da fare è che se il kernel che ho configurato non “funge”, vuol dire che ci sarà del codice che “serve” alle nuove features ma che non sta “confinato” nel suo spazio : anziché stare nel “device layer” sta anche in altre parti più sensibili e quindi togliendo le nuove features si crea instabilità anche in altre parti che a ragion di logica non dovrebbero esserne intaccate … se fosse effettivamente così , la cosa mi saprebbe di winzozzata bella e buona : fino a WinXP infatti c’era addirittura codice ad hoc nel kernel per far funzionare alcune applicazioni O_O ( non l’ho visto di persona , c’erano all’epoca dei pareri autorevoli di persone che avevano avuto accesso al codice nel’ambito del programma di distribuzione del codice di Win ai partner istituzionali )
Se così non fosse come motivare la scelta di RH la cui nuova versione di RHEL si basa ancora sul 2.6.9 ???
@anonimo “Se così non fosse come motivare la scelta di RH la cui nuova versione di RHEL si basa ancora sul 2.6.9 ???”
Semplicemente dicendo che il kernel della nuova RHEL _non_ e’ il 2.6.9
RHEL 4.5 non e’ la “nuova versione” di RHEL, e’ un’update della RHEL 4 (ed ha senso che mantenga quanto piu’ possibile lo stesso kernel)
@Mercurio
“Il vantaggio di Linux e dell’FOSS è di essere una fucina di alta tecnologia … ”
Beh il supporo alle watchdog cards è di “altissima tecnologia” : se il kernel s’impalla niente di meglio che un bel reboot rapido e la macchina torna operativa … bello !!!
Visto che si tira in ballo l’alta tecnologia ce lo vedo un robot che nel bel mezzo di una operazione delicata s’impalla e si “reboota” … niente diagnostica o esclusione temporanea della “zona grigia” … NO !!!!! UN BEL REBOOT !!!!
@Anonimo
Non ho capito ti lamenti che il supporto ci sia o che sia mal fatto?
Che io sappia sistemi di watchdog sono largamente usati in qualsiasi tipo di microcontrollore. Un sistema di questo tipo all’avvio si mette in uno stato “non pericoloso”.
Se stai comandando un motore con un “bel” trapanozzo, se entra in funzione il watchdog, il sistema si riavvia e blocca il trapano. Altrimenti il trapanozzo potrebbe distruggere un bel pò di cose.
Il watchdog è un sistema di sicurezza in casi estremi, mica una funzione di routine!
E poi cosa c’entra tutto ciò con questa discussione?
@Anonimo #11:
Mi sa che hai ragione. Sul fatto dell’agricoltura intendo :D
Scherzi a parte, un conto è lo sviluppo del kernel, le API/ABI, la comodità per i distributori minori e le altre cose da sviluppatori, un altro è la configurabilità da parte dell’utente. Il post, e la critica di James, sono ovviamente riferiti al primo aspetto :)
@tutti:
Vorrei che fosse chiaro che io non condivido l’uscita di James Rayner, anche se trovo interessante la critica mossa.
@Mercurio
Non ho capito ti lamenti che il supporto ci sia o che sia mal fatto?
Beh prevedere un simile sistema “allegerisce” la coscienza : tanto se non funge o si blocca c’è watchdog !!!!!
Beh da qualche versione a questa parte pure noi di gentoo abbiamo unsupportato in kernel vanilla per diversi motivi, uno dei quali è che nel Makefile c’è un check che se non passa fa “rm /dev/null” :P
Senza considerare che in ogni passaggio di versione 2.6.19->2.6.20 rompono la compatibilità con qualcosa e alsa non compila quasi mai :P
@Anonimo
Credo che tu stia veramente sconfinando nel trollismo. Il watchdog è un sistema di sicurezza usato *ovunque* non solo nel mondo dei computer.
Ma se la cosa ti da problemi, semplicemente non usare più auto, treni, aerei, motori, termometri… e qualsiasi sistema elettronico con un minimo di elettronica digitale.
Ho già spiegato perché è meglio che ci sia: un robot fermo fa meno danni di un robot impazzito. E non sto parlando di giocatoli o modellini.
p.s. non serve essere registrati per inserire un nick
Il problema sull’HD esterno è stato risolto oggi grazie ad aggiornamernto. :D
@felipe
” le API/ABI, la comodità per i distributori minori e le altre cose da sviluppatori, un altro è la configurabilità da parte dell’utente. Il post, e la critica di James, sono ovviamente riferiti al primo aspetto :) ”
no no … aspe’ … se le API/ABI sono ben definite , la configurazione da parte dell’utente avrebbe due sole possibilità : o funziona o non funziona ; invece ultimamente capita spesso che eliminando parti che con un certo hardware non hanno minimamente a che fare, il sistema risulti instabile … questo comportamento è ANOMALO !!! Se il codice dello specifico driver è confinato al solo layer d’appartenenza il sistema dovrebbe funzionare correttamente senza problemi … se invece è instabile significa che quel qualcosa che ho tolto aveva o generava delle dipendenze in altri punti.
@Anonimo
Sei approssimativo, fai confusione tra cose che non hanno niente a che fare tra loro e dici una valanga di cose inesatte.
La tua opinione sulla qualita’ del kernel e a dir poco inattendibile.
PS: Inoltre potresti usare uno straccio di nick
qua si sputa nel piatto in cui si è mangiato…magari c’ha anche ragione ma non si fa…non si fa!!
ehm… la slackware current adotta l’ultimissimo kernel ed ha abbandonato la serie 2.4
cmq anche io ho sempre ricompilato e patchato il kernel senza problemi (vabbè le prime volte mi è scappato qualche kernel panic ma stavo imparando)
ok la mia opinione non conta nulla , provate – ad esempio – a fare una ricerca su questo :
atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying access hardware directlyuno dei primi risultati è questo ma se si scorrono i risultati si scopre che il bug ricorreva anche in versioni precedenti.
non ho gli strumenti per dire esattamente cosa non va : non sono un manteiner … mi limito a riportare ciò che osservo
per come la vedo io watchdog è fin troppo comodo : se i tempi di risposta non sono accettabili oppure si registrano dei malfunzionamenti la soluzione è un bel reboot … comodo per un server virtualizzato su Xen.
Nel caso di un robot “l’ideale” sarebbe che sia in grado di diagnosticare il problema , di corregerlo o eventualemente che escluda la routine che ha creato il malfunzionamento e che possa magari il “pezzo di codice incriminato” possa essere corretto o aggiornato runtime da un operatore locale o remoto … cmq gli esperti siete voi !!!
si si … già lo vedo il kernel linux girare su un qualcosa di simile a questo
A mio parere Linux ha iniziato la sua guerra affermando che un kernel monolitico non è per nulla inferiore ad un microkernel. Dopo anni forse si puo’ affermare che ha il 50% delle ragioni.
l altro 50% va alla semplificazione di un modello di messaggistica per costruire driver di buona qualità — anche se non lo fossero non crollerebbe il sistema!!! un kernel linux deve essere al 100% scritto bene per dare il 99,99% di uso il 0,01% che tutto crolli è dato dal fattore C di ognuno!! cmq il sono passato a linux dal 2000 non sono vecchio del sistema ma credo che migrero’ in altri settori linux si sta gonfiando ed un giorno il suo peso fara’ si che non riesca a muoversi piu’. Proprio come un obeso, a volte credo che bisogna snellirlo un po’ astrarre meglio l hardware e fare delle classi hardware simili e dare API per i driver scritti al 100% funzionanti che fungano anche da controllori a driver non scritti al 100%. Non so se sono chiaro ma a volte non mi capisco nemmeno io.
credo che molti di voi dovrebbero conoscere meglio il kernel linux, e il tutto si riassume nella famosa frase di torvalds: “linux is evolution, not intelligent design”
Se capite questa frase, allora avrete capito tutto.
E poi che andate dicendo dei driver blabla? ma non lo sapete che linux è il sistema operativo a supportare piu hardware di ogni altro OS esistente sulla terra? non lo sapete che su linux i driver non necessitano di una rivisita per ogni kernel nuovo a differenza degli altri OS? raga i bug sono una cosa, l’implementazione è altro. non cambierei l’evoluzione del kernel linux per nessuna ragione al mondo. se ce un bug correggetelo da voi visto che siete bravi a parlare. ma implementare l’algoritmo giusto non ha nulla a che vedere con i bug.
Pingback:Top Posts « WordPress.com
ma non lo sapete che linux è il sistema operativo a supportare piu hardware di ogni altro OS esistente sulla terra?
Beh grazie i driver sono il kernel stesso :-D o ti sfuggiva questo particolare? io comunque dicevo che sarebbe meglio astrarre e far si che la gente si scarichi il minimo indispensabbile e poi i driver che realmente gli servono e non i 30 mega che in 2 anni sono divendati quasi 50 di codice ( proprio perche’ comprendono i driver per le periferiche )
A proposito di mantenibilità… è strano che nessuno abbia parlato di linguaggi.. Il kernel linux è scritto in C, un linguaggio già di per sè ben poco mantenibile, e tante distribuzioni per funzionare usano script bash a palla, e bash è un linguaggio ‘sporco’ per definizione, per lo più dovrebbe essere usato solo come shell interattiva.
Per il kernel ormai ovviamente non c’è più niente da fare, ma almeno sostituire la roba bash con Python a me sembrerebbe una scelta azzeccata…
Mi fan tristezza anche le GTK, base scritta in C, più eventualmente interfaccia C++ con GTKmm o wxWidget hanno avuto i loro bei problemi di mantenibilità, cambiamento di API e casini vari.
Uso Linux tutti i giorni, e vorrei iniziare ad usare Blender che pure è scritto in C, ma se dovessi mantenere un grande progetto C/bash avrei *orrore*.
Ho visto che esiste un interfaccia C++ a Linux, si chiama CoreLinux++, http://corelinux.sourceforge.net/, chissà se riescono a mantenersi bene in sync con le API
@Waxblood “Per il kernel ormai ovviamente non c’è più niente da fare, ma almeno sostituire la roba bash con Python a me sembrerebbe una scelta azzeccata…”
accomodati! cosa aspetti a mandare il tuo bel lavoro in python alla LKML?
ah, preparati ad avere una delusione quando il tuo lavoro non verra’ accettato. Ci sono delle ottime ragioni per cui in questo caso e’ preferibile bash piuttosto che python.
@Federico
a parte che le ottime ragioni potevi pure spiegarmele, mi riferivo al codice bash di gestione che trovi nelle distro, alla LKML avrei ben poco da mandare.
Non ho mai scritto alcunchè in Python, ma uno script Python lo capisco con poco sforzo, per capire quelli scritti in bash pieni di awk sed etcetera ci vuole un guru.
E tanto per fare un esempio, Portage è scritto in Python, perchè non lo riscrivi in bash e lo spedisci alla gentoo-dev?
ah, preparati ad avere una delusione quando il tuo lavoro non verra’ accettato. Ci sono delle ottime ragioni per cui in questo caso e’ preferibile Python piuttosto che bash.
@Waxblood
> “E tanto per fare un esempio, Portage è scritto in Python, perchè non lo riscrivi in bash e lo spedisci alla gentoo-dev?”
1. perche’ non me ne potrebbe fottere di meno di portage e di gentoo in generale
2. non mi sembra di aver mai detto di volerlo fare o aver detto che python non va bene per quello scopo
3. perche’ nessuna persona sana di mente si metterebbe a riscrivere un sistema complesso (funzionante) in un altro linguaggio solo perche’ a qualcuno sembra piu’ leggibile
> “ah, preparati ad avere una delusione quando il tuo lavoro non verra’ accettato. Ci sono delle ottime ragioni per cui in questo caso e’ preferibile Python piuttosto che bash.”
Appunto, se e’ stato scritto in python forse ci sono delle ragioni. Comunque sei stato te a propormi di riscriverlo in bash, quindi sei te quello che devi convincere, non me.
“Beh grazie i driver sono il kernel stesso :-D o ti sfuggiva questo particolare?”. cosa? ma sai cosa sia un kernel? credo che qui si stia facendo un pò di seria confusione. i driver non sono assolutamente il kernel! ma da dove ti è uscita questa idea? forse volevi dire che il kernel gestisce i driver, ma questa è tutt altra storia da quello che dici tu! e poi che stai dicendo? i driver a parte?l’obiettivo del kernel è di “includere” il supporto per piu periferiche in assoluto, non ha senso scindere i driver dal pacchetto del kernel. inoltre il kernel è modulare. sai cosa significa? quello che hai detto è proprio sbagliato ma tranquillo :P
a quelli che stanno dicendo che il kernel è in C blabla… il problema del kernel non è linguaggio ma la scelta implementativa. il kernel è il software che usiamo che è a piu stretto contatto con la macchina. questo significa che MOLTO codice è scritto in linguaggio Assembly. ogni singolo byte deve essere caricato manualmente per intenderci. Il C è il linguaggio del vero programmatore. Permette di fare molte porcate perchè è flessibilissimo, ma attenzione a ricordarvi che piu aumenta il livello del linguaggio e piu è difficile capire il costo di un “operazione”. e siccome il kernel è la cosa piu importante in assoluto, sapere ogni costo di ogni ciclo while ecc è una cosa importantissimaaaa. se linux è la flessibilità per eccellenza , ci sarà un motivo.
Beh grazie i driver sono il kernel stesso :-D ma che dici? anche windows ha molti driver nel kernel, non per questo è l’OS che supporta piu hardware al mondo. stai facendo un pò di confusione su cosa sia realmente un kernel ;) gestione dei processi concorrenziale, memory allocation ecc
@Federico
>1. perche’ non me ne potrebbe fottere di meno di portage e di gentoo in generale
Facevo l’esempio di un software di gestione ben progettato (che si possa compilare un intero sistema operativo + programmi utenti senza troppe rogne ha del miracoloso)
>2. perche’ nessuna persona sana di mente si metterebbe a riscrivere un sistema complesso (funzionante) in un altro linguaggio solo perche’ a qualcuno sembra piu’ leggibile
il codice per la maggior parte del tempo viene *letto*, non scritto, quindi scriverlo in un linguaggio leggibile è importante (e il Python è indiscutibilmente più leggibile di bash grep/awk/sed/arggg $`(cat ln -a boh). E poi il mondo dell’informatica si è evoluto perchè ogni tanto qualcuno ha avuto il coraggio di riscrivere meglio l’esistente, o vorresti leggere roba scritta in assembler, perchè per il momento funziona?
>3. Appunto, se e’ stato scritto in python forse ci sono delle ragioni. Comunque sei stato te a propormi di riscriverlo in bash, quindi sei te quello che devi convincere, non me.
ti ho solo rigirato la domanda retorica che mi hai fatto, avrai notato che non è uno stile piacevole.
Ciao
4. @anonimo:
Se il progetto è immenso come Linux tu hai centinaia di patch da tenere in sync e che possono intereferire tra di loro, e da solo questo problema IMO è in grado di distruggere qualunque precisione ottenibile dal solo C pure usato dall’artista del software. Perciò penso che un buon supporto (leggi OOP, type-checking, etc) da parte del compilatore possa aiutare parecchio ad evitare casini.
PS *metti il nick nel campo name* non è difficile
@Waxblood
>”Facevo l’esempio di un software di gestione ben progettato (che si possa compilare un intero sistema operativo + programmi utenti senza troppe rogne ha del miracoloso)”
Errore logico numero 1: Non si estende mai un caso particolare ad una situazione generale.
>”E poi il mondo dell’informatica si è evoluto perchè ogni tanto qualcuno ha avuto il coraggio di riscrivere meglio l’esistente, o vorresti leggere roba scritta in assembler, perchè per il momento funziona?”
Errore logico numero 2: Hai cambiato il contesto. Come dici te, le cose se si rifanno e’ perche’ si rifanno meglio. Rifarle allo stesso modo ma in un altro linguaggio e’ una cosa diversa.
“ti ho solo rigirato la domanda retorica che mi hai fatto, avrai notato che non è uno stile piacevole.”
Errore logico 3: Io non ti ho rigirato nessuna domanda. Io ti ho fatto una domanda su qualcosa che hai scritto TE. Tu mi ha fatto una domanda su qualcosa che io non ho mai detto.
Questa e’ l’ultima volta che ti rispondo, perche’ discutere con qualcuno che ha opinioni diverse e’ un conto, discutere con qualcuno che non e’ capace a seguire un filo logico e risponde ad affermazioni mai fatte e’ una perdita di tempo e una fonte di stress della quale faccio volentieri a meno.
Io ho risolto i problemi con Linux migrando su FreeBSD.
Interfaccia API/ABI stabile, supporto hardware piu’ che adeguato alle mie macchine, e la possibilita’ di usare i software closed di Linux senza problemi.
In 5 anni di utenza Linux non sono mai riuscito a restare con una distro piu’ di 6 mesi. Adesso da un anno uso quasi solamente FreeBSD e non mi preoccupo piu’ di aggiornare.
Lunga vita e prosperita’ :-D
@ per tutti
Ragazzi posso capire la tifoseria ma difendere una filosofia che andava bene dieci anni fa’ quando le cose erano abbastanza differenti credo meriti una riflessione.L’attuale modello di sviluppo e l’approccio verso l’utente finale sono oramai datati ed inadeguati.Il kernel di dieci anni fa’ era piccolissimo e supportava un decimo delle caratteristiche che ha oggi.E’ quanto mai improponibile da parte dei kernel developers questa resistenza al cambiamento,cosa che francamente essendo nel software *libero* dovrebbe esserne un valore aggiunto non un problema.Non e’ una proposta di rilasciare kernel solo binari,ma dovrebbe essere tutto riprogettato tenendo in considerazione aspetti che all’epoca non si consideravano.A mio avviso l’utente dovrebbe ricompilarsi il kernel (a mo’ dell’XNU del Darwin) solo nella situazione di modifica esplicita e “fuori standard” del kernel stesso,non per attivare o disattivare delle caratteristiche.
@Zarathustra
Gia’ ottimo sistema ed ottima scelta.Un po’ tristezza e rabbia mi vengono ripensando alle occasioni mancate.Ad oggi sogno ancora forse un po’ ingenuamente l’ubuntu desktop sopra un kernel BSD.Sia esso FreeBSD oppure il rivoluzionario DragonFly.Anzi sarebbe ora che ci contassimo e facessimo qualcosa in proposito. :P
Saluti.
@71
In effetti DragonFlyBSD si dovrebbe adattare molto bene ai chip multicore : mi sembra che sia l’unico progetto opensource che fornisca un pacchetto di kernel thread (LWKT) perfettamente funzionante e un supporto al multiprocessor abbastanza semplice, senza gli svantaggi delle soluzioni SMP adottate in linux.
In futuro molto probabilmente cambierà anche il paradigma di programmazione dei sistemi : tempo fa quando ho sentito per la prima volta il termine di MORPHWARE ho pensato subito a una delle solite trovate commerciali.
Scavando invece mi sono reso conto che è una vera e propria rivoluzione nel concetto dei sistemi computazionali. In sostanza è un sistema congiunto hardware/software in cui l’hardware si “adatta” alle esigenze del software in maniera dinamica “allocando” risorse di calcolo nell’arco temporale.
Ad esempio se stanno girando un gioco , un’applicazione di calcolo e un wordprocessing , le risorse di calcolo sono allocate dinamicamente a tali processi o allocando staticamente “pezzi” di hardware a tale compito o switchando in multitasking parte dei circuiti dell’hardware che transitano dallo stato di GPU a quello di CPU per calcoli in floating point a quello di CPU a bassa intensità di lavoro.
Un kernel linux – come tanti altri presenti oggi sul “mercato” – nato e cresciuto con presupposti molto diversi , non credo ruscirebbe ad “adattarsi” ; un microkernel – a questo punto un nanokernel ;-) – si adatterebbe meglio a simili nuove circostanze.
Non è che questa sostituzione avverrà domani :D … però fa bene guardare un po’ al futuro per capire i limiti del presente che indubbiamente si riflettono anche “sull’incertezza” che regna all’interno di molti dei progetti OpenSource e non ;-)
Per chi volesse saperne di più sul morphware la pagina da cui partire è http://www.morphware.org/
Ma state tutti quanti a criticare di qui e a criticare di la’ ma qualcuno di voi fa’ qualcosa per
l’OS, mantenete pezzi del kernel di Linux o fate solo chiacchiere ?
Bello dire “E’ quanto mai improponibile da parte dei kernel developers questa resistenza al cambiamento” e allora fallo tu il kernel developers se ne sei capace, altrimenti zitto e ringrazia che qualcuno lo faccia per te!
Mi aspetterei un 3ad del genere da persone coinvolte nello sviluppo del kernel ma da semplici “user” mi sembra troppo!
Vogliamo parlarne, parliamone, ma giudicare le scelte fatte da persone che si fanno “un mazzo tanto” senza alzare un dito mi pare troppo comodo.
@phoebius
“Ma state tutti quanti a criticare di qui e a criticare di la’ ma qualcuno di voi fa’ qualcosa per l’OS, mantenete pezzi del kernel di Linux o fate solo chiacchiere ?”
Cos’e’ l’ennesima giustificazione che fra l’altro suona come ricatto per non migliorare le cose? Io non mi occupo di kernel (non ne sarei capace) ma ho il diritto dopo piu’ di dieci anni di esperienza con linux di esprimere un mio parere e se c’e’ qualcosa che non va’ di sottolinearlo per PROMUOVERE un miglioramento se ho l’idea giusta.L’OPENSOURCE E’ ANCHE QUESTO.”L’idea del perche’ e’ gratis e libero prendi e stai zitto” non mi sembra la formula migliore per perfezionare quello che abbiamo,anzi non lo e’ mai stata da nessuna parte ed in nessun contesto.Saluti.
Credo che phoebius intendesse: “Non ti va bene? Prego, fatti avanti”. Oppure porta soluzioni tecniche attuabili. Le critiche han senso se costruttive. Il tuo uscirtene con “L’idea del perche’ e’ gratis e libero prendi e stai zitto” l’hai messa in campo tu. Vuoi qualcosa di migliore? Contribuisci. Nel modo che puoi. Non in panciolle sul divano criticando, ma facendo notare le migliorie derivanti dalla tua idea. Questo è Open. Questa è la Libertà. Non la Libertà d’infangare, ma la Libertà di costruire insieme. Altrimenti ci son sempre le alternative.
@Xander
Ripeto la mia idea l’ho espressa credo (e spero!) abbastanza chiaramente.Sono profondamente convinto che da un po’ di anni a questa parte,forse complice anche il successo,alcuni progetti si siano irrigiditi su posizioni di intransigenza pura.La situazione del kernel oggi (come sviluppo ed uso) non e’ delle migliori considerando che si procede a piccoli passi verso la standarizzazione degli ambienti operativi del sistema.L’approccio del kernel e’ vecchio,vecchissimo del periodo in cui ti aggiustavi e ti settavi qualunque particolare su distribuzioni di primo piamo (quindi le piu’ standarizzate per l’epoca) come Suse,RedHat,Slackware.Oggi per come la vedo io e’ necessario facilitare la gestione del kernel per le normali operazioni d’uso a scapito degli interventi straordinari come la modifica del codice o l’inserimento/esclusioni di caratteristiche.
Siamo nell’opensorce,siamo nella liberta’,nella flessibilita’ piu’ completa.Non esiste nessun punto fermo (neppure le API a quanto sembra…) per cui non trovo motivo per non considerare un miglioramento anche a costo di cambiare parecchie cose al fine di adeguarsi ai tempi e supportare al meglio chi il kernel lo usa come componente di un sistema operativo e non come un pacchetto di sorgenti su cui svilupparci codice.
In ultimo ,sembra che tu preferisca non sentir nulla o meglio sentire quello che ti fa’ piu’ piacere piuttosto che scontrarti con questioni forse spinose.Dalla tua risposta deduco cio’.Non vedo perche’ (non contribuendo al kernel per incapacita’ e perche’ occupato in altro progetto) non possa/debba criticare quello che considero (ma ti posso assicurare non solo io) un problema in prospettiva…….Il fatto che non ti vada bene la mia critica non e’ un problema che necessiti di un chiarimento sulla liberta’ in generale e sulla suo applicabilita’ ma un *tuo* problema.
@71
Si l’approccio del DragonFly nel multiprocessing e’ interessantissimo ed in prospettiva ancora di piu’.Il multiprocessing simmetrico dei sistemi tradizionali come Linux,FreeBSD e Solaris hanno fatto secondo me,il loro tempo e forse in futuro potrebbero mostrare tutti i limiti prestazionali.Gia’ abbiamo visto come l’approccio M:N per il threading in questi ultimi due sistemi sia stato prestazionalmente fallimentare.Lo switch di processi fra CPU e’ costosissimo in termini temporali e chissa’ che un giorno si dimostri come l’approccio asimmetrico non solo scali di piu’ ma sia piu’ semplice da gestire e prestazionalmente migliore.
#76 “Non c’è peggior sordo….”
Nessun problema personale, stai tranquillo. Se tu ed io non manteniamo il kernel, e chi lo mantiene vuole “qualcosa” in più che semplici parole, mi spieghi che fine ha il tuo punto di vista? Serve a rimescolare le acque se le rimescola, alrimenti, pur essendo una buona idea, non approda da nessuna parte. Suggerisco una discussione costruttiva con chi di dovere, per vedere se la tua richiesta ha seguito oppure no. In alternativa, IMHO, è un po’ dispersivo far qui delle proproste quando i diretti interessati non le vagliano.
Ma se vuoi continuare, libero di farlo.
Auguri.
@Xander
“Non parliamo del cieco allora….”
Certo e’ vero ed il mio rimane un punto di vista.Pero’ l’idea e/o la volonta’ di avere linux sul desktop non l’ho decisa/voluta io.Volere capre e cavoli sbagliando (il piu’ delle volte) e’ un difetto che puo’ colpire tutti quindi anche lassu’ fra gli “unti” della storia informatica recente.E nostro diritto/dovere far notare alcune cose e suggerire delle soluzioni.Ma lo e’ altrettanto da parte loro.Ovviamente non sto’ dicendo che la mia idea debba essere necessariamente la migliore o la piu’ corretta.Ci mancherebbe! :P
Comunque meglio fare gli auguri a chi queste cose le dovra’ gestiree ne risponde direttamente.Io ho la possibilita’ di scegliere sempre il sistema migliore sul mercato che non e’ detto sia linux e/o rimanga linux.Saluti.
@Federico
>Errore logico numero 1: Non si estende mai un caso particolare ad una situazione generale.
Un caso particolare di successo (quanti credevano che una roba come Gentoo potesse funzionare e avere un seguito?) è particolarmente auspicabile che si estenda al contesto generale, è così che funziona l’Open Source
>Errore logico numero 2: Hai cambiato il contesto. Come dici te, le cose se si rifanno e’ perche’ si rifanno meglio. Rifarle allo stesso modo ma in un altro linguaggio e’ una cosa diversa.
rifarle in un linguaggio orientato agli oggetti facilmente estensibile e mantenibile E’ rifarle in modo diverso
>Errore logico 3: Io non ti ho rigirato nessuna domanda. Io ti ho fatto una domanda su qualcosa che hai scritto TE. Tu mi ha fatto una domanda su qualcosa che io non ho mai detto.
quella roba sulla gentoo-dev in effetti potevo risparmiarmela, mi giravano solo un po’ le palle perchè non avevo gradito il tono della tua risposta
>4.Questa e’ l’ultima volta che ti rispondo, perche’ discutere con qualcuno che ha opinioni diverse e’ un conto, discutere con qualcuno che non e’ capace a seguire un filo logico e risponde ad affermazioni mai fatte e’ una perdita di tempo e una fonte di stress della quale faccio volentieri a meno.
Se vorrai rispondermi, commettendo l’errore logico di contraddire la promessa appena fatta, sarò lieto di leggere le tue opinioni.
Ciao
@Anonimo “Pero’ l’idea e/o la volonta’ di avere linux sul desktop non l’ho decisa/voluta io”
Per caso te l’hanno imposta ?
“.E nostro diritto/dovere far notare alcune cose e suggerire delle soluzioni.”
“Io non mi occupo di kernel (non ne sarei capace) ma ho il diritto dopo piu’ di dieci anni di esperienza con linux di esprimere un mio parere e se c’e’ qualcosa che non va’ di sottolinearlo per PROMUOVERE un miglioramento se ho l’idea giusta.L’OPENSOURCE E’ ANCHE QUESTO.”
Dovere puo’ darsi, diritto…….mmmmm e chi te lo ha dato questo diritto ?
Il diritto a fare o a dire qualcosa non ti arriva dallo Spirito Santo ma dall’ impegno che metti,
per migliorare, o come dici tu per PROMUOVERE un miglioramento.
Senza dubbio tu puoi dire la tua, come tutti noi d’altronde, ma, come avevo gia’ scritto, FORSE per migliorare le cose, piu’ che di gente che si sente in DIRITTO di criticare si avrebbe il bisogno di gente che si senta in DOVERE di aiutare la comunità OS a migliorare, in qualsiasi modo (per farti un esempio io non sono capace a scrivere o correggere il Kernel, ma do’ una mano nelle traduzioni o in piccole localizzazioni).
Tu stesso dici “”L’idea del perche’ e’ gratis e libero prendi e stai zitto” non mi sembra la formula migliore per perfezionare quello che abbiamo,anzi non lo e’ mai stata da nessuna parte ed in nessun contesto.”
Poi prendi, critichi ma non fai nulla per cambiare, il che mi pare peggio del “prendi e stai zitto”.
Forse la formula migliore potrebbe essere “prendi, critichi ma dai una mano a migliorare” o no ?
Saluti
@phoebius
“Per caso te l’hanno imposta ?”
No,ma non e’ questo il punto.Non rivoltiamo la padella ogni volta secondo convenienza.Temo che si vogliano fare le cose senza prendersi neanche una critica, sia essa giusta o sbagliata.Francamente la cosa e’ abbastanza curiosa poiche’ si parla di opensource tradizionalmente piu’ vicino alla mentalita’ della gente comune e non alle logiche aziendali “superiori”.
“Dovere puo’ darsi, diritto…….mmmmm e chi te lo ha dato questo diritto ?”
La democrazia.Ma stiamo parlando di opensource o cosa? Indipendentemente da tutto non vedo perche’ non si debba/possa utilizzare lo stesso metro di giudizio che si applica ovunque.
Voglio credere che nel tuo ragionamento ti sia sfuggita per errore la sospensiva riguardo al diritto di critica.Non voglio credere che tu sia parziale.
Il fatto di non contribuire a quel progetto per incapacita’ e perche’ occupato altrove ( cosa che ti sfuggita evidentemente) non mi esenta (come chiunque,anche il semplice utilizzatore) dal fare critica se la considero costruttiva.Quello che stai facendo passare come giustificazione e’ una palese violazione di un diritto.Fai attenzione.Saluti.
@anonimo
solo chiacchiere al vento!(come si dice dalle mie parti)
come puoi pretendere di sapere cosa c’è che non va nel kenrel e cosa sarebbe meglio fare se, a quanto dici: “Io non mi occupo di kernel (non ne sarei capace)…”.è un discorso che non sta ne in cielo ne in terra visto che non hai idea di quale siano i problemi in realtà. come se io che non ne capisco un cazzo di calcio e mi metto a mandare delle mail di consigli a lippi….
ps
eppoi tra tutte queste “idee innovative” non ti è ancora venuta un’idea per un nome decente??
Personalmente da quando sono passato a linux soprattutto a ubuntu ho sempre avuto problemi.L’unica cosa buona è la mancanza di malware per il resto sto per sprofondare nel cesso, scusate il termine.
Per una recensione più accurata vi invito a visitare il mio forum,ci sono tante nuove distro ahahhaha
cliccate sul nick