LFS építésből sokat lehet tanulni. Megismerhető általa egy GNU/Linux rendszer minden esszenciális eszköze, vagy pl. hogy hogyan működik a linkelés és az shared objectek keresése a futtatható binárishoz, mit érnek az optimalizált CFLAG-ek és LDFLAG-ek stb. Felmerülnek azok a problémák is, amelyeket a csomagkezelő és a ports-rendszerek oldanak meg a disztrókban, így jobban meg lehet ítélni, mennyire jól oldja meg egy-egy disztró ezeket a problémákat.
A könyv 6.3-as és development verzióját vegyesen használtam, az esszenciális eszközöknél (Linux, GLibC, GCC) maradtam a konzervatívabb verzióknál, az egyéb dolgoknál pedig leszedtem a legújabb verziókat. Első LFS építésnél nem ajánlják a könyvtől való eltérést, voltak is kisebb és nagyobb gondjaim belőle, de ezeket sikeresen megoldottam.
Az LFS mellett megcsináltam még a BLFS könyvből a PostLFS beállításokat is.
Minden nagyon szép és jó, gyorsan indul a rendszer, a GRUB-ban leütött ENTER-től 10s a login prompt, bár ebből csak az utolsó 3-4s az init folyamaté (sima SysV init, semmi függőségalapú párhuzamosított init), van szép színes konzolom mint amilyen a Gentooé, a rendszer egyszerű és átlátható.
Mivel csak tanulási célokra tettem fel, nem pedig azért, hogy lecseréljem az eddig használt rendszeremet LFS-re, így nem fogtam neki, hogy a BLFS-sel használható rendszert készítsek belőle, hanem gyönyörűen ezt is becsomagoltam:
43M lfs-6.3-tools.tar.bz2 # a toolchain, amiben chrootolva felépítettem a rendszert
87M lfs-base-system.tar.bz2 # maga a bootolható és működő LFS rendszer
74M lfs-kernel-tree.tar.bz2 # kernel source és build
201M lfs-sources.tar # a felhasznált upstream források és patchek
Lehet még beleolvasgatok az {A,C,H}LFS-be is, de azokat nem tervezem végigcsinálni.
- utpKabel blogja
- A hozzászóláshoz be kell jelentkezni
- 1959 megtekintés
Hozzászólások
És mit használsz?
Át tudnál térni egy LFS-re? Hogyan lehetne naprakészen tartani egy ilyen forrásalapú rendszert?
- A hozzászóláshoz be kell jelentkezni
És mit használsz?
Debian 4.0-t használok mindennapi teendőkre, de van egy 8GB-s partícióm, amin a mindenféle más disztrókat váltogatom kipróbálásra.
Át tudnál térni egy LFS-re? Hogyan lehetne naprakészen tartani egy ilyen forrásalapú rendszert?
Sok-sok fölösleges szopással. Először is már csak a csomagok frissítése miatt is fontos megoldani a programok eltávolítását.
Legtöbb programot ha úgy installálom, hogy
make DESTDIR=/ide_tedd install
akkor az /ide_tedd könyvtárba installálja, mint ha az lenne a gyökér. De van jó pár olyan program is, ahol a készítők nem tettek DESTDIR-t a Makefile-okba, ott kézzel kell ügyködni. Vannak más módok is csomagkészítésre, de mindnek megvannak a maga hátrányai. Meg ha rendezett csomagokat akarunk csinálni, akkor kézzel kell strippelni a binárisokat, meg tömöríteni a man és az info dokumentumokat.
Ez vonatkozik a csomagkezelésre. A másik dolog, hogy ha egy library-t frissítünk, lehet hogy újra kell fordítani az őt használó programokat is. Ezt a feladatot oldja meg Gentooban a revdep-rebuild.
Meg vannak olyan eszenciális csomagok (glibc, gcc, binutils), amelyek szinte minden más csomagra hatással vannak, így ha ezeknél major verziót frissítünk akkor újra kell (legalább is érdemes) fordítani az egész rendszert 0-ról.
Mondjuk az alap LFS építése valamilyen szinten automatizálva van, lásd ALFS.
Tök fölösleges mindenkinek ezzel szopni, elég ha a disztrókészítők szopnak fele, a felhasználó meg használja.
- A hozzászóláshoz be kell jelentkezni
Gondolom library-knél nem szoktak verziót ugrani csak hibajavítani, átlagos disztribúciókban.
Szerintem is felesleges pár másodperc előnyért napokig küzdeni.
A "Mítoszok és tények a Gentooról" írásodra kíváncsi leszek.
- A hozzászóláshoz be kell jelentkezni
Futtatni kellett volna regenworld nevűt...
Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش
- A hozzászóláshoz be kell jelentkezni
Kösz, majd ha legközelebb kell, akkor azt csinálom.
- A hozzászóláshoz be kell jelentkezni