- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Azta! Szép teljesítmény.
- A hozzászóláshoz be kell jelentkezni
Hát nem tudom, ez szerintem Linusnak nem fog tetszeni.
- A hozzászóláshoz be kell jelentkezni
meg a 3rd party kernel modul/driver fejlesztoknek se
amugy ezt 20-25 eve kellett volna meglepni, amikor masfel ora volt a kernel forditas. most egy 5 eves szerveren is lebuildeli fel perc alatt, nem nagyon izgat mar senkit az a kis speedup...
- A hozzászóláshoz be kell jelentkezni
Szerintem mindig jo szebe tenni a kodot. Erdemes Ingo levelebe beleolvasni, nem csak a perf javult, hanem tisztabb is lett a kod.
- A hozzászóláshoz be kell jelentkezni
Mingo
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.
- A hozzászóláshoz be kell jelentkezni
hat azert tisztabb attol nem lesz, hogy a struct-okat lecsereli ilyenre:
DECLARE_PER_TASK(type, name);
per_task(current, name) = val;
meg csomo inline-t kivett stb... ez inkabb ganyolasnak tunik mint tisztitasnak :)
ez meg egeszen aggaszto:
I did find a couple of semi-bugs in the kernel where a specific order of headers guaranteed a particular code generation outcome - and if that header order was disturbed, the kernel would silently break and fail to boot ...
- A hozzászóláshoz be kell jelentkezni
Olvasom a threadet (eleg jo), az uninline-okra mas is rakerdezett. Ma irt rola, hogy volt koztuk sok meghizott fv, egyszer hivottak, stb.
Az meg hogy eddig veletlenul mukodott valami, azt en sem tudom masnak ertekelni, mint bug. Mindenki includalja explicit amire szuksege van.
- A hozzászóláshoz be kell jelentkezni
egyszer hivottak
Azt hittem, pont ezekre jó az inline. Csak egyszer kell lefutnia, oda beteszi a fordító, nem kell futásidőben ugrálnia, mégse hízik meg a kész bináris.
Vagy miért nem jó, ha egy egyszer hívott függvény inline?
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.
- A hozzászóláshoz be kell jelentkezni
Szerintem ezt a fordito felismeri magatol. Emiatt nem erdemes overuse-olni.
Inkabb ott erdemes az inline-t hasznalni, ahol kifejezetten kered, hogy ugy forduljon.
- A hozzászóláshoz be kell jelentkezni
Nekem nem teljesen világos, hogy mit jelent az, hogy egyszer hívott. Egy helyről, de potenciálisan sokszor hívott, vagy a kernel teljes életciklusa alatt egyszer hívott függvényt? Mert ha utóbbi (pl. valamilyen inicializálás), akkor azért a néhány órajel ciklusért teljesen felesleges inlineolni. Előbbi esetén pedig attól függ, mit csinál az adott függvény. Ha a függvényhívás overheadje elhanyagolható a függvény futásidejéhez képest, illetve nem teljesítménykritikus code pathon van a függvényhívás, akkor valószínűleg szintén felesleges inlineolni.
- A hozzászóláshoz be kell jelentkezni
Az a gond az inline-nal, hogy ha egy sok helyről include-olt headerben van, minden őt include-oló .c forrás is lefordítja tök értelmetlenül, miközben 1-2 helyről hívják csak.
- A hozzászóláshoz be kell jelentkezni
Technical debt-et csökkenteni mindig jó, ez biztosítja a hosszú távú túlélést. Ezt a Linux kernel közössége jól csinálta eddig is.
Az szerintem különösen értékelendő, hogy egy ekkora kódbázison valaki nekiáll egy ekkora változtatásnak.
Ennek már a kommunikációja is szép feladat, mert gondolom volt előre PoC, egyeztetés, hogy végül bekerüljön a nagy meló outputja.
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
ez maga a PoC. irja is, hogy ez meg csak egy javaslat, nincs teljesen kidolgozva, es a fogadtatastol fugg hogy befejezi-e...
az hogy bekeruljon meg sok ev szerintem, ha egyaltalan...
- A hozzászóláshoz be kell jelentkezni
Yesss!!! Állati jól hangzik, most nemrég hozta le a Phoronix is. Ez a másik, amit szeretek a Linuxban, hogy állandóan van fejlődés, a fejlesztők folyamatosan fejlesztenek, ha nincs mit épp fejleszteni, akkor egy meglévő kódot optimalizálnak (legutóbb NTFS driveren javítottak, a random generátor lett többszötösen gyorsabb, most a kernelfordítás lesz). Nem úgy van, mint zárt platformokon, ahol a fejlesztő egyszer kiszenvedi, hogy végre látszólag bugmentesen megy, akkor úgy vannak vele, hogy jól van, kezünket leporoljuk, hátra dőlünk, ez LTS lesz, 5-10 évig nem nyúlunk hozzá if it ain't broke, don't fix it / ought to be enough for anybody alapon, vagy csak tömeges piaci igény esetén, mikor rentábilis lesz lefejleszteni-támogatni, meg majd soha napján patchkedden. Meg az új verziókban általában tényleges technológiai, szakmai fejlődés van, és nem arról szól egy új verzió, hogy áttették Electron/Chrome-alapra, meg szebben csillognak benne a megnövelt méretű ikonok, progress bar és egérkurzoros animációk, és le vannak benne kerekítve az ablakok sarkai, meg középre van igazítva a tálca tartalma.
Ezt nem szokták érteni a Debian-Ubuntu userek, hogy nem az ő disztrójuk a világ közepe, meg a rolling és btw. I use Arch az nem csak egy reddites meme, hanem tényleges előnye van. Míg náluk nagy eljut a gép a BIOS bootos GRUB2 bootig, addigra egy Arch usernél nem csak hogy az UEFI systemd-boot vagy EFI stub boottal a kernel és/vagy initramfs villámgyors zstd-tömörítéssel már ki is bontatta magát (egy tíz éves üzleti laptopon is, rendes SSD-n, ahol nincs I/O bottleneck), és bebootolt, mire náluk a kernel betöltött, addigra nálam már az egész rendszer betöltött minimál WM-mel, gyorsabb (vagy ugyanolyan gyors) a boot, mint náluk esetleg a hibernációból feljövetel. Ugyanez frissítésnél, mikor még az apt és apt-get még egyáltalán a tárolók szinkronizálásával szüttög, addira Archon pacman-ban nem csak párhuzamosan lefrissült az összes tároló, meg leértek a csomagok szintén párhuzamos letöltéssel, hanem megint villámgyors zstd-tömörítéssel már ki is lettek bontva, megvan a telepítés, frissítés is, két szempillantás. Persze, elérnek ezek az újítások az Ubuntuba is, pl. a zstd-vel tömörített csomagok, de a 21.10-es verzióig kellett vele várni, LTS usereknek még extra fél év, debianosoknak min. 5 év, mert a zstd új, meg a gzip stabilabb, még kell mindenkinek 5-10 év haladék, és akkor még a párhuzamos csomagletöltésről nem is beszéltünk. Ez a baj a corporate szoftverrel, meg túl kötött döntéshozatallal bíró konzervatív disztrókkal, hogy inkább vállalati környezetbe meg szerverre valók, de nem annyira jól mindennapos felhasználásra, mert lassúak, rugalmatlan a döntéshozatal, nehezen adoptálnak újdonságokat. Ez főleg Nvidiánál látszik, hogy milyen lassan őrölnek a nagy céges bürokrácia, kódvalidálás, engedélyezés, mire kitolják a következő verziós zárt driverüket, addigra a kernel meg a X.org/mesa már 2-3 alverzióval előrébb jár megint, és az egész egy reménytelen versenyfutás, amiben mindig lemaradnak.
Windows userek ennél is rosszabbak, főleg az a retrós fajta, akinek a szemellenőjét levetetve nem lehet elmagyarázni, hogy miért gáz az XP. Csak azt tudják hajtogatni, hogy megy a Battlefield, meg a Fotóbolt, RGB, majd pedig legvégső érvként a mindenkinek falat kényérként kellő AutoCAD. Nem bírják megérteni, hogy ezek érdektelen dolgok a legtöbb usernek, aki egyszer megtapasztalta a Linux előnyeit (nem is a licencen spórolás, hanem az extra sebesség, modularitás, testre szabhatóság szabadsága, saját rendszer és adatok feletti nagyobb kontroll), sose fog visszaváltani Windowsra, se Macre, nem fogja érdekelni semmilyen Fotóbolt meg MS Iroda, nem fogja visszasírni a bűn lassú NTFS-t, meg a kínzóan lassú frissítéseket, lagokat, malware-eket, vírusirtózást, kényszerített online fiókot, telemetriát, registry-hackelést, kigyomlálandó reklámokat, Cortanát, stb.. Nem fogja érdekelni a hardvertámogatás se, mert eleve kis odafigyeléssel olyan hardvert fog venni, ami máris korrekten támogatott (és nem az fog számítani, hogy Ray Tracingben hoz extra 5-10 fps-t, vagy hogy a Mac M1 geekbenchben egy szálon kicsivel többet hoz), nem fog hiányozni neki semmilyen MS/Adobe szoftver, mert megtanulja kiváltani natív linuxos alternatívákkal, módosított workflow-val, játékokhoz meg végső esetben tart windowsos célgépet vagy célhardvert (játékkonzol).
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Hogy a faszba birsz fosni ennyit a semmirol?
- A hozzászóláshoz be kell jelentkezni
Apad hogy a faszba nevelt ekkora tahot beloled?
- A hozzászóláshoz be kell jelentkezni
Elsőre írtam vmit, de inkább hagyjuk:)
- A hozzászóláshoz be kell jelentkezni
Mondjuk abban igaza van, hogy egy tl;dr, aztán a pol. korr. fórumtársak is elégedettek. :D
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Fel kell írni mi a "mi ne legyen a hupon" topikba: csúnya beszéd
- A hozzászóláshoz be kell jelentkezni
Az a helyzet, hogy a karomkodassal telebaszott kommentek altalaban kurvara fel lesznek szavazva. A kozonsegnek is tetszeni szokott az adott kontextusban. Mert altalaban addigra mar gecire nem indokolatlan, es addigra, mire kozossegunk egy tagja nagyritkan karomkodni kezd, mar sokmindenki mast is kurvara felbaszott valami.
(Ez a komment kivetel, mert ez egy eroltetett szemleltetes)
- A hozzászóláshoz be kell jelentkezni
(Hiányzott a végéről a B+)
- A hozzászóláshoz be kell jelentkezni
Ez ilyen, örülök, hogy tetszik. A legtöbb esetben egyébként úgy indulok neki, hogy rövid lesz, egy darab pár soros bekezdés maximum, aztán eszembe jut még ez-az, aztán néha grafomániába torkollik.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Az esetleg eszedbe jutott már, hogy a saját álomvilágod feleslegesen hosszú grafománializálása helyett inkább utánanézz a valóságnak?
- A hozzászóláshoz be kell jelentkezni
Szerintem nem rossz a srác. Ráadásul ki tudja rendesen fejteni az álláspontját. Nyilván nincs mindig mindenben igaza, de legalább szokott lenni egy olyan képe adott témáról, aminek egyes pontjait lehet vitatni, és amit lehet tovább formálni.
Másoknak tudnám javasolni inkább, hogy picit tájékozódjanak, mielőtt hülyeségeket írnak.
- A hozzászóláshoz be kell jelentkezni
manager szindroma
Every single person is a fool, insane, a failure, or a bad person to at least ten people.
- A hozzászóláshoz be kell jelentkezni
Látom ez többeket zavar, most visszanéztem, hogy ez a legtöbb szavazatot kapott komment az elmúlt 30 napban, én is nyomtam rá egy +1-et, hogy örüljetek. Tényleg nem értem, mert 1) akinek nem tetszik, letiltja a hozzászólásaim, vagy átugroja, 2) nem minden hozzászólásom ilyen hosszú, 3) azért 99%-ban a témába szokott vágni, és szerintem lehet benne hasznos dolog, azért is írom le. Amire nem tudok témába vágót írni, ahhoz inkább nem szoktam hozzászólni egyáltlán. Azt értem, hogy nem mindenki ért ezzel-azzal egyet, de az meg megint egyéni szocprobléma, erről szólna egy fórum, hogy különböző szempontokról írnak egy adott témát érintően.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
> etiltja a hozzászólásaim
Lehet olyat? Hogyan?
- A hozzászóláshoz be kell jelentkezni
Én kimondottan kedvelni szoktam a hozzászólásaidat és kedvelem a Raynes-effektust.
Ne feledd, sokan csak a farkukat üríteni meg a stresszt becsatornázni járnak a fórumba. Vagy a kis buborékukat erősíteni. Nekik nyilván frusztráló egy kifejtett vélemény.
- A hozzászóláshoz be kell jelentkezni
"Nem úgy van, mint zárt platformokon, ahol a fejlesztő egyszer kiszenvedi, hogy végre látszólag bugmentesen megy, akkor úgy vannak vele, hogy..."
Nem tudom, hogy máshol hogyan megy, de nálunk a fejlesztés része, hogy mindig keressük a lehetséges fejlődési pontokat. És ez egy belső céges alkalmazás. ;)
- A hozzászóláshoz be kell jelentkezni
Ezer köszönet a zstd megemlítése miatt. Kipróbáltam.
Az egyik HW-ünkhöz a toolchain tele van mindenféle előrefordított libbel, emiatt ~700MB, és xz-vel kicsomagolni a tar-t még SSD-s gyors gépen is ~14s. Ugyanez a toolchain zstd -19 -cel "sűrítve" alig nagyobb az xz-s archívnál, és 7x (!!!) gyorsabban csomagolódik ki. Na ez már előrelépés!
Átkonvertálom a legfontosabb csomagjainkat.
- A hozzászóláshoz be kell jelentkezni
Összemérnéd esetleg a pigz-vel is sebességben?
- A hozzászóláshoz be kell jelentkezni
xz-t tobb threades modban (-T) hasznalod? Az is sokat dob rajta.
- A hozzászóláshoz be kell jelentkezni
Persze. Kicsit jobban tömörít, de sokkal lassabban csomagol ki.
- A hozzászóláshoz be kell jelentkezni
Nagyon durva cucc. Amikor az Arch bevezette a pacmannél 0.8% csomag méret növekedést kaptak de 1300%-al gyorsabb kicsomagolást.
- A hozzászóláshoz be kell jelentkezni
Átkonvertálni szerintem nem éri meg, vagy max. azoknál az archívumoknál, amit sokat kell kibontogass, vagy ha mondjuk a fájlrendszerbe épített transzparens tömörítésre használod. Igazából a legjobb alacsony tömörítési fokozaton, már -1 beállítással is jobban tömörít, mint a gzip, igaz ekkor elmarad az xz tömörítési szintjétől jóval, de cserébe még gyorsabban csomagolódik be (vagy 100×-os sebességgel akár), és a kicsomagolási idő is rövidebb lehet (7x helyett mondjuk 8x-os). Én főleg a gyors betömörítési idő miatt használom, mert a saját időm kímélem vele, hogy az, amit az xz hosszasan csomagol, a zstd -1 pillanatok alatt tömöríti be, és előre tudom, hogy majd a kitömörítési oldalon is időt spórolok az illetékesnek (aki lehetek én is).
Függ a mérettől is, mert ha valami kisebb adatmennyiséget, forráskódot, stb. tömörítesz, pár KB/MB, ott nem olyan nagy az időbeli nyereség. De ha már ilyen gigabájtos, sok gigás, terás méretről beszélünk, ott iszonyat nagy az időspórolás. Főleg, ha sok magos, sok szálas a proci, és van egy gyors SSD, ami miatt nincs durva I/O bottleneck.
A zstd-nek az a baja, hogy túl új még, és mivel a Facebook reklámozza, azért nem bíznak benne az emberek, mindenki úgy van vele, hogy ez is valami egynyári sláger lesz, amit most hype-olnak, majd kikopik. Igazából meg nem, mert aki kipróbálja, látni fogja, hogy zseniális, és azt is elárulom, hogy a Facebooknak semmi köze nincs hozzá. Egy független fejlesztő munkája, ami a FB előtt is létezett, csak a FB megvette a zstd-t és lz4-et, meg a fejlesztőt tovább alkalmazza, hogy dolgozzon, optimalizáljon a kódon, de a tényleges szakmai fejlesztésbe nem szól bele, az épp úgy egy egyemberes projekt, ahogy előtte, csak a finanszírozása történik új keretek között. Elég sok minden támogatja már sok platformon, WinRar, 7-zip, peazip, Ark, stb. mind ki tudják már csomagolni a zst, tar.zst fájlokat, csomagok meg elérhető hozzá minden disztróhoz, BSD-khez, MacOS-re, stb.. Különböző commanderek alá is van már kicsomagoló addonja, meg a fuse archivemount is támogatja (amivel szintén be lehet drótozni a támogatását különöbző programoknak).
Az lz4 elméletileg még gyorsabb algoritmus, de még gyengébben tömörít. Nem győzöm hangsúlyozni, hogy elméletileg, mert a gyakorlatban az lz4 egy szálat tud, míg a zstd adott esetben a többszálúsággal visszaelőzi elég durván.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Nálunk nem volt szabad csomagot frissíteni a bundle-ben, csak ha explicite az ügyfél kérte (mert mondjuk known vulnerablity volt valamelyik komponensben).
Oka: a bent lévő régi verzió már ,,kipóbált". Ha frissítek és e miatt lesz valami regresszió --> balfasz vagyok. Ha nem frissítek és kiderül valami sebezhetőség, szét lehet tárni a karokat és mutogatni a csúnyagonosz hekkerekre/zsidókra/kommunistákra. Hamar beléd verték, hogy az egyéni érdeked azt diktáljha, hogy ne nyúlj semmihez, ne javítsd ki, inkább ne is nézz oda.
Mint ahogy mástól átvett projektet sem szabad sikerre vinni soha. El kell sorvasztani, a régi projektgazda örökségének felgyújtása és égő hamvainak rituális lehugyozása közben látványosan bemutatni mekkora baromság volt már elkezdeni is. Aztán a megfelelő pillanatban reinkarnálni saját projektként.
Így megy ez.
- A hozzászóláshoz be kell jelentkezni
Azért az első bekezdés nem ilyen egyszerű. A munkahelyen azért fizetnek, hogy olyan munkával töltsd az időt, amiért az ügyfél fizet. Az ügyfél pedig új feature-ért fizet és ahhoz tartozik garanciális javítás hiba esetén. Azért nem fizet, hogy valaki hobbiból szépítse a dolgokat. A tulaj pedig tud kitalálni feladatot, ha nincs mit csinálni. Például olyan módosításokat, amelyektől később költségcsökkenést vár.
Az is egy nagyon téves elképzelés, hogy ha valaki ingyen, szabadidejében dolgozgat, akkor az milyen jó. Láttam több valóban ügyes és maximalista fejlesztőt éjszakánként hobbiból refaktorálgatni. Viszont ennek magas költsége is volt. Ő nem értékelte a saját szabadidejét, ami az ő baja alapból. Viszont a többiek munkaidejének jelentős része arra ment el, hogy az ő hobbijához alkalmazkodjon. Így fele annyira volt termelékeny a csapat és a tényleg kért feladatok lassabban haladtak. Időnként tényleg új hibákat is behozott a lelkes kolléga. És persze nagyon projekten minden módosított részt le is kellene rendesen teszteltetni. Fogja az automatizált teszt / élő teszt kapacitást. Esetleg üzleti logikát is ellenőriznie kell a megfelelő embereknek. Plusz marhára frusztráló a többieknek ez, különösen akkor, ha nekik még túlórázni is kell, hogy a saját feladatukat be tudják fejezni a folytonos variálás mellett. Szóval komonyabb projekteken tényleg nem úgy megy ez, hogy majd valaki elkezd világot megváltatni hobbiból, mert lehet hogy hosszú távon tényleg ad hozzá értéket, de rövidtávon meg tönkremegy a cég bele. Egyszemélyes projekteknél lehet esetleg ezzel játsznai, de ott eleve más az egész szituáció.
- A hozzászóláshoz be kell jelentkezni
Szerintem akkor is durva, hogy ismert kritikus sebezhetőséggel rendelkező komponenst nem frissítünk, de még patchelni is csak nagy durcásan patchelünk.
Nekem valami más jut eszembe erről.
Refaktorizálásra szökőévenként került sor kb.
Az, hogy az általad leírt csapatban gyenge volt a kohézió és szélsőségesen eltértek a nézőpontok, amit nem sikerült hosszútávon sem feloldani, szerintem egy másik jellegű probléma.
- A hozzászóláshoz be kell jelentkezni
A sebezhetőség is olyan, hogy az ügyfél tudja, hogy neki milyen kockázat és milyen megtérülés. Övé a kockázat. Ő fizet.
Ettől még persze lehet / kell jelezni az ilyet, de a döntés azé akié a felelősség.
- A hozzászóláshoz be kell jelentkezni
Nem tudom, én nem szeretek olyan kódot szállítani, amiben tudom, hogy ismert critical vulnerability van.
Nálunk a nemfrissítés elsődleges oka az volt, nehogy valami nem várt regresszió legyen. Azt hittem ezért vannak az egységtesztek meg a tesztverziók (ügyfélnek is adtunk rendszeresen tesztverziókat egyébként - nálunk és náluk is volt tesztkörnyezet plusz felrakhatta bármilyen eszközre amire ő úgy gondolta).
- A hozzászóláshoz be kell jelentkezni
Ha jól csinálja a refaktorálást, akkor nem tör el vele semmit.
Ha rosszul csinálja, akkor meg szólni kell neki, hogy inkább ne nyúljon hozzá!
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.
- A hozzászóláshoz be kell jelentkezni
Általában azzal szokott lenni a probléma, hogy nehéz meggyőződni arról, hogy nem tör el semmit. Egy legacy kódbázis teszt lefedettsége sem biztos, hogy megfelelő, ezért bármilyen nem-triviális refaktorálás előtt teszteket is kellene írni, így meg annyival több effort, hogy már nem éri meg, vagy nem jut rá elég idő.
- A hozzászóláshoz be kell jelentkezni
Ezért érdemes minél korábbi szakaszban gyakran refaktorálni a kódot. Jó esetben így később egyre csökken a szükségessége.
- A hozzászóláshoz be kell jelentkezni
Hát biztos cégtől is függ, nálunk ha valaki régi kódhoz nyúl, amiben nincsenek tesztek, akkor az az alap, hogy mielőtt valamit változtat, teszteket készít. Refaktorálás előtt is.
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.
- A hozzászóláshoz be kell jelentkezni
A való életben akkor lehet refaktorálgatni, ha más éppen nem dolgozik azon a forráson. Viszont aktív fejlesztés közben (határidők), ha valaki minden éjszaka átmozgatja a metódusokat fájlon belül vagy pláne fájlok közt, esetleg még át is nevezi őket, akkor a verziókövető rendszer nem tudja azt feloldani. Gyakorlatilag újra kell írni minden módosítást, ami a valóban szükséges fejlesztésekhez kell.
Persze amikor valaki már elég rutinos, akkor maga is rájön erre. De ehhez az kell, hogy sokat dolgozzon csapatban, ahol nem mindenkinek hozzá kell igazodnia. Újdonsült vezető fejlesztőknél szoktam ilyet látni, akik bizonyítási kényszert éreznek magukban, de még nem alakult ki az a látásmód, amivel csapatban lehet dolgozni. Nem ütköztek még eleget a managementtel, hogy megértésék az üzleti érték egy vállalkozásban keményen pénzkérdés, nem pedig magasztos elméletek követésében mérhető.
- A hozzászóláshoz be kell jelentkezni
Vica versa. Amennyi előnye van egy arch-nak a debian-hoz képest, vagy fordítva, annyi hátránya is.
- A hozzászóláshoz be kell jelentkezni
Nem úgy van, mint zárt platformokon, ahol a fejlesztő egyszer kiszenvedi,
Nem tudom, hogy te melyik világban élsz, nekem a tavalyi évem fele hasonló munkákból állt.
- A hozzászóláshoz be kell jelentkezni
tl;dr:
- kiszámítható software lifecycle nemjó
- Ubuntu plusznemjó
- Windows duplaplusznemjó
- A hozzászóláshoz be kell jelentkezni
Na de ki küldte? :) Grat!
- A hozzászóláshoz be kell jelentkezni
A fiatalok kedvéért emeltem ki :)
- A hozzászóláshoz be kell jelentkezni
Egész Windows-os lett már ez a linux, hogy ilyen teljesítménynövelő potenciálok vannak belefejlesztve...
- A hozzászóláshoz be kell jelentkezni
Ennek a Linux teljesítményéhez nem sok köze van, ez egy - részben - kernelfordítás-optimalizálás.
Nem tudom mennyire prio 1 meló a kernelfordítás-optimalizálás, tekintve
- végfelhasználó ma már alig fordít kernelt (nem érinti)
- egy AMD Threadripper 3990X 22 másodperc alatt fordítja le az 5.4-es kernelt, disztribútornak/kernelfejlesztőnek kellene futnia egy ilyenre (ha másból nem, szponzorációból)
Ettől függetlenül, foglalkozzanak ezzel is, ha van értelme.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Mondjuk lehet pl az OpenWRT vagy más projektek napi snapshotjait előállítani is jól jöhet.
- A hozzászóláshoz be kell jelentkezni
Merem remélni, hogy azokat nem egy OpenWRT-szintű hardveren állítják elő :D
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
LOL :-D
- A hozzászóláshoz be kell jelentkezni
Mondjuk nem is arra gondoltam, hanem mindegyik target-re lefordítani éjjelente...
- A hozzászóláshoz be kell jelentkezni
Legalább egy Windows-szintűt aláraknak.
- A hozzászóláshoz be kell jelentkezni
De akinek csak RPi-re telik, annak jól jöhet :-)
- A hozzászóláshoz be kell jelentkezni
Ez jutott eszembe:
... olyan, mint sajtreszelővel rejszolni ...
:D
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
"Nem tudom mennyire prio 1 meló a kernelfordítás-optimalizálás,"
A cloudban bérelt erőforrás nem olcsó, jó az, ha kevesebbet kell venni belőle, ha buildelni kell.
- A hozzászóláshoz be kell jelentkezni
A cloudban bérelt erőforrás nem olcsó,
Akkor nem ott kell buildelni.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
hanem, valakinek a pincéjében? három évre előre kipengetve a szükségesnél esélyesen lényegesen több erőforrást? És baszakodni infra managementtel?
Ahelyett, hogy veszünk pont annyi erőforrást, amennyi kell a munkához, és a baszakodós időt inkább azzal töltjük, hogy kevesebb kelljen belőle?
- A hozzászóláshoz be kell jelentkezni
A nyílt forrású projektek általában szponzorációban kapják a vasat, a kisebb szolgáltatóknál a Salgó-polc/rack szekrény helyet, a villanyt, a hűtést. Az üzemeltetést pedig megoldják a projekt önkéntesei stb. Vagy szponzorációban kapják a felhős erőforrásokat. Nem nagyon hallottam a 20+ év alatt, amióta ezeket a híreket követem olyat, hogy kitettek volna projektet azért, mert sokat buildeltek. Olyat hallottam még az internet hajnalán, hogy kitettek projektet mert elvitte a sávszélességet a sok letöltés, de mindig azonnal találtak másik szolgáltatót, egyetemet, amelyik belépett a kieső helyére.
Én ezt nem látom akkora problémának.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Én se látom akkora problémának egyáltalán, csak szerintem ez nem ilyen fekete, fehér. Egyrészt nem csak opensource projectek vannak, ahol ez adott esetben nem mindegy, másrészt bár valóban sok open source projekt kap vasat, helyet, netet, egy csomó meg nem kap, És ha a projekt maga kell előteremtse, akkor rohadtul nem mindegy, hogy a havi aws számlát kell bebudgetelni, vagy vasat.
Vagy ma már pl cloud erőforrást kap. Ha megnézed, a github igen jelentékeny részén egy csomó "nem elég nagy szponzort vonzani" projekt működik úgy, hogy valamelyik CI szolgáltató (néha direkt opensourceos) free tearjét használja, ezek pedig bizony jellemzően erőforrás limitesek, pl havi 1000 perc, vagy ilyesmi. Na, ezeknek például jó eséllyel nem mindegy, hogy mennyit lehet spórolni.
- A hozzászóláshoz be kell jelentkezni
Mivel kuratóriumi tag vagyok nyílt forráskódú-related alapítvány témában (FSN), pontosan tudom, hogy ez hogyan megy. Nem egyszer intéztünk ilyet, tárgyaltunk feltételekről, kaptunk erőforrást T-től, kaptunk rackszekrényt, villanyt, sávot, vasat stb.
Szóval, beszélgethetünk tovább róla, csak kérdezném: neked milyen rálátásod van a témára?
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Beszélgessünk. Valamit szeretnél hozzátenni a modandómhoz is, vagy csak péniszt lengetsz?
- A hozzászóláshoz be kell jelentkezni
Szeretek péniszt lengetni, főleg, ha az a témában ontopik. Tehát, te mire alapozva teszel kijelentéseket?
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Arra, amit huszon éve látok magam körül. Sajnos nem tudok péniszt lengetni, mert nem vagyok kuratóriumi tag, szóval ha erre van igényed, akkor nem tudok érdemben hozzászólni.
Cserébe nem is vitattam semmiféle állításod ;)
- A hozzászóláshoz be kell jelentkezni
Ez tiszta sor. Kb. 30 éve ezt olvasom egyfolytában, hogy mi minden lett gyorsabb, közben meg mindig azt tapasztalom, hogy minden egyre nagyobb és lassabb. De persze mindig örülünk a "sebességnek".
- A hozzászóláshoz be kell jelentkezni
Ezért kell gyorsítani, hogy a hajbi által bloatnak nevezett cuccokat elbírja a rendszer :D
Ez a Molnár gyerek megérdemelne valamilyen Pingvin Oszkárt vagy hasonló díjat, mert visszaolvasva sokat tett a Linux használhatóbbá tételéért
- A hozzászóláshoz be kell jelentkezni
Igen, eléggé sokat tett már, nem ma kezdte az ipart, és egy csomó jelentős kernelbeli fejlesztés a nevéhez fűződik. Lehet utánaolvasok egyébként ki ez, megérdemelné, akár csak egy cikket írhatna valaki róla.
Az meg senkit ne zavarjon meg, hogy látszólag a fordítási időből a végfelhasználó nem profitál, mert készen kapja a disztrókban a bináris kernelt. Pl. akinek valami drivergubanc miatt saját kernelt kell forgatni, meg a disztrók fenntartóinak is könnyebb, ha patchelni meg gyakran kell rollingnál fordítani az új verziókat, gyorsan kihozni, az nagyon nem mindegy, ha kétszer olyan gyorsan fordul le a cucc vagy nem, még ilyen 64 mag 128 szálas procinál is jelentős tétel, ha sokat fordítgat az ember. Arról nem is beszélve, hogy ergyább, 2 magos gépeken milyen nagy segítség ez, számos percet megtakarítanak vele csak egy fordításnál. Ennek szerintem most legjobban a gentoo-sok örülnek.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Ez egy fejlesztői feature, aminek a fordítás gyorsulása csak hasznos mellékhatása (és ezzel lehet könnyebben eladni, hogy miért kell megcsinálni :) ). Egyébként az, hogy sokkal kevesebb lesz az egyes fordítási egységek (1 db .c fájl + az összes behúzott header) keresztfüggősége nagyon sok szempontból előnyös, pl. könnyebb elemezni (kevesebb bug) vagy akár helyességet bizonyítani. Rust binding generálásról nem is beszélve.
- A hozzászóláshoz be kell jelentkezni
Én sem értem, hogy miért a fordítási időt emelte ki, és miert ez a "selling point".
Ha jól értem itt egy függőség tisztításról van szó, ami mellékhatásként jelentősen tudja növelni a forítási sebességet, de elsősorban architekturális jelentősége van.
- A hozzászóláshoz be kell jelentkezni
Nem, ettől nem lesz windowsos. Bár sajnos vannak windowsos vonatkozásai is, sok mainstream disztró tényleg csak a csili-vili-re próbál gyúrni, meg Windowst/Mac-et utánozni, meg szükségtelenül mindenkire rátolni a bloatot és az univerzális konténerformátumokat (Snap, Flatpak. stb.). Ahogy egyre népszerűbbek a Linux disztrók, sajnos van egy ilyen negatív hatása, windowsosítják el. Hála az égnek, ezeket még ki lehet kerülni nem annyira mainstream disztró használatával, ahol nincs minden szar előtelepítve, meg a felhasználóra tolva.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Fellélegezhetnek a build szerverek. :-)
- A hozzászóláshoz be kell jelentkezni
35-45%-uk elmehet bányászni.
- A hozzászóláshoz be kell jelentkezni
made my day... :)
- A hozzászóláshoz be kell jelentkezni
Elolvasva a teljes emailt nekem ez sokkal inkább tűnik egy karbantarthatóságot javító patchsetnek ami mellékhatásként gyorsabb fordítást eredményez. A 8 említett technikából az első 6-nak akkor is van értéke, ha nem hoz fordítási teljesítmény javulást.
- A hozzászóláshoz be kell jelentkezni
Akkor nem ezt kell első helyen kiemelni a bejelentésben:
- speeding up the kernel build (both absolute and incremental build times)
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ez az a pont amit a menedzser is megért. Kell az egyszerű siker.
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
Ez egy technikai lista, amit kernelhackerek olvasnak. Ez nem egy vezetői összefoglaló, hanem egy patch mellé mellékelt összefoglaló azoknak, akik nem tudnak napi 2000 LKML levelet és az azokra jövő reply-ket elolvasni.
Tehát, célszerű tömören, de érthetően leírni, hogy WTF, illetve, ha nem az a patch elődleges célja, ami a felsorolásban az első helyen szerepel, akkor azt kell az első helyre tenni, ami a fő célja. Mellette meg megjegyezni, hogy sideeffect-ként, még gyorsult a kernelpörgetés is.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
25,288 files changed, 178,024 insertions(+), 74,720 deletions(-)
Hogyan tudnak ennyi modosítást ellenőrizni merge előtt?
- A hozzászóláshoz be kell jelentkezni
manymanyeyeballz :)
- A hozzászóláshoz be kell jelentkezni
es rebase-elni idonkent
- A hozzászóláshoz be kell jelentkezni
GKH megmondta, hogy emailben, nagyon gyorsan, mert mire egy gitlab vagy ilyesmi betölt, hát neki annyi ideje nincs....
- A hozzászóláshoz be kell jelentkezni
Amúgy ezt használják integrációra?
- A hozzászóláshoz be kell jelentkezni
Nem tudom, annyira nem követem, cikkeket szoktam olvasgatni néha. Volt valami sztori, ahol megmagyarázták, hogy azzal a patchmennyiséggel, ami keresztül megy rajtuk kizárólag levelekben küldött patchekkel managelhető, mert úgy a leggyorsabb....
- A hozzászóláshoz be kell jelentkezni
Nem. Ez csak tükör. Linus mergel aztán kernel.org. Előtte tényleg email + patch.
- A hozzászóláshoz be kell jelentkezni
Félelmetes.
- A hozzászóláshoz be kell jelentkezni
megértem, 25000 módosított fájl átnézése után már én sem szívesen várnék a gitlabre
- A hozzászóláshoz be kell jelentkezni
(Eh, elsikkadt, bocs)
Ha valóban át akarod nézni, akkor nem számottevő a gitlabra várás, mert a 25000 sort nagyon sokáig nézegetjük, hogy jó-e (hogy cserében mennyivel kényelmesebb benne diffet nézni meg kommentelni....). Ha csak random adminisztrálgatunk, mert kell rá a GKH pöcsét, és az a lényeg, hogy minél gyorsabban villanjon fel, amit el sem olvasol, akkor lehet, hogy tényleg jobb az email meg a patch.
Kedvenc példám, hogy mennyire, khm, érdekes amit a kernel tetején csinálnak, az überkirály wireguard. Amiről ugye még Linus is megmondta, hogy überkirály, state-of-the art, és így kell ezt csinálni. Ugyan a threadből kiderült, hogy a vélemény kialakítása közben sikerült egy az egyben nem észrevenni vagy 80k sor crypto kódot, szóval kissé invalid. És ugyan nevezett cyrpto kódot azért erőst megköpködték akik valójában meg is nézték, ezzel együtt még mindig ott tartunk, hogy a wireshark state of the art, mert Linus megmondta
- A hozzászóláshoz be kell jelentkezni
hat 20 eve az mplayernel egy ido utan mar en se gyoztem rendesen atnezni a napi patch-mennyiseget. es nem segitett senki. raadasul a legtobb esetben nem egy yes/no kell, hanem megirni hogy mit modositson/javitson rajta, vagy neha egyszerubb/gyorsabb megcsinalni helyette.
aztan voltak olyan nagy patchek is mint Albeu configtree-je, amirol tudtam, hogy szukseg van ra mert sok problemat orvosol, de az egesz kodot millio helyen modositgatta, lehetetlen volt rendesen atnezni es vegiggondolni a kovetkezmenyeket, megtalalni a bugokat. betoltuk, aztan honapokig ment a bugfixeles utana... akkor utolag nagyon megbantam, de ez van, neha kell kockaztatni :)
(es persze elsore az is szep elegans megoldasnak tunt, kb mint a wireguard lehetett a kernelben)
- A hozzászóláshoz be kell jelentkezni
Persze hogy szoppancs, ha nem segít senki. Akkor is, ha igen. Pusztán azt szerettem volna mondani, hogy ha azon nyüsszög valaki, hogy lassú végigkattogtatni egy reviewt, mert neki literally másodpercei vannak, akkor amit csinál, az lehet hogy jó valamire, de hogy nem review, az tuti.
- A hozzászóláshoz be kell jelentkezni
s/wireshark/wireguard/
de értjük
- A hozzászóláshoz be kell jelentkezni
ah, pedig az elején még észrevettem :D
- A hozzászóláshoz be kell jelentkezni