- A hozzászóláshoz be kell jelentkezni
Hozzászólások
A net tele van bátor kontárokkal. Szeretem, ha koppannak az ilyenek.
READY.
▓
- A hozzászóláshoz be kell jelentkezni
ezen jót mosolyogtam: "I repeat: do not use spinlocks in user space, unless you actually know what you're doing. And be aware that the likelihood that you know what you are doing is basically nil."
meg ezen is: "You might even see issues like "when I run this as a foreground UI process, I get different numbers than when I run it in the background as a batch process". Cool interesting numbers, aren't they?"
- A hozzászóláshoz be kell jelentkezni
Örömmel látom, hogy a PC-bohócok által majdnem átnevelőtáborba üldözött Linus kezdi visszanyerni régi formáját, elhagyta az erőszakmentes kommunikációs bullshit tanfolyam baromságait és kezd magára találni újra :D
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Legalább a személyt direktben nem támadta, de valaki kódját garbage-nek nevezni olyan dolog, ami mondjuk közeli kollégák esetén eléggé kellemetlen tud lenni.
- A hozzászóláshoz be kell jelentkezni
Azért az is ember és munkahely függő. Én például saját főnököm által írt több éves kódot szoktam gyakran felhozni, hogy felesleges és hülye dolgok vannak benne. Mindezt a főnökömnek. Aki ezen nem sértődik meg, hanem ő maga is belátja, hogy igen, amit anno írt az nem mindig állja már meg a helyét. Elfogadja és kész, meg hangoztatja is ,hogy ha ilyen kód van, amit lehet csinosítani/gyorsítani, akkor nyugodtan.
Nem sértődés van ebből, mint a PC-k esetén.
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"
- A hozzászóláshoz be kell jelentkezni
Lehet ezt szépen mondani, meg lehet úgy, mint Linus, hogy a kódod egy szeméthalom. Ezen a PC előtt is megsértődhetett volna bárki. Ez egyszerűen sértő. A PC-t kár idekeverni, mert nem politikai jellegű az inzultus.
- A hozzászóláshoz be kell jelentkezni
Félve kérdem, ha valaki egy rakás szart ad ki a kezéből, azt hogyan kellene nevezni, hogy ne sértődjön meg kis érzékeny lelke? Kakinak?
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
A magyar nyelv hálistennek bővelkedik normális, paraszt-bunkó stílust nélkülöző szavakban, amikkel szintén el lehet magyarázni valamiről, hogy rossz. Például add elő a munkahelyeden a "színtiszta szemetet gyártottál" műsort. Vagy bárkivel, élőben. Twitteren könnyű előadni a parasztot. Egyesek még meg is védenek. Szerintem az hogy szükségtelenül nem parasztkodok másokkal nem azért teszem mert PC vagyok és féltem a lelki világát, hanem mert ezt tartom normális viselkedésnek. A twitteres őrjöngés sajnos teljesen napi divat lett.
- A hozzászóláshoz be kell jelentkezni
Például add elő a munkahelyeden a "színtiszta szemetet gyártottál" műsort
Eléggé szókimondónak ismernek a munkahelyemen, szóval, ha valami egy rakás szar, arra én ott is azt mondom, hogy egy rakás szar. Nem szoktam cukrozni.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Szerintem Linus levele a magyarazattal (miert rossz) egesz korrekt, a jelzoket es a minositgetest nyugodtan kihagyhatta volna, az mar nem adott hozza semmit a tartalomhoz.
- A hozzászóláshoz be kell jelentkezni
Egy csomó hibás feltételezés van már a kérdésben is. Feltételezed, hogy a kód egy rakás szar, feltételezed, hogy sértődős a másik ember, feltételezed, hogy egyáltalán kell valaminek nevezni. Lásd felettem Gaab válaszát: a jelzők nélkül Linus válasza teljesen korrekt.
Neked volt már, hogy szar munkát végeztél, és beszólt a főnök vagy kolléga? Én pl. elfogadnám, ha tényleg rossz, de a jelzőket nem, csak az előremutató kritikát, hogy hogyan lehetne jobbá tenni. Ugyanakkor ezt nem nevezném sértődésnek, inkább kulturális kérdés egymás tisztelete.
- A hozzászóláshoz be kell jelentkezni
+++
Sajnálatos hogy egyeseknek fontosabb az antiPC-ség, mint a normális emberi viselkedés.
- A hozzászóláshoz be kell jelentkezni
Sajnálatos, hogy egy elsősorban informatikai fórumon a PC nem a Personal Computer rövidítése.
Sajnálatos, hogy a mai világban a PC (nem a Personal Computer) fontosabb mint a C (nem a programozási nyelv).
Sajnálatos, hogy ha egy noname valaki próbálja bemocskolni a már ~30 éves édes gyermeked, akkor elnézést kellene kérni, hogy esetleg te IS kellemetlen szavakat mersz használni.
- A hozzászóláshoz be kell jelentkezni
Neked volt már, hogy szar munkát végeztél, és beszólt a főnök vagy kolléga?
20 év alatt nem emlékszem ilyenre. Inkább elismerő díjakat (pénzmag jutalommal) szoktam kapni. Vagy vagy 6, de ki számolja? Egyszerűen nem szoktam szar munkát végezni.
inkább kulturális kérdés egymás tisztelete.
Valahol ott lesz a probléma, hogy te tiszteletlenségnek veszed, ha megmondják neked a szarodra, hogy szar, más meg őszinteségnek. Ha nem tiszta miről beszélek, olvasd el még egyszer azt, amire válaszoltál. Abból a feltevésből indultam ki, hogy szart csináltál.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Már vagy 3 tucat kisebb-nagyobb pénzes bónuszt kaptam 5 év alatt, de ez nem jelenti azt, hogy én vagyok mr. tökéletes.
Egyrészt azt kell látni, hogy a jó munka néha szubjektív, nem lehet mindent objektíven mérni. Másrészt tegyük fel, hogy gyártok valami "szart". Lehetséges reakciók:
* Ez egy rakás szar: szubjektív, hasznavehetetlen, bunkó
* Ez egy rakás szar, amúgy azért, mert X, Y, Z: ez már használható, de még mindig bunkó és tiszteletlen (ez Linus a témaindítóban)
* Ezen az nem jó/azt kellene javítani, hogy X, Y, Z: teljesen tényszerű, ebből szokott kialakulni egy konstruktív párbeszéd (nézd csak, megmondták, hogy valami nem jó, de mégse tiszteletlen módon, nem nem jelzőkkel illetni)
* Ez szuper jó, de esetleg még lehetne módosítani, hogy X, Y, Z: ez már nem őszinte, átesik a ló túloldalára (a PC-skedést képzelem így el)
Technikai érvek felvetése önmagában sosem tiszteletlen. Ami efölött van, pl. jelzők, az már lehet az.
- A hozzászóláshoz be kell jelentkezni
ez nem jelenti azt, hogy én vagyok mr. tökéletes.
Senki nem állított ilyet. Óriási a szakadék a tökéletes vagyok, rendes munkát adok ki a kezemből és a szart csináltam közt.
Ez egy rakás szar, amúgy azért, mert X, Y, Z: ez már használható, de még mindig bunkó és tiszteletlen (ez Linus a témaindítóban)
Megint másról beszélsz. Ez a kóder írt valamit, amihez fingja sem volt és amit írt, az is rossz volt. Utána telesírta vele a netet. Szerinted erre mit kellett volna írni? Most ahelyett, hogy a kritikát megfogalmazót okolod (manapság ezt szokott lenni a csapásirány) mi lenne, ha a problémáról beszélnél, vagyis arról, hogy az illetőnek mit kellett volna csinálnia. Egy kis önvizsgálaton kívül. Az nem volt tiszteletlenség, hogy tények ellenőrzése vagy szakmai tudás hiányában a tények ellenőriztetése nélkül beleírta az internetbe, hogy a Linux scheduler rossz?
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Szerintem nem volt teljesen rossz, amit a kóder írt. És a blog címe, hogy milyen rossz az ütemező, szintén nem szerencsés, habár nem olyan szint, mint Linusé, de jobb lett volna pl. hogy nem optimális.
Kicsit csúsztatás, hogy a kritikát megfogalmazót okolom. A kritika 95%-ban korrekt, kritizálni hasznos és muszáj is. Csak a plusz jelzőkkel volt gondunk, mással nem.
- A hozzászóláshoz be kell jelentkezni
Vegyük úgy, a súlyozás már túl szubjektív lenne. De az egyszeri olvasó akkor is Linuson fog jobban kiakadni, mert az ő pozíciójában kéne óvatosnak lennie (ő a rendszer arca, meg meg is ígérte). De felőlem Linus is azt csinál, amit akar, nem leszek jobban vagy kevésbé Linux hívő.
- A hozzászóláshoz be kell jelentkezni
Hagyjuk már ez a pozíciójában dolgot! Miért kellene neki jobban vigyáznia?
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ha egy random blogger beszél így, kb. senkit nem érdekel (mondjuk pont ez a téma ellenpélda, de úgy általában). Ha Linus, az bejárja a világsajtót. Hiába nézik el neki a szűk belső körben, ha egyszer a pénzt adó cégek vagy az SJW-k kicsinálják, az nekem mint júzernek is rossz lesz. De ez az élet minden területén megvan, minél több ember figyel a szavadra, annál jobban kell vigyázni, mit mondasz, a szavaknak nagy ereje lehet, nézd meg pl. kik és mekkorát buktak kikerült hangfelvételek miatt, amikor nem vigyáztak annyira.
- A hozzászóláshoz be kell jelentkezni
Azért egy hónapra le tudták jegelni. De ezt már kiveséztük.
- A hozzászóláshoz be kell jelentkezni
Érdekes megfogalmazása ez annak, hogy hagyta a picsába az egészet és elment inkább pihenni.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
mindig arra jutok, hogy nem biztos, hogy tudnek olyan helyen dolgozni, ahol nem mondhatom meg a kollegamnak hogy "ez egy rakas fos amit kiadtal a kezedbol jozsi".
- A hozzászóláshoz be kell jelentkezni
Indokolatlannak érzem a Linus pöcsfejségét, van egy mérés, most mindegy, hogy pontosan mit is mér, de Linuxon sokkal nagyobb a rosszabb érték, mint windowson, és ez akár érdekes is lehet.
- A hozzászóláshoz be kell jelentkezni
Pedig itt a culture fit is egy értékelési kategória a felvétel során :). Az a baj, hogy a rakás fos önmagában semmit sem ér, egy meritokráciában érvelni kell, de ha már vannak érveid, akkor a fosozás nem ad előnyt, inkább hátrányt. Amúgy persze hangzik el ilyen néha, inkább szóban, mint írásban és inkább viccből, mint komolyan, olyan kontextusban, ahol tudjuk, hogy a másik ember veszi a lapot ([gonosz]vagy nincs jelen[/gonosz]). A default egymás iránti tisztelet az egyik fő oka, amiért szeretem a munkahelyem. Engem a technikai érveken kívüli, akár pozitív, akár negatív szófosás inkább stresszel. És mivel ez így jól működik, ugyanígy állnék hozzá bármelyik jövőbeli munkámhoz és open source projekthez is.
- A hozzászóláshoz be kell jelentkezni
Nálunk olyan a menedzsment, hogy én a vezérigazgatónak is mondhatom azt, hogy "szerintem ez így szar". Nem is véletlen talán, hogy 20+ éve itt dolgozom.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Azt én is. Hogy a te munkád szar, azt inkább nem próbálom ki.
- A hozzászóláshoz be kell jelentkezni
Abból indultunk ki, hogy akkor mondjuk ki, hogy szart csinált, ha valaki szart csinált. Ha ezt megmondom neki, akkor mit csinálna?
( ) kirúgna, mert igazat mondtam
( ) hátrányos helyzetbe hozna, mert igazat mondtam
( ) gyerekes módon nekiállna a stíluson vitatkozni (terelés) és nem a problémáról beszélni
( ) egyéb
Első kettő esetben a munkaügyi bíróságon vitatkoznánk tovább a részletekről. A harmadik esetben azt nyerné vele, hogy a faszom nem mondaná meg neki a véleményét legközelebb (ami egyébként igaz, hisz ebből indultunk ki), ami nem tudom kinek lenne rosszabb. Nekem? Leszarom. Neki? Hogy nem kap egy inputot döntéshozóként?
Tovább?
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
jocoeknal ez nem fer bele a hatalmas PC kulturaba, ahol barmi lehetsz ha akarsz (gender: apache helikopter ROTFL)... :) nem hiaba irtam, hogy nem biztos, hogy tudnek ilyen helyen dolgozni ahol nem lehet megmondani az oszintet, hanem be kell csomagolni mindenfele szep cimkebe.
- A hozzászóláshoz be kell jelentkezni
Az "ez egy kalap szar" általában túlzottan leegyszerűsítő, elfogult, mentes a szakmai alázattól, és pontatlan szokott lenni. Szakmaiatlan.
- A hozzászóláshoz be kell jelentkezni
Senki sem állította, hogy a "kalap szar" után kérésre nem fog indoklás következni. Még egyszer: arról van szó, hogy feltételeztünk, az illetőnek igaza volt. Tényleg kalap szar volt amit csinált.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nem volt kalap szar. Az illető nem mondta sose, hogy amit írt, az egy élesben futó spinlock implementáció, Linus meg számon kéri rajta. Játékfejlesztéseknél valószínű a spinlock-szerű várás, akármilyen optimalizációval vegyítve, és az illető azt állítja, hogy a linux másképpen viselkedik egy, ilyen preparált esetben, mint akár a windows, xbox vagy ps4.
- A hozzászóláshoz be kell jelentkezni
"az illető azt állítja, hogy a linux másképpen viselkedik egy, ilyen preparált esetben, mint akár a windows, xbox vagy ps4"
Másképp is viselkedik, mivel a CFS (completely fair scheduler) másképp működik, mint a Windows ütemező. Amennyire én tudom (nem biztos, hogy jól tudom), a Windows ütemező igazából nem preemptive (Win32 alatt biztosan nem az volt, és azt hiszem, még most sem az). Azaz egy végtelen ciklust soha nem fog megszakítani egy másik taszk (vagy process, vagy thread, vagy mittomén hogy hívják), amíg a másik taszk prioritása nem magasabb. Ha van magasabb prioritású futásra kész taszk, az is csak akkor fogja megszakítani a végtelen ciklust, ha interrupt történik. Vagyis Windows alatt egyszerre csak 1 végtelen ciklus futhat (nyilván minden CPU magon 1). Egy ilyen környezetben a fickó által írt mérő rutinok véletlenül ugyan, de működnek.
Linux alatt a CFS fair, azaz nem hagy taszkokat "éhezni". Egy végtelenciklustól a CFS akkor is elveheti a procit, ha már túl sokáig futott, vagy van olyan nem magasabb prioritású másik taszk, ami meg már túl rég óta nem futott. Ez az igazi preemptive ütemezés. Vagyis egyszerre több végtelenciklus is futhat egy procin, az alacsony prioritásúak nyilván sokkal kevesebbszer fognak majd futni. Ebben a környezetben pedig a fickó által írt rutinok vagy működnek, vagy nem. Pontosan azt teszik, amit Linus írt: a környezettől függő random időket fognak mérni.
Ha a fickó a játékaiba írt egy OS absztrakciós interface-t, amit a játékokban levő közös kód használ, és amit minden OS-re (Windows-ra, Linux-ra, Xbox-ra) újraírnak, és azt a bemutatott elvek alapján írta meg, akkor ne csodálkozzon, hogy másképp működnek a játékai Liux-on, ugyanis a Linux-os interface-e szar, azaz "garbage".
- A hozzászóláshoz be kell jelentkezni
"a Windows ütemező igazából nem preemptive"
dafuq?
Talán windows 95 volt az utolsó, ahol egy 3 bájtos .com fájl (CLI+JMP) végtelen ciklusa teljes fagyást idézett elő.
- A hozzászóláshoz be kell jelentkezni
Nem olvastál figyelmesen. Win32 alatt (tehát user space-ben) ha indítasz két végtelen ciklust azonos prioritáson, akkor csak az egyik fog futni. Linux alatt mindkettő felváltva. Azaz a Linux tényleg preemptive, a Win32 meg csak amúgy félig-meddig. Win32 óta nem csináltam ilyet, de a hirtelen elém került doksik alapján a mostani Windows ütemező is így működik.
- A hozzászóláshoz be kell jelentkezni
Ha nem akarnék PC lenni, akkor azt mondanám, hogy ez totális baromság.
- A hozzászóláshoz be kell jelentkezni
Melyik felét nem hiszed el? Linux-on biztosan így van, próbáld ki!
- A hozzászóláshoz be kell jelentkezni
Már a Windows 9x is csak 16 bites módban volt non-preemptive.
- A hozzászóláshoz be kell jelentkezni
Hm. Most próbáltam Win7 alatt, és valóban rendesen preemptívnek tűnik. Mentségemre legyen szólva, hogy ilyen végtelen ciklusos földolgozást W95 alatt írtam utoljára.
Viszont akkor nem értem, hogy a játékos fickó miért nem értette Linus válaszait, hiszen a kódja Win7-en is ugyanúgy rossz, mint Linux-on, csak véletlenül másképp működik.
Illetve valami különbség mégis lehet. A következő gyors tesztet csináltam, Írtam egy for() ciklust, ami 1 magon 10mp-ig fut. Ezt elindítottam kb. egyidőben 5 példányban egy 4 magos i5-ön. Linux-on mindegyik példány kb. 13mp-ig futott. Win7-en viszont nagyon determinisztikusan (5-ből 5-ször) a következő történt: 3 példány lefutott kb. 11 mp alatt, 2 pedig kb. 15 mp alatt. Meg sem próbálom megmagyarázni, hogy ez miért lehet, de egyrészt furcsa, másrészt tényleg más, mint a Linux.
- A hozzászóláshoz be kell jelentkezni
A különbség nálam is kijött (lásd a tesztemet), és szerintem valami olyasmi irányban keresendő a különbség, hogy a core-ok valamilyen csoportokba vannak szervezve, és "indok nélkül" a core csoportok között nem akar processzt átmozgatni a Windows (pl. NUMA access miatt vagy ilyesmi). A scheduling így csak a core csoporton belül fair, cserébe viszont gondolom meg van spórolva a cache elvesztése.
Disclaimer: ez csak tipp, igazából nem tudom, hogy mi történik valójában.
- A hozzászóláshoz be kell jelentkezni
Ja, tényleg: hyperthreading? Gondolom olcsóbb ugyanannak a magnak a másik threadjére váltani, mint másik magra váltani, és ezt láthatjuk. Nálam ez lehet, a proci "Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz", ami a leírások alapján tud hyperthreadinget, de csak 1 NUMA node-ja van.
- A hozzászóláshoz be kell jelentkezni
Ez egy WSL (Windows Subsystem for Linux), Windows 10 Home-on futtatva:
[zmezei@jane ~]$ for i in {1..5}; do while :; do true; done & done
[1] 725
[2] 726
[3] 727
[4] 728
[5] 729
Az eredmény ilyen egy top-ban:
top - 22:00:24 up 17 min, 0 users, load average: 0.52, 0.58, 0.59
Tasks: 11 total, 6 running, 5 sleeping, 0 stopped, 0 zombie
%Cpu0 : 25.0 us, 0.0 sy, 0.0 ni, 75.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 75.0 us, 0.0 sy, 0.0 ni, 25.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 : 26.3 us, 0.0 sy, 0.0 ni, 73.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3 : 75.0 us, 0.0 sy, 0.0 ni, 25.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu4 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu5 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu6 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu7 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu8 : 12.1 us, 6.1 sy, 0.0 ni, 81.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu9 : 3.0 us, 8.0 sy, 0.0 ni, 89.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu10 : 12.0 us, 0.0 sy, 0.0 ni, 88.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu11 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 16336.2 total, 9413.2 free, 6699.0 used, 224.0 buff/cache
MiB Swap: 49152.0 total, 49152.0 free, 0.0 used. 9506.6 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
725 zmezei 20 0 15516 528 328 R 100.0 0.0 2:56.34 bash
726 zmezei 20 0 15516 532 332 R 100.0 0.0 2:56.35 bash
727 zmezei 20 0 15516 528 328 R 100.0 0.0 2:56.41 bash
728 zmezei 20 0 15516 532 332 R 100.0 0.0 2:56.36 bash
729 zmezei 20 0 15516 528 328 R 100.0 0.0 2:56.35 bash
1 root 20 0 8892 308 276 S 0.0 0.0 0:00.01 init
6 root 20 0 8896 212 172 S 0.0 0.0 0:00.00 init
7 zmezei 20 0 15516 2680 2492 S 0.0 0.0 0:20.38 bash
717 root 20 0 8896 212 172 S 0.0 0.0 0:00.00 init
718 zmezei 20 0 15516 2576 2492 S 0.0 0.0 0:00.01 bash
721 zmezei 20 0 17152 2024 1432 R 0.0 0.0 0:00.20 top
Erre pedig:
[zmezei@jane ~]$ for i in {1..13}; do while :; do true; done & done
[1] 741
[2] 742
[3] 743
[4] 744
[5] 745
[6] 746
[7] 747
[8] 748
[9] 749
[10] 750
[11] 751
[12] 752
[13] 753
Ilyen:
top - 22:02:24 up 19 min, 0 users, load average: 0.52, 0.58, 0.59
Tasks: 4 total, 1 running, 3 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.4 us, 0.2 sy, 0.0 ni, 99.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
top - 22:04:47 up 22 min, 0 users, load average: 0.52, 0.58, 0.59
Tasks: 19 total, 14 running, 5 sleeping, 0 stopped, 0 zombie
%Cpu0 : 97.9 us, 2.1 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu1 : 99.8 us, 0.2 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu2 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu3 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu4 : 97.9 us, 2.1 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu5 : 99.4 us, 0.6 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu6 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu7 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu8 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu9 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu10 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
%Cpu11 :100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 16336.2 total, 9435.0 free, 6677.2 used, 224.0 buff/cache
MiB Swap: 49152.0 total, 49152.0 free, 0.0 used. 9528.4 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
741 zmezei 20 0 15516 536 316 R 100.0 0.0 1:17.59 bash
753 zmezei 20 0 15516 536 316 R 100.0 0.0 1:13.50 bash
742 zmezei 20 0 15516 540 320 R 100.0 0.0 1:18.32 bash
748 zmezei 20 0 15516 536 316 R 100.0 0.0 1:15.99 bash
747 zmezei 20 0 15516 536 316 R 100.0 0.0 1:12.51 bash
749 zmezei 20 0 15516 536 316 R 100.0 0.0 1:18.33 bash
752 zmezei 20 0 15516 536 316 R 100.0 0.0 1:12.94 bash
745 zmezei 20 0 15516 536 316 R 100.0 0.0 1:17.53 bash
743 zmezei 20 0 15516 536 316 R 82.6 0.0 1:06.98 bash
746 zmezei 20 0 15516 540 320 R 82.4 0.0 1:05.79 bash
744 zmezei 20 0 15516 540 320 R 82.0 0.0 1:06.40 bash
751 zmezei 20 0 15516 536 316 R 81.0 0.0 1:04.37 bash
750 zmezei 20 0 15516 536 316 R 79.6 0.0 1:02.54 bash
1 root 20 0 8892 308 276 S 0.0 0.0 0:00.01 init
717 root 20 0 8896 212 172 S 0.0 0.0 0:00.00 init
718 zmezei 20 0 15516 2620 2544 S 0.0 0.0 0:00.02 bash
736 root 20 0 8896 212 172 S 0.0 0.0 0:00.01 init
737 zmezei 20 0 15516 2608 2428 S 0.0 0.0 0:00.01 bash
740 zmezei 20 0 17152 2012 1424 R 0.0 0.0 0:00.01 top
Pár perc után ps kimenetéből látszik, hogy nem teljesen fair az ütemezés, valóban (lásd a TIME oszlopot):
[zmezei@jane ~]$ ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 8892 308 ? Ssl 21:42 0:00 /init
root 717 0.0 0.0 8896 212 tty2 Ss 21:54 0:00 /init
zmezei 718 0.0 0.0 15516 2620 tty2 S 21:54 0:00 -bash
root 736 0.0 0.0 8896 212 tty1 Ss 22:02 0:00 /init
zmezei 737 0.0 0.0 15648 2764 tty1 S 22:02 0:00 -bash
zmezei 755 97.1 0.0 15516 532 tty1 R 22:08 3:56 -bash
zmezei 756 92.9 0.0 15516 532 tty1 R 22:08 3:45 -bash
zmezei 757 88.7 0.0 15516 536 tty1 R 22:08 3:35 -bash
zmezei 758 91.2 0.0 15516 532 tty1 R 22:08 3:41 -bash
zmezei 759 99.8 0.0 15516 532 tty1 R 22:08 4:02 -bash
zmezei 760 92.1 0.0 15516 536 tty1 R 22:08 3:43 -bash
zmezei 761 87.6 0.0 15516 532 tty1 R 22:08 3:32 -bash
zmezei 762 91.0 0.0 15516 532 tty1 R 22:08 3:41 -bash
zmezei 763 89.2 0.0 15516 532 tty1 R 22:08 3:36 -bash
zmezei 764 93.3 0.0 15516 532 tty1 R 22:08 3:46 -bash
zmezei 765 83.5 0.0 15516 532 tty1 R 22:08 3:23 -bash
zmezei 766 89.8 0.0 15516 532 tty1 R 22:08 3:38 -bash
zmezei 767 85.8 0.0 15516 532 tty1 R 22:08 3:28 -bash
zmezei 770 0.0 0.0 16816 1936 tty2 R 22:12 0:00 ps aux
Ennek ellenére egyáltalán nem az van, hogy valamelyik processz ne kapna processzoridőt. Nem mellesleg ez az egész futott, miközben megírtam ezt a kommentet, úgyhogy nem állt meg tőle a rendszer, mint a szög...
Ezek alapján szerintem nincs igazad abban, hogy hogy működik a Windows ütemezője.
- A hozzászóláshoz be kell jelentkezni
Amikor a tesztedben csak 5 szál fut, akkor olyasmi történik, mint amit én láttam az eredeti tesztemben, amikor már csak 2 szál futott. Az 5-ből 3 elfut 1-1 magon, a maradék 2 pedig 4 magra van szétdobva. Nálam, amikor már csak 2 szál futott, azok 2-en mind a 4 magot használták.
- A hozzászóláshoz be kell jelentkezni
A top az elmúlt X másodpercre átlagolja a CPU mag kihasználtságát. Ha mondjuk X=2, és 0.5 sec-et az egyik processzormagon, 1.5 sec-et meg a másik processzormagon futott ugyanaz a processz, akkor 25%-ot és 75%-ot fog jelezni. Ez még ugyanúgy 100%, csak közben a scheduler úgy döntött, hogy másik magra akarja rakni a processzt. (Ami meg nyilván azért van, mert más is futott a gépemen, pl. egy Chrome, egy Slack, egy nvidia driver telepítő, 3 google drive sync meg egy rakás más cucc, aminek kellhetett még CPU, és simán lehet, hogy valamiért optimálisabb volt a végtelen ciklust arrébb rakni.)
- A hozzászóláshoz be kell jelentkezni
"ahol nem lehet megmondani az oszintet, hanem be kell csomagolni mindenfele szep cimkebe."
Elvárás, hogy megmondd az őszintét, akár a főnököd főnökének is. Nem muszáj szép címkébe csomagolni (én nem szoktam), de csúnya körítés se kell hozzá (annak tényleg lehet negatív következménye).
- A hozzászóláshoz be kell jelentkezni
Azt mondod, a szemét (garbage) vagy szar (crap) az az utlimate csúnya szó, ami annyira alja, hogy nem tudnám se angol se magyar nyelven fokozni?
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
HUG
:D
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"
- A hozzászóláshoz be kell jelentkezni
Nem mondtam ilyet. Suboptimal, inefficient, slow, technical debt, overcomplicated, overengineered, unnecessary, ezekkel semmi gond nincs. A garbage és crap már egy kicsit az elvárt szint alatt van. És van ettől még rosszabb is, horrible fucking mess, idiotic rambling, have you lost your fucking mind... De ne hidd azt, hogy van itt egy céges szótár a jó és rossz szavak listájával. Ez ilyen társadalmi konszenzus. Szerintem egy részletesebb értelmező szótárban is meg lehet nézni a szavak színezetét, melyikhez van odaírva, hogy szleng/obszcén/informális.
- A hozzászóláshoz be kell jelentkezni
Szerintem tökéletesen passzol a "garbage" arra, hogy valaki először lekéri az időt, majd fölszabadítja a lock-ot, és azt hiszi, hogy közben nem történhetett ütemezés.
- A hozzászóláshoz be kell jelentkezni
Szerintem nem hiszi azt.
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy egyesek úgy gondolkodnak, ahogyan az SJW-k. Baromira nem érdekli őket, hogy mi a szakmai háttér, hanem általánosságban foglalkoznak Linus stílusával. Pedig a szakmai háttér az az, hogy olyan kódot, amit az állítólagos játékfejlesztő bemutatott, csak óvodás ír, vagy idióta. Nem is az a baj, hogy butaságot írt, hanem az, hogy óriási publicitást csinált neki. A "garbage" és a "crap" nagyon visszafogott jelző arra a kódra.
- A hozzászóláshoz be kell jelentkezni
A levlistában egyébként utána elő is jött egy elvileg fejlesztő SJW aki számonkérte Linus-t a stílusa miatt, meg kérte, hogy normális release metódusra álljanak át...
Utána többen ki is jelentették, hogy igazából egyik oldalról sem érzik, hogy bármi sértő lenne a levelezésben.
Lehet sokaknak nem tetszik a garbage és crap kifejezés, de még mindig finom jelzők. Lehetne simán f*cking sh*t is, akarom mondani hugging sh*t.
Meg tegyük hozzá, hogy Skarupke nem is sértődött meg rajta. Értette, hogy azokat a jelzőket miért használja Linus és értelmes hangnemben tovább folyt a beszélgetés. Akik ezen felhúzták magukat nem is közvetlen résztvevői a beszélgetésnek, ugyanis az Linux és Skarupke között folyt. Egyikőjük sem sértődött meg a másikon.
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"
- A hozzászóláshoz be kell jelentkezni
Én is ilyen kódot írnék (vagy rosszabbat), mert nem értek hozzá, úgyhogy óvodás vagyok, vagy idióta. Kösz! :-)
- A hozzászóláshoz be kell jelentkezni
Munkahelyen, azaz ahol voltaképpen mindenkinek az az érdeke, hogy a mindenki jól végezze a feladatát, teljesen igaz, amit Jocó ír. Vegyük azért észre, hogy Linus és a blogger viszont nem ilyen relációban vannak egymással, és Linusnak igen kevés érdeke fűződik ahhoz, hogy később is gördülékenyen együtt tudjon működni az illetővel. Ellenben a beszólás hatására egész sokan elolvasták Linus magyarázatát is, amitől akár okosodhattak is. (Vagy nem.)
Amúgy kedvenc védekezésem főnöktől, amikor szembesítették ~10 éves kódjával: "Fiatal voltam, kellett a pénz!"
És kedvenc beszólásom Linustól:
We do not trust BIOS tables, because BIOS writers are invariably totally incompetent crack-addicted monkeys. If they weren't, they wouldn't be BIOS writers. QED.
- A hozzászóláshoz be kell jelentkezni
Kicsit sok a bullshit abban, amit Linus ír. Ugye abból indult az egész, hogy a Stadiaban nem akarnak rendesen futni a játékok, és hát lássuk be a Linux sosem volt egy erős játék platform.
- A hozzászóláshoz be kell jelentkezni
Elmondom miről volt szó:
Measuring Mutexes, Spinlocks and how Bad the Linux Scheduler Really is
Ebben a témában történt a szakértés.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Gyanús, hogy vagdalkozik, meg 1900 szavas bullshiteket ír, nem hiteles. Olyan, mintha Newton törvényeit szemétnek neveznénk, mert nincs benne idődilitáció. :)
A srác mért valamit, ami Linus szerint egy rossz random generátor, viszont a játékosok meg ezt érzik, ez a végfelhasználói élmény. Nem hiszem, hogy a játékosokat érdekli Linus hosszú, általános, és igaz magyarázata.
- A hozzászóláshoz be kell jelentkezni
Viszont bevallom én nem tudtam hogy a spinlockokkkal ennyire meg lehet szívni, meg még sok más érdekes dolog is volt a poszban, szóval örülök hogy ilyen hosszan ecsetelte a dolgot. Jó lenne elolvasni ezt (https://arxiv.org/abs/1701.00854) és képbe kerülni rendesen a témában, de pont jó hogy itt Linus működési szempontból leírja ezeket a bonyolultabb mechnaizmusokat.
- A hozzászóláshoz be kell jelentkezni
A srác implementált egy naív spinlockot Linus szerint, és elkezdi azért ekézni, mert a naív splinlock nem professzionális spinlock. Hát persze, hogy nem, nem is az volt a célja. Hanem az, hogy érdekes anomáliákat mutasson a schedulerről, és ez szerintem sikerült.
- A hozzászóláshoz be kell jelentkezni
Nem sikerült. Nézd meg a srác kódját! Linus ezt írja róla, és tökéletesen igaza van: what you are measuring is "I have a lot of busywork, where all the processes are CPU-bound, and I'm measuring random points of how long the scheduler kept the process in place".
- A hozzászóláshoz be kell jelentkezni
Szerintem ezt nem is cáfolja a srác. Inkább azt mondja, hogy ez is hasznos információval szolgálhat. Ha a mérési táblázatok helyesek, akkor valahogy mégis csak az van, hogy a srác által kitalált konstelláció a linunxon rosszabb teljesítményt nyújt, mint a windowsos. És mivel a userspace spinlock szerű förmedvények gyakoriak a játékoknál, ez a konstelláció is érdekes lehet.
- A hozzászóláshoz be kell jelentkezni
Szerintem Linus udvarias volt, finom és nőies ahhoz képest, amit tőlem kapott volna a gyerek. Aki user space-ben végtelenciklusban vár egy változóra, és még panaszkodik is, az ennél többet is érdemelt volna.
- A hozzászóláshoz be kell jelentkezni
Itt nem tiszta spinlockra kell gondolni, hanem olyasmire, ami egy játéknál simán előfordulhat, hogy amíg vár a flag-re, addig elvégez valami cpuintenzív kis feladatot. Egyáltalán nem hülyeség, amivel a srác kísérletezett.
- A hozzászóláshoz be kell jelentkezni
Ezt is írta a csávó: "the Windows scheduler is pretty good though".
Aki próbált már többszálas programot írni Windows API-ra, annak tisztában kell lennie az ellenkezőjével. Én a fönti mondatnál tovább nem is vagyok hajlandó olvasni az egészet, és tökéletesen biztos vagyok benne, hogy amit Linus írt, annak minden betűje helytálló. (Sajnos kicsit mégis továbbolvastam, és később is találtam benne butaságokat. Linus első pár kritikáját is elolvastam, és azok korrektek.)
- A hozzászóláshoz be kell jelentkezni
Alapvetően én sem bírom a bunkó stílust és elég stresszes tud lenni.
Mindazonáltal ha tényleg baromság amit csinál valaki, amiben nem valami rossz, meg lehetne jobb, hanem hulladék az egész (akár koncepcionálisan, akár megvalósításban) akkor meg kell mondani, azzal együtt hogy miért, helyette hogyan kéne és tanulni belőle. Persze mindezt kulturáltan, de nem köntörfalazva, hogy ehh-öhh himi humi ez így nem az igazi izé.
- A hozzászóláshoz be kell jelentkezni
Ha szemét a minősége, akkor minek nevezze? Én is annak nevezek dolgokat, amiket arra érdemesnek találok.
Viszont amennyiben lehetséges, akkor az észhez térítő fröcsögés után a megmagyarázásra/javításra/helyretételre célszerű törekedni. Itt Linus is így járt el.
„A jó pap is holtáig tanul.”
- A hozzászóláshoz be kell jelentkezni
Valószínűleg ezek a dolgok a generációbeli különbségekből jönnek. Akik jártak ipari iskolába, vagy esetleg voltak katonák (Elnézését kérem kedves honvéd úr/úrhölgy, megtenné, hogy a gépkarabélyt csőre töltve és kibiztosítva nem fordítja maga .... ratatataatatatta .... eh, mindegy, vigyék el vs. Mi a faszt csinál, kopasz?!?) , azok megszokták az egyenes (és hatékony) beszédet. Akik meg Waldorf-ba jártak, azok besírnak, ha találkoznak egy előbbivel.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Egyenes beszéd: menekülj Pista, omlik a bánya! Fölöslegesen negatív: takarodj innen Pista a jó kurva anyádba, mert omlik a bánya! Fölöslegesen pozitív: kedves Pista, esetleg gondolkodj el azon, hogy kimész, mert van rá esély, hogy beomlik a bánya.
Lehet keménykedni, de az egyenes beszédnek nem kell bunkósággal párosulnia. Pont akkor lesz kevésbé lényegre törő, ha az is van benne. És adott környezetben az illedelmes fölösleges köröket se várja el senki.
- A hozzászóláshoz be kell jelentkezni
Annyit mondott egy rossz kódra, hogy komplett szemét. Ha azt mondta volna, hogy ez teljesen használhatatlan a célra az számodra megfelelt volna?
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ez már kicsivel jobb. De ne ragadj le itt, a jelzőktől mentes kritika hatékonyabb, egyben lényegre törőbb és kifogástalan is. Tök fölösleges ragozni. "A te kódod nem a lock idejét méri, mert ...". Egy céges belső vagy publikus code reviewban ugyanezt írnám. Nem akarok más lelkébe taposni, neki is rossz, meg utána nekem is. De ez nem puhányságot jelent, mert a technikai érvekben nincs kompromisszum, még csak nem is fogom őket lassabban adagolni.
- A hozzászóláshoz be kell jelentkezni
Teljesen egyetértek.
- A hozzászóláshoz be kell jelentkezni
Ja, csak ez nem munkahely, nem munkatársai egymásnak, nem is ismerik egymást és az egyik fikkantással kezdett, ráadásul melléfogott. Tehát egyáltalán nem az a helyzet, amikor te egy munkatársadnak írsz egy céges rendszerben, mert ott kötnek a munkahelyi írt és íratlan szabályok.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Szerintem nagy szükség van mindkét fajta hozzáállásra. Én is próbálok jóindulatúan fordulni mások kódjához, hibáihoz. Többnyire azt tapasztalom, hogy ha én írok szar kódot, vagy csinálok valamit szarul, arra is jóindulatúan, türelmesen mondják el, hogy nem így kellett volna. Viszont sokkal izgalmasabb, hogy vannak akik Linushoz hasonlóan jól leb*sszák az embert néha, másképp elég tyúkszaros, unalmas lenne az ipar :D
- A hozzászóláshoz be kell jelentkezni
orulok hogy segithettem kollega :D :D
- A hozzászóláshoz be kell jelentkezni
:D
- A hozzászóláshoz be kell jelentkezni
Jó, most itt lefejtem a hozzászólók közül, hogy melyik érintett (kóder), mert van köztük egy csomó (tapasztalat), amelyik ha a kódját kritzálod, akkor azt rosszabbnak veszi, mintha az anyját szidtad volna. Ezekkel nem lehet mit kezdeni.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Aki úgy általában megsértődik már a kritika tényén, abból jó fejlesztő nem lehet, csak snowflake. De egy code review-ban nem kell semmi sértőnek lennie. És nem akarok nagyon nyelvészkedni, de angolban jobban átjön a különbség: "Criticism looks for flaws in the writer as well as the writing/Critique addresses only what is on the page".
- A hozzászóláshoz be kell jelentkezni
A garbage code az garbage code, ennél egyenesebben nem lehet mondani.
- A hozzászóláshoz be kell jelentkezni
.
- A hozzászóláshoz be kell jelentkezni
Mondjuk azt azért nem értem, hogy OK lehet a gyerek mellé lőtt/hibázott, de akkor ez azt jelenti hogy amit kiadott a kezéből szar? Nekem a kettő nem feltétlenül egyenlő.
- A hozzászóláshoz be kell jelentkezni
Úgy látom, hogy Linusnak már megint fáj, hogy vannak felhasználói, akik nem értenek annyira a dolgokhoz, mint ő. Illetve pontosabban: más dolgok fontosabbak a felhasználók számára, mint Linus számára.
- A hozzászóláshoz be kell jelentkezni
És részben beismeri, hogy valójában tényleg szar az implementáció és update érett...
smeuletz (alexsmeu.delete@this.yahoo.com) on January 6, 2020 9:11 am wrote
> Well, in his post Linus Torvalds himself says: "End result: sched_yield() is basically historical garbage"
> So, since it rarely has any good use, and can only be used with a realtime scheduler, it should
> be deprecated and later removed and a new header (eg: sched_realtime.h) should be added, with a
> new sched_realtime_yield() API, which would return error if the scheduler is not realtime.
> And thus, the API would be updated to reflect reality and minimize the chance for erroneous usage.
- A hozzászóláshoz be kell jelentkezni
Mondjuk az érdekelne, hogy aki szerint szemét amit kiadott a kezéből a srác, az végigolvasta-e a cikkét esetleg végigment-e a thread-en ahol Linus maga is bevallja hogy némi update ráférne a dologra.
Vagy ha Linus azt mondja hogy szar akkor az tényleg szar.
- A hozzászóláshoz be kell jelentkezni
Én nem azt mondom, hogy szemét, amit csinált a srác. A kód minőségére nem tudok mit mondani, mert ahhoz nem értek... DE:
- Skarupke írja is, hogy kipróbált több ütemezőt és más eredményeket kapott, ami természetes
- A spinlock-ra írt egy saját megoldást, amit userspace-ben használt
- Hozzászólások között elismeri, hogy ez volt az első alkalom, hogy Linux-os ütemezővel kellett dolgoznia (úgy, hogy igazából nem is az ő feladata volt, csak kíváncsiságból tesztelt)
- A többi hozzászólásban már többen felhívják a figyelmét rá, hogy a spinlock nem userspace-be való. Van kernel szintű megoldás rá, azt kell használni és nincs ilyen probléma.
- A blogban kb nyíltan kinyilvánítja, hogy hát a Windows ütemező jobb, mert ott nem tapasztaltak ilyeneket. Hát köszönjük, minden ütemező más felhasználásra van optimalizálva
- Kb mondhatjuk, hogy az egymás munkájának szitkozódását nem Linus kezdte. Elég csak a blog címét nézni: "Measuring Mutexes, Spinlocks and how Bad the Linux Scheduler Really is". Ez kb ugyanaz, mintha kijelentette volna, hogy szar az ütemező. Tehát még örülhet is, hogy Linus visszafogottabban fogalmazta meg a dolgot.
- Skarupke válaszában felveti a problémáit, de mivel nem ért hozzá teljesen, így túlságosan egyszerűen kezeli a dolgokat és olyan dolgokhoz hasonlítja az egészet, ami teljesen más megoldásokat kívánnak, lásd a PlayStation és Xbox, hogy ott ilyen nincs. Linus erre tőle telhetően normálisan elmagyarázta a dolgokat, hogy mi a probléma a felvetéseivel és a leegyszerűsített gondolkodással. Egy konzol esetén az az optimális, hogy kb minden más folyamat háttérbe szorul és a játék élvezi a kiemelt pozíciót, de egy Linux disztribúcióban lévő kernel (ha már Stadia), elsősorban nem ilyen felhasználásra van kihegyezve. Nem tudom a Google csinál-e módosítást ezért. Ott háttérben minden másnak is futnia kell. Ahogy Linus is írja, hogy ha egy processz megfogja a lock-ot, amíg az neki kell az nagyon rontja a rendszer használhatóságát. A példájával élve játék közben jön egy antivírus, ami végig akarja ellenőrizni a rendszert miközben játszol... Ha úgy működne az ütemező, ahogy Skarupke véli, akkor az av minden erőforrást elvenne a játéktól, azt játszhatatlanná téve.
- Ahogy Skarupke is írja: "I hope to have convinced you to avoid spinlocks, even for very short sections." Ezzel az a legszebb, hogy Linus is pont ugyanezt fejtette ki. Illetve a dokumentációban is ez szerepel:
"Avoid calling sched_yield() unnecessarily or inappropriately (e.g., when
resources needed by other schedulable threads are still held by the
caller), since doing so will result in unnecessary context switches,
which will degrade system performance." - "End result: sched_yield() is basically historical garbage" ahogy Linus fogalmazta. Tehát igen, elismerte, hogy a kernelben is van olyan ami már szemétre való, de ahogy egy későbbi levelében írja, a Linux fejlesztése azon az irányon marad, hogy ha lehetséges, akkor ne törjenek meg semmit, hogy ha esetleg valaki mégis használná az adott API-t.
Így most ennek a témának a felröppenése kapott egy kis visszhangot ezért most mindenki rászállt a Linux ütemezőjére, aminek köszönhetően javítgatnak rajta ha kell.
De az egész összefoglalva:
- Skarupke, használt egy olyan kernel funkciót ami dokumentációban írja, hogy ne használják.
- Nem tetszett neki az eredmény.
- Sírt egyet a blogjában róla
- Megkapta a választ, hogy hülyeséget csinált
Kell még ezt ragozni?
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"
- A hozzászóláshoz be kell jelentkezni
Hát ez az hogy nem, ezért nem értem hogy miért szaroznak egyesek, azaz érzésem hogy van egy ilyen attitűd hogyha Linus mondja hogy szar akkor az csak szar lehet (és igen ettől még lehet szar a munkája, szerintem egyébként nem, de igen van benne hiba)... Igen nem volt szerencsés, hogy a srác azt a címet adta a cikknek ami, de egyesek olyan nyíltan fikázzák itt mások munkáját mintha részletekbe menően körüljárták volna a témát... Ebből így lett egy flame, merthogy kevés szakmai vitát vélek felfedezni mind itt, mind pedig a linkelt threaden.
Egyébként csakhogy a pozitív hozadékot is említsük meg, Linus is elismeri hogy ennek "hála" valószínűleg a téma több figyelmet fog kapni.
"Maybe this discussion ended up at least making more people aware of this all.."
Ha más nem talán ennyi hozadéka lett a "szarozásnak"...
- A hozzászóláshoz be kell jelentkezni
Kb erről van szó:
Szar a plédakód? - Igen
Mélyebb Linux scheduler hozzáértés nélkül kezdett szakérteni a poster? - Vessetek a mókusok elé, ha nem.
Nem lehet semmi hasznosat szólni az eredménnyel kapcsolatban? - Vitatható, tény hogy ez esetben Linusnak nem volt feladata hogy konstruktív legyen.
Rossz és hatásvadász volt a blogpost címadása ami felhúzta Linust - Teljes mértékben. De a reakciód nem a másik felet minősíti hanem téged.
Egy masszívan interaktív alkalmazást szerencsésebb lenne realtime prioritással szimulálni ami, ahogy én kivettem a tesztekből teljesen out of scope volt.
Lehetett volna ez egy építő jellegű beszélgetés kezdete? - Egy épeszűbb világban mindenképp. De a mai módi amikor mindenki by default védekező állást vesz fel (igen, ez a közösségi média mechanizmusainak a mellékterméke, legalább részlegesen) ez túl idealista elvárás.
"Dummies guide to create a lose-lose situation". Legalábbis a blogpost hatásvadász címadása és Linus reakciója erre állította be a nyitóhangulatot. Nekem nagyon hiányzik a régi open source közösség hangulata, persze sok minden (beleértve a közösség összetételét) változott időközben.
Nyilván, ez csak a saját naív véleményem és én - másokkal ellentétben - szoktam tévedni. :)
- A hozzászóláshoz be kell jelentkezni
Igen,Alapvetoen az emberek arrogansabbak
- A hozzászóláshoz be kell jelentkezni
Apropo PC:
Most hallgattam egy eloadast ahol a Man in the middle attackot, Person in the middle attacknak mondta az eloado:)
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
- A hozzászóláshoz be kell jelentkezni
hanyinger
- A hozzászóláshoz be kell jelentkezni
Ha elég tökösek lennének, eltörölnék a nemek nyelvtan szintű megkülönböztetését, mint ahogy a magyarok csinálták.
- A hozzászóláshoz be kell jelentkezni
lol :) Értem én hogy kulturális forradalom, de értékeltem volna ha az IT szekciót ebből nagy ívben kihagyják. Nincs fontosabb terület ahol aktivizálódhatnának? Nem mondom hogy nézzenek körül afrikában de ilyenkor rendszeresen gondolom.
- A hozzászóláshoz be kell jelentkezni