Többé nem tesz elérhetővé a kernel.org bzip2 tömörített fájlokat

Kernel

A kernel.org adminisztrátorai bejelentették, hogy a mostantól újabb .tar.bz2 fájlokat már nem adnak az archívumhoz, de ezzel együtt azt is közölték, hogy a már meglevő .tar.bz2 fájlok továbbra is elérhetők maradnak. A jövőben a Linux kernel új forráskód-csomagjait a "klasszikus" .tar.gz és az "új" .tar.xz formákban lehet majd letölteni.

Részletek a bejelentésben.

( uid_7086 | 2013. 12. 28., szo – 21:25 )

Kicsit le vagyok maradva: ebben mi a jó? Eleve a kétféle tömörítést sem igazán értem a mai háttértár méretek és hálózati sebességek mellett (miért nem volt elég a gzip?), de mi volt a gond a bzip2-vel?

Lehet, hogy az angolom kevés, de én csak annyit értek belőle, hogy ezentúl .xz lesz .bzip2 helyett, mert a két, gzipnél jobban tömörítő formátumot nem akarják párhuzamosan fenntartani. Ez OK, ezt értettem elsőre is.
Ami engem zavar, hogy minek egyáltalán a .bz2/.xz? Mai sávszélességek mellett tényleg van még jelentősége annak a pár megabájtnak? (utolsó kernelverziónál ~40MB eltérés van a .gz és az .xz között)

Vagy csak én vagyok túlságosan hozzászokva a digihez és sok helyen csak mobilnet van? (mert gyanítom, a 56kbps modemek kora már mindenhol lejárt)

The goal is to provide two formats --
.tar.gz for fast decompression and maximum compatibility between various platforms,
and .tar.xz for smaller tarballs (in order to save bandwidth for people downloading releases).

linux-3.13-rc5.tar.bz2 22-Dec-2013 21:17 88M
linux-3.13-rc5.tar.gz 22-Dec-2013 21:17 111M
linux-3.13-rc5.tar.xz 22-Dec-2013 21:17 74M

33% kulonbseg azert lenyeges.
--
Live free, or I f'ing kill you.

A paq-nál a kitömörítés is ugyanolyan lassú (ha jól emlékszem az évekkel ezelőtt olvasottakra, illetve akkor ki is próbáltam), mint a betömörítés, így a felhasználók számára nem praktikus.

Nem egyértelmű, hogy melyik a legjobb kompromisszum:

  • A tömörítés egyszeri költség a szolgáltatónak. Mind a villanyszámlája (CPU), mind a valós ideje elhanyagolható.
  • A letöltés N-szer kerül pénzbe a szolgáltatónak (forgalom).
  • A letöltés minden fogyasztót megvárakoztat.
  • A kitömörítés minden fogyasztót megvárakoztat.
  • A kitömörítéshez szükséges program esetleg nem mindenhol elérhető.
  • A kitömörítés memóriaigénye esetleg nem mindenhol praktikus.

A gzip, pigz, bzip2, pbzip2/lbzip2, xz, pxz, paq mind máshol helyezkednek el:

  • gzip: nagy tömörített méret, maximális elérhetőség, kicsi memóriaigény, elfogadható kitömörítési sebesség.
  • pigz: nagy tömörített méret, pocsék elérhetőség, kicsi memóriaigény, szuper kitömörítési sebesség.
  • bzip2: közepes tömörített méret, nagyon jó elérhetőség, nagyobb, de még mindig kicsi memóriaigény, borzasztó kitömörítési sebesség.
  • pbzip2/lbzip2: közepes tömörített méret, pocsék elérhetőség, potenciálisan óriási memóriaigény, jó kitömörítési sebesség.
  • xz: jó tömörített méret, viszonylag jó elérhetőség, nagy memóriaigény, jó kitömörítési sebesség.
  • pxz: jó tömörített méret, pocsék elérhetőség, nagy memória- / buffer cache igény, szuper kitömörítési sebesség.
  • paq: szuper tömörített méret, pocsék elérhetőség, memóriaigényét nem ismerem, borzalmas kitömörítési sebesség.

A szolgáltató nyilván kiköti a minimum "viszonylag jó elérhetőséget", amivel csak a gzip, bzip2, xz marad játékban. A gzip a "compat" megoldás, az "xz" pedig a "feature" megoldás. A bzip2-nek egyszerűen nincs use case-e, mióta az xz elérhetősége megjavult. (A pbzip2 / lbzip2 kliensoldali teljesítmény szempontjából indokolná a bz2 file-okat, de ezeknek az elterjedtsége minimális.)

Szerintem érdekes példa még a yum Presto plugin-ja (deltarpm). Képes a frissítéskor letöltendő adatmennyiséget akár a harmadára is csökkenteni. A "normál" RPM-ek helyi újraépítése azonban (amely ráadásul csak egy szálon fut) döbbenetesen sokáig tart. Az elterjedt lakossági netes csomagoknál felhasználóként simán megéri (valós időben) a nagyobb (kész) RPM-eket letölteni. Ez viszont jóval többe kerül a mirror-ok üzemeltetőinek (magasabb forgalom).

A fenti természetesen csak vélemény.

+1
A sok buzgómócsing nem tud elhallgatni. Biztosan ki fognak dolgozni még újabb tömörítési eljárásokat, és bevezetik azokat is. :) Szerintem ez az egyszerűsítás már azokat készítí elő. ;)

Komolyra fordítva azt kellene látni, hogy a tömörítés mértéke egy bizonyos érték fölött már mindegy. Sőt, 20 éve is az volt. A lényeg az adatszállítás, amelyhez a szabványos formátum a fontos. A gzip a túlburjánzott pc (dos) tömörítő programok mellett is egy hatékony "továbbfejlesztése" az addig szabványos, de cpu és tömörítés szempontjából gyenge compress-nek.
Szóval ehhez és sok egyéb feladathoz pontosan elegendő a gzip és az UStar.
( rfc1951: DEFLATE Compressed Data Format Specification 1.3, rfc1952: GZIP file format specification, POSIX.1-2001 UStar )

Fogalmazzunk úgy: mióta a népszerűbb disztribúciók maguk frissítik a kerneleket, nekem úgy tűnik, nem igazán jellemző, hogy a felhasználók/rendszergazdák a kernel.org-ról/tükrökről szereznék be a kernelt.
Persze nincs rálátásom, hogy mekkora forgalmat bonyolítanak a kernel.org és mirrorjai, de úgy képzelem, pusztán a kernelek miatt nem túl nagyot.

Tudom, Amerika a korlátlan lehetőségek hazája, de szerintem a szolgáltatójának sem mindegy, hogy mennyi adat megy át rajta. Ezzel meg csökkenthetik. Vagy pont emelik, mert még inkább gzipet töltenek, de ez már más szál. :-) Az is lehet néztek statisztikákat és az alapján döntöttek. És az is lehet, nem csak Amerikára gondoltak. Van még a világon szerintem forgalomkorlátos net.

Nem tudom ez az oldal milyen konstrukcióban van ott, de szerintem minden szolgáltató, bármilyen vastag vonalai is vannak, szereti ha kevesebb anyag megy át, így később telítődik a vonala, aminek a bővítéséhez már pénz kell. És gondolom nem is kevés azon a szinten.

Engem például jobban zavar, hogy a DragonFlyBSD dolgai bzip2-vel vannak fönt, így az rsync-elés deltája elég szar hatásfokú lehet (sosem mértem le, csak tipp). ISO írás előtt kitömörítés, ami miatt bukom az eredetit, vagy lesz egy bzip2 és egy kitömörített verzió is.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

Kicsit off mar, de a digi-hez kapcsolodva: nem tudom milyen digi-hez vagy szokva, de az orszagban nagyon sok helyen a (lehet, hogy inkabb a nehany nagyvaros a kivetel mindenhol?) a digi altal nyujtott maximum a 8/2 (mindez 3500Ft/ho (igen, Budapesten +200Ft-ert 40/20...), es nem is terveznek bovitest). Nyilvan egy kernel eseten az a par 10 masodperc nem szamottevo, de mondom, nem az aktualis szalhoz kapcsolodoan irom.

/sza2

Névleg 20/10-es gyakorlatban volt már 20/30-as is :)
De öt éve még valahol 4 (de max. 8) Mbps körüli ADSL-em volt és már az is elfogadható volt pár száz megabájtos tételeknél.
Nem mondom, egy komplett Debian telepítő CD letöltésénél már morogtam, hogy sokáig tart. ;)

Túlságosan hozzá vagy szokva a Digihez. Nem mindenki él városban. És azt is vedd figyelembe, hogy Magyarország a világ top egyharmadában van a telekommunikációs lehetőségeket tekintve.
http://www.netindex.com/download/allcountries/
Itt konkrétan a 25-ikek vagyunk, 188-ból. Azaz rengeteg országban SOKKAL szarabb a nethozzáférés.

„Ami engem zavar, hogy minek egyáltalán a .bz2/.xz?”

Ha szerinted nincs értelme, akkor ne is vegyél tudomást róla. Ennek az eredménye az lesz, hogy eggyel kevesebb gondod lesz, kisimulnak a ráncaid, talán még boldogabb is leszel. És nem utolsó sorban, az ezen való töprengésre fordított időt más, hasznosabb dolgokra használhatod.

Más oldalról megvilágítva a dolgot: A világ nem körülöttünk forog. Bár divat panaszkodni, de az internetelérés átlagos sebességének szempontjából benne vagyunk az első tizenötben*. Ez persze nem boldogítja azt a magyart, akinek a lakóhelyén nincs normális sebességű elérés. Azonban a hír szempontjából ez lényegtelen. A világ nagyobb részén még sokkal kisebb sebességű az internetelérés, és azokon a helyeken még számít az a 40 MB-tal kisebb adatmennyiség.

*: Sőt a dollárban számolt szolgáltatási díjak szempontjából is a legolcsóbbak között vagyunk. Bár itt az a „bibi”, hogy sokkal rosszabb helyezést érünk el, ha az átlagfizetésekhez hasonlítjuk az árakat .

----- 

(&%;_98\<|{3W10Tut,P0/on&Jkj"Fg}|B/!~}|{z(8qv55sr1C/n--k**;gfe$$5a!BB]\.-

Röviden: Felhasználó oldalról a bzip2-nek semmi előnye nincs az xz-vel szemben. Utóbbi erősebben tömörít, és gyorsabban kibontható. (Tömörítés ugyan lassabb, de azt csak egyszer kell elvégezni a kernel.org karbantartóinak.)

+ nincs a világon mindenütt szupergyors internet.

Felhasználó oldalról a bzip2-nek semmi előnye nincs az xz-vel szemben. Utóbbi erősebben tömörít, és gyorsabban kibontható.

Így van, ha a standard bzip2 utility-ről beszélünk.

Ha a felhasználó lbzip2-vel tömörít ki, és van egy sokmagos gépe, akkor valós időben (akár lényegesen is) jobban járhat, mint az xz kicsomagolásával. Ugyanakkor a bz2 letöltése még mindig tovább tart, illetve többe kerül a szolgáltatónak.

Szeretem amikor az emberek azzal jönnek, hogy megvan az erőforrásunk, úgyhogy nyugodtan pocsékoljuk. Nem mindenhol van 120 meg 240 megabites internetelérés, amikor párszáz megákra órákat kell várni, és esetleg fontos, akkor nem mindegy, hogy spórolsz-e tíz percet tíz megával...

( log69 | 2013. 12. 28., szo – 23:15 )

Nézegetem a pixz és pxz párhuzamosított verzióit az xz-nek, és érdekes módon pl. a pxz csak egy ideig futatt több szálat, illetve mindegyik csak 1 szálon tömörít 9-es szinttel.

Amúgy tényleg jó azért, nálam egy 30 MB-os SQL dumpot a bzip 5.7 MB helyett (-9 szint) 1.1-re lenyomott -9e kapcsolóval.

Tesztelem, de tényleg rohadt sok CPU-t eszik az összes lzma-as cucc, xz meg amit most nézegettem, az lrzip. A saját mentésem a te lbzip2 progiddal 8 perc (levelek, fejlesztés és minden egybe tarolva és pipe-olva lbzip2-n keresztül). pxz-vel több mint 1 óra volt, és 6 GB helyett 5.6 lett (notim meg szinte elfüstöl a melegtől). Úgy látom, hogy nem éri meg pxz a gyakorlatban számomra.

(a) Az lbzip2 már nem az enyém :)

(b) ellenőrzés van mindig a backup befejezése előtt, ugye?

(c) Te nem terjesztési céllal tömörítesz (1 tömörítéshez milliós nagyságrendű letöltés és kitömörítés), hanem mentéshez (1 tömörítés, 1 kitömörítés ellenőrzési céllal, és 0 vagy 1 kitömörítés visszaállítási céllal). Erre a célra az lbzip2 valószínűleg tényleg jobb. (Még fokozhatnád a sebességet (a tömörítési arány kárára) a pigz-vel.)

( Mico v | 2013. 12. 29., v – 02:22 )

Nem értem ezeket az újfajta kompressziókat, hogy mire jók. Amikor a munkámban jelentősége van az ilyeneknek, az pl. egy döntés, hogy mentésnél a drót előtt tömörítek, vagy megoldja a tape drive. Ha összességében több adat át tud menni előtömörítve a dróton, akkor az a jó. Itt számít az algoritmus sebessége. Vagy, ha átküldök egy tar stream-et ssh-n valahova. Tömörítsek, mivel tömörítsek, milyen SSH crypto legyen? Sokszor ezen múlik, hogy valami egy, vagy 3 nap alatt fejeződik be. Na bármi ilyesmire tökéletesen alkalmatlanok ezek a csoda cuccok. A teljesítményt visszalövik a középkorba. Egy telepítőt pl. tegnap úgy alakult, hogy itthonról kellett a gagyi netemről felmásolni, igénybe vettem az xz-t, mert tudtam, hogy sokáig fog tartani, és mert hype. Na mit veszek észre? A sávszélesség nincs kihasználva, csak a procit tekeri.. ctrl-c, gzip. És akkor mit szóljon az, akinek nem jutott i7 proci se. Komolyan nem értem, mire jó, ez valami új zöld dolog? Le lehet majd tölteni open source source tar-okat jobban betömörítve, és majd el is magyarázza valaki, hogy neki számít, mert lassú a netje, mintha nem 1000x annyit töltene le filmből és egyéb tartalomból úgyis.

+1

Sőt, pár hónapja talán épp itt a HUP-on volt valami diskurzus egy statisztika/teszt vagy micsoda kapcsán ha jól emlékszem, ahol alaposan kielemezgették ezeket az algoritmusokat, s kiderült hogy a hatékonyság rengeteg mindentől függ, ráadásul az se mindegy a kicsomagolás meddig fog tartani ugyebár...
-------------
Honlapom: http://parancssor.info Könyvem a VIM-ről
Lenovo ThinkPad T530, Core I7, 16 GB RAM, 500 GB HDD
=== Disztróm: KISS-Linux, saját készítésű, "from scratch"! ===

Csak továbbgondolta a kérdéskört.

Azt mondd meg b+viktor, Mico mivel bántott meg téged hogy ilyen ocsmány, aljas, ordenáré és fertelmesen viszolyogtató stílusban kellett beszólnod neki, hogy "egyéni nyomorodnak"?

Nem lehetett volna úgy fogalmaznod ehelyett, hogy mondjuk "az egyéni gondjainak", vagy hogy "a személyes problémáidnak"?

Miért kell mindjárt a legislegdurvább, legsértőbb, legmegalázóbb szókapcsolatot választani?

Nincs szebb talán az egyéni szókészletedben? Miféle bunkó környezetben szocializálódtál te, hogy mindenkivel szemben ezt a stílust alkalmazod, és rögvest, azonnal? Neked talán olyan illemtanárod volt gyermekkorodban, aki rendszeresen bántalmazta az időseket, és leköpdöste szórakozásból a nála gyengébbeket és a nőket?
-------------
Honlapom: http://parancssor.info Könyvem a VIM-ről
Lenovo ThinkPad T530, Core I7, 16 GB RAM, 500 GB HDD
=== Disztróm: KISS-Linux, saját készítésű, "from scratch"! ===

Mert ha semmibe veszik a felhasználók igényét, akkor nem akarnak majd tőlük semmit. Választanak más megoldást vagy nem frissítik a már meglévő rendszerüket.
Nekem sincs erős vasam, így azért sokat számít, hogy mit hogyan oldanak meg. Nagyon sok olyan linux felhasználó van, akiknek nincs erős vasuk vagy gyors netjük. 10 éves laptopot használok, de van aki 5 évente fejleszti csak a gépét.

Ennek semmi köze a felhasználó igényéhez. A kolléga arról panaszkodik, hogy a saját adatai szalagra tömörítésénél (meg egyéb, totál "hétköznapi" problémáknál) milyen szar neki az xz, ami tökéletesen irreleváns a kernel forráskódja szempontjából. Ezen kívül, mint már mondtam, elérhető gzip-ben is. Harmadik, akinek szar gépe van, az nem fordít kernelt forrásból, így az egész hajcihő kurvára nem érinti.

Oke, akkor most forditsd le rajta a 3.12-es kernel-t. Meg a mai world-ot. Mert ugye most arrol szol a szal, nem arrol, hogy 1848-ban mit csinaltal.

Aki pedig mazochista, az nem fog azon rinyalni, hogy lassu, mert kvazi pont arra gerjed, hogy ezer ev alatt keszul el azzal, amivel 1 ora alatt is lehetne (binarisbol vs forrasbol telepites).

Hát ha így nézzük a dolgokat, akkor ebből nekem az következik, hogy rohadt jól fizet az a trollkodás, amit te itt elkövetsz. Különben nem tennéd. Vagy az is lehet, hogy önmagadnál elfogadod azt is, hogy szimplán csak kedvtelésből csinálsz valamit - másnak viszont ezt a luxust nem engeded meg.

Hat egy forumnak poppet mas celja van, mint egy kernelnek, szoval a tarsas erintkezest egy lapon emliteni a make output orakon at bamulasaval szamomra kicsit eros (biztos nem vagyok elegge nolifer hozza).

De oke, akkor az en hibam, hogy barmi ertelmet probaltam keresni az ervelesben, es ti egyszeruen csak elveztek kernelt forgatni, oszt' ugorgyunk.

Elég néhány nap alatt is hozzá. Nem tudom, hogy honnan veszed azt, hogy évekre van szükség. A főiskolán pont tanítják azt, hogy hogyan kell a kernelt optimalizálni, fordítani. Egyszerűen kiveszed azokat a hardvertámogatásokat, amire nincs szükséged, amire meg csak néha, azokat berakod modulként. Azt hiszem a menuconfig az, ahol pontosan tudsz a menükben lépegetni, ki-bepipálni amire szükség van vagy nyomsz a modulba rakáshoz "m" gombot, ha jól emlékszem.

Nem, ezzel rengeteg újrafordítási időt lehetne megtakarítani.

Konkrétabban... Az egyik gépemen debian wheezy van. Mind a gyári kernel, mind a bpo kernel elcseszte a hangkártyám támogatását a squeeze-hez képest. Finoman kifejezve tajtékoztam, amikor a többi inkompatibilitás kifésülése után ezzel nem tudtam mit kezdeni. Úgyhogy váltottam az upstream 3.10.y ("stable") branch-re, amelyet rendszeresen frissítek és újrafordítok a Debian make-kpkg-jével. (Ezzel jól megy a hangkártya. Komolyan, ez gabucino-díjas regresszió a debian 6 és 7 között.)

Nagyon úgy tűnik, hogy a make-kpkg nem tud (nem akar) inkrementálisan fordítani (*), tehát minden git pull után kb. két óra, mire újraküzdi az új deb-et nulláról. Ha hajlandó lennék egyszer rászánni magam, hogy a stock debian kernel configot hozzácsupaszítsam a gépemhez (agysejtjeim tömegét feláldozva), akkor a rendszeres újrafordítás lényegesen lerövidülne. Egyelőre az van, hogy hónapok óta nem vagyok hajlandó ránézni arra a menüre.

(*) corrections welcome

A főiskolán rosszul tanítják, illetve, gondolom azt is megtanítják, hogy a megoldás hatékonyságát mindig meg is kell mérni, számszerűsíteni, és ez alapján tudod, hogy optimalizációs céllal manapság nem éri meg ilyennel foglalkozni, csak ha valamilyen hardvereszköz vagy egyéb feature miatt a működéshez szükséges.

Nem vitatom hogy elméletileg igazad van. De azért a kép ennél kicsit árnyaltabb.

Mert ugye, talán tudsz róla te is (de ha nem, akkor elárulom most) hogy pár napja készültem el az LFS alapú úgymond „saját disztrómmal”. Na most az LFS esetén kénytelen voltam kernelt fordítani. Nem tudok róla, hogy lenne módszer rá, miként tehetek fel valamely általános célú, előre fordított bináris kernelt LFS-hez. Úgy értem, bizonyára megoldható lenne hogy valamely híresebb disztrónak letöltsem a megfelelő kernelcsomagját, mondjuk valami .deb-et vagy ilyesmit, azt kicsomagoljam és telepítsem valamiképp. Mély meggyőződésem, hogy ha igazán ezt venném a fejembe, meg tudnám csinálni. Ez azonban nemcsak ennyiből áll, mert ehhez pontosan tudnom kéne, hogy éppen melyik előfordított bináris kernel való a gépemre! De ezek amennyire tudom, nincsenek összegyűjtve egyetlen helyre, mint a források, rengetegféle van, disztrónként különbözők, mert egyik ilyen pöcsökkel patkolja a másik olyanokkal, és ezt fordít bele vagy azt, ezt rakja bele fixen és azt modulba a másik meg másképp, ráadásul külön tortúra kideríteni, egyáltalán pontosan miféle paramétereket is állítottak be a .config fájlba a fordításhoz!

Szóval ha minden kernel-releaseból lenne egyetlen honlapon összegyűjtve sok különböző bináris előfordítva, amiből lehetne válogatni, akkor azt mondom oké, megspórolhatnánk az egyéni fordítgatást, mert a további optimalizálás már ne éri meg. De így nem ez a helyzet.
-------------
Honlapom: http://parancssor.info Könyvem a VIM-ről
Lenovo ThinkPad T530, Core I7, 16 GB RAM, 500 GB HDD
=== Disztróm: KISS-Linux, saját készítésű, "from scratch"! ===

Bocs de az LFS-emben még nincs se Javascript se Adobe Flash player, emiatt nem tudom még megnézni a jótubus videlyókat. És ez valszeg rém sokáig így lesz, mert ezernyi dolgom van amit ennél messze fontosabbnak tartok megoldani.
-------------
Honlapom: http://parancssor.info Könyvem a VIM-ről
Lenovo ThinkPad T530, Core I7, 16 GB RAM, 500 GB HDD
=== Disztróm: KISS-Linux, saját készítésű, "from scratch"! ===

Van Firefoxom. Az általad fent írt linken azt írja ki, hogy támogatja a HTMLVideoElement és a WebM VP8 lejátszását. Be is állítottam a html5-öt alapértelmezésnek. De hiába, mert ahhoz a videóhoz akkor is Adobe Flash plélyer köll.

Bocs de nekem a dolog nem ér meg annyit, hogy csak emiatt feltegyek egy zárt forráskódú valamit, ráadásul azt is nagy szopás árán. Tapasztalatom szerint az efféle jótub videók engem csak egészen infinitezimális százalékban érdekelnek és szórakoztatnak, akkora kockázatot meg kész vagyok bevállalni hogy épp emiatt maradok le valami jóról.
-------------
Honlapom: http://parancssor.info Könyvem a VIM-ről
Lenovo ThinkPad T530, Core I7, 16 GB RAM, 500 GB HDD
=== Disztróm: KISS-Linux, saját készítésű, "from scratch"! ===

Nekem nincs olyanom hogy vlc. Nekem Mplayerem van. Meglehetősen konzervatív ember vagyok.

Momentán még Javam sincs telepítve. Mondjuk azt majd valamikor azért fogok, de az is hátul van a prioritási listámon.
-------------
Honlapom: http://parancssor.info Könyvem a VIM-ről
Lenovo ThinkPad T530, Core I7, 16 GB RAM, 500 GB HDD
=== Disztróm: KISS-Linux, saját készítésű, "from scratch"! ===

Ma mar gyakorlatilag minden modul, ami lehet, a disztrok keszitoi nem hulyek, barmennyire is szeretik itt sokan okosabbnak erezni magukat. Es igen, optimalizalhatsz a sajat CPU-dhoz, amivel nyerhetsz mondjuk 1% CPU idot.

AKkor mar csak azt kene kiszamolnod, hogy lehetseges-e, hogy ez az 1% kiteszi-e par het alatt (a kovetkezo kernel release-ig) azt az idot, amit egyetlen kernel leforgatasaval elpocsoltel a disztro csomagjanak telepitese helyett. Es termeszetesen vedd meg bele a kepletbe azt is, hogy csak a CPU-limites feladatok eseten szamolhatod a nyereseget.

Meg a használati idő is fontos lehet, pl napi 10 óra használat.
Bár ha az ember nem frissíti olyan gyakran a kerneljét, még azzal javíthat a számokon. Tegyük fel, hogy van egy régi gépe, laptopja és nincs nagyon szüksége új kernelre. Sőt elvileg egy régebbi kernel verziót is használhat. A jó kérdés az, hogy mennyi idő után kezd el az ember anyázni, hogy egy programhoz újabb kernelre van szüksége.

Az az 1% azt csak hasra ütés szerűen gondoltad vagy valahol tényleg kb ennyit lehet nyerni?
Egyébként ha tényleg csak hosszú idő után kell frissítenie a kernelt, akkor mivel összidő alatt kevesebbet eszik a proci, picit az energiafogyasztás is kevesebb lehet.
Persze ez már nagyon is túlzásnak tűnhet, hiszen a sok rászánt idővel valóban nem sokat nyerünk a kernel fordításával. Azt hiszem a régebbi gépeknél jobban megérte ezt is megcsinálni.

Alapvetoen egy kerneltol nem kene csodakat varni. Ma mar azzal se tudsz szamottevo javulast elerni, ha a teljes userspace-t is raoptimalizalod a CPU-dra, ami egy nagyragrenddel tobb erofeszites, mint egyetlen kernel leforgatasa.

Szoval nyugodtan hidd el, hacsak nem renderfarm-ot uzemeltetsz, semmi kimutathato elonyod nem fog belole szarmazni, hogy a YouTube video nezese kozben 36 helyett 35% lesz a CPU load. De ha nem hiszed el, akkor teszteld es merd le magad, aztan meglatod. Egyebkent a renderfarm eseteben is csak azert lesz elonyod, mert ott meg talan veszik is a faradsagot a proggerek, hogy hasznaljak a CPU kulonbozo extension-jeit, ami egy altalanos programrol nem igazan mondhato el.

Ez egy lehetséges felhasználási kör, de brutál memóriahasználata van a cuccnak és lassú. Ha csökkented a paramétereket, akkor csökken az előny is. Lassú alatt azt értem, hogy a MIPS médialejátszómon majd 2 perc kicsomagolni egy fájlt, ami gzip-ben 15 sec. Azt hiszem ez már túl lassú lenne, ha így bootolna.

Egyébként meg vegyen mindenki nagyobb hardvert :) Emlékszik valaki a STACKER.EXE -re?

Egy 4MB-os .xv tömörített kernel+rootfs kicsomagolása egy 400MHz-es ARM processzorral pár másodperc. Fordítás közben persze egy kicsit tovább tart az .xv tömörítése, de a kicsomagolás már sokkal gyorsabb mint a tömörítés.
Írtam is, hogy ne gigabájtos .arj fájlokhoz hasonlítsd.

Egy telepítőt pl. tegnap úgy alakult, hogy itthonról kellett a gagyi netemről felmásolni, igénybe vettem az xz-t, mert tudtam, hogy sokáig fog tartani, és mert hype. Na mit veszek észre? A sávszélesség nincs kihasználva, csak a procit tekeri.. ctrl-c, gzip

Attól, hogy a szűk keresztmetszet áttevődött a netedről a CPU-dra, a végeredmény még lehetett volna jobb. Példa: tegyük fel, hogy az "xz -9e" CPU igénye a "gzip -9"-ének a 30-szorosa, az xz-vel elérhető tömörítési ráta pedig cca. 3.3-szoros (ezeket nem annyira hasból mondom, most futtattam egy ad-hoc naplótömörítést). Azt is feltesszük (nyilván), hogy a tömörítés és a feltöltés párhuzamosan zajlik, megfelelő buffereléssel a kettő között, hogy a nagy blokkmérettel dolgozó tömörítő is jól át tudja lapolni a feltöltést. 


upload_time(compressor) ~= max { compression_time(compressor), data_size / compression_rate(compressor) / bandwidth}

Látható, hogy a sávszélességgel való osztás a kételemű halmaznak (amelyen a maximumot számoljuk) csak az egyik elemét befolyásolja. Így a sávszélességtől függően lehet az egyik vagy a másik megoldás jobb. Attól függően, hogy a halmaz melyik eleme bizonyul maximumnak, nevezhetjük a folyamatot CPU- vagy IO-bound-nak.

Konkrét példával, tegyük fel, hogy

  • a forrás mérete (data_size) 2GB
  • a gzip által elérhető tömörítési ráta 8.5, az xz-vel elérhetőé 28
  • a gzip-pel való tömörítés 90 másodpercet vesz igénybe, az xz-vel történő pedig 2700 másodpercet

upload_time(gzip) ~= max {   90s, 2GB /  8.5 / bandwidth }
upload_time(xz)   ~= max { 2700s, 2GB / 28   / bandwidth }

upload_time(gzip) ~= max {   90s, 246,724KB / bandwidth }
upload_time(xz)   ~= max { 2700s,  74,898KB / bandwidth }

bandwidth  upload_time(gzip)  upload_time(xz)  gzip limited by  xz limited by  winner
---------  -----------------  ---------------  ---------------  -------------  ------
 5000KB/s                90s            2700s  CPU              CPU            gzip
  500KB/s             ~ 493s            2700s  network          CPU            gzip
   50KB/s            ~ 4934s            2700s  network          CPU            xz

Az utolsó esetben (50KB/s feltöltési sebességgel számolva) az xz a nyertes, annak ellenére, hogy a gzip-hez képest a szűk keresztmetszet áttevődik a hálózatról a CPU-ra.

Teljesen igazad van, de sajnos a tömörítési ráta és az időigény előre nem tudható, az én adataimnál pl. messze nincs ekkora különbség a kompresszióban a két megoldás között, viszont a CPU használat aránya hasonló, így extrémebb esetben érné csak meg használni.

Erre van az eszed és az a képességed, hogy tudsz olvasni. Szerintem végtelen számú teszt létezik tömörítőkről. Azok alapján meg tudod határozni, hogy "realtime" tömörítéshez van-e értelme mondjuk xz-t használni. Feltételezem jellemzően "nincs értelme" lesz a megoldás, kivéve persze ha tied a világegyetem leggyorsabb gépe.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

( sigellef | 2013. 12. 30., h – 06:07 )

Szerintem az xz jó választás akármilyen forrás tömörítéséhez. A kérdés inkább az, hogy minek a gz (kernel)forrás tárolására xz mellé?
xz-nél a betömörítés tart jó sokáig, a kitömörítés nem sokkal több, mint a gz-nél. Egy forráscsomag betömörítése teljesen lényegtelen, hogy meddig tart, aki készíti annak ezt úgy is csak egyszer kell megtennie, amikor közreadja.
Egy kernel forráscsomag kitömörítésénél szintén nem számottevő dolog, hogy pl. 3 perc helyett 5 perc alatt fog kibontódni, itt a fordítás úgy is több órát vesz igénybe.
Jómagam minden csomag forrását, kész binárisát tar.xz-ben tárolom, így egy komplett Linux alaprendszerrel, desktoppal, szerverprogramokkal, kütyükkel ráfér egy DVD-re úgy, hogy az a forrást és a telepítendo csomagokat is tartalmazza.
Forrás kibontása / rendszertelepítés 25-30%-kal lassabb, de kit érdekel? Ritka művelet.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

( atomjani | 2013. 12. 30., h – 10:53 )

Úgy tudom, hogy például a Firefox is úgy csinálja, hogy csak azokat szedi le a böngésző frissítője, ami változott. Ha a kernel fájlja nem lenne becsomagolva, amit majd a memóriába kitömörít, akkor ez a megoldás jobb lenne. Mert mindenki leszedi a kernel verziójához való frissítést, amit a kernel könyvtárába kitömörít és felülírja a változott fájlokat és t9rli a szükségtelen fájlokat. Mondjuk egy scriptel ez egyszerűbb. Így a letölthető frissítő állományok általában kisebbek lennének.

Amit leírtál, majd a jövőben fogják feltalálni. Asszem verziókezelő rendszer lesz a neve.
BTW, anno betöltöttem az összes kernelt ágankénti bontásban egy CVS fába, a repót betömörítettem, és a végeredmény majdnem akkora volt, mint a legutolsó kernel tar.gz...
--
zsebHUP-ot használok!