Linux From Scratch 7.0

Linux

A Linux From Scratch (LFS) közösség nevében Bruce Dubbs ma bejelentette, hogy megjelent a Linux From Scratch 7.0 stabil kiadása. A Linux from Scratch egy "DIY" (Do It Yourself) Linux projekt, egy "lépésről lépésre" felhasználói útmutató, amely arról szól, hogy hogyan tudunk felépíteni egy komplett Linux rendszert egészen az alapoktól saját kezűleg. A 6.8-as kiadáshoz képest számos frissítést - Linux-3.0.4, GCC-4.6.1, Glibc-2.14.1 stb. - tartalmaz.

A nagyobb változások közt említhető, hogy a /run könyvtár - hasonlóan az Ubuntu-hoz - a root fájlrendszerre költözött. A /var/run és a /var/lock is ide linkelődik.

Az útmutató olvasható online, vagy letölthető egy 347 oldalas (~ 1,6M) PDF formájában innen.

( uzsolt v | 2011. 10. 29., szo – 13:28 )

Régi szép idők, mikor még volt időm ilyenekre... de jó is volt...

( vl v | 2011. 10. 29., szo – 16:46 )

Ennek az egésznek a gentoo kifejlődésével van még valami értelme?
Egy emerge --rsync, egy gentoo install howto, és ott van a leírás is, meg a sok kis fájlban a sok package előállításának mikéntje is.

A Gentoo install howto utat mutat, hogyan telepits Gentoo-t. Ez meg azt irja le, hogyan huzz fel egy Linux rendszert. Szamomra ennek van ertelme, masok szamara lehet, hogy nincs. Ha megkerdezel mondjuk egy hardcore Ubuntu felhasznalot, lehet hogy o is felrohog a Gentoo hallatan. Szamara annak nincs ertelme, hogy 1 millio szorgos kis legy, ugyanazokkal a USE flagekkel forditson forrasbol. De lehet, hogy egy elszant Greenpeace-es is csunyan nezne lol.

LFS-el egyet értek, Gentoo -0.5. Ugyanis van ahol nagyon megéri a fordítás, optimalizálás, stb. Pl az én munkámban a +5-10% sebességnövekedés is jól jön. Előfordul, hogy egyes programjaim desktop gépen sok sok napig (a rekord 17 nap) futnak, átlagban nem nagyon több ami elérhető gentoo-val 5-10%-nál, de volt péda hogy több mint 20%-ot nyertem egy bináris distrohoz (debian volt de szerintem nem ez a döntő) képest. De egy átlag usernek valóban mindegy, hogy 2, vagy 2,2 sec alatt indul el a firefox pl.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Mint ahogy igoor írta előttem én is azt mondom, hogy van értelme (LFS), mert rendszerépítésre tanít. A Gentoo """"haszonontalanságában"""" volt külön véleményünk. Abban én látok értelmet. Gyanítom hogy ő sem látja értelmetlennek, csak abban az értelemben nem lát benne értelmet hogy 100-ból 90-en pont ugyanazt az optimalizációt fordítják le maguknak, ráadásul ez 90%-ban egyezik egy rakat másik bináris distro-val. Szerintem emiatt nem lesz soha a Gentoo egy főáramlati linux terjesztés, mert pont ott van értelme, ha valamilyen módon külömbözőt akarsz építeni mint a főáramlat.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Ja ilyen munkam nekem is volt, de vicces a hozzaallas, hogy ilyenkor az egysegsugaru optimalizalok rogton ujraforditjak az egesz rendszert (termeszetesen -O10 flaggel, mert az meno). Holott ismert teny, hogy sok esetben pl az agressziv optimalizacios flag-ek az altalanos szoftverek eseteben akar teljesitmenycsokkenest is eredmenyezhetnek. Ahelyett mondjuk meg lehetne merni, hogy mi az az 1-2 csomag amit egyaltalan optimalizalni kell es akkor mar jo is. Nem vitatom, hogy neha nyernek a nepek a Gentoo hasznalataval par szazalekot, de szerintem irto pazarlo/nemhatekony/balfek hozzaallas egybol mindent ujraforditani....

Egyetértek. Igazság az, hogy nekem a Gentoo-használatnak részben tradícionális okai vannak. Nekem már a 64 bit előtt gond volt a 32-bit miatti memóriakorlát, azon felül numerikus matekkal foglalkozom, és ott is főként nagy számosságú rendszerek leírásával, valamit képelemzéssel. Ez utóbbit nem szeretem annyira, de ezt is kell csinálni. A képelemzés miatt állandóan különbözö kamera, capture card..... Hardvereket kellet folyton bepatkonom a rendszerbe. Emiatt egy forrás alapú distro sokkal kézenfekvőbb. Egyébként én sem értettem soha ezt az optimalizációs őrületet, nekem mindössze ennyi szerpel a gcc optimalizácónál.:
CFLAGS="-O2 -march=native -pipe"
CXXFLAGS="-O2 -march=native -pipe"
Azért mert a Gentoo dokumentációban mint legjobb kompromisszum van megjelölve. Egyébként Gcc-4.4 előtt -march=core2 volt.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

ez a gento -O666-os hulyeseg akkor lett volna igaz, ha a programok jellemzoen cpu intentizvek lennenek

emberk konkrétan egy olyan programot említett, ami 17 napig zabálja a CPU-ját... Ha 5-10% gyorsulást elér az -O kapcsoló és tsai masszírozásával, akkor: (1) az adódó plusz optimalizálás igenis jelentős, (2) másfél napot spórolhat vele valós időben, (3) nyilvánvaló, hogy a programja CPU-bound.

Illetve amint az SSD egy kicsit jobban elterjed, térjünk majd vissza erre a "CPU intenzívek lennének"-re. Ha egy program (vagy feldolgozás) futásidejéből most 900 rész random read és 100 rész CPU, akkor jelenleg IO-bound. Átrakva SSD-re a random read mondjuk lemegy 15 részre, kb. másfél nagyságrenddel (log10(900/15) = log10(60) ~= 1.8). Innentől a folyamat "zömében" CPU bound.

Akkor pedig 10%-ot megspórolva a CPU-n a teljes idő lemegy 100+15=115-ről 90+15=105-re, ami még mindig cca. 8.7%-os gyorsulás.

Mindez arra az esetre vonatkozik, amikor az IO nincs átfedve a CPU-val. Ha át van fedve, akkor az SSD-re áttérés (mivel az IO így már rövidebb ideig tart, mint a CPU) színtiszta nyereséggé teszi az optimalizálásból fakadó CPU megtakarítást.

Nem hiszem, hogy emberk "a Gentoo"-t futtatja 17 napig... Ha van egy saját speciális programja, amit hosszan futtat, akkor értem, hogy az optimalizáció jót tesz neki, de ahhoz minek Gentoo? Hol profitál abból, hogy az operációs rendszerének az 1%-ban futó része is optimalizált?

- Mit számít az, hogy a rendszer része? Attól még újra lehet fordítani, ha sebesség kell. Sőt egy bináris disztribúciónál kézenfekvő, hogy a saját optimalizált változatot a gyártó által szállított mellé lehet telepíteni, így nem kockáztatod meg azt, hogy a saját változatoddal hazavágod a rendszert.
- Ha valamit intenzíven használ az ember, akkor kifejezetten üdvös, ha megismeri, hogyan kell lefordítani, milyen opciók vannak, és a frissítésnél changelogot is néz, nem csak emerge worldöt futtat.

Persze, hogy megtehető minden, egy bin-distroval, csakúgy mint egy forrás alapúval. Lévén nyílt a kód. És nem igazán a sebességoptimalizáció nyomott a latba, azon felűl, hogy azt is megkapom.A Gentoo azért igazán jó, nekem, mert.:
1. Sokszor kellett "egzotikus hardwereket" bapatkolnom, és egy remekbeszabott csomagkezelővel könnyegén újra tudtam forgatni a kritikus libeket. sőt a genkernel-le nagyon könnyen tudok a kiépítettségnek megfelelő kernelt összerakni.
2. Munkám típusánál fogva mindíg a kor "izomgépeivel" dolgozom, így egy este alatt (szinte) mindíg komplett rendszerem van. DE-vel, opengl-el, stb...
3. Gyakran használok különböző fejlesztői libeket (opencv,fftw3,unicap,......) ezeket is gyakorta patkolnom kellett a fent említett hardware-k hez. Bár ehez kapom a patch-eket szerencsére nem nekem kell írni.
4. A legfontosabb érv, megszoktam, és szeretem. Szerintem a leg flexibilisebb kiadás, és amellett maximálisan optimalizálható. Elfogadom azon "felűlmulhatatlan" tulajdonságát is, hogy ha egy hiba van a rendszerben gyakorlatilag garantált, hogy nekem kell megjavítanom, mert ahány Gentoo annyi fajta, kis költői túlzásal.

Tömörn, hosszas mérlegelés után számomra még mindíg a legjobb döntés, ugyanis 8-10 órányi szívás után ezzel a rendszerrel tudok a leghatákonyabbban dolgozni. Ha valakinek más a megfelelő használja azt.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

"Attól még újra lehet fordítani, ha sebesség kell."

Ebben latod igazad van. Csak mondjuk egy libpng konyvtar eseteben erre epul mondjuk egy komplett Gnome/KDE kornyezet, es ha valami API/ABI valtozas van, azt lehet, hogy a disztro csomagjai lekovetik, de a te kezzel ganyolt forgatott csomagjaid mar nem. Ezert fontos az, hogy lehetoleg a disztro maga nyujtson tamogatast ezzel kapcsolatban, igy ha valami valtozas van, akkor se dol ossze a rendszered. Es a pelda nem legbol kapott, valoban volt mar jo par API valtozas a libpng konyvtarban.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Na igen. Ez az, ami egy binaris disztronal nem megteheto. Ott hiaba forgatod ujra a libpng-1.4.1-et, a libpng-1.4.2 megjelenesevel eltorik minden, es jobb esetben nem mennek fel a friss csomagok dependency nyuglodessel, rossz esetben felulvagodik az optimalizalt csomagod, a legrosszabb eset pedig, hogy felmennek a frissitesek, es lesz egy torott rendszered. Na ez az, amiert 5x at kell gondolni, hogy belevagjon-e az ember egy binaris disztro optimalizalasaba.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Jaj, ne mondd már! Nem kell semminek eltörnie. Ha a disztribútor szállít újabb verziót a libpng-ből, akkor a felülírja a disztribútor régi verzióját, és kész. Ha neked valamiből gyors kell, azért nem kell csesztetni az operációs rendszeredet, fordítasz egy saját optimalizált változatot a libpng-ből, ami szépen megfér a disztribúció által szállított mellett. A disztribúció csomagjai továbbra is a gyárit használják, de a te überoptimalizált programod pedig a te überoptimalizált libedet.

Ez meg azt irja le, hogyan huzz fel egy Linux rendszert.

A gentoo ebuildek is pont ezt írják le, gép által (is) értelmezhető módon...
Csak azt per package, per verzió frissen tartják (amikor éppen sikerül nekik).

A kérdés arra utalt: miben nyújt ez többet, mint ami a gentoo ebuildekből kinyerhető információhalmazban van.

Azt értem, hogy kézzel mennyivel nagyobb munka kiadni a tar xzf; ./configure; make; make install parancsokat 800 package-re, és ez a munka elvégzése után mennyivel jobban tudja az ember mellkasát dagasztani - volt idő, amikor nem volt gentoo, és én is így csináltam. Csak aztán az emberből elfogy az ifjonti hév :D

Van értelme.
Egy 'emerge --rsync', egy 'apt-get --dist-upgrade', 'pacman -Syu', stb. között mi a különbség egy sima (akár r>1) user számára? Az 'emerge --rsync' kva sokáig tart.
Attól, hogy az 'emerge --rsync' parancsot ki tudod adni, nem feltétlenül érted jobban a rendszer működését illetve a programfordulások mikéntjét.
Viszont ha te magad vagy kénytelen vagy ezeket megcsinálni, illetve automatizálni (ahogy valamennyire én megtettem), az már gííkebb :)
Ha pl. különféle linkelési problémákba ütközöl (egy libet frissítesz, nem oda linkelődik, stb.), és nincs egy kész recept, hogy mit kell csinálni ("futtasd le a 'kijavítom a hibát' parancsot és kész"), akkor kénytelen vagy kitalálni. És szerintem ez (mármint hogy tanulásra/problémamegoldásra késztet) az LFS egyik legnagyobb erőssége/előnye.

Attól, hogy az 'emerge --rsync' parancsot ki tudod adni, nem feltétlenül érted jobban a rendszer működését illetve a programfordulások mikéntjét.

Szerintem valamit félrenéztél. A parancs lefutása után kezdődik a programfordulások mikéntjének megnézése. Az emerge --rsync csak letölti a "leírásokat" a gépedre, amit utána böngészgethetsz. Ne keverd a apt-get meg a pacman parancsokkal, azok a telepítendő kódot állítják elő a gépeden.

És szerintem ez (mármint hogy tanulásra/problémamegoldásra késztet) az LFS egyik legnagyobb erőssége/előnye.

Na várjunk!
Én úgy vettem le, hogy ezeket a problémákat nem a tanulóval oldatja meg az LFS, hanem készen le van írva, hogy így meg így kell fordítani. Ha eltérsz a recepttől, kísérletezgetsz, akkor tanulni talán fogsz, de szopni is, és saját káron tanulás lesz az a tanulás - ezt meg bármilyen rendszerben gyakorolhatod :PP
Ha meg nem térsz el a recepttől, hanem szolgaian begépeled a leírás szerinti parancsokat, akkor meg az mennyiben lesz jobb, mint ha kiadnád a make/emerge/whatever parancsot, és a mások által készített gépi receptet a gép végrehajtja neked?

Na ezt a különbséget nem látom. Már persze az "ezt a rendszert én csináltam" c. virtuális feelingen túlmenően...

Szerintem valamit félrenéztél. A parancs lefutása után kezdődik a programfordulások mikéntjének megnézése. Az emerge --rsync csak letölti a "leírásokat" a gépedre, amit utána böngészgethetsz. Ne keverd a apt-get meg a pacman parancsokkal, azok a telepítendő kódot állítják elő a gépeden.
Oké, sose voltam gentoo-s. Akkor arra a parancsra gondolok, ami teljes upgrade-t csinál (valami world is van benne :)).

Én úgy vettem le, hogy ezeket a problémákat nem a tanulóval oldatja meg az LFS, hanem készen le van írva, hogy így meg így kell fordítani. Ha eltérsz a recepttől, kísérletezgetsz, akkor tanulni talán fogsz, de szopni is, és saját káron tanulás lesz az a tanulás - ezt meg bármilyen rendszerben gyakorolhatod :PP
Ha meg nem térsz el a recepttől, hanem szolgaian begépeled a leírás szerinti parancsokat, akkor meg az mennyiben lesz jobb, mint ha kiadnád a make/emerge/whatever parancsot, és a mások által készített gépi receptet a gép végrehajtja neked?
És neked elég az a néhány program, ami a (B)LFS-ben le van írva? :) Nem biztos, hogy pont az az ablakkezelő/DE kell neked, amiknek a fordítása le van írva, nem biztos, hogy pont az a böngésző, stb. És ezeknél jön elő az, hogy mit/hogy kell csinálni. Ha pl. az xfce ablakkezelőt akarod felrakni, akkor azt kénytelen vagy te magad megcsinálni, nem pedig néhány './configure && make && make install' -t végigcsinálni. Emlékeim szerint az Xfce fordítása eléggé mókás volt, a sorrendre nagyon figyelni kellett a függőségek miatt. Gentoo-ban meg gondolom valami 'emerge xfce-desktop'-szerű parancsot kiadsz, vársz egy "kicsit", és már meg is van :)

Na ezt a különbséget nem látom. Már persze az "ezt a rendszert én csináltam" c. virtuális feelingen túlmenően...
Azért valld csak be, sokkal menőbb egy ilyet mondani, hogy "ezt a rendszert én csináltam", mint hogy "felraktam egy gentoo-t" :) Azért nem volt az rossz érzés számomra, hogy a csomagkezelő szkriptjeim automatikusan letöltöttek mindent, adott szabályrendszer (amit én írtam, teszteltem, stb.) szerint lefordítja, telepíti, linkeli, stb.
Persze amint elfogy az "ifjonti hév" (előbb-utóbb ez történik), ráun az ember, és kész megoldásokat keres. De azért a tapasztalatai nem vesznek el, egy disztró sincs, ami tökéletes, és nincsenek benne hibák, amit kénytelen az ember saját maga megoldani. Ekkor lehet az ilyen tanulásnak hasznát venni, illetve ha esetleg valamelyik disztróban csomagolni akar...

Akkor próbálom érthetően megfogalmazni az eredeti kérdést (mert láthatóan nem arra született az előző irományod sem - és másnak is sikerült elkövetnie ezt):

mi van abban az LFS leírásban, amit a gentoo ebuildjeiben nem találsz meg?
mi az a többletinformáció, amitől ez több, hasznosabb lesz? mi az, ami miatt erre bárkinek igénye lehet, ha ugyanazt (vagy még több) információt megtalálhatnál a gentoo package adatbázisában?

Na megmondod, bár egyszerűen bele is nézhettél volna, és akkor meglátod.

Vannak az egyes fejezetek elején bevezető szekciók, ahol az ember számára szövegesen leírja, hogy mi fog most történni, mi az a fontos tudnivaló, amit tudni kell ahhoz, hogy megértsd, mire jók a következő buildek. Ráadásul a build utasítások után összefoglalja, hogy milyen fontos parancsok, illetve egyéb dolgok települnek az adott csomaggal, minek az adott csomag a rendszerbe.

Praktikusan semmivel sem több, mint egy ebuild.

Viszont amíg a gentoo ebuild-eket nem vagy köteles elolvasni, addig nem is biztos, hogy elolvasod, csak kiadod az "emerge foo" parancsot. Te pl. hány gentoo-ebuild-et "olvastál" el? Ha teszem azt, besz@rik az emerge/portage rendszer (pl. akármi miatt a python-telepítést/frissítést elszúrtad, mert ebuild-et szerkesztettél, és nem lett jó), akkor képes lennél-e kézzel telepíteni mondjuk a python-rendszert? Illetve melyik leírás alapján lenne könnyebb feltelepíteni: ebuild vagy BLFS alapján?

Míg LFS-ben kénytelen vagy elolvasni (hacsak nem századjára csinálod, és már kívülről fújod ;) ), lesz némi fogalmad arról, hogy mi az, ami történik (illetve történnie kellene). Találkoztam már olyan gentoo-használóval, akinek a "./configure && make && make install"-nál már a ./configure során keletkezett hibát nem vette észre, és nem értette. Míg LFS-essel még nem (bár azért az is igaz, hogy több gentoosról tudok, mint LFS-esről ;)).

Szóval nem az információ több/kevesebb, hanem az információ átadásának módja, és az ebből származó (várható) tudásnövekedés... Elismerem, amikor én még az LFS-t csinálgattam, sokszor néztem ebuild-eket is, spec-fájlokat, PKGBUILD-eket, hogy ötleteket merítsek illetve egy (fordítási, forráskód-beli vagy bármilyen) hibát meg tudjak oldani.

Találtam Gabucino blogján egy linket (--> lwn --> L.P. postja). Már most tudom, pedig még bele sem néztem a postba, hogy ez valami irtózatos baromság lesz; erre garancia a szerző.

... Bejött.

... A fedora-devel-en különösen egyetértek ezzel:

Any ordinary Fedora contributor with a similar proposal would have been "sent to hell".

Ezért nem (sem) vagyok hajlandó otthoni felhasználóként Fedora-t futtatni.

Igen, en is talalkoztam tobbfele ilyennel, es megmondom oszinten, csak szivtam vele. Inkabb azokat a konkret mappakat teszem kulon particiora a /var alatt, amik helyet foglalnak (/var/lib/mysql, /var/www, stb), mintsem a komplett /var-t. Ez reszben azert is jo, mert igy tobb fajlrendszer - kevesebb adatvesztes eset van (annak az eselye hogy ket fajlrendszer egyszerre serul meg sulyosan, valamivel kevesebb, mint egy nagynal). A tobbi mappa merete pedig sosem szokott szamottevo lenni egy jol karbantartott rendszernel (/var/cache megfelelo mappai automatikusan uritgetve, /var/tmp symlinkelve a /tmp -re, ami ugye automatikusan torolgetve van, meg ilyesmi).
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal