Aki meg nem csinalt vegig egy LFS-t, az nem ember

Forras
Mekkora igazsag. A szambol vette ki a szot.
Oriasi +1.
A sorok iroja (is) egy isten.

( uzsolt v | 2016. 06. 06., h – 14:07 )

Ne terelj, mondd meg, de őszintén: ember vagyol-e?

( gelei v | 2016. 06. 06., h – 14:21 )

Kimaradt azért egy fontos rész a mondatból:

"Basically whoever calls himself an UNIX-whatever operator in any serious way and all the while have never created his own hand-built and customized LFS [...], is not even a human in my eyes."

Amúgy meg van a dologban némi igazság, még ha a stílus esetleg nem is tetszik valakinek: attól, hogy valaki apt-gettel fel tud telepíteni egy LAMP/LEMP stacket, még nem lesz az illető rendszergazda/üzemeltető/whatever.

s/UNIX/Linux a többi még akár helyes is lehet... Attól, hogy nulláról össze tud rakni egy SystemD-OS-felé haladó valamit, még nem lesz sokkal több, pláne a többi UNIX, vagy UNIX-szerű OS ismeretét tekintve :-P Tessen végigcsinálni három-négyféle hardveren, mondjuk 5-6 féle UNIX(-szerű) OS telepítését és adott célra való hangolását, és utána lehet szó arról, hogy vannak általános UNIX-os ismeretei/tapasztalatai :-P

( abalole | 2016. 06. 06., h – 15:14 )

Tok allat lenne egy olyan LAN-party, amin LFS versenyt rendeznek.
Szerintetek erdemes lenne-e idohatart szabni?
Mondjuk 24-36-48(?) ora utan kene megmutatni, hogy hova jutott a versenyzo.

binutils fordítása. Egyszerű kontrol-cé, kontrol-vé. A többi hasonlóan.

Az írónak (gondolom) nem azért lett egyre jobb, mert egyre ügyesebben és egyre gyorsabban adta ki a parancsokat. Hanem azért, mert egyre jobb dolgokat talált ki és valósított meg. Pl. a csomagkezelés terén, a (később) feltelepített csomagok fordítási opcióit tekintve, a gcc (vagy clang, vagy bármi más) opcióit variálva - meg pl. uclibc-re építkezve.

Lényeg, csináld végig, és meglátod.

( bird v | 2016. 06. 06., h – 15:39 )

ami át van húzva, azt teljesen fölösleges elolvasni. az olyan, mintha ott sem lenne

( uid_194 | 2016. 06. 06., h – 15:43 )

Buszken vallalom, hogy nem vagyok ember. Kb annyi ertelme van LFS-t csinalni, mint parszor fejjel szetverni a falat, hogy az ember frankon lassa a benne futo kabeleket.

--
|8]

Attol, hogy epitek egy-ket hazat ami osszeomlik, nem leszek okosabb. Cserebe elment ra egy csomo ido es energia. Ha rabizom a munkat az ahhoz ertoknek, es en csak megmondom mit szeretnek, mindenki jobban jar.

Hogy mas fenybe helyezzem ugyanezt: attol, hogy nem en epitettem a hazam, meg siman karban tudom tartani, meg tudok szerelni, vagy szereltetni ezt-azt. Az emberek nagyon nagy tobbsege nem a sajat ket kezevel huzza fel a hazat, mielott lakna, vagy szerelne benne.

Azert jo a distro, mert munkat sporol. Lehet, hogy nem fogok olyan melyen belelatni, mint aki LFS-t epitett (bar azert megkockaztatom, hogy tobbet tudok a rendszer mukodeserol, mint sok LFS-sel jatszadozo ember), de nem is szukseges ez a munkamhoz. Ahogy sem a gepi kod, sem az assembly nem hasznos egy frontendes javascript fejlesztonek (eltekintve attol a ritka esettol, amikor szarra kell valamit optimalizalni - na, akkor segit, de az azert ritka).

--
|8]

Attol, hogy epitek egy-ket hazat ami osszeomlik, nem leszek okosabb.

Dehogynem. Tudod, hogy mit csesztél el. Ha meg nem tanulsz a saját hibáidból... :)

attol, hogy nem en epitettem a hazam, meg siman karban tudom tartani, meg tudok szerelni, vagy szereltetni ezt-azt

Ennek az ellenkezőjét senki nem állította (én legalábbis biztos nem).

Lehet, hogy nem fogok olyan melyen belelatni, mint aki LFS-t epitett

Csak kilyukadtunk oda, ahova akartam ;)

tobbet tudok a rendszer mukodeserol, mint sok LFS-sel jatszadozo ember

Ezt se vitatom :)

Egyébként ez inkább olyan, hogy valakit érdekel, valakit nem.
Kőműves rokont, mikor segít, szoktam dolgokról kérdezgetni, mert érdekel - viszont annyira nem, hogy megpróbáljak egy kisebb épületet építeni (mondjuk egy szerszámtárolót).
Kb. 10 éve érdekelt annyira az LFS-móka (és volt is időm), hogy megpróbáljam. Sikerült, ment rendesen kb. két évet, utána a hosszú fordítási idők miatt ráuntam. Cserébe viszont olyan tudásra/szemléletre tettem szert, amellyel csomagok karbantartásában tudok segíteni (hú, ilyen sablonos marketingdumát...).
"Öregkoromra" viszont lényegesen kényelmesebb a pkg install foo parancs után 10 másodpercet várni, mint fél órákat.

Cserébe viszont olyan tudásra/szemléletre tettem szert, amellyel csomagok karbantartásában tudok segíteni (hú, ilyen sablonos marketingdumát...).

En ezt ugy oldottam meg, hogy nem pocsoltem LFS-sel, hanem alaposan megismertem a distrot, amit hasznaltam, es ahova csomagolni akartam. Sokkal relevansabb tudas, mint sajat package managementet irni pl, amit utana soha senki mas nem hasznal, cserebe benne van minden hulyeseg, amit a Nagyok mar evtizedekkel elotte kinottek :P

En ugy tartom, hogy egy kiforrott distrobol tanulni sokkal hasznosabb, mint feltalalni a spanyol viaszt.

--
|8]

Nem konkrétan a .spec/ebuild/FrugalBuild/... fájlok (logikai) szerkezetére gondoltam és nem is saját formátumra, hanem egy teljesen általános tudásra, az ezzel kapcsolatos problémák megoldására (ami pl. egy "profi" csomagépítés során normál esetben elő se jön, viszont a "saját" egyik gyerekbetegsége).
Nem azzal lehet igazán tanulni, hogy fogsz egy kész .spec fájlt és abban átírod a Name, Version, stb. mezőket és lefuttatod az rpmbuild-et, és örülsz, hogy csináltál egy csomagot.

Nem is arra gondoltam, hogy trivialitasok, azt irtam melyebb megismeres. Amikor mar symbol versioninggel foglalkozik az ember, migracios scripteket ir, teszteli alaposan az upgradeket, a teljes rendszerbe integraciot, pre- es postinst scriptek, debconf, stb... na, ez mar messze hasznosabb, mint a gyerekbetegsegek sajat csomagkezelonel. Nem is beszelve a soft skillekrol, ami egy csomag karbantartasaval jar - LFS-nel ezt nem kapod meg, lehetoseg sincs ra.

--
|8]

Amit en mondok, azt is lehet autodidakta modon tanulni, en is azt tettem. A *mit* a lenyeg, nem feltetlen a *hogyan*.

(Az autodidakta sem azt jelenti, hogy mindent nullarol, a rendelkezesre allo informaciot, tudast hanyagolva. Az LFS sem ezt csinalja, ahhoz is van egy meretes manual, ami alapjan el lehet indulni.)

--
|8]

( wachag | 2016. 06. 06., h – 17:17 )

Nevetséges ennyire túlmisztifikálni a dolgot.

( turul16 v | 2016. 06. 06., h – 17:47 )

gcc 2.95 javaslasa 2016 -ban erdekes ;-)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nyilván a perspektíva kedvéért javasolja:

But I implore everyone to try and build an old LFS (just about gcc 2.95/3.x or so), it will completely change the way you see things.

Bár ma már természetesen nem használnám én sem a gcc-2.95-öt, azért igenis nosztalgiával emlékszem vissza rá. :) A mai C fordítók látszólag két célra törekszenek:

  • minél durvábban büntessenek meg futásidőben bármiféle definiálatlan viselkedésért a kódban,
  • minél hangosabban rinyáljanak (= warning-okkal) teljes mértékben érvényes és jóldefiniált nyelvi konstrukciókért.

Természetesen a definiálatlan viselkedést tűzzel-vassal irtani kell a kódból, de nem az a helyes megközelítés, hogy futásidőben büntetjük érte azokat, akik UB-ről még csak nem is hallottak esetleg.

A helyes megközelítés a fordítás megszakítása hibával, illetve egy értelmes C dialektus kialakítása, amelyben sokkal kevesebb fajta UB van: http://blog.regehr.org/archives/1180

Szerkesztés: emitt egy másik link ("boringcc"): https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1kWignU/o8GGp…

( Replaced | 2016. 06. 06., h – 18:04 )

aki nem irt meg kernelt az pedig nem ferfi!

--
NetBSD - Simplicity is prerequisite for reliability

( mrceeka v | 2016. 06. 06., h – 23:04 )

Nincs új a nap alatt!

Aki dudás akar lenni,
Pokolra kell annak menni.
Ott kell annak megtanulni,
Hogyan kell a dudát fújni.

Üdv,
Marci

( uid_2716 | 2016. 06. 07., k – 21:58 )

Én tartózkodom mások minősítésétől, de azt megjegyzem, hogy néhány LFS-t én is végigcsináltam. A lényeg természetesen nem maga az elkészült alap LFS rendszer (és az itt kommentelők közül sokan elsiklanak efelett), hanem hogy (a) hogyan jut el odáig az ember (értve, kísérletezve, testre szabva), (b) utána mit tesz az ember az alappal.

create[] his own hand-built and customized LFS complete with handmade package management

A lényeg ez. Nagyon sokat lehetett belőle tanulni (pl. az egyes projektek konfigurálásáról, a függőségeikről), utána pedig még munkára is lehetett fogni. Persze nagyon sok időt igényelt.

Ha jól emlékszem (nagyon régen volt), a BLFS-hez sosem kaptam kedvet.

... Nem várom el másoktól, hogy rendelkezzenek ezzel az élménnyel, de annak azért örülök, hogy nekem megvan :)

Ebben pedig brutálisan igaza van G-nek:

I understand everyone's feelings not wanting to build the current era GNU/Linux ecosystem with its 3.x/4.x/whatever kernels, udevs, systemd and whatnot as Linux has been a dead-end environment for the last 10 years for people who require complete insight and 100% control

A "complete insight" és a "100% control" az, ami a mainstream-mé válással valóban kiment az ablakon.

(Vegyük észre, hogy a fenti idézet nem válogatás nélkül szidja a Linux-ot -- sokkal inkább arról van szó, hogy egy tapasztalt felhasználói réteg tokkal-vonóval cserben lett hagyva (szépen, magyarul :)). Én hivatásszerűen fejlesztek Linux-on hardverközeli FLOSS projekteket (projektenként eltérő súlyú részvétellel persze), de a systemd környékét (általánosabban: a freedesktop.org termékeit) évek óta változatlanul a rendszer legtolakodóbb és legnehezebben kezelhető részének találom.)

Nemrég írtam, és idevág: https://www.reddit.com/r/linux/comments/4lh7yv/systemd_developer_asks_t…

Amúgy az udev, dbus és társai elég korrektül kezelhetőek. Illetve bele is tudsz látni, ha akarsz (speciel hotplug eventeket sima socket handlinggel is tudnál kezelni, nem halálos).
A DBusnak (és az erre alapuló freedesktopos dolgoknak) van egy nagyon hasznos funkciója: szabványos, egységes módon elérhetővé teszik az egyes rendszerobjektumokat (pl. NM a hálózati kapcsolatokat, stb.). Lényegében RPC (RMI) formában. Sokkal könnyebb scriptelni, toolt írni hozzá (nem kell textfilet parsolni, stb). Lehet jogosultságokat finomhangolni az egyes beállítások eléréséhez (policykit), lehet távolról kezelni a gépeket (remote dbus). Ha valami szolgáltatás nem fut, akkor activation segítségével automatikusan indítható.

Ezzel amúgy tudnám racionalizálni a systemd "begyűjtő" szokását: nem várhatják el, hogy az ezerféle konfigfilelal, össze-vissza indítható alapszintű szolgáltatások fejlesztői egy egységes formában tegyék elérhetővé a dolgaikat (jelenleg: ahány szolgáltatás, annyi unix domain socket, ráadásul distrofüggő helyen (/run, /var/run, stb.). A Red Hatnek meg gondolom érdeke, hogy ne kelljen ezekkel külön kínlódnia, hanem végre legyen valami egységesen kezelhető dolog. De haters gonna hate.

( Dwokfur v | 2016. 06. 08., sze – 22:11 )

"Linux has been a dead-end environment for the last 10 years for people who require complete insight and 100% control, like me"
Kíváncsi lennék, hogy akkor mi? Gondolom nem a MacOS X... Talán az OpenVMS? Vagy valami egzotikus OS?

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( uid_2783 | 2016. 06. 08., sze – 22:13 )

..itt voltam topiktörlődés és abalole kivagdalása előtt..
(ha-ha-ha)

--