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

È tornato.

Mangerà le anime di chi gli ha datto torto quando invece aveva ragione. Quando si era spaccato per creare uno scheduler ottimo ed è stato sorpassato dal primo arrivato. Ha già dato alle stampe le sue dichiarazioni furenti, dicendo anche che non spingerà per far entrare il nuovo scheduler che ha scritto nella mainline.

Si, perchè Lui ha scritto un nuovo scheduler. E non avrà pace finchè non avrà mietuto tutte le vittime di cui ha bisogno per nutrirsi. Come quali vittime? I vostri PC naturalmente.

Il suo nuovo scheduler dicono che spacchi.

Si è pronunciato riguardo lo scheduling, dicendo che sarebbe meglio concentrarsi su uno scheduler per i desktop, ed uno per i server; in linea di massima sono d’accordo con lui.

È sempre stato il mio kernel hacker preferito, Con Kolivas, e, come molti, gioisco e applaudo al suo ritorno. Un ritorno in grande stile.

]]> http://dottorblaster.it/2009/09/con-kolivas-2-il-ritorno-e-la-vendetta-d/feed/ 13 http://dottorblaster.it/2009/07/xf86-video-intel-2-8-0-e-fra-noi/ http://dottorblaster.it/2009/07/xf86-video-intel-2-8-0-e-fra-noi/#comments Wed, 22 Jul 2009 20:29:36 +0000 Bl@ster http://dottorblaster.it/?p=416
Chi mi conosce bene sa che sono stato uno tra i più grandi avversatori della scelta fatta dagli sviluppatori di Intel: dare la precedenza al metodo di accelerazione UXA dichiarandolo deprecato ed eliminando ogni supporto ad EXA e XAA mi sembrava una forzatura, una scelta stupida che avrebbe solo intaccato la stima di quei pochi [...]]]> Chi mi conosce bene sa che sono stato uno tra i più grandi avversatori della scelta fatta dagli sviluppatori di Intel: dare la precedenza al metodo di accelerazione UXA dichiarandolo deprecato ed eliminando ogni supporto ad EXA e XAA mi sembrava una forzatura, una scelta stupida che avrebbe solo intaccato la stima di quei pochi utenti che Linux ha acquisito sul fronte Intel.

Poi questi driver. Stamattina, vista la notizia, mi sono precipitato ad aggiornare a manina il driver sulla mia Arch, comprendente anche Mesa 7.5, Xserver 1.6.2 e tante altre sciccherie che solo noi testers (tsè! :D) possiamo permetterci di avere.

Dunque, riavviando, ho sgranchito le articolazioni di pollici, alluci, e tutto ciò che ci sta di mezzo, ed ho finalmente testato l’ultimo driver partorito dalla nota casa di microprocessori.

Sbalordito, ho visto con i miei occhi che le prestazioni, a distanza solo di qualche commit, sono migliorate tantissimo. Grazie a Mesa 7.5, tra l’altro, non ho più un odioso flickering che avevo scoperto dovuto agli effetti di fade; Mesa e sciccherie a parte, il driver funziona, e ho constatato che non sento più una grossa mancanza di EXA. Qualche mese, ad essere pessimisti, e penso davvero che UXA diverrà pari a EXA se non addirittura migliore.

Nota bene: non utilizzo il Kernel Mode Setting.

Riagganciato il tutto con un po’ di colla, ho cominciato a leggere: Microsoft ha contribuito al kernel Linux, inviando agli sviluppatori di Linux un modulo per l’Hyper-V rilasciato sotto licenza GPLv2 :|

Lì per lì sono rimasto un po’ perplesso, valutando la notizia, poi ho deciso che, tutto sommato, non mi stupisce più di tanto. Le ragioni per cui Microsoft può aver fatto un gesto del genere sono molteplici, tuttavia ci si deve ricordare che l’azienda è partner di Novell (come mi ha ricordato LuNa), e che Google ha appena espresso la volontà di rilasciare un proprio sistema operativo dedicato apposta allo sfruttamento dei servizi in Cloud Computing. Ed in tutto ciò, guarda caso come il cacio sui maccheroni, Microsoft contribuisce al nostro amato kernel con un modulo che riguarda la virtualizzazione la quale, si sa, costituisce parte essenziale dei servizi Cloud :D

Chissà come andrà a finire questa storia. Magari tutti coloro che vedono di cattivo occhio tutto ciò che richiama lontanamente Microsoft calmeranno i bollenti spiriti. Perchè ricordate: dalla release 2.6.32, starete usando qualcosa in cui avrà messo le mani Microsoft ;)

Ovviamente il computer di cui si parla è il mio laptop, che come ricorderete avevo toccato ma non troppo, preferendo crogiolarmi tra gli agi del “sistema operativo universale”.

Dunque, dopo aver inserito il CD e aver completato l’installazione, accorgendomi che qualcosa non andava, ho controllato i file di log senza rebootare e mi sono trovato un bel FAIL nell’installare il kernel; per qualche motivo mkinitcpio non andava, ma è bastato un

pacman -Sy kernel26 -r /mnt

e magicamente il kernel è stato installato; tutto a posto dunque, per quanto riguarda l’installazione.

Un plauso va ai developers di ArchLinux, infatti essendo Arch una distro bleeding-edge, il kernel era all’ultima versione disponibile: grazie a delle migliorie apportate ad alsa e ai driver della mia scheda audio, adesso Arch non necessita di alcun fix per quanto riguarda il suono. Si sente tutto perfettamente, e ho potuto gustare da subito alcuni pezzi dei Dream Theater senza dover fare nulla.

Ho proceduto facendo un upgrade diretto al ramo testing, e senza perdermi d’animo, ho applicato quello che sapevo sui malfunzionamenti di mouse e tastiera: Xorg con l’ultima release è infatti migrato dai vecchi xf86-input-keyboard/mouse al nuovo xf86-input-evdev.

Per dovere di cronaca, ricordo che quando si esegue xorgcfg per configurare X in maniera automatica, il demone HAL dev’essere in esecuzione, pena il mancato riconoscimento di mouse e tastiera.

Con testing abilitato, posso anche godermi Compiz grazie ai nuovi xf86-video-intel e al nuovo Xorg; è una goduria girare il cubo e giocare con le finestre anche sulla mia distro preferita.

Dopo un po’ di tempo passato a gestire la connessione wireless tramite iwconfig ho anche installato seguendo l’ottimo wiki NetworkManager, che a dispetto di tutti i racconti dell’orrore sentiti in passato, a me funziona perfettamente e fa il suo dovere in modo egregio.

Il risultato, dunque, di questi smanettamenti dell’ultim’ora, è questo:

Non mi sembra che ci sia altro da dire, se non: io sono drogato di Arch! :D