Visszatért a régi Linus: "... a kódod szemét"

Kernel

Linus jó ideje (kb. amióta pihenőre ment) nem veszítette el nyugalmát annyira az LKML-en, mint a minap, amikor flame-be keveredett a Google egyik fejlesztőjével az inode-okkal kapcsolatban. Okító szándékkal jelezte, hogy a fejlesztő által beküldött "baromságot" nem fogadja el:

Úgy másoltad le ezt a funkciót, hogy nem értetted meg mit miért tesz, és ennek eredményeként a kódod SZEMÉT.

A teljes levél:

Steven,
stop making things more complicated than they need to be.

And dammit, STOP COPYING VFS LAYER FUNCTIONS.

It was a bad idea last time, it's a horribly bad idea this time too.

I'm not taking this kind of crap.

The whole "get_next_ino()" should be "atomic64_add_return()". End of story.

You arent' special. If the VFS functions don't work for you, you don't
use them, but dammit, you also don't then steal them without
understanding what they do, and why they were necessary.

The reason get_next_ino() is critical is because it's used by things
like pipes and sockets etc that get created at high rates, the the
inode numbers most definitely do not get cached.

You copied that function without understanding why it does what it
does, and as a result your code IS GARBAGE.

AGAIN.

Honestly, kill this thing with fire. It was a bad idea. I'm putting my
foot down, and you are *NOT* doing unique regular file inode numbers
uintil somebody points to a real problem.

Because this whole "I make up problems, and then I write overly
complicated crap code to solve them" has to stop,.

No more. This stops here.

I don't want to see a single eventfs patch that doesn't have a real
bug report associated with it. And the next time I see you copying VFS
functions (or any other core functions) without udnerstanding what the
f*ck they do, and why they do it, I'm going to put you in my
spam-filter for a week.

I'm done. I'm really *really* tired of having to look at eventfs garbage.

Linus

A teljes szál itt kezdődik.  🍿

( nagyjoco | 2024. 02. 07., sze – 15:13 )

Az asszertív kommunikáció mintaesetét olvashattuk. 

( gyomber | 2024. 02. 07., sze – 15:16 )

Építő jellegű hozzászólásnak biztosan nem tekinteném...

Szerintem is rendben van.

A csávó egy nem létező problémát akar megoldani úgy, hogy közben szétkúrja a Linux kernel forrását. És ráadásul nem először teszi ezt. Teljesen jogos és megalapozott Linux felháborodása, és aki csak azon csámcsog, hogy milyen a stílusa, az valószínűleg nem értett meg semmit sem magából a problémából.

nekem úgy tűnik, hogy nem itt kezdődött....

Pár idézet csak a fenti emailből:

It was a bad idea last time, it's a horribly bad idea this time too.

AGAIN.

No more. This stops here.

stb. szóval ja, a leghatározottabban nem itt kezdődött, jól látható, hogy ez csupán az utolsó csepp volt már, amit számos kulturált Linus megnyilvánulás előzött meg. Persze azokból nem lett hír.

Linusnak igaza van de hozzáállását még oktatja is :) https://lkml.iu.edu/hypermail/linux/kernel/2401.3/04265.html

If somebody goes "I want to tar this thiing up", you should laugh in
their face and call them names, not say "sure, let me whip up a
50-line patch to make this fragile thing even more complex".

És? Nem értem, hol itt a probléma. Valakinek el kell küldenie ezt a sok gyökeret a faszba, különben szétcseszik a kernelt, és láthatóan senki más nem hajlandó erre. Talán azt hiszed, hogy a Linux Foundation tulajdonos Microsoft majd ingyé' odateszi magát a minőségéért? Hát arra várhatsz!

Miért ekézitek Linust a stílusa miatt, miért nem a sok balfaszt szidjátok inkább, akik semmi másból nem értenek? Azért azt lássuk be, Linux sosem ilyen hangvételű levéllel indít, mindig van egy-két jószándékű magyarázó előzmény levél is (persze azokról sosem esik szó).

Így van. Linus nagyon konstruktív, nem őt kéne anger managementre küldeni, hanem ezeket a balfaszjancsikat programozást tanulni.

(Bár élek a gyanúperrel, hogy sok esetben nagyon is tisztában vannak vele, hogy totál hülyeség, amit csinálnak, de kényszerből szándékosan teszik ezt, a nagyközönség elől titkolt, kifejezetten a munkáltatójuk által diktált üzleti érdek által vezérve. Például ennél az esetnél simán el tudom képzelni, hogy ezek az egyedi eventfs inode-ok ahhoz kellenek, hogy a Google kémprogramja még pontosabb jelentéseket küldhessen a nagytestvérnek a felhasználók Androidos tevékenykedéseiről, nem máté'. Nem állítom, hogy így van, csak azt, hogy akár még ez is lehetséges.)

Ez nem egy balfaszjancsi, több mint 25 éve dolgozik a kernelen, azon belül főleg a tracing alrendszeren és ehhez tartozó library-kon. Régebben dolgozott valós idejű ütemezésen is, bár jelenleg a hard-realtime patcheket már jó ideje mások hegesztik. Itt most egy fájlrendszer dologgal mellényúlt, nem az ő területe ezek szerint.

Ha jól tudom a patcheket kézzel küldözgetik be egy embernek, aki önhatalmulag dönt a sorsukról - a levelezésből itélve előre nem definiált kritériumok alapján.

De hogy működik a betanulási folyamat?

Hogy válhat valaki kernel-fejlesztővé?

Hogyan segítik az új tag integrálódását?

Én nem érzem valami fancy, generitikus eszköznek ha a commit-ok dokumentált, kereshető, mérhető work item-ekre épülnek.
Azoknak egyértelműen meghatározott minőségi követelményeknek kell megfelelniük,
az integráció jelentős része automatizált és nem függ egy ember személyes megitélésétől.

A subsystem maintainereknek (MAINTAINERS file) küldik általában a patcheket. A maintainer véleménye meg azért fontos, mert neki kell majd karbantartania a beküldött kódot a következő években vagy évtizedekben (stabil ABI), így jobb ha nem fogad be olyat, amit feleslegesen kell majd kerülgetni.

Keresni itt tudsz:

https://lore.kernel.org

https://patchwork.kernel.org/

Nem értem, hogy mi köze az emailnek (mint a patchek eljuttatására használt eszköznek) a döntést meghozó személyhez, vagy a dokumentációhoz. Ha Githubon (vagy hasonló felületen) menne a fejlesztés, ott is lehetne rossz döntéseket hozni, és ott is lehetne "elfelejteni" dokumentálni. Tehát még egyszer, mi a baj az emaillel? (A patch-et célba juttatja, tehát gond egy szál se. git-send-email, git-am, git-apply, git-request-pull pedig segítik a melót, ha kell, mindenfajta ~Github nélkül is.)

Mielott kinyitod a szad, es baromsagokat beszelsz, nezd meg GregKH videojat, hogy mikent zajlik a fejlesztes. A 4.3-as kernel idejen 8.1 change / hour volt a code frequency. Azota csak gyorsult. Tuti nem tudjak, hogy kellene ezt jol csinalni, majd Tassadar megmondja nekik a vallalati kornyezetbol.

szerk link lemaradt: https://www.youtube.com/watch?v=vyenmLqJQjs

Tassadar megmondja nekik a vallalati kornyezetbol.

aha, kernel commitok hány százaléka jön ma már gigavállalatoktól?
Valószinűleg ezek mögött van egy kidolgozott fejlesztési folyamat, a végtermék jut el Linushoz, aki a maga őrűletében integrálja azokat.

Ebben igazad van teljesen. A csak tisztán git alapú fejlesztés meg egységesebb bug tracking, jobban-rendszeresebben frissített, részletesebb dokumentáció jobb lenne. Linusban mindig is megvolt ez a konzervativista hozzáállás, bár én ma már ezt egyfajta értéknek tekintem, mármint hogy nem csábult el a modern, bullshit, agilis, mindent túlbonyolító, polkorrektkedő fejlesztői attitűdök felé.

A mailban küldött patch-eket azért nem is értem, mert a git-et is ő találta fel. Mindegy, én egyébként nem akarnám neki megszabni, hogy hogyan fejlessze a kernelt. Egyrészt jobban ért hozzá, mint én valaha is fogok, illetve már 3. évtizede sikeresen viszi ezekkel a kőkorszaki módszereivel a projektet, így ez meg a fenntarthatóságról, időtállóságról tanúskodik.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

a levelezésből itélve előre nem definiált kritériumok alapján.

Nem tudom, ezt honnan vetted, de nem a levelezésből, az tuti. A levelekből pont, hogy az világlik ki, nagyon is jól definiált kritériumokat sértett meg, amik nemegyszer le lettek már fektetve, és amikre már többször felhívta a figyelmét Linus. Elég nehéz védeni az álláspontod.

Többek között ilyen kritérium:
- olyan dologot akar javítani, amire nincs is egyetlen hibabejelentés se
- nem árulja el, hogy miért kell a javítás
- leduplikál már meglévő funkciókat
- olyant próbál meg újfent beerőszakolni a kernelbe, ami már egyszer - kellő indoklással - el lett utasítva

Ha neked úgy tűnik, hogy ezek "nem definiált kritériumokba" ütköznek, akkor ne haragudj, de Veled van a baj, és nem Linus-szal.

nem utólag ráhúzva egy commitra.

Mégis miről beszélsz? Az megvan, hogy ez a levél egy ISMÉTELTEN, korábbi észrevételek figyelmen kívül hagyásával beküldött patchre érkezett? Hogy lehetne már ez "utólag", amikor ismételt beküldésről van szó?

Egyébként meg jó olvasgatást: https://www.kernel.org/doc/html/latest/process/submitting-patches.html csak gyorsan átfutva legkevesebb 3 ponton megsértette az itt lefektetett irányelveket.
De csakhogy a legkézenfekvőbbet említsem (kiemelés tőlem):

Whether your patch is a one-line bug fix or 5000 lines of a new feature, there must be an underlying problem that motivated you to do this work. Convince the reviewer that there is a problem worth fixing

Ugye azt még mindig nem árulta el, miért is akarja betolni ezt a patchet, csak annyit tudunk biztosan, hogy egyetlen hibajelentés sincs ezzel kapcsolatban...

Mégis miről beszélsz?

Beszélj normális hangnemben.

Az megvan, hogy ez a levél egy ISMÉTELTEN, korábbi észrevételek figyelmen kívül hagyásával beküldött patchre érkezett? Hogy lehetne már ez "utólag", amikor ismételt beküldésről van szó?

Én arról írtam hogy ezeknek könnyen elérhető helyen, egyértelműen definiálva kellene elérhetőnek lennie.
Linus saját véleményének megfogalmazása egy mail thread-ben nem ilyen, ellentétben ezzel:
Programming Principles

Itt most egy fájlrendszer dologgal mellényúlt, nem az ő területe ezek szerint.

Nem tudom, ezt honnan vetted, de nem a levelezésből, az tuti. Nem igaz, hogy most írt először fájlrendszer patchet, és nem igaz az sem, hogy most egyszer mellényúlt. Ez már a többedik eventfs patche, így még az sem állja meg a helyét, hogy ismeretlen lenne számára a terület.

Linus elég egyértelműen megmondta, azért akadt ki, mert olyant próbált a kernelbe erőszakolni, ami egyszer már - kellő indoklással - el lett utasítva, ennek ellenére semmibe vette a korábbi indoklást és változatlanul beküldte ismét.
"It was a bad idea last time, it's a horribly bad idea this time too."

Általában élvezettel olvasom, ha Torvalds kiosztogat embereket, de most kivételesen veled kell egyetértenem. Sajnos a kernel doksija elég szar, sok minden nincs ledokumentálva rendesen, meg a leendő fejlesztők szájába rágva, hogy mit hogy kell és érdemes csinálni. Ha állandóan leosztogat mindenkit, akkor is ha tényleg ők voltak a hülyék, akkor az lesz, hogy megint kényszerpihenőre küldik a polkorrektkedők, meg hogy antiszociális, nem lehet vele együtt dolgozni, bla-bla, meg akkor senki nem fog neki a kezel alá a kernelbe bedolgozni, és akkor azon fog menni a sírás, hogy nehéz embereket találni, meg kiégés van, bár a videón a maintainerekről beszél, nem a fejlesztőkről. Ezért ilyen tekintetben óvatosabbnak kéne lennie, meg türelmesebben a szájába rágni az embereknek a dolgokat, ha kell, általános doksiba is berittyenteni, és akkor mutogathat az RTFM szövegre.

Írom ezt úgy, hogy az eventfs-t nem ismerem, meg a fájlrendszerekhez sem értek elég mélyen, de tudtommal a VFS és az inode-ok minden linuxos natív fájlrendszernél lekerülhetetlenek. Bár itt nem is az inode-ok, hanem az inode számok voltak a probléma.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Nekem úgy tűnik, hogy meglévő hívás helyett lemásolt, mókolt működésről, talán memory leakről és más agyament dolgokról van szó.

Meg talán senki nem is érti, hogy mit akarnak a googlenél összehozni itt. Talán chromecast vagy más eszközüknél akarnak valami nagyon minimál dolgot, amit belegányolnának, csak hogy valahogy működjön, akkor is ha másnak semmi haszna belőle és ha amúgy hibásan működik.

vegigolvastad a threadet? teljesen ertheto mezei emberek szamara is, hogy mi a baja Linusnak. Meg vagy 20 levelen keresztul segit egyebkent neki.

A csavo olyanokon aggodik, hogy a tar pl nezi a file inode szamat, es az alapjan csinal/nem csinal dolgokat. es az eventfs lenyegeben egy pszeudo filerendszer (kb mint a /proc), emiatt spec inode szamokat akart hasznalni, es ezzel lenyegeben tori a tar-t pl (meg kitudja milyen mas userspace dolgot). Linus meg elmondja, hogy ha valaki be akarja tar-olni a /proc filerendszert pl, akkor az is csunya dolgokat fog tapasztalni, tehat ez PEBKAC, es nem kell azon aggodni, hogy a tar nem fog mukodni a /proc-on meg az eventfs-en. De a ficko csak koti az ebet a karohoz, es a pszeudo filerendszeret ugy akarja kezelni, mintha rendes fs lenne.

Elhiszem, te jobban értesz hozzá, meg nem érdekel, amit írok. Akkor ignorálod. Ilyen egyszerű.

Annyit még leírnék, mielőtt jönnének itt az önjelölt szakértők, hogy fájlrendszert írni nem könnyű. Legalábbis olyat, ami normálisan működik, normális teljesítménnyel, és megbízhatóan működik. Elég kevés ember utazik ebben emiatt.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Igen. Mezei ember nem fog érteni a fájlrendszerekhez ilyen mélységében. Amúgy a csávó ezirányú aggódása némileg jogos, a tar-nak nem kéne ilyeneket nézni. Abban viszont neked van igazad, hogy ki a rák akarnak /proc-ot tar-ozni, az tuti valami komplett elmebeteg. Ezzel az eventfs-sel továbbra sem vagyok azért teljesen képben, hogy minek kell ez, miért dolgoznak rajta. Valahogy ez nekem kimaradt. Gondolom valamihez tényleg fontos lesz, ha a Google is embert állított rá, nem csak unatkozásból csinálják.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ez tök OK lehet a guglitól.

Ám ettől függetlenül egy "azért fogadd be a vackomat, mert..." sor és utána ütős érvek felsorolása, csak kellene, ha már jegy nincs hozzá.

Igy kb ez történt:

- Csináld meg!

- Nem, mert van már ilyen funkció

- Csináld meg!

- Nem, mert van már ilyen funkció.

...

- Csináld meg!

- Na elmész te.... 

( deje | 2024. 02. 07., sze – 15:26 )

Én jókat szórakoztam ezeken mindig is, már hiányzott :)

( sz332 v | 2024. 02. 07., sze – 17:57 )

Ez nagyon a helyén volt, ez különösen tetszett:

My point stands: I want this filesystem *stabilized*, and in s sane format. Look to *simplify* things. Send me patches that *remove* complexity, not add new complexity that you have zero evidence is worth it.
 

No, hát ez a különbség a mérnök meg a tákoló között.

( locsemege v | 2024. 02. 08., cs – 22:29 )

Teljesen rendben van Linus levele. Mégis, mit kellett volna tennie? Lemónikáznia a hülyegyereket? :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( gee v | 2024. 02. 09., p – 14:55 )

Úgy másoltad le ezt a funkciót, hogy nem értetted meg mit miért tesz, és ennek eredményeként a kódod SZEMÉT.

Láttam már én is ilyesmit fiatal titánoktól, akik úgy képzelték, hogy a programozás az nem úgy megy, hogy az ember végiggondolja, kitalálja és megírja, hanem úgy, hogy összeollózza a dolgot.

Mondjuk nem linux kernel volt, de azért nemzeti szolgáltatónál simán lehet üzemkiesést, rossz számlázást és hasonlókat elkövetni. Ha addig sikerül eljutniuk, hogy legalább lefordul a kód.

Én leginkább azzal a szeméttel találkoztam, ami még le se fordult, mert az illető annyira nem értette, hogy mit is csinál. :-(

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

C-ben meg aztán könnyen lehet olyat csinálni, ami felületesen nézve jó, le is fordul, de nagy baj lesz belőle.

Van olyan kódom, amelyben két soros kommentben magyarázom meg, hogy ami itt van, az miért jó, és igen, ránézésre úgy tűnik, minthe el lenne rontva, és épp fordítva történne egy feltétel vizsgálata, de bizony bármennyire csábító a „kijavítása”, azzal lenne elrontva, szóval ne. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( igor | 2024. 02. 10., szo – 15:01 )

Na vegre! Visszakaptuk a regi Linust!
Amugy lassan annyira PC minden ceg, hogy ha visszadobsz egy pull requestet azt sertesnek veszik.