Periòdicament, els desenvolupadors de el nucli Linux debanten o es reuneixen per tractar certs temes. Normalment s'aprofiten algunes AMB per reunir-se personalment, cara a cara, però també s'empren les famoses LKML per debatre sobre altres detalls com aquests.
En aquesta ocasió s'ha tractat un tema específic, i és el límit de la longitud de les línies de text en el nucli Linux. Hi ha persones a les que els agraden les línies una mica més llargues per no malbaratar espai en vertical, i d'altres que prefereixen línies més curtes perquè no ocupin massa a l'ample. És més una qüestió de gustos o gairebé estètica.
Alguns pensen que els monitors i resolucions de pantalla s'han tornat tan grans en els últims anys que s'hauria de permetre escriure línies molt més llargues en els fitxers de codi de l'nucli. De fet, un dels desenvolupadors anomenat Alastair D'Silva està entre els que pensen això, i va publicar un pegat que permetia longituds de línia de 64 bytes en lloc dels actuals 16 o 32 bytes.
alguns com Petr Mladek no els va agradar això, Ja que pensa que 64 bytes significa tenir més de 256 caràcters per cada línia, i dubta que qualsevol humà li resultés fàcil llegir una línia tan llarga d'una forma senzilla, i que a més la resolució de pantalla necessària per ajustar aquest tipus de línies hauria de ser superior a la HD estàndard, i que probablement encara hi havia desenvolupadors amb pantalles modernes amb aquestes resolucions.
Sembla que hi ha poques possibilitats que el pegat escrit per Alastair arribi a incluírse de forma oficial en el nucli Linux. A més, sabem que Linus Torvalds és molt estricte pel que fa a no afavorir a uns desenvolupadors més que a uns altres i assegurar-se que els desenvolupadors poden treballar fins i tot amb equips humils, maquinari antic i low-cost. De fet, la longitud de línies no és una cosa nova, ja es va tractar en el passat. El mateix Linus va parlar sobre la longitud quan es discutia sobre pujar de les 80 als 100 caràcters, i va preferir mantenir les 80 en aquell moment (7 anys enrere).