Brain F(uck)AQs

Avrete letto ormai tutti del ritorno di Kolivas annunciato da me e non solo, ma forse non vi siete documentati abbastanza da leggere le FAQ riguardanti il nuovo patchset sviluppato dal nostro kernel hacker preferito, che tornando in grande stile non ha perso occasione per sbeffeggiare chi lo ha preso in giro buttando alle ortiche il suo lavoro.

Infatti, ogni riga delle sue FAQ è pregna del rancore che serba verso gli sviluppatori del kernel Linux, e tale rancore, trasformato in battutine e frecciatine quantomai azzeccate, mi ha fatto rotolare a terra per dei minuti, ridendo di gusto.

Per prima cosa cominciamo dal perchè ha scelto questo nome.

Perchè “Brain Fuck”?

Perchè non prende in considerazione nulla di ciò che conosciamo riguardo il design di uno scheduler moderno secondo il criterio di scalabilità.
Perchè è ridicolmente semplice.
Perchè fa le cose così ridicolmente bene riguardo ciò che deve fare, pur essendo così semplice.
Perchè è disegnato in un modo secondo cui la mainline non sarebbe mai interessata nell’adottarlo, che è appunto come piace a me.
Perchè farà alzare le persone in piedi e accorgersi di cosa non va nel progetto attuale.
Perchè la fa finita con la storia di uno scheduler che va bene per tutti i processi, e mostra che le cose possono andare benissimo con uno scheduler progettato per uno scopo specifico. Non voglio usare un rullo compressore per rompere le noccioline.
Perchè attualmente più CPU significano latenze migliori.
Perchè devo essere bacato in testa per pensare di lavorarci ancora.
Penserò a qualche altro perchè più tardi.

E già qui traspare il voler mettere in ridicolo chi lavora sulla mainline :D

Poi va avanti spiegando tecnicamente alcuni punti ostici dello sviluppo e alcune features particolari. Dopodichè entra nel vivo:

Processori multicore?

Beh, questa è la cosa che BFS fa meglio.

Uno scheduler progettato appositamente per PC moderni, in barba a Stallman e il suo medioevo informatico, e in barba a tutti gli sviluppatori del kernel che mantengono ancora il modulo per il token ring, per dirne una.

Ma continua con le sue battute non tanto bonarie, regalandoci attimi di ilarità:

Pensi di spingere mai per l’integrazione di questo scheduler nella mainline?

LOL.

No, veramente, lo farai?

LOL.

Dai, sul serio, lo farai mai?

No. Sarebbero pazzi ad integrare questo scheduler, se non altro perchè non scalerebbe fino alle loro macchine con 4096 CPU. L’unica via è riscriverlo per lavorare in quel modo, o avere più scheduler nel kernel. Non voglio fare il primo arrivato, nè la mainline vuole essere l’ultima. D’altra parte, sono un cattivo maintainer, cosa che ha senso dal momento che per qualche ragione sembra che io voglia avere una carriera, una vita, mettere su famiglia con dei bambini, avere degli hobby, tutte cose che non hanno a che fare con Linux.

Dopo aver letto queste FAQ, e l’amarezza di uno che ha dato tantissimo al kernel, ed è stato solo calciato via come una mela marcia, ho quasi pianto.

Ripeto, come ho fatto nello scorso post, che Con ha tutto il mio tifo perchè faccia vedere al mondo di cosa è capace lui, e quali mancanze abbia il kernel Linux. Così magari, forse, gli sviluppatori del kernel decideranno che il metodo di Con non è tanto male, e forse è ora di dare una svecchiata a Linux. :)

Post correlati:

This entry was posted in Kernel, Linux. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.
  • http://www.koalalorenzo.com koalalorenzo

    C'è qualche cosa che non quadra… o meglio… Linus Torvalds (così scrive), nel caso ci siano 2 patch che fanno la stessa identica cosa, utilizza scegliere la più utilizzata… dunque, se è veramente così, e se è vero che GNU/Linux può sbarcare benissimo lato Desktop, perché non la implementano???

    Del resto non abbiamo più CPU 4096 :9

    BTW: LOL.

  • http://dottorblaster.it/ Bl@ster

    Non la implementano perchè Linus ha preferito scegliere la strada più comoda, lo dice anche lui che è un pigrone e non gli piace assumersi troppe responsabilità: e lo Staircase Deadline era più problematico essendo scritto da un esterno alla kernel-dev :)

  • http://www.piplos.org/ Piplos

    Però ammettiamo che Linus è stato un po' stupido a respingere uno dei migliori per un sacco di tempo. Ho letto che con lo Staircase Deadline vi erano dei miglioramenti notevoli sulle performance della CPU, quindi perchè non implementare questa patch nella mainline?

    Troppo faticoso mantenerlo? Sti cazzi, ci pensa Con. :)

    Come minimo Linus avrebbe dovuto aggiungere CK nel suo gruppo di kernel developer. Why not?

  • http://dottorblaster.it/ Bl@ster

    Linus è stato MOLTO stupido. E non solo lui ;)

  • http://www.piplos.org/ Piplos

    Mi sorprende il tuo realismo, qualità che solo l'1% dei linari hanno. :)

  • http://dottorblaster.it/ Bl@ster

    Non concordo, in realtà quando si è saputo che Con aveva fallito il suo tentativo, si sono incacchiati in molti ;)
    Grazie comunque del complimento :P

  • http://andrealazzarotto.com/ Lazza

    Premesso che non entro nei meriti della vicenda che tratti perché non la conosco a fondo (e francamente non me ne importa nulla), c'è una cosa da dire su Con Kolivas. Un grande si vede anche da come si atteggia con gli altri. Anche se sei il più bravo in assoluto in qualcosa non ti puoi prendere il permesso di ridicolizzare gli altri, sennò passi per cafone e basta. Un vero “gentleman” non ostenta i propri pregi sfottendo gli altri del suo settore. ;)

  • http://dottorblaster.it/ Bl@ster

    Infatti non dice che quello che c'è fa cagare ;)
    Però fornisce un punto di vista interessante, perchè dal suo scritto emerge evidentemente il rancore che c'è nei confronti di chi ha buttato alle ortiche il lavoro di anni e anni.
    Ho usato lo scheduler di Kolivas per poche release prima che il patchset fosse dismesso, e devo dire che lo Staircase Deadline era ottimo. Se fossi stato in lui, avrei dato in escandescenze anche in Mailing List, invece quando lo hanno gentilmente mandato a quel paese, lui non ha detto nè fatto nulla, si è limitato a usare le sue ultime patch. Senza reclamare. Però è ovvio che se torna a lavorarci, se è così pazzo da farlo, allora qualche riga contro questa gente la scrive ;)

  • linuser

    I traduttori automatici sono delle rogne : non dice che lo scheduler non scala su CPU 4096 ( che non esiste ) , dice che il nuovo scheduler non scala bene sulle loro macchine da 4096 CPUs ( NUMA )

  • http://dottorblaster.it/ Bl@ster

    Non è stato un traduttore automatico, semplicemente non mi sono documentato abbastanza e causa ignoranza ho tradotto male :)

  • linuser

    Per rendersi conto di quale siano le vere macchine target di linux basta dare uno sguardo a questa lista : http://www.top500.org/stats/list/33/os

    CFS , lo scheduler che è stato integrato tempo fa in mainline , scala benissimo su queste macchine : in queste macchine l'obiettivo principale non è spremere la singola CPU , ma ottenere la massima efficienza ( performances + uptime + durata dei singoli componenti ) e onestamente a me non dispiace che la stessa politica sia adottata per il desktop : usare le singole componenti con efficienza piuttosto che spremerle al 120/130 per cento singolarmente coma fa windows anche quando non ci sta girando nulla.

  • http://dottorblaster.it/ Bl@ster

    Per carità, anche col Completely Fair i risultati sono ben visibili, ma gli scheduler di Con hanno dimostrato di essere degli ottimi scheduler per desktop sul campo, quindi non vedo motivo di non integrare lo SD insieme al CFS.
    In ogni caso, il problema non sussiste :D

  • Pingback: Brain F(uck)AQs

  • http://opensource2007.netsons.org LuNa

    ma qua facciamo le chiacchere di portinaia ? lo scheduler è l'ultima cosa e l'ultima delle priorità in ordine di importanza per il desktop linux in questo momento. onestamente, prima di schedularli, i processi, bisognerebbe averceli e bisognerebbe avere anche un desktop degno di tale nome.
    se c'e' una cosa che funziona, in un desktop (ugh!) linux è proprio il kernel. possiamo esaltarci per delle gran teste di *bip* che discutono peggio dei ragazzini di 5 anni (l'età tipica in cui ci si danno le cartelle nei denti stile paperissima sprint per un semplice giocattolo) ma il punto è un'altro e nessuno ci discute mai sopra. Con tutto il rispetto per Kolivas, grande quanto volete e mito quanto vi pare, può giusto stare dov'è perchè in questo momento rappresenta solo un'alternativa (la miliardesima) a qualcosa che c'e' già e che funziona benissimo. Porca miseria vogliamo standardizzare una volta per tutte questo *azzo di Linux e avere così forse qualche risposta sensata da produttori e software house di calibro mondiale ? ragazzi, fin quanto i driver li scrivo a casa mia e il desktop linux lo scrivono 100 sfigati (nel senso buono non fraintendete !) potete avere anche il miglior scheduler mai esistito al mondo che sempre una schifezza di desktop avremo per le mani. Esempi lampanti di organizzazione finita con base linux ? Ve ne do soltanto 2: Android (Google) e Maemo (Nokia). Fin quanto non succede questo a livello globale, niente desktop, e non facciamo i soliti confronti persi ancora prima di cominciare con Mac OS X e Windows perchè nel settore di cui stiamo parlando non ha alcun senso. Bisogna acchiappare tutto sto casino, la comunità, gli sviluppatori, ed i loro prodotti e incanalarli, ordinarli, obbligarli e spremerli incentivandoli per ottenere un risultato ma per farlo bisogna formattare le teste. Una volta raggiunto questo, Kolivas sarebbe un bel più. In questo momento però, è come avere il formaggio grattuggiato senza i maccheroni sotto.

  • http://dottorblaster.it/ Bl@ster

    Tanto non succederà mai finchè c'è Stallman fra le palle, suoi accoliti compresi, quindi almeno parliamo di scheduler.

  • telperion

    Ho appena compilato ed ho in uso il 2.6.31 con bfs-211, su 9.10 customizzata.
    Al primo impatto non mi pare di notare nulla di diverso dal solito, insomma il pc non ha cambiato faccia.
    Ora ricompilo il kernel 31 vanilla, e nel frattempo lavoro con gimp con elaborazione pesanti e scrivo il commento.
    Testo il tutto qualche giorno e poi vi dico.

  • http://dottorblaster.it/ Bl@ster

    Ottimo, attendo feedback dato che ho saputo della sua instabilità, e anche se è pressochè stabile voglio proprio vedere come va.
    Ovvio che al primo impatto non vedrai nulla, prova GIMP, la scrittura e anche un po' di editing audio per condire il tutto. ;)

  • linuser

    Non so se ti può interessare ma il nuovo scheduler è presente nel progetto zen-sources ; hanno un proprio ramo git per lo sviluppo del kernel che include anche altre features : http://git.zen-sources.org/?p=zen.git;a=summary

    Sto andando ad aggiornare il ramo che ho clonato localmente e a produrre la patch ( 2.6.31-zen0 ) per il kernel 2.6.31

  • telperion

    Ma, sarà per il fatto che io uso preemptive e timer 1000Hz su tutti i vanilla, ma non ho visto “ALCUN” miglioramento percettibile, anzi con xbmc si è frezzato il pc.
    Tornato al 2.6.31-vanilla e amen, troppo poco vantaggio (sempre che ci sia) per rischiare ulteriori instabilità.
    Amen.
    :)