Linus keményen kiosztotta az ex-Google-most-Meta-mérnököt: a kódod egy szemét ...

Kernel

A napokban Linus egy ex-Google-most-Meta-mérnökkel közölte, hogy kódja "szemét" és "rosszabb hellyé teszi a világot". Ez az eset is jól példázza Linus pull request-eket érintő kemény, de következetes hozzáállását, ami ugyan egyeseknek nem tetszik, de tény, hogy ezzel a szemlélettel évtizedek óta sikerrel egyengeti a világ legnagyobb FLOSS projektjét, ami nélkül az IT világ ma már kb. működésképtelen lenne.

( bennyh | 2025. 08. 14., cs – 09:09 )

Szerkesztve: 2025. 08. 14., cs – 09:11

Akkor, ha jól értem az ürge csinált egy felesleges függvényt egy sornyi kódnak, aminek a neve jobban elviszi a sűrűbe a többi fejlesztőt, mintha csak használta volna az egysoros bal shift + összeadást, amiről lehet is látni, hogy micsoda?

Ha ilonka valami jót is akarna adni a világnak AI fronton, inkább a Linus tudását pakolnák bele a grokba :D

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

( kikadff v | 2025. 08. 14., cs – 09:29 )

Fura nekem Linus. Kiosztja az nvidiat, bcaches fejlesztőt, stb, kiosztja ezt is, de mi változik? Annyira nem látok bele a linux fejlődésébe, de van bármi eredménye ezeknek a Linus kitöréseknek, vagy már mindenki beárazta, hogy Linus ilyen, amúgy megy minden a maga útján? Valaki linkelte másik topikban, hogy a requestek kicsiny százaléka megy át Linuson, mindenki tudja, hogy ha hozzá kerül és olyanja van épp, akkor majd lesz egy kis műsor?

Régebben még itt is hír volt, hogy el volt ájulva valami új kódon, hogy milyen kevés sorban oldja meg a régi kódhoz képest a fejlesztő, aztán meg mások szóltak, hogy kilométeres sorok vannak benne, meg valami feature szegénység is talán.

Nem tudom hová tenni Linust, erős kezű toppon lévő vezető, vagy csak egy brand.

Ha azt gondolja, hogy szemét a kód, akkor valószínűleg az is.

De a make_u32_from_two_u16-ból nagyon úgy tűnik, hogy igaza van az (a << 16) + b -vel és gondolom azon csesződött fel, hogy meg kellene ütni egy szintet. 

Abban is igaza van, ha rutinokat nem a megfelelő "általános"  header-be tettek. Plusz a szósorrendet, ami nem lesz mindenkinek megfelelő, elfedi a rutin (a nevét látod a rutinnak).

Gondolom nem az első ilyen a kernel történetében, és a linux most nem ilyen lenne, ha minden ilyet beengedne. Meg én elhiszem, hogy frusztrált emiatt, próbál tartani egy szintet, és akkor jönnek ilyenek.

Igen, azért általában (vagy mindig) van oka a kifakadásra, csak mi fog változni? Jó, gondolom ha megfogja ezeket a vitatható (szar) kódokat, akkor a megszólított fejlesztő változtat rajta, de a nagy képet nézve mi változik? Nem akarom becsmérelni Linust, méltán írta bele magát a történelem könyvekbe, azért még az ilyen-olyan fanboyoknak is egyértelmű, hogy a világ legelterjedtebb kernele az a linux, mégha nem is uralja az összes szegmenst. Ez hatalmas és elvitathatatlan eredmény Linustól. Viszont pont ezért a linux már óriási project, kizárt hogy egy ember toppon legyen az egészben, rengeteg kód kerül bele, amit Linus nem látott (#FIXME), szóval mi jelentősége van ezeknek a Linus kitöréseknek? Vagy van mástól is ilyen csak ők nem Linus és nincs visszhangja?

Évről évre olvasom a Linus kiosztotta ezt, kiosztotta azt híreket, már az a benyomásom, hogy Linus így működik alapjáraton és ez be van árazva. A fejlesztő is tudja, hogy majd előbb-utóbb eljön az idő, amikor Linus kiosztja, ő majd az aktuális szarságon módosít, aztán megy minden tovább.

Ha már látott egy ilyet, akkor nem lehet felette szemet hunyni, mert problémákat okoz. Gondolom az pluszban frusztráló lehet, ha nem tud minden kódot megnézni, és közben ilyenek is érkeznek.

Szerintem van értelme "beszólni". Akinek ezt írta, annak most az lenne a helyes hozzáállás, hogy "húú, erre nem is gondoltam, és igaza van", és beküldeni normálisan, legközelebb pedig figyelembe venni ezeket a szempontokat is. Ahelyett, hogy azt elemezgetni, hogy miért így kellett válaszolni. Tehát gyakorlatilag próbál átadni egy szemléletet annak, aki sz*r kódot küldött be. (És Linus elég jó kóder lehet, jó kis szemlélettel ami a kernelhez kell, mert jó-pár éve csinálja. Érdemes lehet hallgatni rá.).

Amúgy felmerül a kérdés, hogy jutott ez el Linusig? Ugye a normális flow szerint az egyéni fejlesztők patchei előbb a subsystem maintainerek reviewján mennek keresztül, ők signoff-olják és úgy megy tovább Linus-hoz végső approve-ra.

Van egy gyanúm, hogy a csávó a késve beküldés miatt (hogy mégis beférjen) megpróbálta megkerülni az alsóbb review köröket és direktbe küldte Linushoz.

Régóta vágyok én, az androidok mezonkincsére már!

Mondjuk ez megoldhato lett volna egy egyszeru elnevezessel: make_u32_from_two_u16_msb()

De abban igaza van, hogy ehhez nem kene helper a kernelben. Akinek ez nem megy, annak valami GC nyelv javasolt.

Eselyes BTW, hogy a kod nem volt valami fenyes mashol sem, es mar ott felhuzta magat, azert robbant ki itt.

Szerintem olyan , amilyennek lennie kell. Nem az embert nevezte szemétnek, hanem a munkáját. Aki ezt nem bírja, annak nem való ez a szakma. 
 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Melyik alapelvet szegte ezzel meg? 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Nem tudna. Ugyanis nem a személyt kritizálta, hanem a kódot - a CoC pedig a személyeket védi, nem a szarul elvégzett munkát. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Mivel nem ez az első "szemét a kódod" kirohanása, talán a CoC-ba be lehetne tenni erre is egy "szabvány" szöveget, ami határozott, de kevésbé élesen fogalmazott.
Aztán ha valakinek azt a szöveget küldené el, arról mindenki tudná, hogy Szemét a kódod haver! :)
De az ilyen vitákat és fölösleges szócséplést el lehetne kerülni vele.

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

  • Other conduct which could reasonably be considered inappropriate in a professional setting

Mondasz te a kollégádnak egy széles körben tartott meeting-en a munkahelyeden, hogy "tesó, a munkád egy szemét" és a "világot sokkal élhetetlenebb hellyé teszi"?

Ha igen, akkor ez teljesen rendben van a CoC szerint. Pont ez a probléma az ilyen erőltetett CoC szemetekkel egyébként. Gumiszabályok.

trey @ gépház

Alap esetben nem mondok, de simán elmondom négyszemközt valamire (ott is igyekszem nem nyersen, amennyire lehet). - Lehet, hogy Linus sem rögtön egy ilyen levéllel kezdi egy új fejlesztőnek, de erről ugye pont ezért nincs hír.

A levél gondolom azért sikerült nyersre, mert nem csak az adott esetre vonatkozik, hanem az összes múltbeli, és jövőbeli egyébként 1. elkésett pull requestekre, ami 2. szar kódot tartalmaz, ami 3. később még káros is, félreviszi a többi fejlesztőt. Tehát másnak is szólt, ha széles körben küldte szét.

Szerintem érhető Linus lelki világa is. Ezekre Linusnak kell odafigyelni, ha elcseszi abból probléma lesz. Arra van valami CoC pont, hogy normális munkát adunk ki a kezünkből a társunknak (nem szívatjuk meg?) ? Tehát hogy ne csak a commitoló lelki világát kelljen figyelembe venni.

Mondjuk itt vannak ezek:

https://www.kernel.org/doc/html/latest/process/submitting-patches.html

https://www.kernel.org/doc/html/latest/process/coding-style.html

https://docs.kernel.org/process/development-process.html

Ha a CoC-ra hivatkozna a fejlesztő, akkor ezeket is át kellene nézni.

"tesó, a munkád egy szemét" és a "világot sokkal élhetetlenebb hellyé teszi"

Azert a masodik mar egy kicsit eros szerintem es felesleges is, de amugy rendben van, a kernel fejlesztese korul ez tulajdonkeppen elfogadott.

Mondhatjuk, hogy a minoseg miatt van erre szukseg, ami annak fenyeben, hogy az Apache projektek "Community over Code" szellemben valo fejlesztese ellenere vagy epp emiatt is kepesek minosegi termek eloallitasara, szerintem inkabb bullshit.

Nem egészen; egy gyors webes keresés első négy találata:

Forrás: kb. mindenkinek a saját szeme, agya.

Nem azt mondom, mi van leírva, hanem hogy mi történik a valóságban.

 

Ezzel BTW nem feltétlen van baj; ugye alapvetően minél feljebb van valaki, annál hozzáértőbb is (...), tehát ha nem követi a szabályokat, "tudja mit csinál".

Tipikusan a groundbreaking tech -nél tényleg gyakori, hogy szabályt követve nem lehet, vagy túlságosan nehézkes eredményt elérni.

Én az eredetit olvastam: https://lore.kernel.org/lkml/CAHk-=wjLCqUUWd8DzG+xsOn-yVL0Q=O35U9D6j6=2DUWX52ghQ@mail.gmail.com/ direkt nem a Lunduke es hasonló 3rd party értelmezéseket.

Szerintem a "garbage" elég specifikusan a risc-v tree-n kivuli change-ekre vonatkozott - amiket a fejlesztő jól belesalátázott a pull request-be. A végén Linus még ki is emeli:

You're on notice: no more late pull requests, and no more garbage
outside the RISC-V tree.

Now, I would *hope* there's no garbage inside the RISC-V parts, but
that's your choice. But things in generic headers do not get polluted
by crazy stuff. And sending a big pull request the day before the
merge window closes in the hope that I'm too busy to care is not a
winning strategy.

So you get to try again in 6.18. EARLY in the that merge window. And
without the garbage.

Régóta vágyok én, az androidok mezonkincsére már!

Ezt irtad:

...hanem azt a konkrét kiemelt példát nevezte szemétnek.

Linus:

This is garbage and it came in too late.
Like this ...

Kurvara nem azt az egy konkret kiemelt peldat, hanem kb az egeszet. Ezzel kezdte. Az, hogy kesobb leirja, amugy a RISC-es reszekbe nem nezett bele, mert az nem erdekli, pont leszarom, amit te irtal az ugy ahogy van felrevezeto.

De simizd meg a fejedet, hogy Te az Eredetit olvastad, leulhetsz.

Szerintem olyan , amilyennek lennie kell. Nem az embert nevezte szemétnek, hanem a munkáját.

Tévedsz.

Torvalds egy mára kiégett, abszolút türelmét vesztett, a hatalomtól szociálisan korrumpálódott projektvezető. A kódot pontosan ugyanilyen technikai következményekkel elutasíthatta volna higgadtan is; pontosan ugyanilyen érvekkel, indokokkal. Csak a rengeteg díszítést kellett volna kihagyni belőle; azt a díszítést, aminek a szerepe egyrészt az indulatának a kifejezése, másrészt a másik megalázása, esetleg elriasztása.

Közel mindegy, hogy a kódot vagy kódert nevezte szemétnek; a legtöbb odaadó kézműves meglehetősen azonosul a munkájával -- és amikor nem azonosul, és nem vállal jól láthatóan felelősséget a munkájáért, akkor pontosan azt rójuk fel nekik. Amikor egy üvegfúvó vagy egy festő termékét megdicsérik, pozitív kritikát kap, akkor is azt mondod, hogy az alkotó "ne vegye magára" az elismerést, mert az nem neki szól, hanem a munkájának? Hogyan állsz a prémium (illetve bármilyen teljesítményalapú juttatás) kérdésével; ott érintheti az embert közvetlenül a munkája minősége? Szerinted írók, költők, séfek nem veszik magukra, amikor az alkotásaikat indokolatlanul támadó éllel kritizálják? (Nem arról van szó, hogy mit, hanem hogy hogyan.)

Ami különösen nagy gáz, az az, hogy Torvalds ezt nagy nyilvánosság előtt, és hatalmi pozícióból csinálja, relatíve noname emberekkel szemben. Olyan károkat okoz (elfogadható indok nélkül) mások szociális státuszában (megszégyenítéssel), amit nem tud (persze meg sem próbál) helyrehozni. Tisztességes projektben ilyen vezető kezéből gyorsan kiveszik a mikrofont (a barátai pedig javasolják neki, hogy menjen terápiára, de legalábbis pihenjen jó sokat). Az az egyszerű valóság, hogy amit Torvalds csinál, az műszakilag vitathatatlanul hasznos, pszichológiailag és szociálisan meg katasztrófa, és azon a területen, ahol ő tevékeny, ott az előbbi számít (= pénz), az utóbbi nem. Ettől még ne mondjuk, hogy "olyan , amilyennek lennie kell". Botrányosan rossz kódot is lehet civilizáltan kritizálni.

Azt is lehet természetesen csinálni, hogy a projekt nyíltan felvállalja, hogy megfelelő skill nélkül a fejlesztőket nem látják szívesen. (A valóság egyébként nyilván ez.) Szerintem ez teljesen rendben van, ha nyilvánosan vállalják és hirdetik. (Az más kérdés, hogy utánpótlást így nehéz lesz kinevelni.)

Aki ezt nem bírja, annak nem való ez a szakma. 

Ez a legnagyobb tévedésed; teljesen érzéketlen vagy. 20+ éve vagyok a szakmában, jó pár (szabad szemmel is látható) open source projektben dolgoztam, fizetésért; volt, amiben kb. évtizedes nagyságrendben voltam co-maintainer és az egyik "közösségi intéző". Ez a stílus teljesen elfogadhatatlan. A fáradtságtól, elnyűttségtől időnként mindenkiből kijön az állat, akár nyilvános listán is, de normalizálni az abúzust, szakmai kritériumként feltüntetni az abúzus eltűrését teljesen abszurd.

A probléma része vagy.

Most képzeld el, hogy van egy kollégád aki rendszeresen olyan PR-t nyit, amire az az első gondolatod, hogy "ez egy szemét"...

Civilizált ember nem abba az üzemmódba vált, hogy következetesen elkezdi minden PR-ra azt írni, hogy "ez egy szemét", hanem megfelelő helyen, megfelelő formában jelzi, hogy a kolléga tevékenykedésével tartósan gondok vannak. Lehet felajánlani / keresni mentorálási programot; sőt, még az is lehet, hogy családi, egészségi problémák állnak a háttérben, amiben pl. az EAP segíthet.

A nyílt forrású, közösségi fejlesztés egyik legnagyobb hátránya pont az, mint ami a legnagyobb előnye: nincs közös főnök. Ezért tudnak olyan megoldások születni, amelyek nűszakilag nem kényszerülnek kompromisszumra (pozitívum), és ezért tartanak parttalan viták örökké, ill. ezért lehet büntetlenül bunkózni (negatívum).

meg is indokolta, hogy miért szemét, nem?

Manapság a legtöbb fórumon bárki lehet destruktív kretén, ha szép szavakba csomagolja a tevékenységét. Van ahol még el lehet küldeni melegebb égtájra az ékeszszóló barmokat és nem pedig inkább átengedik, mert szépen beszél, miközben tönkretesz valamit. Pláne, amikor ugyanaz az ember sokadjára teszi, és ugyanazt a sokadik ember teszi sokadjára.

Pontosan.  Itt is a bolond nevű takonygerincű egyed épp a határon evickél a helyi "coc szabályok" szerint (bár az állandó és álltalában offtopic spam miatt már rég ki kellet volna penderíteni), de amint valakinél átlépi a határt az agyatlan trollkodásával, ráhívja az ellenre az banbotot.

Van ahol még el lehet küldeni melegebb égtájra az ékeszszóló barmokat és nem pedig inkább átengedik, mert szépen beszél, miközben tönkretesz valamit

Hamis dichotómia.

Ki lehet zárni valakit bunkózás nélkül is. "Kedves X.Y., az eddigi hozzájárulásaid a projektben megkövetelt műszaki színvonalat többnyire nem érik el. Kérjük, tarts fél év szünetet kód beküldésében; képezd magad."

Ha valakiről egyértelműen látszik, hogy rosszindulatú, troll, akkor lehet arra hivatkozni, de akkor is jobb kerülni olyanokat, hogy "munkád hatására a világ rosszabb hely lett".

Nem.

Fel is vehetne egy szépenszólót, aki a a másik szépenszóló coc-át körbenyalogatja, lefordítja az üzenetét píszíre. És mindenki mellett lehetne egy szépenszóló, aki cocos nyelvre fordítja a cocolást, hogy mindenki eltartson még egy embert. De igazából 4, mert 3 műszak plusz a szabadságok.

Vagy kirúghaták ezekez az élősködő képmutatókat és a világ jobb hely lenne, mert nem fontoskodhatának, mások életét megkeserítve a semmirekellők. 

Vegyük már észre magunakat, hogy azok fontoskodnak ezeken, akiknek amúgy semmi más hasznos dolga nem akad azon kívül, hogy az önnön fontosságukat folyton hangsúlyozzák a saját maguk megtartására hozott szabályokkal. Tipikus ballaszt a cégeknél, akik meglepnek mindent és viszik az erőforrásokat, miközben apró fégek módjára felzabálják a cég húsát.

Miért kellene plusz erőforrásokat felhasználni a kártevőknek való kedveskedés érdekében...

Vegyük már észre magunakat, hogy azok fontoskodnak ezeken, akiknek amúgy semmi más hasznos dolga nem akad azon kívül, hogy az önnön fontosságukat folyton hangsúlyozzák a saját maguk megtartására hozott szabályokkal

Az én tapasztalatom nem ez; pontosabban: nem csak ez. A szakértelem/teljesítmény és az érzelmi intelligencia (akár "közösségfejlesztés") nem egymást kizáró jellemzők; vannak emberek, akikben mindkettő megvan. Nem fontoskodásról van szó, hanem figyelemről, tapintatról, érzékenységről. Egyből emlékszem két volt kollégámra is; mindegyikük kimagaslót mutatott mindkét területen egyszerre. Mindkettejüknek csodálattal adózom a mai napig.

Léteznek olyan projektvezetők az open source világában, akik egyszerre bámulatos szakemberek és kitűnően kezelik a közösség szociális működését (a kiégés persze őket is utolérheti). Én évekig dolgoztam ilyen emberekkel.

Vannak, akik nem értenek a szép szóból. Ez tény. Azt is milliószor láttam, hogy szépen kérte levélben, hogy utazik stb. kevesebb az ideje, mindenki tisztelje meg a merge window zárását, ne késsen, ne küldjön stabilizációs időszak alatt feature pull request-eket. 

Falra hányt borsó. Teljes mértékben igaza van.

trey @ gépház

Abszolút értem, hogy van olyan kultúra, ahol mindenek előtt kell lennie a képmutatásnak, miközben egymást hátbaszúrnák legszívesebben. Többre értékelem az egyenes választ a képutatásnál. 

De ezeknél a műhisztiknél, amit felkap a net és a buta média vagy valami infuenszer csökevény, mégcsak erről sincsen szó. Egyszerű, közvetlen kommunikáció hatékonyan. Az üres fecsegés azoknak megy erőlködés nélkül, akik mindig csak semmiről beszélnek sokat. Persze elég sokan lehetnek ilyenek a klasszikus nagy céges környezetekben. Az egész cocolás arról szól, hogy a semmirekellők maguhoz hasonló semmirekellőket segítsenek pozíciókba, miközben érdemi hasznunk nincsen.

Két gondolat: 1. Attól még bunkónak nem kell lenni. 2. De nem tudjuk, hogy itt miről volt szó, mert mindenkit, a leg kenyérre kenhetőbb embert is ki lehet hozni a béketűrésből. Szerintem amikor ilyet látunk Linustól, annak jó oka lehet. Az pluszban fájdalmas, hogy ilyenkor elkezdenek vinnyogni, hogy “dühkitörései” vannak, közben mosolyogva, a CoC-nak megfelelve, de tettek róla bőven.

Vagy csak mára már simán mindenki túl lett "érzékenyítve"...

Hamis dichotómia.

Az igaz, hogy a nagy nyilvánosságban, PR-ban az érzékenyítés túl lett tolva. De ettől még az is igaz, hogy nagyon sok ember alkatilag érzékeny (ebben van örökletes / születési rész, és gyerekkori / tanult minták is). Rá lehet gyúrni arra, hogy az ember bőre vastagodjon, de ezt követelményként szabni műszaki fejlesztéshez egyszerűen életszerűtlen.

Nézd, egy gigaprojektet visz 30+ éve. Szerintem tökéletesen tudja, hogy mi kell a sikerhez, fejlesztőkkel hogy kell bánni, mit nem szabad engedni. Igen, néha keménynek tűnik, de gondolom ez kell neki ahhoz, hogy a projektet összetartsa, a színvonal ne csökkenjen. Ez a munkája, hogy irányítson, helyre tegyen. Erre jön még rá, hogy eleve senki sem tökéletes, infós emberke, azok nem a legjobb modorukról, emberbarátságukról, népszerűségükről szoktak híresek lenni.

Amiben nem értek vele egyet, az a merge windows vége. Minek van annak vége, ha már a vége előtt sem szabad x nappal beküldeni, akkor mikor lehet? 2-3 nappal előtte, vagy mikor? Ezt jó lenne tisztázni, mert nem először probléma, és ha meg lenne rendesen szabva az utolsó nap, amikor még be lehet küldeni, akkor senki nem csalódna, aki beküldte, annak okés, aki meg elkésett, az se kapna dorgálást, csak erről a kernelciklusról lecsúszna, és áttolódna a következőbe. Vagy akár azt is lehetne, hogy a merge window marad, ami most van, de utána mindig betold egy extra hetet, amikor a legutoljára beküldött kódokon dolgozik még, amik túl nagyok, és így senkinek nem okozna ez gondot többé.

A másik, amit nem szeretek, hogy most neki különleges időszaka van, jelenleg majd Európába megy, igazodjon mindenki hozzá. Ez teljesen felesleges szopatás, ha utazik, utazzon, érezze jól magát, pihenjen, mozduljon ki, a ciklus elejét bízza rá Greg-re, és akkor senkinek nem kell a spéci igényeihez meg utazásához igazodnia.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Egy érett kézműves igenis tudja, hogy az elismerés a munkájának szólt, nem neki, és addig jár neki, amíg ilyen minőséget tesz le az asztalra. Hogy hol húzódik az abúzus a kemény kritika határa, mindenki döntse el maga - és lépjen ki, ha nem fér bele az, amit Linus csinál. Linus ILYEN,  és ezen semmiféle haragkezelő tréning nem segít. 

El tudom fogadni, hogy te teljesen elfogadhatlannak tartod azt, amit én gond nélkül lekezelek - például úgy, hogy tudom, az emberek megnyilvánulásai róluk szólnak, nem rólam, így csak mosolygok azon, amin mások már teljesen kiakadnak. Figyeld meg: ha higgadt maradsz, nem hagyod, hogy elvigyenek az érzemeid, száraz tényekhez ragaszkodva a legtöbb dühöngő ember megállítható.  

A valóság része vagyok, ha te a hozzáállásomra a "probléma" címkét rakod, akkor a te szubjektív valóságodban ott vagyok. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Linus ILYEN,  és ezen semmiféle haragkezelő tréning nem segít

Amíg ő maga nem akarja, addig valóban nem. Kívülről nem lehet, csak belülről.

az emberek megnyilvánulásai róluk szólnak, nem rólam, így csak mosolygok azon, amin mások már teljesen kiakadnak

Ezzel nem értek egyet.

(1) Biológiai tényt nem veszel figyelembe.

Valaki egy vitában kést ragad, és belevágja a másikba. Erre ugye nem szokták azt mondani, hogy "offense can only be taken, never given" (más szóval: "csak azt lehet megsérteni, aki hajlandó megsértődni"). Belement a kés az emberbe, megsérült; nem fogod a fejéhez vágni, hogy "miért nincs páncélból a bőröd?; azért ment beléd a kés, mert nyüzüge vagy".

Pontosan így működik mentális egészség is. Az emberek rezilienciája, traumatűrése, traumakezelése különböző. Ha valakinek belegázolsz a lelkébe, akkor lehet, hogy lepereg róla, de az is lehet, hogy tartós és nagy fájdalmat okoz neki. A biológiai tény pedig az, hogy a pszichés trauma esetén mérhető agyi, fiziológiai viselkedés nagyon hasonló ahhoz, mint amit fizikai trauma esetén találnak. Nagyon erős hormonális és egyéb fiziológiai változások, pszichoszomatikus tünetek stb.

(2) A kritikát azzal elutasítani, hogy az feltétlenül a kritikát megfogalmazóról szól, és sohasem a kritizált személyről: sarkítok, de ez narcizmus ("csak a másik lehet hülye").

A valóság része vagyok,

Így van :)

ha te a hozzáállásomra a "probléma" címkét rakod, akkor a te szubjektív valóságodban ott vagyok

Természetesen.

Egy érett kézműves igenis tudja, hogy az elismerés a munkájának szólt, nem neki, és addig jár neki, amíg ilyen minőséget tesz le az asztalra.

(Második válasz, bocsi; erre tegnap is szerettem volna reagálni, de akkor még nem bíram megfogalmazni.)

A kijelentésed első felével nem értek egyet (a második felével igen).

Az egyenletesen jó munkát az alkotó személyes rátermettségének és munkamoráljának bizonyítékaként tekintik; az ilyen munka bizalmat szül. Onnantól nagyobb felelősséget bíznak az emberre (ha akarja/vállalja), jobb juttatást kap, kikérik a véleményét, folyamatosan jönnek az új megbízások. A kódját kevébé bogarásszák át nagyítóval review során (ez nagyon fontos, mert review-ra soha nincs elég erőforrás, úgyhogy veteránok egymás kódját egy idő után még átnézik ugyan, de erősen bizalmi alapon; műszakilag ez nem igazán helyes, de attól még így van.) Egyszóval emelkedik a státusza.

Ugyanígy, egy magas státuszú tekintélyfigura által szénné pocskondiázott kód nagyon rossz fényt vet a fejlesztőre. Én azt mondom, hogy ilyen módon közel megsemmisíteni valakinek (főleg egy kezdőnek) a megbecsültségét indokolatlan.

1. Nem kernel specifikus, hogy specifikus függvényeket nem teszünk általános helyre, szoftverfejlesztési igazgatóként ezt nagyon kellene (kellett volna) tudnia. A tapasztalatával ilyen dogok terén jobban kellett volna tájékozódnia, mi hova való, amennyiben nem tudja: ha kezdő is a kernel felépítése terén, illik körbe nézni, hogy mégis miként épül fel az a böhöm nagy kód, mielőtt a nagy főnöknek küld be valamit. Elég nagy cégeknél dolgozott már.

2. Ez nem gúnyolódás volt, Linus tárgyilagosan leírta, mekkora szemét, amit beküldött. Csak ismételni tudom önmagamat: "ha sok hasonló kódot kap, az őt őrli fel, mikor szűkös idejében ilyenek jönnek szembe, ráadásul késve". A beküldésből az jön le, hogy nem tiszteli kellően Linust és idejét. Nem igazán látom, hogy miért kellene az ilyeneket pátyolgatni, innen nézve inkább a srác volt bunkó, hogy rabolta Linus idejét. Nem kizárt, hogy ez még használ is neki, talán tanul némi alázatot.

azóta küzd a későn, szart beküldőkkel

A szart beküldők elleni érzéseket teljesen megértem, de amióta az eszemet tudom, a "késői beküldésen" is megy a vergődés. Nincs 2025-ben valami tool, ami kibassza ezeket, hogy ne a nyomorult projektvezetőnek kelljen őket manuálisan eligazítani?

Ez egy sima branch protection rule Githubon, Gitlabon vagy ~bárhol, ami kezel Gitet (és nem plain text email). Nincs ott egy informatikus, aki tudna segíteni?

nyilvan kozel 0-at. nem is az a lenyeg, hanem hogy a kernel mar reg nem egy kis hobbi projekt ahol orulhetsz ha valaki kuld hozza patchet, hanem a cegek (fizetett fejlesztoi) kuzdenek, hogy a sajat cuccuk (driverjeik, hw supportjuk, sajat termekeikhez szukseges extra syscalljuk) bekeruljon a hivatalos kernelbe...

hat neha le kell vezetni a feszkot valakin/valamin... :)

Tökéletesen igazad van. Futás, guggolás, fekvőtámasz, húzódzkodás, konditerem, kerékpározás; legjobb a bokszzsák a pincében; terápia.

nem a fejleszto tesz szivesseget hogy kuld patchet, hanem o hogy belerakja

Ez alapvetően igaz, bár én inkább úgy fogalmaznám, hogy mindig a reviewer/maintainer a szűk keresztmetszet (éspedig jó okkal!). Ezért van az, hogy a patch szerzőjét nagyobb felelősség (nagyobb elvárt gondosság) terheli. Tiszta sor.

jol teszi ha nem hagyja teleszemetelni a forrast.

Persze, hogy jól teszi.

Csak ez teljesen független attól, hogy hogyan beszél olyan emberekkel (és nyilvánosan), akik szociálisan kisebb státusszal rendelkeznek. Megtehetné, hogy kulturált marad.

Csak ez teljesen független attól, hogy hogyan beszél olyan emberekkel (és nyilvánosan), akik szociálisan kisebb státusszal rendelkeznek. Megtehetné, hogy kulturált marad.

Aki meg beküld egy olyan PR-t, ami olyan alapvető sebből vérzik, hogy közös részbe tettek platformfüggő kódot, ráadásul értelmetlent, félrevezető névvel, az megtehetné hogy ezt nem csinálja. Azt el tudom képzelni, hogy ha Linus fél életét "végigpofázza magyarázza", hogy ilyet nem szabad, akkor idegesen reagál (főleg, hogy ezt egy bármilyen C fejlesztőnek is meg kellene ugrania).

Mert ezt ugyanolyan bántó dolognak lehet megélni, mint amikor valaki beszól a PR-ben adott válaszában. Lehet, hogy úgy gondolja, hogy a kölcsönös tisztelet ott kezdődne, hogy betartjuk a PR határidőt, és akármi sz*rt nem küldünk be (szívatva vele aki review-za) - Szerintem valahol jogosan.

Nem csak a PR válaszokat kellene elvárni, hanem a PR-nek is olyannak kellene lenni...

Mert ezt ugyanolyan bántó dolognak lehet megélni, mint amikor valaki beszól a PR-ben adott válaszában.

Igen, tudom; tapasztalatból. Én is égtem ki emiatt (karbantartói oldalon); többhetes pihenésre volt szükségem, aztán a projektből is kiszálltam.

Senkitől nem lehet emberfeletti viselkedést elvárni; írtam máshol, hogy ha már valaki nem bírja, akkor váltson. (Lehet, hogy nem veszi észre, hogy már nem bírja.)

> Megtehetné, hogy kulturált marad.

vagy hasznalhatna LLM-et :)

 

 

Tárgy: Kérlek, vedd figyelembe a jövőbeni PR‑ekkel kapcsolatos irányelveinket

Kedves Palmer Dabbelt!

Először is szeretném megköszönni a hozzájárulásodat a projektünkhöz. Nagyra értékeljük az erőfeszítéseidet és azt a szándékot, hogy a kódbázist bővítsd.

Azonban néhány fontos szempontot szeretnék megosztani veled a legutóbbi pull request‑eddel kapcsolatban, hogy a jövőben még gördülékenyebben tudjunk együttműködni:

  1. Időzítés
    Mivel jelenleg utazás miatt korlátozott időm van, különösen fontos számomra, hogy a pull request‑ek a merge‑ablak elején érkezzenek. A késői beküldések nehezítik a felülvizsgálatot, és esetlegesen a beolvasztást is.

  2. Célzott változtatások
    Kérlek, kerüld a nem RISC‑V specifikus módosításokat a generikus fejlécekben. Amennyiben egy változtatás csak egy adott architektúrára vonatkozik, azt a megfelelő RISC‑V könyvtárakban vagy modulokban célszerű elhelyezni.

  3. Segédfüggvények használata
    A make_u32_from_two_u16() segédfüggvény példáját tekintve úgy gondolom, hogy a kód olvashatósága és egyértelműsége érdekében érdemesebb a közvetlen bitmanipulációt (pl. (a << 16) + b) alkalmazni, esetleg egy megfelelő típuskonverzióval. Így a kód olvasója egyből láthatja a szó szerinti műveletet és a szó sorrendjét, ami megkönnyíti a karbantartást.

  4. Közös irányelvek betartása
    Kérlek, a jövőben a pull request‑ekben ne szerepeljenek olyan változtatások, amelyek a generikus fejlécekbe kerülnek, és ne legyenek olyan „helper” függvények, amelyek nem hoznak egyértelmű előnyt a kódbázisban. Ezzel elősegítjük, hogy a projektünk tiszta és könnyen érthető maradjon.

Összefoglalva, nagyon örülünk a hozzájárulásodnak, de a fentieket figyelembe véve a következő merge‑ciklus (6.18) elején, a fentieknek megfelelően szeretnénk újra átnézni a módosításaidat. Biztos vagyok benne, hogy a közös erőfeszítéseink eredményeként a kód még jobb és fenntarthatóbb lesz.

Ha bármilyen kérdésed vagy észrevételed van a fentiek kapcsán, szívesen állok rendelkezésedre. Köszönöm a megértésedet és a további együttműködésedet!

Üdvözlettel,

Linus

 

( joco01 v | 2025. 08. 14., cs – 11:45 )

Szép hatásvadász címadás, de nem Google mérnök.

https://www.linkedin.com/in/palmerdabbelt/ szerint már egy ideje Meta. Pár éve volt Google-nél, de most tuti nincs, és biztos elfelejtette frissíteni a honlapját, amiben semmi meglepő nincs.

Amúgy ha Linus kioszt egy akármilyen random mérnököt, annak már nincs hírértéke, csak akkor, ha mellé lehet tenni valami plusz szaftos infót?

Egyébként tudom trey hogy te csak átvetted a címet, mint sokan mások, de szerintem minden újságíró saját felelőssége, hogy ellenőrzés nélkül ne tegyen ki fals infót a saját neve alatt.

https://www.dabbelt.com/~palmer/

Frissítse a resumé-ját. Blogger vagyok, nem oknyomozó újságíró. 

PS: az, ha az szerepelne a címben, hogy kiosztotta a Meta-mérnököt semmit sem vesz le a téma ínyencségéből. Az meg, hogy a RISC-V Foundation elnökét tették helyre egy azzal kapcsolatos patch nyomán, ... még kellemetlenebb lenne az úr számára.

trey @ gépház

( Ice | 2025. 08. 14., cs – 15:28 )

Már hiányoztak ezek a "rendberakások". :) Végre van újabb. :) 100%-ig igaza szokott lenni. Ha nincs rend, nagy káosz lesz az tuti!

Vagy csak igényli, hogy valakit pesztráljon, most pihenőre van küldve a békés-efes-es Overstreet csávó, így most keresett mást csesztetni, megtalálta magának ezt a metás fazont. Ki tudja, neki is hiányoznak ezek. Ilyen szappanopera jelleggel el lehet rajta szórakozni, de olyan nagyon nem mozgat meg, hogy miket írogatnak a levlistára, meg épp kit dorgál.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( Dolphy | 2025. 08. 14., cs – 16:20 )

Szerkesztve: 2025. 08. 14., cs – 16:25

Ha igy mukodik, akkor hat igy mukodik. Nekem mint "end usernek" a termek minosege szempont, nem a fejlesztok well-beingje.

Orommel latom azt is, hogy Linus nem "puhult el" a "terapiak" hatasara vagy akarhol is volt a kenyszeru vagy nem annyira kenyszeru pihenojen.

Meg csak azt sem lehet mondani, hogy nem adott volna konstruktiv feedback-et a valaszaban. :)

Viszont ha sok fejlesztő szarul érzi magát, annak lehet olyan következménye, hogy majd pár szükséges dolog lekódolására nem marad önként jelentkező ember.

Lehet jó minőségű terméket fejleszteni az emberi méltóság figyelembe vételével együtt is. Ezért én azt mondom, hogy fontos a minőség és a well-being is, egyik se menjen a másik rovására.

Egyetertek, nem is szeretnek kernelt fejleszteni, de ha megis szukseg lenne ra, jol tudom mar, hogy mire keszuljek fel. :)

Linus is megtehette volna, hogy csak annyit ir, nem eleg jo a kodminoseg ezert meg azert es amugyis tul keson kuldted, -1.

Az eredmeny ugyanaz lett volna szemelyeskedes nelkul.

Lehet jó minőségű terméket fejleszteni az emberi méltóság figyelembe vételével együtt is.

azt tapasztalja hogy a módosítás mögött az ambíció több volt, mint az illető képessége. Szóvá teszi, mert linux kernel fejlesztőnek, kontribútornak lenni rang, nem kényszer. Ami LT stílusát illeti, a pályafutása hosszához és jelentőségéhez képest szinte szerény személyiségnek tartom. 

azt tapasztalja hogy a módosítás mögött az ambíció több volt, mint az illető képessége. Szóvá teszi, mert linux kernel fejlesztőnek, kontribútornak lenni rang, nem kényszer

Így van!

Ami LT stílusát illeti, a pályafutása hosszához és jelentőségéhez képest szinte szerény személyiségnek tartom.

Ja, pályafutásánál csak az arroganciája nagyobb.

Igen, ez benne van, hogy elriassza vele a fejlesztőket, más részről viszont, ha nem csinálja, akkor meg a színvonal esne le a béka valaga alá, ami ugyanolyan rossz. Próbál szerintem a kettő között egyensúlyozni.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( bognarattila | 2025. 08. 15., p – 10:01 )

Én nem követem szorosan a folyamatot, csak olvasom néha a kirohanásait, amivel lehet vitatkozni, de az is kérdés, hogy mi a tapasztalata.

Azaz a kirohanása mennyire csak a címzettnek szól. Jó esély van arra, hogy ez mindenkinek szól: kapják össze magukat, különben ők is ezt kapják.

Lehet, hogy próbálkozott már szép szavakkal, privátban (ilyenekről nyilván nem is tudunk), de az elmúlt sok évben ez akár nem is működhetett, így kénytelen is volt váltani. Engem is fel tud húzni sok hülyeség, ő hatványozottan kapja és jelentősen nagyobb a felelőssége, a projekt mérete is jelentős, hülyeségre nincs idő/erőforrás, mindenkinek felelősen kell működnie, kódolnia, gondolkodnia, ki kellene néznie a saját kis szemét dombjából. Sokan vannak, akik nem értenek a szép szóból, arra sincs ideje, hogy mindenkit egyenként megismerjen (emailben eleve nehezebb, időigényesebb).

Ez jó gondolat szerintem, viszont aki eljutott arra pontra, hogy a default a bunkózás, az (minimum) kiégett. Nem hibáztatok senkit kiégésért, mert a reviewer/maintainer kiégés ezekben a projektekben (a fejlesztési módszernél fogva) szinte elkerülhetetlen (nem csak LT-t érinti, hanem egy csomó más maintainer-t). Ugyanakkor a bunkózást nem is menti; tartson szünetet, pihenjen. Vagy váltson tartósan.

Szerintem egyrészt nem értetted meg, mit akartam írni (ha sok hasonló kódot kap, az őt őrli fel, mikor szűkös idejében ilyenek jönnek szembe, ráadásul késve), másrészt ezt a munkát nem lehet kiégve csinálni. Konkrétan ha kiégett volna, akkor lehet, hogy beletojik az egészbe mind kódminőséget illetően, illetve utolsó pillanatban nem is nézi meg. Nekem azt tükrözi, hogy vannak elvárásai, elképzelései, pörög a témán. Ez külön tiszteletet érdemel.

A fejlesztő megtisztelhette volna azzal Linust, hogy körültekintőbben jár el, Linus jogosan várja el, hogy saját szemét dombjuknál messzebb lássanak az emberek egy Linux kernel jellegű kódnál. Pláne egy RISC fejlesztő tisztában lehetne azzal, hogy a bitsorrend nem egyértelmű, mint gimiben a 2-es számrendszer. Tényleg érthetetlen.

Abba is érdemes belegondolni, ha ez bekerül, milyen galibát okozhatott volna, ha valaki körültekintés nélkül használja. Úgyhogy 100%-ig igaza van Linusnak. A stíluson lehet vitatkozni, temperamentumtól függően lehet esetleg kicsit enyhébb a megfogalmazás, de az ilyenek ellen mindenképpen határozottan fel kell lépni.

Én jó esélyt látok rá, hogy egy-egy ilyen után mindenki jobban magába néz.

ha sok hasonló kódot kap, az őt őrli fel, mikor szűkös idejében ilyenek jönnek szembe, ráadásul késve

Egyetértek.

Konkrétan ha kiégett volna, akkor lehet, hogy beletojik az egészbe mind kódminőséget illetően, illetve utolsó pillanatban nem is nézi meg.

Ez nem feltétlenül így van. A kiégés nem feltétlenül jár apátiával, nemtörődömséggel. Azzal is járhat, hogy az ember erején túl feszíti, zsigereli önmagát (és hosszú távon), mert a saját egészségénél is fontosabb számára a projekt, a felelősség, a rombolás/regresszió kívül tartása. (Tapasztalatból beszélek.) Nem veszi észre, hogy személyesen hol van, hol tart, csak nap mint nap öli magát. Szakmai ötletei vannak; türelme az értetlenkedőkkel, kezdőkkel szemben nincs, rögtön üvölt. Ebből látszik a legjobban, hogy a szerepe strukturálisan, hosszú távon nem fenntartható.

Azok a maintainer-ek bírják nagyon hosszú távon mindig udvariasan, akik nem teszik bele a lelküket. Aki beleteszi a lelkét, az sokkal jobbat nyújt a közösségnek, de hosszú távon rámegy, és ki kell szállnia.

Linus jogosan várja el, hogy saját szemét dombjuknál messzebb lássanak az emberek

Jogosan, de teljesen hiábavalóan. Sok lúd disznót győz! A kezdők (vagy trehányok) sora nem ér véget, a maintainer meg csak fogy, kopik, emészti magát. A stílusa vállalhatatlanná válik. Vagy a projektet kell bezárni az újoncok elől, vagy ki kell lépni, vagy abba kell hagyni a törődést.

Kiégés: nem tudom, én inkább azt látom, hogy viszi a flow, de ha van ilyen tapasztalatod, elfogadom, hogy igazad lehet. Elképzelhető, hogy temperamentumosabb, mint ideális lenne, de ez van. A feleségem is meglehetősen temperamentumos tud lenni, de a jó szándéka felől nincs kétség. Lehet, hogy ezért is vagyok megértő :-)

Simán benne van, hogy ez nem ideális állapot, de ha a szerepe felől nézzük, akkor ez van.

Kívülről nem tudom, félre lehetne-e állítani, lenne-e helyette olyan, aki mind szakmailag, mind "politikailag" elfogadottá válhatna. Ha nem ilyen ember kerül a helyére, akkor a projekt szétesik. Ha valakinek nem tetszik, forkolhatná a projektet, biztos voltak már, akik gondolkodtak ezen, de ilyen széleskörűen nem egyszerű, a projekt ereje pont abból jön, hogy sokan tesznek hozzá, ebből mindenki profitálhat. Legfeljebb szűkre szabott céllal, belsőleg lehet forkolni, ilyenekre van is példa (Android?).

Linus szempontjából is érthető, ha nem akarja elengedni: el kellene gondolkodni rajta, hogy van-e még hasonló nagyszabású projekt úgy általánosságban. Elképzelhető, hogy úgy fogja fel, ez az élete, nem akar mást. Most még benne élünk a történelemben (patetikusan hangzik, de ez van), a helyzetet Linus szerepének vége után néhány évvel fogjuk tudni megítélni szerintem. Gondolj bele: egy finn egyetemista alkot valamit, amire technológiailag a világ nagy része jelentősen támaszkodik. Ráadásul kvázi non-profit. Ha idegen civilizáció lenne és az emberiség erényeit kellene kidomborítani, akkor véleményem szerint ez beletartozna. Az emberiséget a közösségi összefogás viszi előre.

A kezdők (vagy trehányok) sora nem ér véget,

...

projektet kell bezárni az újoncok elől

Ez baromi nehéz lehet egy hasonló projekt esetén, amikor a projekt ereje abban (is) van, hogy a közösség rakja össze. Nem követem annyira a dolgokat, érdemes lenne megnézni, milyen próbálkozások voltak/vannak ilyen téren (biztos vagyok benne, hogy voltak, legalább felmerülés szintjén).

( kisg v | 2025. 08. 17., v – 08:38 )

Amíg az if/else után nem kötelező a {} a kernelben, addig ne okítson senkit Linus a kódolási stílusról. :) 

Viccen kívül, szerintem millió dollárban lehet mérni azt a veszteséget, amit a kernelben az "if (...) csakegyutasítás" jellegű kódrészek - és utána a hibás refaktorálásuk okozott. (Nem, nem néztem utána, mert annyira nem érdekel, de ha kifizeti valaki, nyitunk erre egy projektet. :) )

Egyébként lehet itt bólogatni, hogy most aztán jól megmondta Linus, de pont az ilyen dolgok, hogy ne vezessünk be helpert az "egyszerű" dolgokra, hanem szórjuk tele a kódot velük, okozhatnak problémákat évekkel később. Aztán ő maga is írta, hogy ja, a b-t lehet, hogy castolni kell ám, hogy helyes legyen. Na ez az, amit simán el lehet felejteni, vagy akár csak változnak a kifejezésben szereplő típusok, ami miatt már castolni kellene, és egyáltalán nem biztos, hogy a manyeyeballs megfogja. Hanem majd egy jó kis exploittal kiderül, akár évekkel később.

Arról lehet vitatkozni, hogy jól volt-e elnevezve a helper.

Az tök egyértelmű, hogy ezt a fejmosást azért kapta a beküldő, mert későn küldte be a PR-t. Ha tökös a csávó, akkor a helperjét a következő PR-be bemozgatja a RISC-V alá és kész. :)