Linus 15 év után Intel-ről AMD-re váltott az elsődleges gépén

Címkék

Linus tegnap kiadta az 5.7-es kernel hetedik prepatchét. Bejelentő levelében arról írt, hogy elsődleges gépében ~ 15 év után dobta az Intel CPU-t és AMD Threadripper 3970x processzorra váltott. A váltással az "allmodconfig" tesztfordításai háromszor gyorsabban futnak le, ami következő beolvasztási időablakban komoly előrelépést jelent majd számára.

In fact, the biggest excitement this week for me was just that I upgraded my main machine, and for the first time in about 15 years, my desktop isn't Intel-based. No, I didn't switch to ARM yet, but I'm now rocking an AMD Threadripper 3970x. My 'allmodconfig' test builds are now three times faster than they used to be, which doesn't matter so much right now during the calming down period, but I will most definitely notice the upgrade during the next merge window.

AMD Ryzen™ Threadripper™ 3970X specifikációk:

# of CPU Cores:                                         32

# of Threads:                                             64

Base Clock:                                                3.7 GHz

Max Boost Clock:                                       Up to 4.5 GHz

Total L1 Cache:                                         2  MB

Total L2 Cache:                                         16 MB

Total L3 Cache:                                         128 MB

Unlocked:                                                  Yes

CMOS:                                                        TSMC 7nm FinFET

Package:                                                    sTRX4

PCI Express® Version:                             PCIe 4.0

Thermal Solution (PIB):                          Not included

Default TDP / TDP:                                   280W

Max Temps:                                               95°C

*OS Support:                                            Windows 10 - 64-Bit Edition

                                                                  RHEL x86 64-Bit

                                                                  Ubuntu x86 64-Bit

                                                                  *Operating System (OS) support will vary by manufacturer.

Hozzászólások

Szerkesztve: 2020. 05. 25., h - 09:39

#influencer

Amúgy ez gáz, hogy még mindig emailben küldözgetik a patch-eket, és egy erre való rendszer helyett a saját (adott esetben lassú) gépükön fordítanak.

hogy még mindig emailben küldözgetik a patch-eket

Why kernel development still uses email

(tl;dr: ez a leggyorsabb)

és egy erre való rendszer helyett a saját (adott esetben lassú) gépükön fordítanak

Linus számtalanszor utazik egy évben, sokszor olyan helyekre, ahol szar vagy nincs internet.

trey @ gépház

Alkalmazkodnia kellene a rendszer működőképességéhez. Nincs olyan rendszer, aminek ne lenne állásideje, karanbartási ablaka, meghibásodása, lassulása stb. Neki ez vált be és ez bizonyítottan működik ekkora projektnél is.

trey @ gépház

A mennyiségi mutatók jól rávilágítanak a rendszer működőképességére. [1]

In short, Greg said, kernel developers still use email because it is faster than any of the alternatives. Over the course of the last year, the project accepted about eight changes per hour — every hour — from over 4,000 developers sponsored by over 400 companies. It must be doing something right. The list of maintainers who accepted at least one patch per day contains 75 entries; at the top of the list, Greg himself accepted 9,781 patches over the year. Given that he accepts maybe one third of the patches sent his way, it is clear that the patch posting rate is much higher than that.

A Gerritben, Gitlabban, Githubon vezetett projektecskék emellett eltörpülnek és jól látszik, hogy mind csak a kényelmes babzsákfejlesztők játékszere, ami amellett, hogy erőforráspocsékoló bloat, azért megpróbál némi rendszert vinni a magukat modern szájízzel agilisnak mondó, lusta, inkompetens quarter-stackek köreibe, ahol a Linux kernelfejlesztőitől megszokott szervezettségnek és professzinalizmusnak nyoma sincs és soha nem is lesz.

Egy szóval, a Linux kernel fejlesztését még valódi szakemberek szervezik. Nem az elmúlt évtizedben a szakmát felhígított ökrök és kóklerek.

Pont, hogy követendő példa lenne, hogy a fejlesztők régebbi, lassabb gépeken dolgozzanak, így a legtöbb bloat implementáció még fejlesztési időben észrevehető és kijavítható lenne.

Nagyon szerencsétlen gyakorlat az, hogy a fejlesztők mindig a legújabb félmilliós csiligépet kapják, amin eszük ágában nem lesz optimalizálni 8 CPU mag, 32 GB RAM és 1 TB SSD mellett.

Aztán maintenance ágon meg már eszük ágában nem lesz optimalizálni, rendszerint mindenkit elküldenek melegebb éghajlatra, hogy vegyen új gépet, ha gyorsulást akar, ami természetesen a régi kidobásával, elektronikai hulladék termelésével, környezetszennyezéssel és egy alapjaiban fenntarthatatlan ipar támogatásával jár.

Jaja, tokre egyetertek. Az oprendszer tokre lassu egy rendes gepen, legalabb csucsgep kell neki. Ez szerintem is Linus hibaja, meg a tobbi kernelfejlesztoje, akik bedolgoznak neki. Ha lassabb lenne a gepe, es azon irna a Windows kernelt, akkor gyors lenne az OSX. Siman.

Disclaimer: ez a poszt az egyik alternativ valosagban szuletett, es nem vallalok felelosseget a rohadek ficego kvantumokert, hogy mikor elkuldom elektronfolyamkent, akkor ugyanabban a dimenzioban materalizalodjon mint ahonnan elindult.

Nem tudom, ki beszélt itt Linus által fejlesztett Windows kernelről, mert én nem, az biztos.

Persze a hozzászólásod hangvételéből jól átjön, hogy nem akarod felfogni az alapproblémát, hogy a fejlesztők igenis elkényelmesednek a gyorsabbnál gyorsabb gépeiken és a legtöbb bloat triviálisan orvosolható lenne, csak egyszerűen nem veszik észre fejlesztési fázisban. Maintenance fázisban meg már nem olyan fontos, hogy külön foglalkozzanak vele, pláne, hogy nem is mindenkinél jön ki, mivel az Intel marketingesei is azért dolgoznak, hogy minél több új gépet vetessenek és minél több régit dobassanak ki.

Oke, legkozelebb kirakom a szarkazmus tablat, semmi gond! :-)

Amugy szerintem nem a fejlesztok kenyelmesedtek el, hanem a management kurvult el. Egyre gyorsabban kell haladni, a teszteles csak tessek-lassek, ennyi fert bele a sprintbe, (vagy windows modszer, teszteljen a felhasznalo, haha), a javitas raer majd maintenance alatt, vagy meg inkabb majd a kovetkezo foverzioban, kit erdekel.

A szoftverek minosege imho egyre pocsekabb, mert a sietsegnek ara van.

Az egyik ara, hogy az egyszeruseg kedveert egy ujabb reteget vonnak azvelozo reteg fole, mert az adott retegben, az adott keretrendszerben gyorsabb leprogramozni valamit. Aztan amikor hozza kell nyulni, akkor kiaf4szom irta ezt, de foleg miert igy, ja, hogy a bugos keretrendszer hibajat kerulte ki, akkor jovan, ehhez nem nyulunk, inkabb valami workaround meg egy komment mert jo fej vagyok.

A rovid tavu celokra optimalizalnak mindent, es ennek ez az eredmenye. Senki nem bizik a jovoben es az emberi joszandekban, kiveve nehany megszallott bolond. Nekik koszonhetjuk a linux kernelt es a userspace jo reszet.

Átjött a szarkazmus, de vele együtt átjött az érzéketlenség is a téma iránt. Pláne, hogy a Linux alkalmazások még jobban szenvednek a bloat-tól, mint általában a Windows alkalmazások.

Egyetértünk abban, hogy a management is jócskán hibás a dologért, viszont jobb helyeken a fejlesztőnek is van azért beleszólása. Ugyanakkor, ha lassabb gépen dolgoznának, akkor magától értetődő lenne, hogy nem hagynak bent triviálisan javítható bloat-okat, mert ezeket a management is látná messziről egy demón, hogy bloat és egy "mindent azonnal akarok" manager típusú ember kifejezetten érzékeny arra, ha a gép lassulgatással akadályozza a felhasználó munkáját. Már csak azt kéne valahogy megoldani, hogy a cégek ne használhassanak gyors munkaállomásokat. Például, az új gépek környezetvédelmi különadójával és a régi gépeket érintő adókedvezménnyel, vagy saját szerelő-karbantartó (pl. laptop szervizes) brigád SZJA-csökkentésével, ha a cégek fenntartanak ilyet. Máris olcsóbb lenne a régit megjavítani, mint újat venni.

A sietségnek elsősorban oka van, és utána van ára. Az oka az, hogy a vadkapitalista befektetők önző módon rövidtávon akarnak sikereket, méghozzá irreálisan nagy sikereket. Mondjuk úgy, hogy a természetes személyek által realizálható befektetési hozamok százszorosát-ezerszeresét akarják. Ami, mondanom sem kell, hogy irreális. Szóval, ennek is gátat kéne szabni, hogy egy cég mekkorára nőhet és valószínűleg a jegybanki alapkamattól kellene függővé tenni. Hosszú távon mind a szabad piacnak, mind a szabad versenynek, mind a környezetnek, mind a társadalomnak hátrányos, ha egy cég túl nagyra nő, lásd Apple, Google, vagy a defektes processzorokban utazó Intel, amit gazdasági ereje és a Trump-érában betöltött amerikai stratégiai jelentősége miatt nem vonnak felelősségre. Pedig pont ugyanazt a sorsot érdemelné egy Spectre/Meltdown után, mint a Volkswagen a dízelbotrány után, amivel visszavásároltatják az eladott autókat.

A spectre/meltdown egy teljesen uj tamadasi fajta volt, arra senki nem volt felkeszulve, nem veletlen, hogy meg teljesen mas architekturak is erintettek voltak. A VW ezzel szemben tudatosan csalt.

Nagyobb cegeknel az a gyakorlat, hogy adott idonkent lecserelik a gepeket, hogy a geppark tobbe-kevesbe egyseges legyen. Egy fejleszto berehez, meg az irodaberlethez kepest ez egy elegge elenyeszo osszeg, es a produktivitason bejon. Szoval le fogjak cserelni. Ami ezt jobban kivaltana, az az lenne, ha a BYOD jobban elterjedne a gepekhez erto emberekkel egyutt (igy nem az IT sziv azzal, ha 100 ember 100 kulonbozo vasat hasznal), esetleg ceges tamogatassal (en is igy vettem btw). A home office elterjedesevel egyutt realis eselyt latok ra jelenleg.

Egyebkent pont a nyilt forrasu programoknal jellemzo kevesbe, hogy ne legyen ido dolgokra (ld. a Debian "elkeszul amikor elkeszul" hozzaallasa), raadasul barki belenezhet, a kodminoseg szerintem jobb, mint a zart oldalon. Ami a masik iranyba billenti a merleget, az az, hogy fejleszteni jobb buli, mint tesztelni, igy aki onkenteskedik, inkabb koddal szall be, a bugok meg nem derulnek ki. Bloatosodas kevesbe jellemzo szerintem, maximum azt tudom elkepzelni, hogy valaki - azert, hogy jobban megismerjen valami uj keretrendszert - osszedob benne egy uj programot, es ha ez a keretrendszer bloat, akkor az eredmeny is az lesz.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Az Intel is tudatosan trükközött, hogy ezzel bizonyos esetekben gyorsabban teljesítsen a processzora. Az nem mentség, hogy mások is ezt csinálták. Ahogy a VW-nek sem mentség, ha mások is csaltak.

Nagyobb cegeknel az a gyakorlat, hogy adott idonkent lecserelik a gepeket, hogy a geppark tobbe-kevesbe egyseges legyen.

Elég nagy baj. Pont ezzel a gyakorlattal kéne szakítani. Régi, használt gépekből is lehet egységes gépparkot fenntartani. A 100 különböző gép szerintem is tökönlövés, viszont 1-2, vagy akár 3-4 különböző típusú szériát már lehet értelmesen karbantartani. A lényeg az, hogy minél kevesebb olyan munkaállomás legyen, amiből nincs tartalék, vagy nincs hozzá alkatrész.

raadasul barki belenezhet, a kodminoseg szerintem jobb, mint a zart oldalon

Ezzel azért vitatkoznék. Az open-source egyik átka pont az, hogy inkább a szép, olvasható kódra mennek, a teljesítményoptimalizáció rovására. A zárt kódban előfordulnak olvashatatlan, esetenként gányolt részek, assembly betétetk, amik adott esetben optimálisabbak, mintha clean code idealizmussal készültek volna.

Bloatosodas kevesbe jellemzo szerintem

Nem, nem az. Egy modern desktop Linux hemzseg a bloattól. A csiligány GTK3 és minden benne írt vagy rá GTK2-ről átportolt alkalmazás hemzseg a bloattól. A Qt5-ben írt LXQt legegyszerűbb párbeszédpaneleinek betöltésére is másodperceket kell várni 100%-on tekert CPU-val egy régi gépen, miközben mind egy MFC-s Control Panel applet egy szemvillanás alatt betöltődik Windows-on.

maximum azt tudom elkepzelni, hogy valaki - azert, hogy jobban megismerjen valami uj keretrendszert - osszedob benne egy uj programot, es ha ez a keretrendszer bloat, akkor az eredmeny is az lesz.

Ez igaz, és benne a legfájóbb az, hogy kötelezően felcommitolják, aztán valaki tovább fejleszti és utána már esély nincs az optimalizációra.

Nem tudom honnan szeded ezeket, de szerintem igen nagy tévedésben vagy.

Az intel nem tudatosan trükközött a meltdown-al. Ez épp nem az ő saruk. Van SW workaround, igazából nem is CPU bug. Csak eddig senkinek nem jutott eszébe, hogy mi történik, ha nem pucolnak ki ott egy memóriaterületet, a gyártó nem specifikálta, hogy ő megteszi.

A zárt kódok assembly betéteiről meg annyit, hogy itt a beágyazott ARM Cortex-M4-re fejlesztő szoftveres kollégáim futva menekülnének el, ha assembly kódot kellene írniuk. Sokan még nem is láttak assembly-t. Találkoztam olyan szoftveressel is, aki szilárd meggyőződéssel állította, hogy "assembly-ben szubrutinok márpedig nincsenek" :D

A legacy zárt kódbázist meg ne keverjük ide. Nyilván egy win 3.1, win 95, meg ezek az őskövületek ki voltak optimalizálva, mert muszáj volt, nem mentek volna máshogy el a régi gépeken. Sok kód innen fejlődött tovább, de nem tartják karban (font selector talán még mindig a win 3.1-es API-kat használja a Win 10 idejében...).

A linuxot pedig nem tudom miért kell azonosítani a QT5-el meg a GTK3-al. Én 12 éves asztali gépen használok xfce-t a legújabb debiannal, eldöcög. Lxde gyorsabb is az xfce-nél. Nem a programok lassúak, csak a browser, azzal meg nem lehet mit kezdeni. Persze ez is erősen függ az adott oldaltól. Úgyhogy ha valakit fenékbe kellene billenteni, azok sokkal inkább a webfejlesztők.

Libreoffice sem nevezhető épp az optimalizáció csúcsának, de semmi teljesítménybeli bajom nincs vele. Kicad, freecad, git, bármi elmegy, ami nekem kell, nem nekem kell a gépre várnom. Az persze megdobta a gépet rendesen, hogy nemrég tettem bele egy SSD-t, az igaz. De azért remélem te sem használsz 10 évesnél régebbi HDD-t... ha meg cserélni kell, akkor már miért ne SSD-t vegyen az ember?

Nyilván egy win 3.1, win 95, meg ezek az őskövületek ki voltak optimalizálva, mert muszáj volt, nem mentek volna máshogy el a régi gépeken.

Ennyi a lényeg, amit el szerettem volna mondani. Köszönöm, hogy megértetted. Tekintettel arra, hogy ezzel te is elismered, hogy a régi gépek rákényszerítik a fejlesztőket az optimalizációra, így magától értetődő, hogy a bloatnak úgy lehetne elejét venni, hogy a fejlesztők nem kapnak 3 évente új gépeket, sőt lehetőleg minél régebbi gépet kapnak, így már fejlesztési időben kijönnek a bloat-ok és valószínűleg szívesebben mennek el low-level-ebb, kevésbé bloated framework-ök használata felé.

A linuxot pedig nem tudom miért kell azonosítani a QT5-el meg a GTK3-al.

Mert a Linux desktop alkalmazások nagy része ezekben íródik, és ezekre portolódik a régebbi, kevésbé bloat (pl. GTK2, Qt3) framework-ökről. Az Xfce-d legalább 50%-a is már GTK3-bloat. Az meg épp elég baj, ha a browser lassú, tekintve, hogy minden interneten elérhető szolgáltatást már inkább abba erőltetnek bele, mintsem natív alkalmazást írnának hozzá. Nem beszélve a legújabb Electron-os csodákról, amik ugyanolyan erőforráspocsékoló bloat-ok, mint a böngésző, cserébe kétszer futtatsz egy browser példányt a gépeden és a memóriát is kétszer olyan mohón fogja elzabálni egy Electronos app egy mellette futó browserrel.

De azért remélem te sem használsz 10 évesnél régebbi HDD-t

SSD-t használok, Windows XP-vel és jóval gyorsabb, mint bármilyen csiligány, GTK3-as vagy QT5-ös app Linux desktopon. A browser itt is lassú, ha épp frissített verziót használok (Mypal, New Moon).

*ááááásít*

Mondod ezt úgy hogy lóf.t se tudsz rólam. Amivel dolgozom 4,5 éves gép és még alsó hangon ugyanennyi benne van. A játékos gépem 10+ éves, az otthoni szerverem 10+ éves, a telefonjaink 4 évesek, a nejem egy 10 éves elitebookon dolgozik. Nem dobáljuk ki évente a cuccainkat. De nyugodtan lökjed, tetszik a műsor, a megfelelő szemmel pl. a mónika show is roppant szórakoztató.

Ha az én 12 éves gépem 10 év múlva használhatatlan lesz, akkor a te 10 éves szervered és elitebookod is használhatatlan lesz. Erre mondtam azt, amit mondtam, nem szórakoztatásképpen. Egyébként a 10-15 évente új eszköz vásárlásával nincs különösebb bajom, viszont a Windows XP-s HP laptopomat, amit fő gépemnek használok, nem fogom lecserélni, amíg nem lesz javíthatatlan baja.

A 4 éves telefonokat pedig nyilván lecseréled 1-2 éven belül, a gyorsabb (tervezettebb) elavulásuknak köszönhetően, úgyhogy ehhez nem fűznék kommentárt, tekintve, hogy klasszikus late majority konzumerként viselkedsz.

Te viszont nem érted, amit én írtam.

Az miért fair összehasonlítás, hogy egy 19 éves rendszert, ami az akkori gépekre íródott, hasonlítasz össze egy 2020-assal? Miért nem mindjárt a DOS 3.3-al?

Hasonlítsd össze a 2020-as windowsoddal, a Win10-el. De akár a Win7-el is (szerintem amúgy a win7 lassabb). Az én laptopom 8 éves, és úgy megy mint a szél debiannal. Windows-hoz szokott kollégáim nem értették, hogy hogy tudok ilyen régi laptopot használni? Nekem meg fel sem tűnik, minden egy pillanat alatt megy vele.

Vagy hasonlíts össze egy 2001-es linuxot az XP-vel. Tudok ajánlani egy Suse 6.1-et, én azt akkoriban nagyon szerettem KDE 1-el. Van hozzá jó kis Star Office is.

Én értem a te szempontjaidat, hogy neked nem kell több, mint amit az XP ad (én is így vagyok vele egyébként), de az OS-eket nem nekünk fejlesztik, mert akkor bezárhatnák a boltot, hogy a windows 2000-el befejeződött a fejlesztés.

Mellékszál: tudod mekkora különbség van egy 133 MHz-es 486 és egy 500 MHz-es K6-2 között? Utóbbin még ma is tudok linuxot használni. És még a K6-2 is több mint 20 éves processzor.

Egyetértek, a Pentium Pro, Pentium 2, K6-2 generációja, de úgy általában a P6-K6 nagyon nagy ugrás volt, mindkét gyártó azóta is erre a technológiára alapozza a mai procikat, nem véletlen, hogy ezeken a procikon még ma is elfutkos ez-az. Már elve architektúrában dimenzionálisan ugrott a korábbi 486-P1-K5 szintjéhez képest, eleve szuperskalár dizájn, mikrokódvégrehajtás, regiszterátnevezés, spekulatív/soron kívüli végrehajtás. Órajelben meg még többszörösége, cache-méretben is nagy előrelépés volt, kb. mint utána a 64 bit, meg a több mag.

De a technológia mindig ilyen, dimenzióugrások vannak benne. Anno egy C64-ben volt annyi RAM, mint később egy PC proci L1 cache-ében, ami még tovább nőtt, ma már egy SATA2 SSD nagyobb átvitelű, mint egy régi proci L2 cache-e, egy NVMe SSD meg gyorsabb, mint az L1 cache-e a régebbi CPU-knak. Mai csúcs procikban annyi MB cache van, hogy anno a DOS-os gépekben a HDD nem volt akkora, így egy egész retró OS elfér benne 1:1-ben!

Csíkszélességek is mennek le folyamatosan, órajelek ezzel együtt emelkednek, buszsebesség is. Ezt nem érti hajbi, hogy nem egy 2005-ös AMD laptopnál meg egy XP-nél kell megállni, mert a technológia fejlődik, és nem csak hardverben, hanem szoftverben is. Ezt csak ő érzi, hogy nem volt fejlődés, mert leragadt egy 19 éves architektúrájú OS-nél, amit egy 15 éves gépen használ, ráadásul egy olyan laptopon, ami a maga korában sem volt a legerősebb hardverügyileg.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Ja, ezt írom én is. Volt mind a két nagy gyártónak kitérője, az Intelnek a Netburst, az AMD-nek a Bulldozer, de nem vált be nekik, dobták is. Mindkettő P6/K6 alapon tolja még ma is. Nem véletlen, hogy az összes modern procinál, ha megnézed a CPUID-t (kivéve Netburst Pentium 4), akkor CPU Family: 6-ot ír Intelnél. AMD-nél máshogy számozzák, így annál nem lehet CPUID-ben tetten érni.

Nem véletlen az sem, hogy a Netburst dobása után az Intel azonnal a P3-as alapokhoz nyúlt vissza, erre alapozva a Pentium M, majd Core termékcsaládot, Core, Core 2, Core i a mai napig. A P3-as meg a P2-esen, ami meg a PPro-n alapul (P6).

Bár egyébként az Intel vissza-visszanyúl a Netburstban lévő hosszabb pipeline-okhoz és magasabb órajelhez is, de ez inkább kisebb teljesítményoptimalizáció szokott lenni, nem fő tervezési elv. A zsákutca jellegét már belátták több évvel ezelőtt.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

így magától értetődő, hogy a bloatnak úgy lehetne elejét venni, hogy a fejlesztők nem kapnak 3 évente új gépeket, sőt lehetőleg minél régebbi gépet kapnak

Nem, a bloatnak úgy lehet elejét venni ha mérve és monetizálva van minden változtatás.

Pl. ha egy weboldal mérete egy új funkció miatt X KB-tal nő, azt felszorozva az átlagos oldalbetöltések számával megkapod az ezzel járó CDN adatforgalom mennyiséget, annak költségét. Továbbá méred, hogy a változtatás hogyan befolyásolja az átlagos oldalbetöltés idejét, az milyen korrelációban áll az oldalt emiatt elhagyó felhasználók számával, ebből kiszámolhatod a várható bevétel kiesést. Ezt összeveted a funkciótól várt bevétellel, valamint annak fejlesztési költségével. Ha az eredmény pozitív akkor megéri lefejleszteni a funkciót, ha az eredmény negatív akkor nem.

Ugyanígy az optimalizáció is mérhető, annak is van költsége, annak is van hatása a bevételre.

Alapvetően jó lenne a gondolatmenet, csupán ott nem stimmel, hogy az oldalt emiatt elhagyó felhasználók számával kéne számolni.

Az oldalt nézők teljes létszámával kell számolni, azok potenciális bloat miatti áramfogyasztás- és adatforgalom-emelkedésével, hogy ez nekik mennyibe kerül és ez a környezetnek mennyit árt. Ez alapján pedig adót kiszabni a bloat oldalakra/alkalmazásokra, hogy ne érje meg olyan önző logikával csak és kizárólag a saját pecsenyédet sütögetni, kibújva mindenféle társadalmi felelősségvállalás alól, ahogy te azt a szűklátókörű befektetői idealizmusoddal elképzelted és előadtad.

Az idealizmusod azért is életszerűtlen, mert mi van azokkal, akik nem szórakozásból látogatják az bloattá tett oldalt (vagy használják a bloattá tett alkalmazást), hanem mert muszáj nekik vagy mert nagyságrendekkel többet veszítenének, ha nem használnák. Ezt hívják döntési csapdába hajszolásnak vagy csúnyábban mondva zsarolási pozíciónak.

Ha mondjuk a Facebook alkalmazása, webes felülete stb. a górcső alá vett bloat, és feltesszük, hogy "kötelező" fent lenned, mert ott megy a digitális távoktatás, meg amúgy ott tartja mindenki is a kapcsolatot és nem vagy akkora influenszer, hogy ezt megváltoztasd, akkor ez esetben a Facebook zsarolási pozícióban van veled szemben, ugyanis egy kis lassulgatás miatt, bár idegesítő, de ugyanúgy nem fogod ott hagyni őket, mintha az adatvédelmi szabályzaton módosítanak úgy, hogy mostantól minden fényképed Zuckerberg tulajdona. Lehet, hogy még új gépet/telefont/tabletet is jobban megéri venned, mintsem törölni magadat és otthagyni a Facebookot a picsába. Éppen az ilyen, arroganciára lehetőséget adó (azt gazdaságossá tevő) helyzetek miatt kéne fossá-húggyá adóztatni azokat, akik fittyet hánynak arra, hogy holnaptól hány százmillió ember gépe fog 5-10W-tal többet fogyasztani, mert ők elspúrkodták a fejlesztési időt vagy lusták voltak optimalizálni. Sajnos a törvényhozás még mindig nem érte utol a technológiát.

Szükségszerűen rossz a számítási erőforrás pazarlás? Ha nem lett volna rá lehetőség a múltban, akkor ma nem lennének fordítóprogramok, grafikus felhasználói felületek, játékok stb. Meg igény sem lett volna még több elpazarolható számítási erőforrásra. Persze jó kérdés, hogy ez hosszútávon fenntartható-e, de nekem úgy tűnik, hogy ez össze van kapcsolva a számítógépek fejlődésével.

Persze jó kérdés, hogy ez hosszútávon fenntartható-e, de nekem úgy tűnik, hogy ez össze van kapcsolva a számítógépek fejlődésével.

A fejlődésével nem, csak a gyártók profithajhász, erőltetett növekedésével, a túlfogyasztás mesterséges csúcsra járatásával, ami minden, csak nem fenntartható. A fordítóprogramok is csak programok, azokat is el lehet készíteni hatékonyan.

Azt pedig egyáltalán nem tartom egészségesnek, hogy a szoftverek növekvő erőforrásigényének kéne a hardveripart stimulálnia, hogy minél több kapacitást építsen az új termékekbe, amit egy jóideje már csak több processzormaggal és integrált GPU-val (tehát csak növekedéssel és nem fejlődéssel), meg egyéb integrált céleszközökkel képesek megvalósítani.

Mégis, a mai napig képtelenek voltunk odáig eljutni, hogy egy korszerűnek mondott, minden nap használt fősodratú alkalmazás egy fősodratú operációs rendszeren vagy böngészőn (Facebook, Gmail, Office 365, Photoshop stb.) < 1 másodperc alatt betöltődjön úgy, hogy az használatra kész legyen, az online videók ne akadozzanak, a webböngészés (ami nagyrészt igazából csak képi és szöveges tartalmak megtekintése) ne merítsen jobban le egy laptopot, mint bármi más művelet.

Az elmúlt évtizedben innováció alig volt a processzorok terén, csak ilyen-olyan utasításkészlet-reszelgetések és TDP-farigcsálás, illetve a mesterséges elavultatásra tett kísérletek, pl. szándékos belassítás biztonsági hibák apropóján, driver-támogatás megszüntetése Windows 10-hez, a 4. generációnál régebbi modellekre. Míg egy 2000-es évek eleji gépnél (Pentium 4) 3x-5x (tehát 200-500%-kal) gyorsabb egy 2011-ben kiadott i5-2400, úgy egy 2020-ban kiadott, 10. generációs i5-10400 csupán a felével-kétharmadával (50-60%) gyorsabb a 2011-ben kiadott i5-2400-nál, ráadásul úgy, hogy az i5-10400-ban már 6 mag van és 12 thread van, tehát az egy magra eső számítási kapacitás max. a harmadával (30%-kal!) nőtt. Ez minden, csak nem innováció. Innováció az lenne, ha olyan gyorsulást tudnának elérni új, merőben más gyártástechnológiák kifejlesztésével, mint az SSD-k és a HDD-k között volt. Az Intel jelenleg álinnovációkkal, marketing-bullshittel, parasztvakítással, FUD-propagandával és az újabb rendszerek (Windows 10) driver-támogatásától való tartózkodással igyekszik mesterségesen piaci igényt generálni és olyan profitra (szebben mondva extraprofitra) szert tenni, amit valójában nem érdemel meg, mivel értékteremtő innováció nincs mögötte, csak újrafeltalált kerék.

Itt az ideje annak, hogy az elspúrkodott milliárdos költségvetéseket végre valódi teljesítménynövekedésre fordítsuk, a szoftverek optimalizációján keresztül, amit célszerű lenne törvényekkel kikényszeríteni a nagyvállalatoktól. Ahogy az áramot, a gázt és az Internetet is drágábban kapják, miért ne kaphatnák drágábban az új gépeket, hogy a használtakat megérje sokkal tovább fenntartani. Az Intel pedig a rengeteg extraprofitját valódi innovációkat elősegítő kutatás-fejlesztésre költse és inkább legyen 10 évente új processzor 10x annyiért, mint a mostani fenntarthatatlan tech-konzumerizmus.

Ha nem lett volna felesleges számítási kapacitás, akkor nem pazarolták volna a drága gépidőt fordítóprogramok futtatására. Ha nem lett volna további felesleges számítási kapacitás, nem akartak volna vizuálisan megjeleníteni semmit. Ha nem lett volna még további felesleges kapacitás, akkor nem akartak volna játszani, vagy böngészőben weboldalakat megjeleníteni, vagy képeket/videókat/zenét editálni. Ha nem lett volna még további felesleges kapacitás, akkor nem 4 hónapos programozók írnák javascriptben napjaink alkalmazásait. Ha nem lett volna még további felesleges kapacitás, nem az AI írná....

Szerintem ez nem baj. Olcsóbban tudsz venni egy olyan gépet, amin elfogadhatóan fut minden, mint 20 éve. Persze lehetne jobb. De ki mondta, hogy nem lesz jobb?

Az AMD le is hagyta az Intelt, nem véletlenül. A Linux desktop éve is eljön majd egyszer. A böngésző helyett is lesz majd egy jobban átgondolt platform.

"Facebook, Gmail, Office 365, Photoshop" Ezeknek van olyan alternatívájuk, ami betöltődik kevesebb mint 1 sec alatt.

Ha nincs, írj egyet.

Ha nem lett volna további felesleges számítási kapacitás, nem akartak volna vizuálisan megjeleníteni semmit.

Nettó baromság. Már a Commodore idejében is írták a jobbnál jobban optimalizált programokat, játékokat, amik egy nagyon erősen limitált rendszert próbáltak meg minél hatékonyabban kihasználni. Nem véletlen, hogy a mai napig az egyik legnépszerűbb retro platform, ugyanis a ráírt szoftverekben sokkal több szellemi munka és eszmei érték van, mint a ma JS-ben összegtákolt, csiligány gépsüvíttető szarkupacokban. Épp ellenkezőleg. Az, hogy korlátozott erőforrásokkal rendelkezel, fogja a jó ötleteket és a "hozzunk ki minél többet a hardverből" irányvonalat erősíteni, ezáltal sokkal optimálisabb megoldásokra vannak kényszerítve a fejlesztők, ami a szoftverek átlaghatékonyságát is pozitív irányba tolja el.

Továbbá, abból a szempontból sem stimmel a felesleges számítási kapacitással kapcsolatos meglátásod, hogy jelen pillanatban már a ló túlsó oldalán vagyunk a weboldalakat megjeleníteni, vagy képeket/videókat/zenét editálni ügyében. A weboldalak egyre kevesebb információtartalommal rendelkeznek, a videó-, zene és képszerkesztőket (és úgy általában a szoftvereket) egyre jobban lebutítják és azonos funkcionalitás eléréséhez minden évben egyre több erőforrás kell. Ezért voltunk a mai napig képtelenek eljutni odáig, hogy egy Facebook, egy Office 365, egy GMail < 1 sec alatt betöltsön, hogy ne akadozzon a scrollozás minden létező eszközön (talán az iPhone-t kivéve, ahol külön figyeltek rá) és hogy ne legyen egyenértékű a webböngészés a gémeléssel akkuidő szempontjából.

Magyarul, itt már nem arról van szó, hogy a felesleges kapacitást új, innovatív, értelmes dolgokra fordítják, mint pl. a képmegjelenítés vagy a videolejátszás, ami 25 éve még kuriózum volt egy számítógépen. Itt már az megy, hogy a fejlesztők lustálkodnak és ugyanazon videó lejátszásához 10 év múlva 3x annyi erőforrás fog kelleni, azonos felbontás és minőség mellett, mert valamelyik babzsákfejlesztő és az idealista menedzsere azzal villogtak a befektetőknek, hogy írtak egy új böngészőt, és bele egy új videokodeket, fele annyi idő alatt, mint korábban bárki. A társadalom meg fizeti villanyszámlában, működőképesen kidobott gépekben, környezetszennyezésben.

Szerintem ez nem baj.

Szerintem meg baj, mert valahol meg kéne húzni egy egészséges határt. Például nem minden jöttment webökröt hagyni JS-t fejleszteni bloated framework-ben, aminek a lefuttatására annyi számítási kapacitás kell, mint amennyi pár évtizede még csak egy szuperszámítógépnek volt. Az, hogy egy otthoni gép ezt pár másodperc alatt megoldja, nem mentség. Megoldhatná századmásodpercek alatt is, ha figyeltek volna az optimalizációra. Pláne, a modern processzorok elég széles tartományban tudnak skálázódni az áramfelvétel terén, tehát az erőforráspazarlás elfogyasztott (elpazarolt) elektromos áramként is megjelenik és ha százmillió ember használja az adott szoftverterméket, akkor százmilliószor több energia lesz elpazarolva.

Az AMD le is hagyta az Intelt, nem véletlenül.

Aminek az egyszerű oka az, hogy az AMD tudott X év kuss után innovációval előrukkolni, legalább saját magához képest. Az Intel pedig az 1-2. generáció óta képtelen.

A Linux desktop éve is eljön majd egyszer.

Nem mostanában, amíg a Red Hat uralja ezt a szegmenst, addig biztos nem. Pláne nem, amíg a "Linux is not about choice" irányvonalat erősítik és a felhasználói szabadságot tiporják. A felhasználói szabadság, a széleskörű konfigurálhatóság egy jó érv lenne a desktop Linux mellett, mint ahogy régen is ez volt az egyik legjobb érv mellette az után, hogy ingyenes. A Red Hat viszont a felhasználói szabadság ellen dolgozik és tiporja azt lábbal. A desktop Linux hamarosan már csak egy végtelenül buta, tapicskoló felületű Windows-Android utánzat lesz, Windows-os és Android-os alkalmazások nélkül.

A böngésző helyett is lesz majd egy jobban átgondolt platform.

Egyelőre nem efelé haladunk, sőt mindenben az ellenkezőjét csináljuk.

Ha nincs, írj egyet.

Ja, aztán tiltsanak ki mindenkit a Facebookról a Youtuberól, aki alternatív klienseket használ, pereljenek be az elmaradt reklámbevétel miatt és dobhassam ki a kukába az egészet. Láttunk már ilyen sikersztorit, nem egyet.

A Commodore előttre gondoltam, amikor még csak valamilyen printer volt az output.

A hw teljesítményét ma is ki lehet használni, nem tiltja semmi. Ki is használják pl játékok, videószerkesztők, egyéb sebességre fejlesztett eszközök (design for performance). Emellett persze futnak ugyanúgy a lassabb cuccok is, amiket inkább a fejlesztés költségére optimalizáltak.
Én inkább a lehetőséget látom ezekben, sok bloat miatt egyre jobb hardverekre lesz igény, ezért ezek egyre olcsóbbak lesznek, viszont a jól megírt dolgok gyorsabban fognak futni. Vagy teljesen új lehetőségeket is hoznak, pl 20 éve senki se gondolta, hogy gpun fog neurális hálókat tanítani.

Ugyanazon videó lejátszásához nagy valószínűséggel ugyanaz a c/asm library, vagy már cpuba/gpuba integrált dekóder lesz 10 év múlva is. Hacsak nem írják át a c libet rustra vagy valami fenszibb nyelvre. Háromszor csak nem lesz lassabb :)

Egyéni szinten inkább pl a lakásod/házad energiafelhasználásának javításával lehet sokkal kevesebb energiát fogyasztani, nem a facebookos másodperc lecsökkentésével.

Nem kliensre gondoltam, hanem egész videómegosztóra, állítólag a Youtube lassú :P

A hw teljesítményét ma is ki lehet használni, nem tiltja semmi.

A lényeg: minél optimálisabban kihasználni. Ami jelenleg az lenne, hogy minél kevesebb energiát kelljen elfogyasztania a processzornak, minél kevésbé melegedjen és öregedjen ezáltal, így minél tovább tarthasson. Ez lenne a felhasználó érdeke, bár egyesek biztos szeretik kidobálni a gépüket.

Én inkább a lehetőséget látom ezekben, sok bloat miatt egyre jobb hardverekre lesz igény, ezért ezek egyre olcsóbbak lesznek, viszont a jól megírt dolgok gyorsabban fognak futni.

Addig lehetnek egyre olcsóbbak, amíg lesz elég kínai rabszolga, aki olcsón legyártja őket és kibányássza a nyersanyagokat. Mondanom sem kell, hogy ennek örülni nagyjából olyan, mint az atomkatasztrófáknak, bár biztos, hogy Fukushima idején is voltak páran, akik örültek, mert sok mérőműszert eladhattak. Így teremti meg a kapitalizmus a káronszerzést és láttat lehetőséget önmagunk és a környezetünk elpusztításában. Büszke lehetsz magadra.

Ugyanazon videó lejátszásához nagy valószínűséggel ugyanaz a c/asm library, vagy már cpuba/gpuba integrált dekóder lesz 10 év múlva

Nem, 10 év múlva ott lesz a Google 10. dekóder-idealizmusa, miszerint "túl milliárdosak vagyunk ahhoz, hogy kifizessük a H.264 után a licencdíjakat, inkább írjunk sajátot", "jaj a VP8 nem sikerült annyira jól, írjunk VP9-et", "jaj a VP9 sem sikerült annyira jól, csináljunk AV1-et". Jelenleg ott tartunk, hogy szarrá kell kiegészítőzni egy Chrome-ot ahhoz, hogy H.264-ben jöjjön le a videósáv és ha szerencséd van azt tudja valami hardveresen dekódolni. Mert a VP9 és egyéb idealizmusokhoz csak Kaby Lake-től elérhető hardveres dekóder. Az AV1-hez meg még egyáltalán nem.

Ha szigorúan CPU-dekódolást nézünk, akkor ma egy videólejátszás egy böngészőben 2x-3x annyi CPU-t használ el, mint egy natív videolejátszóban. Azt én értem, hogy ugyanaz a libx264 és libvpx van mögötte, mint amivel a VLC is dekódol, viszont afölött meg minden más erőforráspocsékolóbb, bloatabb, gányabb, tákoltabb. Ezért is fordulhat elő, hogy egy Youtube-ról letöltött Full HD 60 FPS H.264 videót a 2007-ben vett AMD Turion 64-es laptopom is le tud játszani 70% CPU-ból, miközben böngészőben ugyanez a videó akadozik. Igen, nem csak Windows XP-n, ahol soha nem volt értelmes hardvergyorsítás, hanem Windows 7-en, ahol állítólag van. Ja nincs, mert elfelejtették megírni a régi videokártyámhoz, így jártam, vennem kéne új gépet, termelnem kéne az elektronikai hulladékot, mint minden normális™ ember. A Google pedig túl milliárdos ahhoz, hogy épkézláb API-t vagy felületet használjon videorenderelésre pl. overlay, sync, vmr9, akármi, a saját bloat szarkupaca (2D Canvas) helyett. Linuxon is ugyanez a helyzet, ott is mindkét mag 100% CPU, videó akadozik, az erőforrás nagy részét az Xorg és a chromium zabálják el. Érdekes, egy VLC-vel ott is képes jól menni, bár több CPU-t zabál, mint Windows XP-n.

Egyéni szinten inkább pl a lakásod/házad energiafelhasználásának javításával lehet sokkal kevesebb energiát fogyasztani, nem a facebookos másodperc lecsökkentésével.

Ezzel tisztában vagyok és teszek is érte. A Facebook-os másodperc nekem egy személyben sokkal jobban kiábrándító, mint környezetszennyező. Mondjuk úgy, az egész IT szakma egyik nagy szégyene. Ha viszont felszorzod a Facebook-felhasználók számával, akkor sokkal inkább környezetszennyező, mint kiábrándító.

Nem kliensre gondoltam, hanem egész videómegosztóra, állítólag a Youtube lassú :P

A Youtube webes felülete lassú, nem "a Youtube". A Youtube H.264, VP9, AAC és OPUS streameket küld, amiket le lehetne játszni natív lejátszóval is, böngésző helyett. Ehhez kéne kliens.

Macen minimális a különbség videó lejátszásnál. Linuxon fura számomra a nagy különbséged, de ott a forrás meg a profilerek, szüntesd meg a bloat dolgokat :) Firefoxszal is lassú?

A Facebook az egy olyan cég ami mások magánéletéből él, nem is lehet nem kiábrándító.

Ne Intelhez mérd, pont ez az, hogy AMD-hez kell mérni. Ott nem 30% növekedés jön ki. Nagyon helyes, hogy Torvalds upgrade-elt, nem is értem, hogy miért várt vele ennyit. Már jó 1-2 éve megléphette volna. Ezeket a sok magos, sok szálas, sok cache-es Ryzeneket szinte neki találták ki, ilyen nagyobb kódok kipörgetésére. Ezért nem kell az adott márka fanboyának lenni.

Azt se felejtsd el, hogy a procik nem 10× annyiba kerülnek, anno egy P3, P4, korai genes i5 is, amihez most méregetsz, nagyon drága volt. Ez a technológia sajátja, hogy a legjobb hardverek eleinte prémiumként jönnek ki, prémium áron.

Sőt, régen még drágábbak is voltak a hardverek, mert épp úgy 250-2000 dollárt kóstált, 1000-2000 dollár között a csúcs CPU-k, de akkor egy USD többet ért, mint ma!

A Linux kernel meg ilyen. Monolitikus, sok millió kódsor, nagy komplexitás. Még így is gyorsabban fut, mint a Windows kernelek, azoknak látnád a forráskódját, be is fosnál, szó szerint. Természetesen átlag disztróban nem fordítanak mindent bele a kernelbe, meg egy csomó minden modulokba is ki van szervezve, és nem tölti be, ha nincs hozzá hardver.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

"nem is értem, hogy miért várt vele ennyit. Már jó 1-2 éve megléphette volna"

Igen, ez valószínűleg szimbolikus lépés volt. Tavaly ősszel az Open Source Summit-on nagyon kifakadt az Intel-re, és GKH is egy komplett előadást szentelt az Intel processzorhibák bemutatásának.

Ha szimbolikus, ha nem, a helyében én már a Ryzen 1xxx-eknél megléptem volna ezt. Neki akár egy 64 mag 128 szálas EPYC Rome is belefért volna, mert 1) nem minimálbérből él, igen jól meg van fizetve, 2) támogató cégek fizetik neki, 3) vagy számlával le tudja írni az adójából mint munkaeszközt. Plusz 4) még az sem lehetetlen, hogy egy ilyen EPYC-es gépet akár az AMD ingyen biztosított volna neki, marketing/PR alapon, mert ez nekik is jó reklám, hogy a fő kernelfejlesztő is AMD alapokon tolja. Bár ez a 3970X is elég kickass proci, lehet ehhez képest úgy ítélte, hogy az EPYC Rome nem éri meg a felárat, meg a spéci foglalatot, hardvert, extra fogyasztást. Bár annak annyiból jobban örültem volna, ha mégis EPYC proci mellett dönt, hogy ha a saját gépén reszelgeti, tesztelgeti, lehet a kernel és az ütemezők jobban skálázódnának több magra/szálra.

Az is kár, hogy mostanában nem nagyon hallunk Torvaldsról részleteket, milyen gépet, milyen disztrót, milyen grafikus felületet és workflow-t használ. Utoljára akkor hallottunk ilyenről, mikor a Macbook Air-jét vette, meg akkor írta utoljára azt is, hogy még mindig Fedora Gnome-ot használ, már nem is emlékszem milyen text editorral, de sok évvel ezelőtt volt az is.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Igazából a mai alkalmazásokban az implementáció a bloat. Nem azért, mert nem optimalizálják ki ASM-ben, hanem indokolatlanul elszabadult a kódbázis mérete.

Ezt akkor tapasztalod meg, mikor pl. Gentoo-t használsz, és sok órán keresztül forgat olyan csomagokat, amik egyenként 1-2 giga forráskódméretűek, és iszonyat soká fordulnak le, ilyen qt4, qt5, llvm, firefox, chrome, glibc se rövidke, meg egy csomó ilyen, és ezek nagy része csak alap libek, emellett még a ráépülőket is le kell fordítani. Nem az, hogy nincs kioptimalizálva, meg nem ASM, hanem ilyen több millió kódsoros, spagettikódos, agilis-szarbilis hozzáállású ömlesztvény az egész, ami akkorára dagadt, hogy csak robot látja át, meg MI, ember már épp ésszel nem fogja fel, hogy mi miért van benne. Az egész egy átláthatatlan káosz, és olyan gigantikus méretű, hogy a Linux kernel kódbázisa elbújik, eltörpül mellette. És ez nem csak Linuxon van így a Qt5-tel meg társaival, hanem Windowson még inkább. Ha nem hiszed el, dobj fel egy Gentoo-t, komplett nagyobb DE-vel, böngészővel, az agyad le fogja dobni a szíjat, mikor már 2-3. napja is kód fordul, mert azon az AMD-s laptopcsodádon minimum lesz annyi.

Ezért van az, hogy mikor elindítasz egy GUI-t, akkor 500-1000 MB között van a memóriafoglalás, mert ez a sok hatalmas bloat hegyekben fut egymás mellett. Én ezért használok javában egyszerű, terminálos/CLI alkalmazásokat, minimalista tiling ablakkezelőt. Sokkal gyorsabb, kisebb, kevesebb erőforrás kell neki, kevesebb függőség, gyorsabban frissül, mivel szög egyszerű, kevesebb dolog törhet el benne frissítéskor, gyorsabb-könnyebb forráskódból kipörgetni is.

Bár sajnos már a terminálos alkalmazások sem a régiek. Pl. nemrég próbáltam Void Linuxon SageMath matekszoftvert lefordítani, mivel ott a bináris tárolókban nincs benne. Akkora 1-2 gigás forráskódbázis, hogy gyengébb gépeken 1-2 napig is fordulhat, de gyorsabb, combosabb, modernebb gépeken is elég sok órát igénybe vesz. És itt egy terminálos matekprogramról beszélünk, igaz nagyon sok modul van benne, főleg C++, Python, Fortran, meg egyebek, rengeteg, de akkor is overkill méret ez ma már, kezelhetetlen.

Ezeket ha normálisan megírnák, átlátható kóddal, az egész mindenféle optimalizáció nélkül, simán magas szintű nyelvben írva negyed annyi erőforrás foglalna minimum. Mikor ilyen kezelhetetlenre dagad egy kód, akkor inkább jobb újraírni, rendbe tenni. És nem azért, hogy itt a HUP-on két megmondóembernek a 100 éves gépe is futtassa, hanem hogy a fejlesztők is átlássák, kezelni tudják normálisan, hogy a bugokat, egyebeket normálisan javítani tudják benne, könnyebben, gyorsabban fordul nekik is a kód.

Ez ugyanolyan lustaság most a fejlesztők részéről, mint mikor ilyen cégeknél szerverekhez évekig nem nyúlnak hozzá, nem frissítik, mert megy, nem mernek hozzányúlni, mert jajj, eltörik, mi lesz akkor. A végén meg ott állnak egy teljesen elavult rendszerrel, ami időzített bomba, hogy mikor nyomják fel, mikor rohad le, és ki fogja azt rendbehozni. Na, ugyanez van itt a kódokkal is, már azt se látják át mi van a forráskódban, mi micsoda, inkább benne hagyják, mert biztos csinál valamit alapon ne nyúljunk hozzá.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

A VW kifejezetten csalasi szandekkal irta meg ugy a firmware-t, hogy felismerje, ha a kibocsatast tesztelik, es olyankor kedvezobb ertekeket mutasson. Ez eleg nehezen vedheto. (mas kerdes, hogy erre eleve a sotetzoldek miatt volt szukseg)

A processzoroknal meg a branch predictiont szurtak el. Ami mar vagy 20 eve a procik resze, mert ezzel lehet tenylegesen gyorsitani a programfutast, es korabban senkinek nem jutott eszebe, hogy ennek lehet ilyen mellekhatasa. Ezert volt az, hogy gyakorlatilag a mikrokontroller szint (ahol mas szempontok szamitanak) felett minden architekturan volt hasonlo gond, es ezek kozul sokban ki is lehetett hasznalni. Teljesen uj tamadasi mod volt. Es nem trukkoztek, nem csaltak (legalabbis ezzel biztos nem).

A geppark egysegesiteset pont igy szoktak csinalni, ahogy irtad. Van parhuzamosan 3-4 geptipus, kulonbozo fazisokban. A legregebbit selejtezik (megvehetik a dolgozok, eladjak hasznalt gepnek, ritkan vegzi kukaban), ahelyett vesznek uj tipust, a tobbi marad. Ha van valakinek valami kulon igenye, akkor adnak csak egyedi gepet. Igy a karbantartasi igenyt eleg jol lehet kezelni.

Az olvashato kod sokszor sebessegben is jobb. Az asm betetek meg a hordozhatosagot fogjak vissza (van, ami elfutna egy raspberryn, most tegyenek ala egy 10-100x annyit fogyaszto gepet, csak mert x86-tol fugg?). Szerencsere nem jellemzo zart kodnal sem (legalabbis amivel dolgom volt).

Az MFC mar akkor is gaz volt, amikor megalkottak, rengeteg hibaja van. GDI-k szama globalisan limitalva van, ezeket nem kezeli rendesen magatol. A Qt teljesen jo, kenyelmesen hasznalhato, platformfuggetlen, van mindenfele OS-es es nyelven bindingja, korrekt tervezot adnak hozza, ki lehet egesziteni sajat dolgokkal. Persze ha akkor inditod el az elso Qt-s alkalmazast, akkor be kell tolteni elobb. Qt-n nem fordul elo olyan, hogy ne tudj megjeleniteni egy widgetet, csak mert egy masik alkalmazas tul sokat hasznal. MFC-nel ez problema (ha nem hiszed, probald ki, fejlesztettem ilyet), nem veletlenul nem hasznaljak mar winen sem csak ahol nehezebb lenne ujra megirni mindent.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Ezzel azért vitatkoznék. Az open-source egyik átka pont az, hogy inkább a szép, olvasható kódra mennek, a teljesítményoptimalizáció rovására. A zárt kódban előfordulnak olvashatatlan, esetenként gányolt részek, assembly betétetk, amik adott esetben optimálisabbak, mintha clean code idealizmussal készültek volna.

Forrás? :) Minden értelmes helyen a clean code az alap és majd ott megy a gányolás, ahol muszáj, mert lassú. Assembly betétek meg... Minek? Egyrészt bármely mai átlag C fordító jobb kódot fordít egy normálisan megírt C kódból is, mint a fejlesztők 99,9%-a, másrészt az ilyen jellegű optimalizációk általában vagy a cache lokalitásra játszanak vagy valami olyan matekolás, amiből sok van. Láttam már C# kódot is mikrooptimalizálva az alapján, hogy a CPU kevesebb cache misst csináljon, még csak unsafe sem kellett hozzá, nem, hogy assemblyvel való tákolás.

Ami a masik iranyba billenti a merleget, az az, hogy fejleszteni jobb buli, mint tesztelni, igy aki onkenteskedik, inkabb koddal szall be, a bugok meg nem derulnek ki.

Tapasztalataim szerint ami tudja javítani jelentősen a kódminőséget és a bugokat csökkenteni az a code review és az automatizált tesztek. Kézzel tesztelni egy one-shoot dolog, arra jövő héten már senki nem fog ránézni. Persze, ehhez úgy is kell megírni a kódot, hogy minél kisebb, egyszerűbb tesztelhető rész legyen (unit teszt) és úgy is kell megalkotni a rendszert, hogy azt egyszerű is legyen integrációs tesztelni. Persze, ez sem csodaszer, csak egy módszer, hogy jobb legyen a termék.

Igen, ezek valoban segitenek. Viszont kis csapatban/hobbi projectnel kevesbe jellemzoek. (jo, irhatsz akar magadnak is tesztet, de ha ugyanaz a logikaja, mint a tesztelt kodnak, azert nem az igazi)

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

Ha már logika van a tesztben, akkor az régen rossz :)

Tapasztalataim szerint legjobb teszt az, amiben 3 dolog van: input, a tesztelt rész meghívása, meg az elvárt kimenettel való összehasonlítás. Picit munkás, mert néha sok a copy-paste a tesztadat _statikus_ leírására, de ebben van a legkevesebb hibalehetőség.

Nem uzleti logika, hanem emberi!

Egyszeru pelda, odaadok neked egy matekpeldat, hogy szamold ki, aztan programozd le, hogy parameteresen mas kezdeti ertekekkel is meg lehessen hivni. Megteszed, de valahol a szamolas meneteben valamit benezel, emiatt a tesztadatod es kodod is ugyanazt a logikai hibat fogja tartalmazni. Megvezet a korabbi gondolatmeneted. Ha a ketto kozul az egyiket rabiztad volna a Belara, o vagy jol csinalja, vagy valami teljesen mas helyen nezi be. Kis csapatnak az a hatranya, hogy nincs benne Bela.

Persze van, hogy ez a problema trivialisan megoldhato (van elerheto tesztadat, vagy nagyon egyszeru), ott nem gond.

When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

követendő példa lenne, hogy a fejlesztők régebbi, lassabb gépeken dolgozzanak

Hát igen. Pl. amikor Poettering első kérdése a journal-lekérés (a jelek szerint évek óta megoldatlan) lassúságával kapcsolatban, hogy ez HDD-n vagy SSD-n jelentkezik-e. Emlékeim szerint a readaheadet is mintha azért dobták(?) volna, mert  "a systemd-fejlesztők már SSD-t használnak". Vagy amikor rákerestem, hogy mi is az az apt-daily cucc, ami a bootidőmet jelentősen növeli. Valaki kérte a Debian-maintainert/-fejlesztőt, hogy ugyan állítsák már ezt át alapból úgy, hogy ne lassítsa az indulást, amire az volt a válasz, hogy nyilván az illető HDD-t használ, ha az a pár másodperc is számít neki, úgyhogy váltson SSD-re. Ha a pofa aranyból volna...

> Amúgy ez gáz, hogy még mindig emailben küldözgetik a patch-eket

Mi is ezt használjuk és szeréntem a legjobb rendszer kód review-ra amit eddigi karrierem alapján használtunk. Kollégáim egy csoportja kiharcolta, hogy párhuzamosan legyen Github Pull Request is, ami szerintem egy pocsék kód review eszköz, számomra szinte használhatatlan.

 

> és egy erre való rendszer helyett a saját (adott esetben lassú) gépükön fordítanak.

Miért is kéne más gépen fordítani? Ma már bőven elérhetőek olyan képességű processzorok asztali gépekhez amikkel élhető idő alatt lefordulnak komolyabb C és C++ projektek. Mért futtassak valamit a felhőbe amikor helyben is megtehetem?

:wq

milyen specialis codereviewet hasznaltok? amivel en GH-n talalkoztam az kimerult az "ezt szar, ird ujra", "ezt X helyett inkabb nevezzuk Y-nek", "miert igy csinaltad?" commentekben. raadasul helyben lehet valaszolni ra, es ha en kodomat neztek at, egybol latom hogy mire irtak commentet, akar a 3. uzenetvaltas utan is.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Semmi különleges codereview-t nem csinálunk. Minden patch-nek megvizsgáljuk a motivációját (tényleg kell ez a változás), a designját, teljesítményre való hatását, helyességet, olvashatóságot, és -- messze a legfontosabb --, hogy helyesen van-e használva a whitespace. Szerintem ez a standard codereview. A GH annyi a baj, hogy egyfelől nagyon le van butítva: pl a hozzászólások nincsenek szálakba rendezve (mint pl itt a HUP-on), szóval ha nem csak 1-2 válasz van valamire akkor hamar olvashatatlan lesz. Másfelől csak egyféle workflow-al működik jól: ha nem érdekel a git history-d és minden review commentet külön commitokba orvosolsz. Ha force push-olod az új verziót (ahogy mi csináljuk) akkor hamar szétesik az egész beszélgetés folyamat.

És persze van egy csomó idegesítő apróság: a commitok dátum szerint vannak rendezve, nem természetes sorrendbe. Az emal értesitések teljesen hasznavehetetlenek, mivel nincs szövegkörnyezet bennük, illetve nem lehet emailbe válaszolni rájuk (az emailben küldött választ a PR-hez csatolja, nem a hozzászóláshoz amire válaszolsz).

:wq

Nem a fordítási idővel szokott a probléma lenni, hanem a test suite futtatási idejével. Pl. fordítási idő 2-3 perc, teljes test suite (unit + integration + e2e) meg 20-30 perc. Miért pazaroljam a saját gépem erőforrásait erre, ha a CI rendszer is meg tudja ezt tenni, ráadásul gyorsabban. Ezért jellemzően csak unit teszteket futtatok lokálisan, azokat is inkább csak arra amit módosítottam. Nyilván olyat nem commitolok ami nem megy át a minimális code checkeken (syntax, lint, stb.), de ha véletlenül mégis azt a CI szintén megfogja.

Van kernel CI,
meglepo, de CI is tud e-mail-t olvasni es kuldeni ..

A fontosabb maintereknek is van jopar toolja,
hogy ertelemesen kezelje a bejovo patcheket.

A rendszer hatranya es elonye, hogy
minden fo maintaner maga csinaja maganak azt a toolt,
amit mas kozosegben egy kozponti rendszer/team dologa.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Szerkesztve: 2020. 05. 25., h - 10:15

Ez az Intel → AMD valtas es a "haromszor gyorsabb lett" azert meg fog vezetni par embert. Gondolom egy N eves Intel CPU-t cserelt le egy uj AMD-re, szoval nem az van, hogy az Intel CPU-k ma ugy altalaban 3-szor lasabbak lennenek. (Lehet az AMD gyorsabb, csak ez nem derul ki, nem irja milyen Intel CPU-rol valtott.)

Szerintem mindenkinek van ennyi esze, mint neked. Úgy értem, azok közt, akik tudják mi a Linux kernel, a fordítás, a allmodconfig. A "mindenkibe" itt nem tartoznak bele a mezítlábas, analfabéta eritreaiak, és ózdi kisebbségiek.

trey @ gépház

nem 80 éves nyuggerek olvassák a twittereit szerintem.

 

Jelentse ez a twitter azt, hogy Linus új gépet vett, ami most AMD-s, 16 magos 32 szálas, és most ez 3x gyorsabb, mint a régi Inteles.

 

Nem írta, hogy az AMD 3x gyorsabb, mint az Intel :)

Nem irta, sot, az egesz valtas egy mellekszal volt a bejelentesben, de ide mar atjott ez a reszlet hirkent is, kicsit leegyszerusitve, hogy "15 év után dobta az Intel CPU-t és AMD (...) váltott. A váltással az "allmodconfig" tesztfordításai háromszor gyorsabban futnak le". Lesznek akik nem olvasnak ennel tovabb, hidd el.

Ez igaz, de az is, hogy most az AMD eléggé meglepte az Intelt.

A Zen széria iszonyatosan jó lett, mind teljesítményben, mind fogyasztásban odaver az Intelnek. Mintha azt olvastam volna, hogy IPC-ben némileg gyengébb, de a magok száma ezt bőven ellensúlyozza.

Hogy a gyártástechnológiának ehhez mennyi köze van, azt nem tudom, de az Intel csak tavaly szeptemberben jelent meg 10 nm-en, míg az AMD már (TSMC által) júliusban kijött a 7 nm-es Zen2-vel. Előtte kb. ember emlékezet óta az Intelnél volt a vezető gyártástechnológia.

Nem teljesen vilagos, hogy az AMD N darab magja ugyanazt jelenti-e, mint az Intel N darab magja.

Volt valami meg a 2-es szeria eseten, hogy az AMD magok kicsit ugy viselkednek, ahogy az Intel eseten a tobb processzor. Ott pedig ugye nagyon nem volt mindegy, hogy hova van bekotve a pl a 2x100Gbps halokartya, es hol fut az applikacio. Nem tudom, hogy ez a dolog all-e meg a legujabb szeriakra.

Ha csak a proci dolgozik, akkor persze minden szep es jo, de nem mindig felhotlen a boldogsag...

kotekedjek?:)

a 2x100Gbps halokartya sehova nem lehet "bekotve" Intelnel, mert a PCI-e v3 x16 nem eleg gyors csak az egyik porthoz, igy a hivatalos ajanlas az, hogy 2x50-en hasznalja az ember ha nem akar backpressuret.

amire gondolsz az a NUMA vs UMA, ez igaz, de ez Intelnel is gond.

A publikusan elerheto megoldasoknal jelenleg meg talan , de nem ez a lenyeg.

Hanem az, hogy az 2xN magos SMP-nel eleg vilagos volt, hogy az nem egy 2N magos rendszer. Az AMD-nel arrol nem nagyon beszelgetunk, hogy ott egy tokon belul hogyan is nez ez ki. Amig a PI-t szamolgatjuk, addig nem igazan tema, de amint NIC-et, diszket, video processzort vagy egyeb erdekesebb celhardvert kell kezelni, rogton kiutkozik. Nagyon nem mindegy, hogy a tokon belul hogy is nez ki az interconnect...

Nem követed akkor elég hosszú ideje ezt a témakört. :D 2018-ban jelezte, hogy gondolkodik a váltáson AMD-re és akkor a 2990WX volt tervben. A processzor, amit lecserélt egy i7 6700K.

"That said, ridiculously scalable or not, those Phoronix numbers do look good on Linux. It’s been a long time since I used an AMD system for my personal work (way back in the good old Opteron/K10 days – I despised all the nasty split-cpu AMD Bulldozer+ cores), but I’m seriously considering upgrading to an AMD system, and the new threadrippers would really fit my load.

During the merge window (like now), I spend a fair amount of time double-checking my merges by doing builds before pushing out, and my old i7-6700K is showing its age, with the kernel having grown, and meltdown slowing things down.

My main worry is noise. I’m not sure I want to deal with the blower required for a 180W+ CPU.”

Vicces, hogy végül egy 280W-os CPU mellett tette le a voksát.

Ahhoz már valószínűleg vízhűtés kell. Mondjuk 32 mag az mégis csak elég sok.

Tavaly, amikor az i9-9900K gépemet raktuk össze az egyik szempont az volt, hogy halk léghűtéses gép legyen. Már akkoriban is voltak erősebb procik, de kb. 8 magnál volt a 100W-os határ, amit még halk ventillátorral lehet hűteni. Ha az i9-9900K-hoz hasonlítjuk, akkor a 280W nem is olyan sok, mert 4-szer annyi mag csak 3-szor annyit fogyaszt.

Az régen volt. Linus tech tips csatornán láttam egy tesztet (nem Torvlads, ha valakinek nem világos :D), a jó léghűtések leverték a vízhűtések, mind hangerő, mind hőmérséklet tekintetében.

A hőcső annyira jól elviszi a hőt arról a kis felületről, amennyire a víz úgy tűnik nem tudja.

Meg persze a 280 W az a peak load, idle-nél messze nem lesz ekkora fogyasztás. Az a 20 mp-et amíg fordít, azt meg kibírja :)

Úgy tudom már egyik sem úgy értelmezi.

Régen én is arra emlékszem, hogy az AMD azt adta meg, ami max. kihajtás mellett leadott teljesítmény volt. Ma már azt adja megy, hogy erre van tervezve a tok (hasonlóan, mint az Intel), aztán ha túlléped, akkor elkezd visszavenni az órajelből.

Nem igazán értem, hogy mi a gond! Ha 64 maggal 80k körüli eredményt ér el egy 3990X, akkor a 28 magos Xeon 39k nem olyan rossz.

Akkora teljesítménybeli különbség szinte biztos nincs a Matisse és Cascade Lake cuccok között, hogy a 16 magos Ryzen legyen azonos szinten egy 28 magos Xeon processzorral. Kernelfordítási feladatokban 2019 elején az Intel még tudta tartani a tempót kisebb magszám mellett is.

Ennyi magszámhoz ez a fogyasztás fajlagosan nem olyan sok. Az intel pedig valótlanul alacsony számokat ad meg TDP-re, és évek óta tartó bűvészkedéssel leplezik hosszú cikkekben, h. terhelés alatt a papíron 100-120W CPU is hát bizony tényleg benyeli akár a 240W-ot is. Viszont azok közel sincsenek ott teljesítményben -még így sem- egy ilyen threadripper-hez.

Ugye megvan, hogy az intel potom 400W-os 56 magos cuccokat küldött harcba ellenük nemrég? :) Szal ezt a sütővasazást felejteni kéne, különösen a 10. generációs Core prociknál, mert bizony a desktopk procikhoz a 125W-os "TDP" mellé PL1 és PL2 nevén igen érdekes fogyasztási adatok kerültek be.

Csak azért gondoltam, hogy választ adhat, mert szerintem ez a kommentje első sorban azoknak szólhatott, akik bombázták javaslatokkal. A szomszéd Mari néni biztos nem fog rohanni a sarki boltba egy $1900 árazású processzorért csak amiatt, mert Linus 3x gyorsabban fordít az új gépén.

Nagyon jók az új Ryzen-ek (3000-es széria), ugyan nem Threadripper-t használok, "csak" egy 8 magos 3800X-et, de az is bitanggyors. Mondjuk árnyalja a témát, h. 15 éve volt utóljára asztali gépem, ami akkor szintén AMD volt Athlon XP 2000+ azóta kb. csak Core2 duo, és i5 mobil laptop-szériás gépeim voltak. Azok után persze h. felüdülés ha van teljesítmény, és nem csak 1 mp-ig tudja azt a 3,5Ghz-et. Utána meg visszaesik 1Ghz-re és throttling-ol az 5 mm vastag laptop ház megolvadásának határán, űrrakéta felszállást imitáló ventillátorzaj mellett.

Mondjuk olcsóbbnak, nem olcsóbb. Kb. most kerül annyiba, mint az i9-9900K egy éve. Viszont másfélszer gyorsabb, és kevesebbet fogyaszt. Csorgatom is a nyálam.

Kb. 10 évig semmilyen fejlődés nem volt procik terén. Most 1 év alatt hirtelen annyit gyorsultak a procik, mint előtte 10 év alatt. Igaz, hogy ez csak a magok számának növekedése miatt van, de amire én használom a gépet (Yocto), ahhoz pont jó a sok egyforma mag.

600 darab mátyásért már lehet is gyors az a cpu.

earth is the lunatic asylum of the milky way

Ezek azért ilyen drágák, mert hasonló árú Xeon-okkal versenyeznek. 60000 CPU Mark környékén már nincs Xeon, tehát az AMD megteheti, hogy ugyanannyiért adja azeket a procikat, mint amennyibe a lassabb Intel kerül.

Talán emiatt lehet, hogy Linus pocija ár/érték arányban eléggé hátul van(33.1 pont/$), a fönt említett 3900x pedig eléggé elől (78.7 pont/$).

Hogy az Epyc-ek miért kerülnek duplaannyiba, mint a jóval gyorsabb 3990X, azt nem tudom. Viszont az Intel is megkülönbözteti az asztali és a szerver pocikat. Technikailag csak annyi a különbség, hogy a szerverprocihoz több RAM-ot lehet tenni, és emiatt más a vevőkör.

Mi, már mi lenne a vicc? A neten azt írják, hogy évi 10 milcsit keres dollárban, ami szerintem erős túlzás, legyünk marha pesszimisták, legyen csak 100 ezer dollár, ami havi 8333. Ez csak magánfizetése, amit a kernelfejlesztésért kap. A gép költségét egészben vagy részben le tudja írni adóból (ha ügyes, talán még áfát is visszaigényel meg ilyesmi), de lehet támogatók is fizetik neki, megint részben-egészben.

USÁ-ban menő fejlesztőnek egy 2000-4000 dolláros gépfrissítés (ha semmit nem téritenek neki vissza, és kisker áron kell vegye áfával, mindennel) nem egy nagy tétel, egy-két hónap alatt kitermeli az árát, és használni fogja jó pár évig. Bőven megtérül neki, telik neki rá, meg tudja oldani. Már amiatt megéri neki, hogy egy ilyen gépen kb. 30 mp. körül fordul le egy teljes kernel clean make-kel, emiatt pedig egy csomó ideje felszabadul, gyorsul a fejlesztés, már ez a kényelem megér neki egy rakat pénzt, mert az ideje, szabadideje bőven többen ér pár ezer dollárnál.

A 600K sokszor még magánembereknek sem sok, látok ennél durvább gépeket overclocker és csúcsgamer közösségekben is, ahol pedig tényleg úgy égetik el rá a pénzt, hogy csak hobbi, nem termeli ki az árát. Még ilyen extrém overclock, csúcsgamer szintig sem kell elmenni, sok átlagember megveszi a 4 milliós Macbookot is, szemrebbenés nélkül. Emlékszem te is valamelyik topikban írtad a csillagászati árú karórád, pedig az nem is munkaeszköz, sok hasznossága nincs, és mégis olyan mértékű összeget tettél bele, hogy az a legtöbb átlag embernek felfoghatatlan.

YouTube-on van egy linuxos redneck jenki csóka, DistroTube, főállásban nyomja a videókészítést, nem is gazdag (pár hónappal ezelőttig egy boltban dolgozott közel minimálbérért), most cserélte le a 12 magos Threadripper 1920X + 32 GB RAM-os, kb 1+ éve 2000 dollárért vett gépét egy még nem tudni hány magos AMD EPYC + 64 GB RAM kombóra, feltehetőleg nem volt filléres (csak azért hogy Arch + dwm, terminális alkalmazások, OBS 1080p, KDEnlive 1080p-t csináljon rajta, semmi extra). Egyszerű YouTuber, nem is nagy nézettségű csatorna, épp hogy megél belőle, de mégis ilyen gépen nyomja + Radeon VII, 3 monitor, 400 dolláros Ergodox billentyűzet, 600 dolláros hangfelszerelés, méregdrága kamerák. Pedig ő anyagilag sehol sincs Torvaldshoz képest, ilyen mellette eltörpülő Average Joe, de már meglép ilyeneket, mert egy részét YouTube fizeti, másik részét adóból írja, jön be neki fizetés YouTube-ból, Patreon támogatók, kitermeli. Pedig nincs rá szüksége, mert ugyanezt a kaliberű munkát Luke Smith lenyomja egy szál, kukából guberált Thinkpad X220-szal, amit néha egy dokkra köt, meg egy 100 dolláros Blue Yeti mikrofon, az egész setupja nincs 300 dollár, és ezt is évekkel ezelőtt szerezte be, és használja, amíg ki nem rohad a keze közül.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Trey apó beelőzött ?, pedig ez nagy hír, éppen be akartam küldeni.

ha csak 3x gyorsabban fut le a forditas, akkor elég lett volna egy 3950X, saccper az is hozott volna ennyit.

HUP te Zsiga !

Igen, valószínű bottleneckbe fut, mert a Linux kernel kódbázisa nem párhuzamosítható annyira, vannak korlátok, amikor hiába lenne még extra mag/szál, a gcc/make nem tud már rá másra nem dependelő job-ot dedikálni, vagy mert a többi jobb dependel, és előbb a dependenciákat fordítja, vagy elfogytak a job-ok. Ezért sose lesz fordításkor a skálázódás lineáris.

De! Annyiból van értelme a 3970X-nek, hogy ha a fordítás sacckábé nem is lesz rajta már gyorsabb, míg pörög a kód, a háttérben dolgozva viszont több erőforrása marad Torvaldsnak máson dolgozni, lesz a rendszerben háttértartalék. Meg a kernelkód is egyre nagyobbra hízik az éves során, meg talán, hogy most már ilyen badass procija van, megoldják, hogy jobban skálázódjon a fordítás, úgyhogy a jövőben lehet tényleg többet nyer egy 3970X-szel.

Nem hinném, hogy az árkülönbség földhöz vágta.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

linuxhoz hardvert tudni kell venni... pár éve nem vett volna semmi pénzért sem AMD-t. Változik a világ.

robyboy