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. :)