Názory k článku
Distribuce slučují adresáře /lib a /usr/lib, je to dobrý nápad?

"A koho to zajímá?"

Treba vsechny ostatni, kteri si ten clanek precetli?

Třeba ty, kteří mají /usr na jiném svazku (např. na síti...)

Ano, těm by to třeba mohlo začít konečně fungovat správně. Viz např. Gentoo Bug 149472

Á, jednou místnímu trollovi a pruduči zřejmě skončila dovolená, :-)

Opět mi nezbývá, než se zeptat:
Proč sem pořád lezeš, když tady tak trpíš?

Tak to nečti. Nikoho tu nezajímá pro změnu tvůj komentář.

Tak to nečti. ...
;-)

očividně podle počtu rozhořčených replik se trefil ;) Že vy se taky hned chytnete...

etc. rozdělení lib a slib je již stejně zbytečné, jako např. bin a sbin či local, opt a usr... a dalo by se pokračovat.
Zhovadilostí (které snad měly opodstatnění v roce 1970) je více, např. share a var...
všechny tyto "drobnosti" výrazně přispívají k problémům typu koexistence jednoho SW v různých verzích, řešení problémů kdy 2 SW potřebují knihovnu v různých verzích...

Vůbec se mi nikdy nelíbilo, jak se unixový OS rozlézá po celém oddílu.
Představoval bych si modrou oblohu a pod ní systém, který by sídlil v jednom adresáři OS, kde by bylo vše.... a mě by vůbec nezajímalo jak to funguje a co se tam mění...

bohužel, není síly to změnit. Chtělo by to všechno vylejt a začít znovu...

> Zhovadilostí (které snad měly opodstatnění v roce 1970) je více, např. share a var...

Svatá noho ježkovo! Oddělení generovaných a instalačních dat, že je zhovadilost? Uffff.

> Představoval bych si modrou oblohu a pod ní systém, který by sídlil v jednom adresáři OS

Tak používej Windows, ty rozumbrado, tam máš kupu bordelu v jednom adresáři.

Tako ostře, jako megatroll, bych to nenapsal, ale jak chceš třeba trošku pokročilejšímu uživateli prodat skutečnost, že na Windows má jako obyčejný uživatel po ruce příkaz ipconfig, zatímco v některých distribucích Linuxu musí napsat /sbin/ifconfig, to fakt nechápu. Nějakou logiku to má, ale zbytečně složitou a zvrácenou. A ta linuxová hierarchie adresářů mi přijde jako celek překombinovaná. Kromě /sbin a /usr/sbin bych zrušil třeba /opt, dále pak nevidím moc smysl v oddělené existenci adresářů /mnt a /media (resp. odůvodnit si to dokážu, ale IMO to má víc nevýhod, než výhod), nemluvě o někdejší "vymoženosti" SUSE v podobě adresáře /windows.

ad /sbin/ifconfig - to je takovej uměle vyšpekulovanej problém. Jednak nevidím žádnej rozumnej důvod, proč by */sbin nemělo být v PATH, jednak úplně stejně bys mohl argumentovat opačně: jak vysvětlíš *jakémukoli* uživateli unixodidních systémů, že je zvyklý nainstalovat python a hnedka ho spustit příkazem "python", zatímco na Windows se buď musí hrabat kdesi ve třetí úrovni menu, nebo do terminálu zadávat jakýsi příšerný C:\program files\python-x.y.z\bin\python :)

Ta hierarchie je "překombinovaná", protože *umožňuje* oddělit různé věci různého typu. Pokud tohle rozdělení distribuce nedodržuje a plácá si mírnixtýrnix cokoli kamkoli, tak to pak smysl nemá, to je jasný. Ale pokud vývojáři OS mají trochu soudnosti a smyslu pro pořádek, tak to rozdělení smysl má. Příklady už tady zazněly.

To je ale trochu argumentace ve stylu "a u vás zase mlátíte černochy", ne? Mně se na Linuxu (na desktopu) nelíbí 1000 věcí, na Windows 1001 a na jiných systémech možná 1002. To /usr/sbin není uměle vyspekulovaný problém; to je problém, na který jsem narážel opakovaně docela dost let a při každé instalaci nové verze nebo nové distribuce znovu a znovu. Teď mám doma Ubuntu a tam to není, což je paráda. Přesto bych byl raději, kdyby *sbin zmizelo úplně. Před (marným) ošetřováním všech možných a nemožných eventualit dávám přednost maximální jednoduchosti.

> To je ale trochu argumentace ve stylu "a u vás zase mlátíte černochy", ne?

Myslel jsem to jinak: jestli je složité někomu vysvětlit, že má napsat /sbin/ifconfig, tak to potom asi nemůže používat žádný OS, protože v každém (mně známém) OS je prostě občas nějakou tu cestu někam napsat.

Jinak ty distribuce, které nemají */sbin v PATH jsou prostě asi blbě udělané, protože afaik není žádný důvod */sbin do PATH nedat. Že ho tam někdo nedá, to přece není chyba FSH...

Taky dávám přednost tomu, když je sbin buď automaticky v $PATH, nebo by byl sloučený s bin, nebo kdyby v sbin byly pouze věci, které nemůže spouštět uživatel. Nevím přesně, které z těch řešení je nejlepší, ale jsem si dost jistý, že je pitomost, když se nacházejí uživatelsky použitelné příkazy mimo cestu.

Co mate furt s tim /usr/sbin? Ja prosel ruznymi distry a na kazdem jsem psal vzdy akorat ifconfig bez cesty.

To bude tým, že si to písal ako root.

Vsak taky userovi je to obvykle na dve veci. Nema prava na to, aby s tim nejak steloval. BTW, jsem ted na Lubuntu a tam to chodi bez cesty i pod normalnim userem. Nekdy se mrknu na Debian, az nekdy zapnu desktop.

Ale ved to ja viem. Len som ti odpovedal, preco si s tym nemal nikdy problem: lebo root ma /sbin a /usr/sbin v ceste.

Nechápeš nebo nechceš chápat dvě věci:

1. Při různých akcích na síti je užitečné znát vlastní IP adresu a ifconfig je nejjednodušší způsob, jak ji rychle zjistit. A nemusíš na tom počítači zrovna nic štelovat.

2. Všechny akce je vhodné provádět s nejmenším možným oprávněním. Čím méně člověk užívá práva superusera, tím lepší.

šmarjá, když vím k čemu je ifconfig, tak si snad do PATH to /sbin jednoduše přidám, ne ?
to jsou zase debaty :-/

1. Viz Imb prede mnou.

2. Jiste. Zrovna pomoci ifconfig vas tezko ale nekdo napadne.

A co „ip address“?

Běžný uživatel pro to ale stejně použije Network Managera :-)

# which ip
/sbin/ip

Takže to isté, čo ifconfig. :)

Doporučuji to zkusit pod obyčejným uživatelem:

sten@lychee ~ $ which ip
/bin/ip
sten@lychee ~ $ sudo which ip
/sbin/ip
sten@lychee ~ $ ll /sbin/ip
lrwxrwxrwx 1 root root 7 dub 10 01:10 /sbin/ip -> /bin/ip

Dobry napad, takze skusme (distribucia gentoo):

$ which ip
which: no ip in (<zoznam adresarov z cesty>)

Teda za predpokladu, ze si uzivatel nenastavi adresare /sbin a /usr/sbin do PATH. (Ine distribucie to samozrejme mozu mat inac. Teraz som napriklad pozeral, ze debian to ma tak, ako popisujes: /sbin/ip je tam symbolicky link na /bin/ip. Zrejme pre uzivatelov, co si nevedia nastavit PATH.)

python se mi na windows vždycky sám přidal do PATH takže jsem ho nikdy nehledal. Navíc mám Start nabídku, která indexuje a najde si .exe pythonu ve vteřině sama.

"ale jak chceš třeba trošku pokročilejšímu uživateli prodat skutečnost, že na Windows má jako obyčejný uživatel po ruce příkaz ipconfig, zatímco v některých distribucích Linuxu musí napsat /sbin/ifconfig, to fakt nechápu"

Jednoduše :
mcedit ~/.profile
alias ifconfig="/sbin/if­config"

Každopádně tohle jsem nikdy nepochopil. LINUX NENÍ WINDOWS!!! Takže když se v Linuxu něco dělá jinak než ve widlích, tak ať se přizpůsobí, nebo si přizpůsobí systém (má-li na to) a nebo ať si klidně zůstane u Widlí.

Jinak rozdělení /mnt a /media mi přijde taky jako hovadina, /opt bych nechal jako /usr/local/opt.

> /opt bych nechal jako /usr/local/opt.

Proc pro matku prirodu menit neco, co je zabehle a nicemu to nevadi?

Naklady jsou potencialne velke (patchovat instalacni skripty vsech aplikaci, ktere ocekavaji /opt) a zisk je nulovy (misto 16 polozek v / jich bude 15... hm).

Proc? Pro jezkovy bodliny PROC resit hovadiny, ktere zavedou dalsi BUGY, misto zamereni se na to, aby se odstranily opravdu zavazne chyby, ktere uzivatele stvou a OSS delaji spatne jmeno?!

fakt je takový problém napsat skript který ty instalační skrypty proleze a změní řetězec "/opt" na "/usr/local/opt"? To snad ne... Navíc ta změna nemusí být hned ze dne na den, ale třeba při přípravě vydání nové verze distra, kdy už se s těmito změnami bude počítat.

Nejde o to, že se sníží / zvýší počet adresářů v kořeni, to je mi docela putna. jde o pořádek a logiku. od lokálních a "jiných" programů je tu hlavně "/usr/local". Tak proč tam nemít i adresář "opt", který tam logicky líp pasuje, než do kořenu?

Pokud vím, do /opt se odjakživa cpaly binární sračky, takže problém to opravdu je - spoustu z těch věcí nelze ani distribuovat a stahují se z webu výrobce. Ale především to je činnost úplně na nic.

Co je u tebe "binární sračka" o_O Pod tímhle názvem si mužu představit vše možné, od kernelu po X.

Co já vím, tak se doporučovalo dávat do tohodle adresáře programy které měli vlastní strukturu adresářů (typicky to byli třeba OOo, nebo Firefox, Thunderbird, a vůbec XUL aplikace), nebo aplikace, které z nějakého důvodu nešlo nebylo možné instalovat do /usr nebo /usr/local (já jsem tam směroval třeba různé verze Wine, které jsem měl nainstalovány zároveň s tou stabilní na jednom počítači, včetně opatchovaných buildů). Dřív jsem tam měl taky dosové programy...

sracky typu Oracle a v podstate mrte 3-stranneho SW. Naco veci komplikovat. Tento adresar/mountpoint ma zmysel, samozrejme kto chce, moze si zlinkovat co chce - kam chce. To, ze na HP-UX ako neprivilegovany uzivatel musim pisat /usr/sbin/ping je uz nieco ineho (nie, nebavi ma to davat si do $PATH, kedze sa hlasim na stovky roznych systemov) a fakt nevidim dovod nedat uzivalom rovnaku cestu ako rootovi (bezpecnost musi byt riesena inak), a hlavne trepat taketo prikazy do /usr/sbin !!!
Cize moj nazor je - zmeny hej, doba sa zmenila, len PROSIM z mierou !

> fakt je takový problém napsat skript který ty instalační skrypty proleze a změní řetězec "/opt" na "/usr/local/opt"?

Teoreticky to mozna tak jednoduchy je, ale praxe neni teorie :)
Jak napr. oddelis ty baliky, ktery se do /opt instaluji jako default od tech, ktere to /opt obsahuji treba jenom jako nejakou moznost? Budes zbytecne vyrabet patche pro baliky, ktere vubec patchovane byt nepotrebuji?

Nehlede na to, ze ne kazda distribuce ma tak jednoduchy balickovaci system jako FreeBSD - staci nahrat patch do konkretniho adresare. U vetsiny distribuci bys musel slozite rozbalovat nejake to udesne SRPM, upravit, zpatky zabalit, prelozit, pak zjistit, ze to nefunguje, rozbali, zmenit, zabalit...

> jde o pořádek a logiku. od lokálních a "jiných" programů je tu hlavně "/usr/local". Tak proč tam nemít i adresář "opt", který tam logicky líp pasuje, než do kořenu?

No hlavne proto, ze baliky v /opt byvaji instalovane balickovacim systemem, takze do /usr/local nepatri :) Jako klidne si muzes /usr/local/opt vytvorit, ale z principu veci bys tam mel davat jenom veci instalovany rucne.

Proste zase tady plati to samy: ten system MA logiku, je jenom potreba ji dodrzovat a ne do ni nesmyslne radobyinvencne vrtat a kaslat na standardy a best practices...

>"Jak napr. oddelis ty baliky, ktery se do /opt instaluji jako default od tech, ktere to /opt obsahuji treba jenom jako nejakou moznost?"

No, kolik balíčkovacích systému ti tuhle možnost dá? Rozhodně ne RPM a DEB. Jestli to umí Slackware to nevím, ale pochybuji o tom. Jde o to, že ve většině případů je velmi důležité vzhledem ke kterému adresáři aplikaci přeložíš (kvůli linkování knihoven) Co jsem si všiml, tak se toho využívalo u OOo balíčku, které tam cpali jen nějaký knihovny. Tam je to potom jen otázka překladu a ani to není neřešitelné (standardně ./configure --prefix="cesta")

> "Nehlede na to, ze ne kazda distribuce ma tak jednoduchy balickovaci system jako FreeBSD - staci nahrat patch do konkretniho adresare. U vetsiny distribuci bys musel slozite rozbalovat nejake to udesne SRPM, upravit, zpatky zabalit, prelozit, pak zjistit, ze to nefunguje, rozbali, zmenit, zabalit..."

Mám ten dojem, že pořád nějak předpokládáš, že jakmile se ta změna jednou "ustanoví" pak ji budou muset hned všichni udělat. nemyslím, že by to bylo tak nutné (alespoň co se týče tohoto konkrétního adresáře). Ta může přijít s jednotlivými updaty. Stejně musíš vzít zdroják, aplikovat patch, vhodně nakonfigurovat, build, komprimace, balíček a šup s ním do repositáře. Tyhle změny může nést už rovnou s sebou. Vývojáři distra mají určitě přehled který program (balík) využívá které adresáře. takže s novou verzi distra bude už drtivá většina programů a balíků převedena a při upgradu se dá prostě odstranit (nebude-li tam něco dalšího), nebo alespoň doporučit jeho zmazání...

> "No hlavne proto, ze baliky v /opt byvaji instalovane balickovacim systemem, takze do /usr/local nepatri :) Jako klidne si muzes /usr/local/opt vytvorit, ale z principu veci bys tam mel davat jenom veci instalovany rucne."

Jinak, pokud jsem si stačil všimnout, tak balíčkovací systém cpe binárky většinou do /bin, /usr/bin, /sbin, /usr/sbin a /usr/games. /opt je věšinou nevyužitý. Ale když jinak nedáš tak ještě "/usr/opt" :) Já to bral tak, že většina věcí v tomhle adresáři je instalována ručně.

s/zmazaní/smazání

Asi jsme si nerozumeli. Reagoval jsem na to, ze zrusit /opt a vsechno presunout do /usr/local/opt fakt neni otazka jednoho spusteni sedu.

> /opt je věšinou nevyužitý

Jak kde. V tom jsou opet jednotliva distra nejednotna. Nektera davaji do /opt/<nazev> "velke baliky" typu gnome, kde, ... Pokud se nepletu, dela to tak napr. Arch nebo SuSE.

Navic se do /opt instaluji nektere non-OSS veci. Kdybych delal komercni aplikaci pro Linux, tak bych ji asi taky distribuoval jako self-contained vec, ktera se rozbali do /opt/mirovasu­peraplikace, protoze resit, jaka verze libprd je zrovna v nejake obskurni distribuci by se mi fakt nechtelo :)

> "Asi jsme si nerozumeli. Reagoval jsem na to, ze zrusit /opt a vsechno presunout do /usr/local/opt fakt neni otazka jednoho spusteni sedu."

Ok, ale rozhodně to není nic zas až tak složitého.

> "Jak kde. V tom jsou opet jednotliva distra nejednotna. Nektera davaji do /opt/<nazev> "velke baliky" typu gnome, kde, ... Pokud se nepletu, dela to tak napr. Arch nebo SuSE."

Máš pravdu, jenže to samozřejmě neznamená, že je to ještě v pořádku (rozhodně je to dost dikutabilní). Trochu mi uchází důvod proč cpát KDE, nebo Gnome do /opt, ale budiž...

„Ok, ale rozhodně to není nic zas až tak složitého.“

Aplikace se budou tak jako tak dál instalovat do /opt, protože bývají zpravidla mimo dosah distributorů, tudíž bude na příští desetiletí /opt fungovat jako symlink, pokud to má opravdu fungovat.

Ale na /opt je i sympatické, že je to krátké na napsání. Já si tam pak cpu instalace různých software, které testuju a potřebuju je volat celou cestou. Což by se samozřejmě při použití symlinku zachovalo.

Otázka je, jestli to má vůbec nějaký smysl.

<i>Jinak, pokud jsem si stačil všimnout, tak balíčkovací systém cpe binárky většinou do /bin, /usr/bin, /sbin, /usr/sbin a /usr/games. /opt je věšinou nevyužitý. Ale když jinak nedáš tak ještě "/usr/opt" :) Já to bral tak, že většina věcí v tomhle adresáři je instalována ručně.</i>

Ježkovy voči, takový základní neznalosti :-O Bral jste to fakt špatně, no alespoň jste vnesl světlo do toho vašeho nesmyslného návrhu umístit /opt do /usr/local.

Děkuji za osvícení vznešný guru ;)

Ono je to spíš tak, že balíčkovací systém tohle prakticky neřeší a je to na tvůrcích balíčků. Takže třeba externí repozitáře Adobe obsahují balíčky, které mají software v /opt.

Kdyby balíčkovací systém instaloval soubory někam jinam než v tom balíčku opravdu jsou, byla by to chyba a většina software by tak vůbec nefungovala.

Dobře, máte pravdu, blbě jsem to formuloval.

Koneckonců, to, že si to uvědomuji trochu vychází už z prvního odstavce toho příspěvku na který reagujete ;-)

Já bych snad ani nic neprodával a přidal /sbin a /usr/sbin do PATH. Spousta normálních distribucí to tak dělá.

Já nikomu nic prodávat nechci, to je nedorozumění. Pokud ale ten člověk přijde sám a v PATH to nemá, zbytečně ho to naštve...

pokud to v path nema, tak si to prida, a pokud nevi, jak se takova naprosto zakladni vec dela, tak velmi pravdepodobne nepotrebuje ani ten ifconfig...

A když mu to někdo smaže, tak si to naprogramuje sám. A pokud neví jak, dobře mu tak.

No já si uvědomuju, že jsem to napsal trochu nešťastně. Linux samozřejmě není Windows a některé věci se tam dělají jinak; například na jednom systému je copy a na druhém cp, na jednom je ipconfig a na druhém ifconfig. Tady ale nejde jenom o uživatele Windows, ale o kohokoliv, kdo není úplná ovce a nenechá si všechno líbit. Tady se prostě někdo rozhodl, že některé programy by měly být k dispozici jenom rootovi, druhý do té množiny zařadil ifconfig a třetího naštěstí napadlo, že ten program potřebují užívat i normální uživatelé, takže je /sbin k dispozici všem. Takže jsme stvořili kočkopsa, který neplní původní zadání a hází uživatelům klacky pod nohy. No a pak přijde čtvrtý člověk a hodí /sbin do PATH, čímž smysl existence toho adresáře definitivně popře.

Řešení přes alias a PATH (a jiná) samozřejmě znám, ale to je podle mě už obcházení problému.

To rozdělení utilit do /sbin a /usr/sbin má zamozřejmě svoji logiku. FHS ji popisuje takhle:

3.14 /sbin : System binaries
4.10 /usr/sbin : Non-essential standard system binaries

Originally, /sbin binaries were kept in /etc. Programs executed after /usr is known to be mounted (when there are no problems) are generally placed into /usr/sbin. Locally-installed system administration programs should be placed into /usr/local/sbin.
( http://www.pathname.com/fhs/2.2/fhs-3.14.html )

Čili do /sbin patří JENOM to, co se používá pro recovery nebo co se používá při bootu před tím, než se namountuje /usr.

A je to právě proto, aby se / udržel co nejmenší. Linux v tom udělal bordel tím, že
A) používá initrd, kam nakopíruje zas úplně jiný utility
B) má (jak tady zaznělo, já to z vlastní zkušenosti nevím) problém s bootováním bez /usr

Jasně, v situaci prasáren A) a B) už to rozdělení nemá smysl a klidně je možný všechno prsknout třeba do /superlinuxbi­naries, protože to, co mělo platit, už stejně neplatí. FHS totiž vychází z logiky, která už je stejně rozbitá.

Bordel v tom nedělá linux, ale administrátoři (se svými požadavky a konfiguracemi) a distributoři (s jejich neplněním či rozbitím). Jinak pokud vím, Linux není zdaleka první systém, který se od myšlenky kořenových bin, sbin a lib odklonil.

Rozdeleni /mnt a /media zas takova blbost neni. V /mnt mam stale mounty a v /media dynamicky vytvarene automaticky montovane veci. Tak at mi v /mnt radsi nejaky automount nedela bordel. Krome toho, kdyz v /mnt budu mit adresar treba abc a na nem neco namontovaneho, vznikne v /mnt co, kdyz pripojim flash disk s labelem abc? No asi bordel.

Hlavně si nepřipoj dva flashdisky pojmenované abc najednou. To by systém nerozchodil vůbec.

Nemluvě o zadání "google" do Googlu!

Ja na to jdu rafinovane a kazdy disk mam pojmenovany jinak, abych nemusel hledat, na co si to system, ktery by to rozdychal, prejmenoval. A lepe se mi hleda v /media, kde mam jenom automountu, nez v /mnt, kde by byly automounty plus fixni mounty.

Za flasku Zubrovky vam upravim Widle tak, ze budete muset psat c:\windows\sys­tem32\ipconfig.

"očividně podle počtu rozhořčených replik se trefil ;) Že vy se taky hned chytnete..."

Ano, on se trefí každý kdo přijde s blbýma kecama. Kolega "mat" má na tohle výjimečný talent.

Ano /lib a /bin, jsou dneska defakto na nic, ale rozhodně ne napřiklad /usr/sbin, nebo /opt (/usr/local/opt) a pod. nevidím jediný důvod proč mixovat binárky ( /usr/bin ) s adresáři programů, které vyžadují mít své věci ve vlastních složkách (ty se dávají do /opt). Stejně tak nevidím jediný důvod proč míchat převážně systémové a administrativní aplikace s uživatelskými ( /usr/sbin vs. /usr/bin ) nebo herními aplikace (/usr/games ). A už vůbec nechápu proč míchat aplikace, které jsou instalovány mimo systémové mechanismy (např. překladem - /usr/local).

Ve widlích jsou zvyklí na hulvátský bordel, aplikace se naštvou kam to jen jde i nejde, hlavně do adresáře C:/Program Files a netrvá dlouho a ani prase se v tom nevyzná. To ani nemluvím o tom, že spousta binárek se dá najít v adresáři C:/Windows a jeho subadresářích a podobně i v adresářích uživatelů. O takovýhle bordel fakt nestojím, máme svého vlastního dost. Ještě si sem tahat nepořádek podle vzoru MS....

Konečně věcný názor. U /opt není co řešit, ten je specifický, nechat. Podobně má smysl odlišit systémové příkazy ve /sbin od aplikačních v /usr/bin a zahodit /bin. Odlišení jaderných a user aplikačních prvků je trvalá nezbytnost, pokud v tom nemá být chlív. V případě Windows není moc o čem mluvit, jejich adresářová struktura vypovídá o kvalitě OS a oddělení systémového a aplikačního prostoru. ostatně proto používáme GNU/linux, že...

> V případě Windows není moc o čem mluvit, jejich adresářová struktura vypovídá o kvalitě OS a oddělení systémového a aplikačního prostoru. ostatně proto používáme GNU/linux, že...

To ale trochu koliduje s tím, co píše kolega vedle:

> Přesun systémových nastaveních jako sítě, správa napájení apod. do desktopu ?

:)

:-) :-) :-)
Kurnik chlapi, proč to lemtáte, když Vám to nedělá dobře?

Tak používej CP/M. Tam nebudeš mít s množstvím systémových adresářů problém.

Mimochodem, jak se dá poznat, co (která knihovna) je ještě „systém“ (a má to tedy být v tom systémovém adresáři) a co není?

Tak tohle má PuppyLinux, ten je rozlezlý do čtyřech souborů. A nebo můžeš jít trolovat pod most.

A hrome, já zapomněl, že jsou prázdniny a náctiletí se nudí...

no predstav si ze mna to zaujima ako admina rhel masin :)

je to dobra vec

Vo Fedore, testovacom piesočku Red Hatu sa to nechystá, akle už nejakú dobu to tak je.

$ file /bin /lib
/bin: symbolic link to `usr/bin'
/lib: symbolic link to `usr/lib'

Ještě jsem si pro jistotu instaloval Fedoru, abych zjistil, jak to opravdu je, ale v článku jsem tuto informaci nakonec zapomněl opravit. Díky za upozornění.

Jeste by bylo vhodne upravit tisickrat zminovany "Archlinux" na "Arch Linux". ;)

No, tady bych tak puritánský nebyl, je běžné používat zjednodušené názvy známých věcí...

Pěkný článek, díky.
Požívám Chakra linux, který vychází z Archu, takže mě to čeká velmi brzy. Na jejich webu už to oznámili (+ přechod na systemd a další).

mhmm?

ja tedy zrovna dvakrat radost nemam a to ani z jednoho pocinu, ktery redhat prinasi. nemam system (gentoo), kde bych nemel /usr na oddelenem svazku lvm, tudiz problemy pri bootovani me cekaji a netesim se na to ani trosku :-(

Už delší dobu dávám do LVM kořenový adresář, takže případné problémy by se mě týkaly už dávno. Řešení jsou dvě, buď se gentooisti naučí používat initrd (což chápu, že se mnohým nechce), nebo má samozřejmě Gentoo jako distributor možnost
oddělený /lib, /bin a /sbin zachovat.

Ono se není zas tak co učit, initramfs už spoustu let vytváří automaticky genkernel, nebo si ho můžou vytvářet přes dracut.

A právě ti, kteří dosud byli zvyklí postupovat vyladěním kernelu bez initrd, se budou muset něco učit :).

nejde o uceni, to mi nevadi. nenapadlo te treba to, ze nekdo muze z ruznych duvodu chtit pouzit jiny fs pro / a jiny pro /usr ?

„nejde o uceni, to mi nevadi. nenapadlo te treba to, ze nekdo muze z ruznych duvodu chtit pouzit jiny fs pro / a jiny pro /usr ?“

Ano, přesně ti, kteří chtějí použít pro /usr samostatný FS a dosud jim to fungovalo bez initrd, se to budou muset naučit.

Cili initrd se stane nutnosti kvuli necemu, co vubec nesouvisi s jeho puvodnim ucelem.

A jsme u toho: spaghetti OS.

Parse error.

stable genkernel neumi vygenerovat initramfs, ktery pri bootu namoutuje /usr

Pak je otázka, jestli je vhodné dělat UsrMove, dokud to nebude umět.

spravne, dostavame se k jadru veci. ja bych to nedelal, nicmene to neovlivnim a uz v tuto chvili mi prestalo fungovat nastaveni alsa, protoze prave alsact je v nekde v /usr a ten se uz ted pri bootu nemountuje, takze jak jste spravne pochopil, nelibi se mi to prave proto, ze uz to presunute je a genkernel patch nema...

Tedy upřímnou soustrast.

> buď se gentooisti naučí používat initrd (což chápu, že se mnohým nechce)

Nevim, jakou motivaci k tomu Gentooisti maji, ale vubec bych se nedivil, kdyby si spolu se mnou hodne z nich myslelo, ze cely koncept initrd je z principu veci vadny a je to ukazkovy priklad workaroundu, ktery vic problemu zpusobuje, nez resi.

Proc propanakrale udrzovat nejaky "startovaci image" s kopiemi neceho, co mam v /, kdyz ho stejne z / nacitam? Dyt to je taskarice jak brno - proc rovnou nepouzit minimalistickou startovaci partition / ?

No jo, ale to by chtelo trochu discipliny a nezasirat / kravinama... Coz chceme, takze pridame dalsi presrackovanou kravinu jmenem initrd...

No jo, ale to by chtelo trochu discipliny a nezasirat / kravinama... Coz chceme, takze pridame dalsi presrackovanou kravinu jmenem initrd...

Fajn, tak mi prosím s trouchou disciplíny vytvoř kravinama nezasranej /, kterej nabootuje z NFS, přičemž potřebuju NFS 4.1 a zabezpečení přes Kerberos. Principiálně vadné je podle tebe zřejmě všechno, co neodpovídá BSD dogmatům.

A v cem jako vidis problem? Co je ten principielni duvod, proc to nejde udelat?

Poznamku s BSD dogmatama nechapu. FreeBSD pouzivam pro ilustraci, ze konkretni veci jdou delat i bez udajne nutnych berlicek.

Proč to nejde udělat? Protože nechces zasírat / kravina, no. Pro jednoho je kravina kerberos, pro druhého je kravina cups, pro třetího je kravina bluetooth klávesnice nebo myš, ale nic z toho nefunguje správně, dokud není namountovaný /usr. Nevidím absolutně žádný smysl v pátrání po tom, co všechno nefunguje za účelem přesunutí do /. Práce úplně k ničemu.

A muzes mi nejak polopaticky vysvetlit, jakej je rozdil mezi temahle dvema vecma?

1. zjistuju, co vsechno musim dat do initrd, abych mohl nabootovat

2. zjistuju, co vsechno musim dat do /, abych mohl nabootovat

No offence, nemam v umyslu trollovat, ale opravdu nechapu logiku uvazovani "nechceme to davat do /, tak to kopirujeme do initrd". Hlavne proto, ze v / mi to zustane navzdy na jednom miste, zatimco do initrd to musim pri kazde zmene kopirovat, rozbalovat, menit, zpatky zabalit, udrzovat konfiguraci, co vsechno tam ma byt, udrzovat miliony skriptu, ktery se o to vsechno staraji.

Mit tu samou vec na dvou mistech je vzdycky nejhorsi mozny reseni a melo by se imho volit jenom v pripade, kdy fakt neni zbyti, protoze s tim jsou vzdycky problemy.

opravdu nechapu logiku uvazovani "nechceme to davat do /, tak to kopirujeme do initrd"

Ano, to asi zůstalo opravdu nepochopeno. :-) Jediné, co tam potřebuju, jsou věci nutné k připojení /usr. Opravdu nikdo tam nechce rvát cups, BT stack atd. do initrd/initramfs, není k tomu žádný důvod.

Hlavne proto, ze v / mi to zustane navzdy na jednom miste

Ano, zatímco initramfs mi to zůstane nejen na jedno místě, ale ještě všecho pohromadě v jednom souboru. Fakt nevidím, v čem je ta výhoda /.

musim pri kazde zmene kopirovat, rozbalovat, menit, zpatky zabalit, udrzovat konfiguraci, co vsechno tam ma byt, udrzovat miliony skriptu, ktery se o to vsechno staraji.

Hmmm... napsat update-initramfs -u v Debianu nebo genkernel --install initramfs v Gentoo, to je fakt děsná práce. :-)

> Opravdu nikdo tam nechce rvát cups, BT stack atd. do initrd/initramfs, není k tomu žádný důvod.

Vubec nechapu pointu.

>> Ano, zatímco initramfs mi to zůstane nejen na jedno místě, ale ještě všecho pohromadě v jednom souboru. Fakt nevidím, v čem je ta výhoda /.

Jakto na jednom miste? Ty veci, ktery mas v initrd prece ODNEKUD kopirujes, ne? Takze je mas NEKDE a potom jeste v initrd. A tyhle dve veci musis odrzovat synchronizovany, misto, abys rovnou pouzil pri bootu to NEKDE a zadnou synchronizaci nepotreboval.

Opet to chce asi priklad z FreeBSD (fakt nejde o zadna dogmata, je to priklad): prijde ti slozity bootovani z NFS+kerberos? A prislo by ti srovnatelne slozity bootovani ze ZFS (obcas se rika, ze ZFS je OS v OS :)? Tak na to jsou ve FreeBSD potreba dva soubory: pmbr (512B) a gtpzfsboot (39KB). Tyhle dva soubory musis odnekud natahnout (typicky zacatek partition + jedna dedikovana partition pro gptzfsboot) a potom uz jedes vsechno primo ze ZFS.

Totez s diskless bootem: potrebujes jeden soubor pxeboot (262KB), kterej umi nacist konfiguraci z DHCP a / namountovat z NFS. Nic uz pak neni potreba premountaovavat, jede se rovnou z toho, co je namountovany.

Magie? Nemyslim si. Proste adekvatni reseni situace bez berlicek. A jelikoz tam zadna berlicka neni, neni potreba ji resit a nic ti ji nemuze podrazit. Zadne "aha, nebootuje to, protoze jsem do initrd zapomnel dat X" se nekona. System nabootuje i v ruznych nestandardnich situacich jako treba kdyz ho preneses na jinej HW apod.

> Hmmm... napsat update-initramfs -u v Debianu nebo genkernel --install initramfs v Gentoo, to je fakt děsná práce. :-)

A vnimas nejaky rozdil mezi "spustit utilitu" a "naprogramovat a udrzovat utilitu"?

A tyhle dve veci musis odrzovat synchronizovany, misto, abys rovnou pouzil pri bootu to NEKDE a zadnou synchronizaci nepotreboval.

Ne, nemusím. Naopak např. Gentoo to tak vůbec nedělá. V initramfs se defaultně používají otestované stabilní verze bez ohledu na to, co je v systému. (Samozřejmě je to konfigurovatelné, pokud chceš verzi jinou/aktuální.) V Debianu se používá to, co je aktuálně v systému s tím, že přes hook se automaticky aktualizuje i initramfs. Práce pro uživatele naprosto nulová.

No tak pokud Gentoo nepouziva aktualni verze, tak to je urcite krok spravnym smerem, to jsem nevedel. Sice pak moc nechapu duvod (aktualni verze modulu jadra tam stejne nemam), ale urcite je to uspech, ze misto BSDackyho jednoho 40K souboru zvladlo Gentoo to samy udelat pomoci nekolikamegovyho image ;)

Nerozumíme si. Jádro je v initramfs samozřejmě vždy to aktuální, které bootuju :-) Mluvím o nástrojích v tom initramfs. Příklad.

Aha, ja jsem myslel, ze v tom initrd ma treba nejakou univerzalni verzi driveru filesystemu, kterou pouzije jenom na to, aby namountovalo root.

No tak pokud je to takhle, tak plati, co jsem rikal: musi se slozite zjistovat, co se ma do image zkopirovat, image se musi vytvorit, musi existovat navic dalsi init skripty atd. Proste uplne zbytecna namaha s nulovym efektem. Spis bych rekl zapornym, protoze:
1. kdyz v imagi neco nemam, tak nenabootuju (na jinym hw apod.)
2. stejny system muzu jenom s obtizema nabootovat jinym zpusobem (napr. normalne bootuju z nfs, ale ted potrebuju TENTYZ system nabootovat z disku)

Opravdu nerozumím.
1/ Pokud si kompilujete "optimalizované" (minimální) jádro pouze pro vlastní stroj, tak samozřejmě nebude na jiném HW bootovat, pokud ten ovladač nemá, to snad dá rozum. To vůbec nesouvisí s initramfs. Pokud máte jádro univerzální, tak nabootuje všude.
2/ Uhm? Změnit v bootloaderu parametry pro jádro třeba z root=/dev/nfs nfsroot=aaa.bbb­.ccc.ddd:/some/path na root=/dev/sda1 je práce na několik sekund.

1) nemluvim o zadnem optimalizovanem jadru. Pokud pouzivam initrd, tak tam typicky nekopiruju vsechny moduly, ale jenom nektere. Musim teda a] nejak urcit, ktere to jsou b] na systemu, kde by byly potreba jine, mi ten system nenabootuje.

Oproti tomu kdyz bootuju rovnou z /, mam k dispozici vsechny moduly.

2) A jste si jisty, ze vetsine distribuci staci opravdu jenom zmenit tenhle parametr a bezproblemu nabootuji? Ja si tim teda jisty nejsem. Viz napr. polozky MODULES a HOOKS v /etc/mkinitcpi­o.conf...

Nerikam, ze to nejde, nemam to vyzkousene. Jenom rikam, ze bych si opravdu nebyl predem jisty, ze to pujde. Napriklad bych si nelajzl to zkouset na masine nekde na druhem konci republiky, ke ktere nemam jiny pristup. S FreeBSD bych se neceho podobneho tolik nebal prave proto, ze boot je jednodussi a timpadem i mnozina pruseru, ke kterym muze dojit, je podstatne mensi.

To je velice jednoduché.

„1. zjistuju, co vsechno musim dat do initrd, abych mohl nabootovat“

Toto odhaduje program, který ti vytvoří initrd a který jde případně dokonfigurovat.

„2. zjistuju, co vsechno musim dat do /, abych mohl nabootovat“

Toto v současných systémech určuje distributor, který tvoří balíčky. Ruční přesouvání souborů ti způsobí problémy s updatem.

„Mit tu samou vec na dvou mistech je vzdycky nejhorsi mozny reseni a melo by se imho volit jenom v pripade, kdy fakt neni zbyti, protoze s tim jsou vzdycky problemy.“

Pokud máš lepší nápad, který nebude způsobovat regrese oproti metodě s initrd, tak sem s ním. Může to být feature (přes)příští Fedory a pak to zase proplout do ostatních systémů :). Nebo naopak.

Jenže je tam jeden drobný rozdíl, který nebereš v úvahu: initrd musím udržovat co nejmenší, protože jinak by se mi loadoval hodinu, zatímco v / se nemusím nijak žinýrovat. Do nějakých těch třeba půl giga se mi vejde fakt všechno, co 99.9999% systémů k nabootování potřebuje. Přesněji řečeno všechno, co potřebuji až do fáze namountování /usr.

A těch 0.0001 procent adminů podivných systémů, si holt bude muset poradit nějak jinak. Tak to holt je - a je tomu tak i s initrd, které taky nemůže myslet na všechno.

Prostě čím složitější způsob bootu a mountování /usr, tím obludnější initrd. Limitně až do velikosti normálního /.

> Pokud máš lepší nápad, který nebude způsobovat regrese oproti metodě s initrd, tak sem s ním.

Nápad na co? Jak udržet bloatware v chodu? To s chutí nechám autorům toho bloatwaru.

Nebo jaký konkrétní problém tahle šaráda (UsrMove) řeší, kromě toho, že má Linux rozbité bootování bez /usr? A co konkrétně řeší initrd, co by nešlo udělat jinak?

kromě toho, že má Linux rozbité bootování bez /usr

To je snad sám o sobě zatraceně dobrý důvod, ne?

A co konkrétně řeší initrd, co by nešlo udělat jinak?

Jinak to jde udělat taky, akorát osobně nemám žádný důvod, proč bych to dělal. Jedinci s fóbií z initramfs mohou v jednoduchých případech (pokud vám jde opravdu jen o oddělený /usr oddíl) použít např. busybox. Pokud máte / na LVM2 nebo šifrovaný, tak to samozřejmě bez initramfs nepůjde a nešlo ani doteď.

> To je snad sám o sobě zatraceně dobrý důvod, ne?

To je zatraceně dobrý důvod to **opravit** a ne vymýšlet berličky, aby se to opravovat nemuselo.

> Pokud máte / na LVM2 nebo šifrovaný, tak to samozřejmě bez initramfs nepůjde a nešlo ani doteď.

Asi je čas toho nechat, protože se motáme v kruhu. Napsal jsem snad už dost jasně, že FreeBSD umí bootovat ze ZFS rootu a žádné initrd k tomu nepotřebuje.

Jaký je principielní rozdíl mezi LVM2 a ZFS z hlediska bootování?

To je zatraceně dobrý důvod to **opravit** a ne vymýšlet berličky, aby se to opravovat nemuselo.

Ano, opraveno to bude, až se to přesune do /usr. Vymýšlení berliček typu musíme přesunout do / tohle, tohle, tamto a ještě támdlencto, jo a estě onohle, toho už mají maintaineři evidentně plné zuby. Nedává to vůbec žádný smysl.

P.S. ZFS nepoužívám. Jestli je vám tak nepochopitelné, že k tomu, abyste zprovoznil LVM2, potřebujete userspace utilitu, tak už fakt nevím, jak to vysvětlit.

>> Ano, opraveno to bude, až se to přesune do /usr.

No asi máme trochu jinou představu o pojmu "opravit"...

>> Vymýšlení berliček typu musíme přesunout do / tohle, tohle, tamto a ještě támdlencto, jo a estě onohle, toho už mají maintaineři evidentně plné zuby.

Co to je za ptákovinu? V / jsou samozřejmě všechny věci, potřebné k dalším fázím bootu STANDARDNĚ.

Imho normální boot prostě vypadá takhle:
1. zavaděč, který umí pracovat s médiem M1 (disk, nfs, ...) načíst filesystém FS1 (ext, zfs, lvm pičfs)
2. skrz médium M1 se z FS1 načte kernel a provede základní inicializace
3. vše ostatní (/home, /var, /usr, ...) je na médiu M2 s FS2 a jelikož už mám kernel a všechny moduly, bez problému si to namountuju a nastartuju libovolně bloatwarové služby z /usr

Nevidím, žádnou tak zásadní výhodu, která by vyvážila kopec nevýhod, když do tohodle přidám ještě stadium 1a "natáhnu z FS1 médiem M1 jakýsi rádobyroot".

>> Jestli je vám tak nepochopitelné, že k tomu, abyste zprovoznil LVM2, potřebujete userspace utilitu, tak už fakt nevím, jak to vysvětlit.

To s tím ale právě vůbec nesouvisí. Je nějaký důvod to nevyřešit tak, že:
1. / je minimalistický a na nějakém rozumnějším FS, pro který existuje rozumný loader
2. zbytek už si zprovozním jakkoli

Jde jenom o to, jestli řešení s initrd je elegantnější než tohle. A já tvrdím, že není. A tvrdím to ze zkušenosti, protože s Linuxem se mi tisíckrát stalo "myslel jsem, že to nabootuje, ale nenabootovalo", zatímco s FreeBSD se mi stejně hodněkrát stalo "myslel jsem, že to nenabootuje, ale nabootovalo".

Tím končím, zjevně se neshodneme a já nemám potřebu někoho přesvědčovat. Jenom jsem chtěl naznačit, že lidi, kteří znají jenom Linux mají tendenci linuxová řešení považovat za řešení sine qua non.

HOWGH.

Ano, tohle absolutně nikam nevede. Není žádná definice toho, co to je potřebné k dalším fázím bootu STANDARDNĚ.. Někdo si dá / na ext2, někdo si ho dá na LVM2, někdo si / zašifruje a klíč má na SD kartě. Jestli vaším "řešením" je "standardně" nic z toho nepodporovat, resp. znemožnit, tak tohle "řešení" si prosím nechte v BSD, nemám zájem.

P.S. LVM2 není filesystém.

Ať si šifruje co chce, ať si bootuje třeba přes médium "poštovní holub", to je úplně jedno - pořád má ten samý problém: z hardwaru X dostat nějaká data a rozumět jejich struktuře. Čili tak jako tak - ať si kdo chce co chce říká, ať si mamka slzy utírá - musí mít loader, který umí s tím HW pracovat a rozumí struktuře dat na médiu, odkud tahá ten initrd image. Oproti normálnímu mountu to má AFAIK jedinou výhodu: initrd je jeden soubor, takže ho můžu tahat jednodušeji (např. prvních X bloků média) než je přímé přimountování nějakého FS ***z toho SAMÉHO média***.

P.S. průměrně inteligentní člověk snad z výše napsaného pochopí, že pojmem "FS" v tomhle kontextu myslím "strukturu dat na mediu" a kolik je tam mezivrstev nás nezajímá. Takže že LVM není FS sice kupodivu vím, ale to je v tomhle případě irelevantní, proto jsem si to dovolil zkrátit.

Když mám root na LVM, tak přece taky potřebuju (nebo aspoň ještě do nedávna tomu tak bylo) mít aspoň /boot na nějaké normální ext partišně, nebo ne?

Potom stojí za zamyšlení, proč vlastně na té partišně nemít celý (minimalistický!) root...

Když mám root na LVM, tak přece taky potřebuju (nebo aspoň ještě do nedávna tomu tak bylo) mít aspoň /boot na nějaké normální ext partišně, nebo ne?

Už ne... (Ne, že bych to doporučil)

Potom stojí za zamyšlení, proč vlastně na té partišně nemít celý (minimalistický!) root...

No ale vždyť ho tam máte v tom initramfs!

Ach jo, já už fakt končím.

Jestli Grub umí číst data z LVM, tak LVM nemůže být důvodem, proč mít initrd.

Tečka na závěr :)

Zjevně se najdou i lidi, kteří pochopili:

Sometimes Linus (Greg KH, ...) like to say how great the haphazard/random development model is, and how every architecture mistake can be quickly and easily fixed inside kernel tree. The whole '/lib/modules' idea is a mistake, I should be able to place kernel and it's modules in one partition and rootfs in another, and vary the kernel without the slightest change to rootfs. It does not work now because before we can mount rootfs (in order to see /lib/modules), many modules need to load. Yes, with messy initrd we can do it. But this 'lib/modules' idea was a mistake.

http://kerneltrap.org/node/7874

Good point! Nebylo by od věci použít třeba /boot/kernel/* :)))

„Jestli Grub umí číst data z LVM, tak LVM nemůže být důvodem, proč mít initrd.“

Přesně tak, Grub 2 je schopný přečíst LVM a tudíž je schopný přečíst kernel, initrd a cokoli dalšího. Potřeba/nepotřeba initrd s grubem nesouvisí.

„P.S. ZFS nepoužívám. Jestli je vám tak nepochopitelné, že k tomu, abyste zprovoznil LVM2, potřebujete userspace utilitu, tak už fakt nevím, jak to vysvětlit.“

To je ostatně nepochopitelné pro mě. Teda rozumím tomu, že LVM vyžaduje userspace utilitu, jen nerozumím tomu, proč.

„Jenže je tam jeden drobný rozdíl, který nebereš v úvahu“

Bacha, tys dával najevo, že nevidíš rozdíl vůbec a že bys byl rád, aby ti byl vysvětlen. Nikde jsem netvrdil, že pokrývám rozdíly všechny.

„Nebo jaký konkrétní problém tahle šaráda (UsrMove) řeší, kromě toho, že má Linux rozbité bootování bez /usr?“

Tenhle přesun žádný zásadní problém neřeší, to jsem považoval za všeobecnou znalost.

„A co konkrétně řeší initrd, co by nešlo udělat jinak?“

Umožňuje s relativně malým kernelem bootovat na libovolném stroji, tedy nemusí být kernel zkompilovaný až u uživatele na míru danému hardware a zároveň nemusí mít zakompilované všechny možné ovladače. Umožňuje bootování z různých partition, které kernel sám o sobě neumí použít jako rootfs ani následně připojit, jako třeba LVM a šifrované oddíly. Při troše snahy umí initrd
bootovat komplet ze sítě.

>> Bacha, tys dával najevo, že nevidíš rozdíl vůbec a že bys byl rád, aby ti byl vysvětlen.

Pro pochopení byla klíčová věta "ale opravdu nechapu logiku uvazovani "nechceme to davat do /, tak to kopirujeme do initrd"."

To, že initrd se vytváří automaticky a / vytváří autoři OS není argument, protože výběr programů do / dělám jednou, ale initrd musím vytvářet pro každý stroj a po každém updatu.

>> Tenhle přesun žádný zásadní problém neřeší, to jsem považoval za všeobecnou znalost.

Fedoří dokument vypočítává několik problémů, které to má řešit - a všechny považuju za pochybné (líbil se mi jeden komentář kohosi "dělá to na mě dojem, že někdo tohle chce udělat a seč může pro to hledá argumenty libovolné kvality").

==

Ad "co řeší initrd": co píšeš, přece není doslovně pravda. Nikdy nemůžu bootovat z média, které neumím použít, to dá rozum. Vždycky musím od někud načíst kernel a initrd. A to je právě ta klíčová otázka: proč na tom místě (který musí loader umět používat!) místo kernel+initrd nemám prostě normální partišnu - buď jenom s /boot, nebo rovnou s celým / ?

Není přece např. pravda, že initrd je potřeba pro bootování šifrovaného systému - vždycky musím mít nějaké nešifrované úložiště, ze kterého natáhnu kernel+initrd. A to úložiště musí být dostatečně jednoduché (nešifrovaná oblast s jednoduchým FS), aby ho uměl použít loader.

Initrd prostě **nutné** není. Je to jenom jeden ze způsobů řešení bootování - a já si myslím, že dost nemotorný a čím dál překombinovanější. Z mýho pohledu jeho největší nevýhoda je, že si na něj lidi zvyknout a začnou ho považovat za nutnost/standard (to se píše i v tom dokumentu o UsrMove: "budete sice muset použít initrd, ale to už stejně používáte tak jako tak"). To není dobrá situace a dost to zavání windowsismem.

„Pro pochopení byla klíčová věta "ale opravdu nechapu logiku uvazovani "nechceme to davat do /, tak to kopirujeme do initrd"."“

Takhle se initrd ani nepoužívá.

„Fedoří dokument vypočítává několik problémů, které to má řešit“

Přesně tak. A žádný z nich nepovažuju za *zásadní* problém.

„dělá to na mě dojem, že někdo tohle chce udělat a seč může pro to hledá argumenty libovolné kvality“

Pro každou změnu se hledají pro a proti.

„A to je právě ta klíčová otázka: proč na tom místě (který musí loader umět používat!) místo kernel+initrd nemám prostě normální partišnu - buď jenom s /boot, nebo rovnou s celým / ?“

K čemu by to bylo? Bootloader by mohl přistupovat ke kernelovým modulům, jenže je k ničemu nepotřebuje a neumí je používat. Kernel by k nim přistupovat nemohl, takže je nemusíš přesouvat, ale můžeš je rovnou smazat.

„Není přece např. pravda, že initrd je potřeba pro bootování šifrovaného systému“

Momentálně pokud vím, tak kernel nemá v sobě žádné UI (když nepočítáš sysrq), takže pokud je šifrovaný filesystém chráněný heslem, je potřeba před jeho připojením mít k dispozici UI, které řeší userspace, který se obvykle přibaluje ve formě initrd.

„vždycky musím mít nějaké nešifrované úložiště, ze kterého natáhnu kernel+initrd“

To obvykle musíš.

„Initrd prostě **nutné** není.“

Ani jsem nikdy nikde netvrdil, že je.

„To není dobrá situace a dost to zavání windowsismem.“

Argumentum ad fenestram. Jak krásné.

Zkusím to říct ještě jinak: zkus si představit, že jsi nikdy žádné initrd neviděl.

Máš zadání: chci mít důležité části systému na RAID26, který je děsně složitý.

Jak bys to vyřešil?

Řešení 1:
Máš separátní partišnu s nějakým rozumným FS (třeba ext2), kam dáš /boot (kam logicky dáš kernel i se všemi moduly a nebudeš ho rafinovaně dávat půlku do /boot a zbytek do /lib/modules). Pak boot bude vypadat takhle: bootloader umí číst ext2, natáhne a spustí kernel, který si načte všechny potřebný moduly pro RAID26 a z něho spustí /sbin/init. Pokud je potřeba v téhle fázi něco v userspace, pak to logicky patří do /boot a nikam jinam. Zvolený FS musí umět číst i loader i kernel, ale to nevadí, protože je to FS jednoduchý a ve všech scénářích stejný.

Řešení 2:
Vyrobíš BloatedLoader(R) (prakticky vzato druhý speciální kernel), který umí číst RAID26. Pomocí něj natáhneš z RAID26 kernel a initrd. A budeš prohlašovat, že to je boží řešení, protože můžeš bootovat, z čeho chceš, a že pro bootování z RAID26 je to nutnost, protože RAID26 je taaaak složitý a vyžaduje user-space utility.

Chytře zamlčíš nedostatky:
1. kód pro čtení RAID26 musíš mít jednak v loaderu, jednak v kernelu (de facto totiž udržuješ dva různé kernely se stejnou schopností (číst RAID26), ale úplně jiným kódem)

2. musíš udržovat ekosystém pro srpávnou volbu toho, co je v initrd potřeba, a pro jeho vygenerování

3. musíš myslet na to, abys initrd vygeneroval vždycky, kdy je to potřeba

4. když disk z počítače vyndáš a dáš jinam, tak nenabootuje, protože v initrd není to, co tam mít potřebuješ

5. jo a jen tak mimochodem - dost pravděpodobně pořád budeš potřebovat nějakou formu té spešl partišny z Řešení 1, protože kód BloatedLoaderu je tak velký (nezapomeňme, že je to druhý kernel), že se ti do miniaturního bootsektoru nevejde a odněkud ho načíst potřebuješ

No takže si zvolíš Řešení 2, budeš se tvářit, že je to jediný možný řešení, protože máš přece RAID26! a když ti někdo řekne, že systém X umí taky bootovat z RAID26 a initrd k tomu nepotřebuje, opáčíš mu, že tě jeho X-ová dogmata nezajímají...

Jo a abych nezapomněl: Řešení 2 má ještě tu báječnou výhodu, že initrd musí kompletně celý překopírovat do paměti. Nejenom, že to bude nějakou dobu trvat, ale hlavně to bude potřebovat větší množství paměti na ramdisk.

bootloader umí číst ext2, natáhne a spustí kernel, který si načte všechny potřebný moduly pro RAID26 a z něho spustí /sbin/init. Pokud je potřeba v téhle fázi něco v userspace, pak to logicky patří do /boot a nikam jinam.

Gratuluji, právě jste vytvořil duplicitní / s tím, že to má ten ohromný "benefit", že to není v ono hrozném fujtajbl initramfs, kterému nerozumíte, ale v /boot. To jsme to ale vyřešili. Ufff.

Jaký duplicitní / ?

Prostě věci, které jsou potřeba k bootu*, jsou v /boot a NIKDE JINDE. Od toho ten adresář (na rozumně čistém systému) je.

* to za normálních okolností znamená jenom kernel a jeho moduly, případně ještě nějaký last-stage zavaděč.

Jasně, pokud potřebuju k namountování / miliony user-space utilit, tak by tohle schema nebylo dobrý, ale pak je otázka, jestli vůbec fs, který potřebuje user-space utility (k namountování!) je rozumně navržený.

Předem pro hnidopichy: když tady píšu "k bootu", tak ti myslím "k bootu až do fáze spuštění /sbin/init, tj. k natažení jádra, modulů a přimountování /"

Jaký duplicitní / ?

No ten, kam jste přesunul všechno nutné pro boot z toho /, protože initramfs je prostě hrozně fuj fuj blééé.

Sorry, ale na tohle fakt nemám nervy.

Přečtěte si, jak vypadá bootování ze složitějších fs - a to bez initrd - třeba tady:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot-blocks.html

http://www.wanda25.de/geli2.html

https://www.dan.me.uk/blog/2010/02/08/booting-from-zfs-raid0156-in-freebsd/

Tvůj popis řešení místo reality popisuje především tvé dojmy. Zatímco implementace RAID ti na dvou místech vadí, implementace ext2 ti na dvou místech přijde samozřejmá.

Způsob, jakým je to řešeno v linuxu je hodně univerzální. Protože každý, kdo nasazuje či distribuuje systém založený na linuxovém jádře, má jiné potřeby. Zakázat initrd z nějakých dogmatických důvodů je nesmysl. V některých případech je to užitečná věc (i kdybych uvedl jen network boot do nějaké aplikace přímo v initrd, třeba instalátoru).

Linux přistupuje k diskovému prostoru výhradně pomocí driverů. Tudíž je nutné drivery buď zakompilovat do kernelu, nebo mu je předat v archivu.

Alternativou by bylo tuhle vlastnost Linuxu změnit a umožnit mu používat nějaké rozhraní BIOSu či dalších bootloaderů pro přístup k disku. Stále bys ale musel zakompilovávat všechny FS, které očekáváš, že budou na disku použity.

Univerzalita vylučuje, že by ten FS musel být za všech okolností ext2. Takže bootloader tak jako tak bude muset obsahovat podporu použitého FS.

Je zajímavé s jakou samozřejmostí připouštíš duplikaci implementace FS a jak se stejnou samozřejmostí shazuješ duplikaci implementace RAID. Je z toho jasně vidět, že celý tvůj myšlenkový pochod je už ovládnutý touhou podpořit předem danou pravdu a ne se dobrat nějakého rozumného výsledku. Ale máš možnost to změnit.

Takže řešení 1 stojí přesně na tom samém, co kritizuješ na řešení 2.

> Tvůj popis řešení místo reality popisuje především tvé dojmy.

Jestli myslíš Řešení 1, tak to je realita, jak se bootuje v BSD. A afaik i v Solarisu do verze 10. Takže tuhle poznámku nechápu.

> Zakázat initrd z nějakých dogmatických důvodů je nesmysl. V některých případech je to užitečná věc

Souhlasím. Ale těch případů, kdy je to opravdu potřeba, je minimum. Neříkám, že initrd je potřeba dogmaticky zakázat, ale že ve většině případů není důvod ho dogmaticky nasazovat.

> Univerzalita vylučuje, že by ten FS musel být za všech okolností ext2.

Ještě jednou a už fakt naposledy: kernel a initrd se musí natahovat z úložiště, se kterým musí umět pracovat loader. Tu "univezalitu" můžeš za takové podmínky dosáhnout jednou ze dvou možností:
1. loader umí číst všechny možné filesystémy
2. loader jich umí jenom pár a kernel a initrd musí být uložen na jednom z nich

Grub například umí tyhle: FAT, FFS, ext2 + čtení konkrétních bloků z disku.

Sorry, ale fakt nikde nevidím univerzalitu, vidím 3 podporované FS (+RAW).

Říkám velmi jednoduchou věc: místo toho, abych na tyto PODPOROVANÉ FS dal kernel+initrd, raději bych z nich rovnou namountoval /boot nebo /. A tímpádem se zbavil initrd, přičemž ona UNIVERZALITA NÁSLEDUJÍCÍCH STÁDIÍ BOOTU ZŮSTANE ÚPLNĚ STEJNÁ. Pokud mi nerozumíš v tom, že ta univerzalita je stejná, potom to utněme, protože líp svůj názor už vysvětlit neumím.

Grub například umí tyhle: FAT, FFS, ext2 + čtení konkrétních bloků z disku.

To bude asi nějaký speciální BSD grub. Pro normální grub doporučuju přečíst dokumentaci.

raději bych z nich rovnou namountoval /boot nebo /.

Dík, já bych zase raději nic podobného nedělal, protože mám jeden /boot pro několik distribucí, tudíž myšlenka mountovat z bootloaderu / je úplně nepoužitelná.

„Takže tuhle poznámku nechápu.“

To jsem si všiml. Takže jinak. Tvůj způsob popisu odráží dojmy, ne skutečné vlastnosti. Zatímco jednou je duplicita implementace diskového formátu samozřejmostí, podruhé je neodpustitelnou chybou.

Tenhle přístup je značně dogmatický a v podstatě nemá smysl, abych s tebou jakkoli polemizoval, dokud nebudeš mít chuť hodnotit obě možnosti stejně kriticky (a beze strachu, že bys došel k jinému závěru než dosud).

„ale že ve většině případů není důvod ho dogmaticky nasazovat.“

Tedy bys jeho konfiguraci odstranil z instalátorů distribucí? Může být, ale je potřeba posoudit důsledky na celý ekosystém.

„Ještě jednou a už fakt naposledy“

Já budu jenom rád, když to pochopíš :).

„Sorry, ale fakt nikde nevidím univerzalitu, vidím 3 podporované FS (+RAW).“

Pak nezbývá, než tě odkázat do dokumentace současné verze GRUBu.

http://www.gnu.org/software/grub/manual/html_node/Features.html

„Říkám velmi jednoduchou věc: místo toho, abych na tyto PODPOROVANÉ FS dal kernel+initrd, raději bych z nich rovnou namountoval /boot nebo /.“

Nevím, proč mě nutíš to psát znovu, ale dobře. Když Linux startuje, nemá k dispozici žádné otevřené filesystémy.

Mountovat / v bootloaderu je nesmysl, protože / si mountuje kernel. Naopak /boot se za běhu systému vůbec nepoužívá, nemusí být vůbec mountovaný, a
dávat do něj cokoli, co může systém za běhu potřebovat je z tohoto pohledu pitomost, protože dosud tam nic takového není.

>> Tvůj způsob popisu odráží dojmy, ne skutečné vlastnosti.

Vlastnosti čeho?

>> Zatímco jednou je duplicita implementace diskového formátu samozřejmostí, podruhé je neodpustitelnou chybou.

Není žádnou chybou duplikovat jeden FS (viz níž), ale je imho úplně zbytečný duplikovat kód dvaceti filesystémů.

>> Pak nezbývá, než tě odkázat do dokumentace současné verze GRUBu.

Omlouvám se, google má na prvním místě manuál pro verzi 0.4, to jsem si nevšiml. No takže Grub jde cestou od bodu 1 k bodu 2 v předchozím příspěvku. To není žádná výhra, protože problémem dvojky je to duplikování driverů.

>> Nevím, proč mě nutíš to psát znovu, ale dobře.

Nenutím, pouze asi píšu nesrozumitelně, nebo v tom hledáš něco složitějšího, než tam je...

Pokud budu mít bootovací partišnu s jednoduchým FS (např ext2), tak z ní loader natáhne kernel. KERNEL (!!!!!) si tu partišnu namountuje (driver toho jednoduchýho fs má natvrdo), natáhne z ní libovolný potřebný moduly a poté už bootuje stejně jako s initrd.

Ta deklarovaná univerzálnost je ÚPLNĚ STEJNÁ, prostě místo initrd je bootovací partišna. Výhoda bootovací partišny je jasná:
1. neduplikují se drivery. Loader umí jenom (např.) ext2. Všechno ostatní umí kernel.
2. nic se nerozbaluje do ramdisku -> rychlejší boot, míň paměti
3. není potřeba vytvářet žádný image s jakýmikoli duplikovanými soubory. To, co se namountuje, tam už zůstane namountovaný až do vypnutí počítače. (kromě speciálních případů, kdy je potřeba něco přemountovat, ale to jsou okrajový specialitky)

Nevýhody jsou taky jasný:
1. / musí být na jednoduchým FS, kterému jednoduchý loader rozumí
2. tímpádem se v / musí udržovat pořádek a nesmí se zasírat blbostma
3. je potřeba jedna partišna navíc (pokud mám GPT nebo BSD partišny, žádný problém to není)
4. pokud z nějakýho důvodu potřebuju v / držet nějaký data, vyžadující speciální zacházení (např. šifrovaný /etc), musí se při nejbližší příležitosti tenhle adresář přemountovat z jinýho úložiště.

4 vypadá hrozivě, ale není to vůbec žádnej problém, protože přemountovat to můžu hned - klidně jako hnedka první věc po spuštění /sbin/init

Tak pokud si už rozumíme a chceš pokračovat v diskusi, omezme se prosím na téma "proč je bootovací partišna špatná a v čem je initrd "partišna" lepší" a vyhněme se prosím větám typu "popisuješ dojmy".

Pokud si pořád nerozumíme, navrhuju diskusi ukončit.

Pokud budu mít bootovací partišnu s jednoduchým FS (např ext2), tak z ní loader natáhne kernel. KERNEL (!!!!!) si tu partišnu namountuje (driver toho jednoduchýho fs má natvrdo), natáhne z ní libovolný potřebný moduly a poté už bootuje stejně jako s initrd.

Hůůůůůůů, to jsme se ale posunuli, že? Jak se to liší od stávajícího stavu?

P.S. Bootloader nepotřebujete žádný, pokud máte UEFI. Opět to neřeší nic ve vztahu k danému problému. Bootloader si sice natáhne kernel z FAT32, ale ten sám o sobě např. z LVM2 nebo z / šifrovaného přes LUKS nic nepřečte.

> Jak se to liší od stávajícího stavu?

Výhodami 1-3 a nevýhodami 1-4.

Znova opakuju, že s UEFI nepotřebujete žádný další loader pro načtení kernelu - "problém" duplikace driverů neexistuje. Další dva body - stále z toho LVM2 nebo šifrovaného / nejste schopen nabootovat. Tak vážně nevím, co jste vyřešil nebo vylepšil.

> Znova opakuju, že s UEFI nepotřebujete žádný další loader pro načtení kernelu

Souhlasím. UEFI odstraňuje problém duplikace kódu. Ostatní platí dál.

> stále z toho LVM2 nebo šifrovaného / nejste schopen nabootovat.

Cituju z předchozího příspěvku: "Pokud budu mít bootovací partišnu s jednoduchým FS (např ext2), tak z ní loader natáhne kernel. KERNEL (!!!!!) si tu partišnu namountuje"

Co přesně teda má znamenat věta "z šifrovaného / nejste schopen nabootovat."? Nerozumím jí. Co přesně nejsem schopen udělat v situaci namountovaného / (tedy v situaci kvalitativně lepší než s namountovaným initrd)?

Situace namountovaného / vůbec nenastane, což jsem snad napsal již dostatečně jasně a několikrát. Kernel si bez initramfs žádný šifrovaný / nenamountuje. UEFI loader už kernel natáhnul, leč je vám to prdlajz platné.

>> Kernel si bez initramfs žádný šifrovaný / nenamountuje.

Snažím se vysvětlit alternativní řešení bootování bez potřeby initrd. Toto řešení jsem popsal a žádný "šifrovaný /" tam není. Nevím, o čem tedy diskutujete, ale zjevně ne o tom, co jsem napsal.

Toto řešení jsem popsal a žádný "šifrovaný /" tam není.

Bezva, ale já ho tady mám a vaše "alternativní" řešení je mi na prdlajz. Na vámi popsanou situaci žádný initrd nepotřebuju. Na šifrovaný / ho potřebuju, na LVM2 ho taky potřebuju. Vytváříte alternativní řešení neexistujícího problému.

No to je bezvadný. Místo nešifrovaného / máte nešifrované initrd.

Tím bych se rád vrátil k tomu, co jsem taky už psal: "omezme se prosím na téma "proč je bootovací partišna špatná a v čem je initrd "partišna" lepší"".

V čem je tedy nešifrované initrd lepší než nešifrované (opět: minimalistické!) / ?

Jediná nevýhoda je snad v tom, že vše, co chci šifrovat (etc, home, usr, var) musím mít umístěné na jiném svazku než je /. Pokud máte dojem, že to je větší nevýhoda než jsou popsané nevýhody initrd, potom diskuse skončila, protože na to prostě máme jiný názor.

„No to je bezvadný. Místo nešifrovaného / máte nešifrované initrd.“

Což je samo o sobě o mnoho lepší situace.

„V čem je tedy nešifrované initrd lepší než nešifrované (opět: minimalistické!) / ?“

Obsahuje jen to nejnutnější, takže je relativně malý, dá se zkomprimovat a je neměnný (obvykle se generuje až při update kernelu). Tudíž má podobné vlastnosti jako kernel samotný a nepředstavuje tak prakticky žádnou další přítěž.

Malý neměnný kernel a malý neměnný initrd se pak dají zabezpečovat různě, od externího média, přes digitální podpis, až po chráněné interní úložiště. Možná vymyslíš pár dalších věcí.

„Jediná nevýhoda je snad v tom, že vše, co chci šifrovat (etc, home, usr, var) musím mít umístěné na jiném svazku než je /.“

Což je taky dost nepříjemná vlastnost.

„Pokud máte dojem, že to je větší nevýhoda než jsou popsané nevýhody initrd“

Jaké popsané nevýhody? Zatím vím o jedné jediné skutečné, že se initrd musí vůbec vytvořit. Pak o nepatrném zpoždění při bootu. A pak ještě domnělá výhoda v úspoře paměti, která je ale mylná, protože paměť naopak ušetří initrd.

„potom diskuse skončila, protože na to prostě máme jiný názor.“

Jedna věc je mít jiné potřeby, druhá věc je mít odlišný a dobře podložený názor, ale tohle bych viděl ještě na tu třetí možnost.

> Což je samo o sobě o mnoho lepší situace.

V čem přesně? Opět opakuji: MINIMALISTICKÝ /. Čili vše hodné šifrování je někde jinde.

> Obsahuje jen to nejnutnější, takže je relativně malý, dá se zkomprimovat a je neměnný

Minimalistický / je neměnný zhruba stejně jako initrd. Proč jsou ostatní věci výhoda, tomu nerozumím.

> Což je taky dost nepříjemná vlastnost.

To je otázka názoru. home, usr, tmp ani var podle mě tak jako tak na / nemají co dělat. Problém je jenom to etc. Když chci šifrovat, budu holt mít asi tak jeden soubor duplikovaný. To je pořád imho menší daň než celá infrastruktura kolem initrd.

> Jaké popsané nevýhody? Zatím vím o jedné jediné skutečné, že se initrd musí vůbec vytvořit. Pak o nepatrném zpoždění při bootu. A pak ještě domnělá výhoda v úspoře paměti, která je ale mylná, protože paměť naopak ušetří initrd.

"Vůbec vytvořit" znamená udržovat nástroje k jeho vytvoření a udržovat jeho konfiguraci. Paměť se uvolní, to je pravda. Na normálním počítači nemá smysl řešit, na embedded může být problém.

> ale tohle bych viděl ještě na tu třetí možnost

Samozřejmě můžeš mít názor jakej chceš, já jsem rád, že jsme se teď konečně dostali k diskusi o důvodech a ne o dojmech, takže bych byl rád, kdybysme se zdrželi invektiv, je-li to možný.

„To je otázka názoru. home, usr, tmp ani var podle mě tak jako tak na / nemají co dělat.“

Tento názor nesdílím a nevidím jediný důvod k tomu, aby to obecně platilo. V konkrétních případech vyčlením samostatné FS na to, co je pro mě zrovna praktické oddělit.

„Když chci šifrovat, budu holt mít asi tak jeden soubor duplikovaný.“

To o tom jednom souboru je jen zbožné přání.

„"Vůbec vytvořit" znamená udržovat nástroje k jeho vytvoření a udržovat jeho konfiguraci.“

Většina z toho se řeší stejně kvůli těm výjimečným případům, kde to bez nějaké formy initrd prakticky nejde (síťové instalace apod). Konfigurace v běžných případech je zcela automatická.

„na embedded může být problém.“

Na embedded lze obejít tím, že se initrd nepoužije a místo toho se kompiluje kernel na míru konkrétnímu modelu. Je to velmi oblíbená metoda.

„takže bych byl rád, kdybysme se zdrželi invektiv, je-li to možný.“

Nemám ve zvyku používat invektivy, kde to situace nevyžaduje, a ani netuším, proč bychom je měli používat tady.

> Tento názor nesdílím a nevidím jediný důvod k tomu, aby to obecně platilo.

Ani já ne. Taky jsem napsal, že _podle mě_ tam nemají co dělat. Čili pro mě osobně je tenhle bod nulová nevýhoda. Pro někoho jiného to nevýhoda být může. Pořád si ale myslím, že podstatně menší než nevýhody initrd.

(pro jistotu dodávám, že tahle nevýhoda platí jenom v případě šifrování a navíc nemusí být jít o 6 separátních partišen, některý věci stačí symlinkovat - např. na FreeBSD je home často symlink do /usr/home)

> To o tom jednom souboru je jen zbožné přání.

Vy jste tvrdil, že by něco muselo být duplicitní. Je na vás, abyste řekl, co. Pro jistotu jenom dodám: /etc se může přemountovat jako první věc po nahrání /sbin/initu, není důvod s tím otálet dýl.

> Většina z toho se řeší stejně kvůli těm výjimečným případům, kde to bez nějaké formy initrd prakticky nejde (síťové instalace apod).

Mně vytýkáte, že nejsem v realitě a sdílím tady dojmy... A řeknete tohle nepotrvzené nezdůvodněné tvrzení. Opět opakuji (jako protipříklad): FreeBSD bootuje ze sítě bez potřeby initrd.

Takže jsme pořád u toho samého: co bez initrd nejde? Nebo aspoň jde výrazně komplikovaněji? V čem je teda ta opodstatněnost initrd?

> Na embedded lze obejít tím, že se initrd nepoužije a místo toho se kompiluje kernel na míru konkrétnímu modelu. Je to velmi oblíbená metoda.

No ale to je samo o sobě opět komplikace: v tomhle případě musím použít úplně jiný způsob bootu, než ten tzv. "univerzální". A samozřejmě budu muset řešit zpoustu komplikací, protože initrd se stalo "standardem" i v situacích, kde vůbec není potřeba, takže se obecně počítá s tím, že ho všichni mají.

Jako klidně si mě měj za škarohlída, ale to je přesně to, o čem jsem mluvil na začítku: nějaká věc se vyřeší berličkou a potom se musí řešit situace, kdy je berlička podražena...

> Nemám ve zvyku používat invektivy

Dobře. Vyjádření "tohle bude ten třetí případ" a to těch dojmech a ne-realitě, nebudu brát jako invektivy.

Pro jistotu jenom dodám: /etc se může přemountovat jako první věc po nahrání /sbin/initu, není důvod s tím otálet dýl.

Prima, takže člověku, který chce komplet zašifrovat systém, jsme to zjednodušili tím, že místo /boot a / bude mít ještě dalších asi 10 oddílů včetně separátního /etc - protože initrd je hrozně fuj. :-)))

S dovolením už přestávám reagovat. Opět to samé: v řešení, které jsem uvedl, není žádný separátní /boot a řeč je o tom, že separátní musí být to, co je v / a zároveň to chci šifrovat. Deseti se dopočítat neumím.

separátní musí být to, co je v / a zároveň to chci šifrovat. Deseti se dopočítat neumím.

$ ls -1 /
bin
boot
dev
etc
home
lib
lost+found
media
mnt
opt
proc
root
run
sbin
selinux
srv
sys
tmp
usr
var

No a kolik z toho je *potřeba* šifrovat?

Zopakujme si výchozí situaci, cituji: "člověku, který chce komplet zašifrovat systém"

> Zopakujme si výchozí situaci, cituji: "člověku, který chce komplet zašifrovat systém"

Vzdávám se a uznávám, že tohle jsem nedomyslel: pro člověka, který chce šifrovat prázdný adresář /dev a adresáře /bin a /lib, jejichž obsah je volně ke stažení, skutečně tahle metoda není vhodná :)

Pro takového člověka skutečně initrd bude nejspíš lepší variantou :)

„Vy jste tvrdil, že by něco muselo být duplicitní. Je na vás, abyste řekl, co.“

Konfigurace sysvinit nebo systemd. Dá se zkoušet udělat nějaká berlička v initu,
ale přijde mi jednodušší takové věci vůbec nedělat. Ale dobře.

„FreeBSD bootuje ze sítě bez potřeby initrd.“

initrd je jen obyčejný archiv s userspace. Nepředpokládám, že by mělo nějaký smysl bootovat kernel bez userspace. Jasně, dají se používat věci jako NFS, HTTPFS, ale v současné době je mnohem jednodušší prsknout tam ten jeden archiv.

Opravuju tedy své tvrzení, že by to bylo přes síťový filesystém komplikovanější než s archivem.

„Takže jsme pořád u toho samého: co bez initrd nejde?“

Až na nešikovnou formulaci se sítí jsem od začátku tvrdil, že se bez initrd obejít dá. Nevím tedy, proč bych měl dokazovat opak.

„Nebo aspoň jde výrazně komplikovaněji? V čem je teda ta opodstatněnost initrd?“

Zde se musím opakovat. Úplně původní význam je odlehčení generického jádra, aby nemuselo obsahovat všechny moduly potřebné k bootování z různých zařízení. Šlo tedy hlavně o úsporu paměti.

Dále initrd umožňuje před mountováním rootfs provést různé akce, které neimplementuje kernel. Připojení šifrovaného rootfs při zadání passphrase budiž konkrétním příkladem. Linuxové LVM rovněž není soběstačné (důvody neznám). Síťová konfigurace a další věci.

Umožňuje rovněž elegantně předat po síti userspace pro instalaci nebo rescue systém třeba po FTP nebo HTTP.

Obvykle se linux bez initrd používá jen s kernelem kompilovaným na míru dané HW sestavě, což je nepohodlné jak při instalci OS, tak při updatech, tak při výměně hardware a v enterprise sféře ještě chybí testování výsledné binárky.

„v tomhle případě musím použít úplně jiný způsob bootu, než ten tzv. "univerzální"“

Na embedded platformách tak jako tak ten klasický univerzální nebývá k dispozici a celý boot bývá nestandardní už jen tím, že se často používají zcela odlišné filesystémy na zcela odlišných úložištích.

Navíc tvá výtka byla směřována optimalizaci paměti, což je další důvod, proč se stejně musí specifický build kernelu udělat. Možnost použít initrd je stále, jen to není zvykem.

„nějaká věc se vyřeší berličkou a potom se musí řešit situace, kdy je berlička podražena...“

V podstatě se na to díváš správně. Ale ptal ses na důvody a účel. Já je celkem znám, proto se snažím ti odpovídat.

Další věc je, že mám pocit, že hodně vycházíš z dogmat FreeBSD. A FreeBSD není Linux a ty rozdíly jsou v mnoha případech zásadní. Už i samotný počet odlišných distribucí dělá svoje. Já jsem zase hodně navyklý na některé představy a dogmata kolem Linuxu a rád se dozvím něco, co současný linuxový svět přesahuje, ale musí to mít hlavu a patu.

„Dobře. Vyjádření "tohle bude ten třetí případ" a to těch dojmech a ne-realitě, nebudu brát jako invektivy.“

Díky a potvrzuju, že tak ani nebyly myšleny.

> Konfigurace sysvinit nebo systemd.

No tak dobře, jeden soubor je zbožné přání, ve skutečnosti jsou to dva: /etc/rc a /etc/fstab :)

> Opravuju tedy své tvrzení, že by to bylo přes síťový filesystém komplikovanější než s archivem.

Tak na tom se můžeme shodnout: pokud chci bootovat ze sítě, ale nechci síťový filesystém, tak to pak bez image půjde těžko :)))

> Úplně původní význam je odlehčení generického jádra, aby nemuselo obsahovat všechny moduly potřebné k bootování z různých zařízení.

...přičemž se tyto moduly přesunuly do loaderu, kde jsou duplicitní. Jak moc se tím ušetří paměti, to těžko posoudíme.

Hrubě zorientovat se můžeme takhle: GENERIC jádro na FreeBSD má 11M. Kolik má Linuxové?

> Dále initrd umožňuje před mountováním rootfs provést různé akce, které neimplementuje kernel. Připojení šifrovaného rootfs při zadání passphrase budiž konkrétním příkladem.

To umožňuje bootovací partišna taky, tady žádná výhoda není.

> Další věc je, že mám pocit, že hodně vycházíš z dogmat FreeBSD.

Nechápu, co pořád máš s těmi dogmaty. FreeBSD používám jako příklad systému, kde se initrd nepoužívá a ptám se: "Čeho tak úžasného teda Linux tím initrd dosáhl"? A proč jej používá i v situacích, kde nemá žádné pádné opodstatnění?

„No tak dobře, jeden soubor je zbožné přání, ve skutečnosti jsou to dva: /etc/rc a /etc/fstab :)“

To by se dalo považovat za fatální neznalost.

„...přičemž se tyto moduly přesunuly do loaderu, kde jsou duplicitní. Jak moc se tím ušetří paměti, to těžko posoudíme.“

Ušetří se paměť za všechny moduly, které se nepoužijou. Duplicitní z hlediska RAM nejsou. Zhlediska disku a no, ale to je prkotina.

„Hrubě zorientovat se můžeme takhle: GENERIC jádro na FreeBSD má 11M. Kolik má Linuxové?“

Na mém systému (64bit fedora) má méně než 5 MB (a osobně se mi to přijde zbytečně moc, pamatuju si ho kolem 1 MB). Na embedded platformách se obvykle pečlivěji konfiguruje a mívá něco přes 1 MB, pokud se nepletu.

Pro zajímavost, můj initrd má 18 MB. Obojí je komprimované. Adresář s moduly má okolo 100 MB.

„To umožňuje bootovací partišna taky, tady žádná výhoda není.“

Popíráš již napsané, ale dobře tedy. Další lekce... ač přemýšlím, jestli tvé úmyslné ignorování již napsaného není samo o sobě urážkou.

Jde o to, čemu říkáš bootovací partition. Třeba linuxová /boot partition se v systému vůbec nepoužívá, takže ta je ze hry. A bavíme se tedy o / partition.

Bez initrd je nutnost mít rootfs mountovatelnou čistě pomocí parametru kernelu.

* Je vyloučený rootfs na LVM (kvůli implementaci)
* Je vyloučený šifrovaný rootfs (kernel neimplementuje passphrase, HW klíče a podobné věci)
* Je komplikovaný boot s rootfs na síti (obvykle se dělá z userspace a ten bez initrd chybí)
* Naroste velikost kernelu o hromadu modulů pro různé chipsety (kvůli diskům)

Najdou se i další věci, ale tyhle jsou dejme tomu z mého pohledu klíčové.

Mountovat jednotlivé podadresáře je komplikace pro administrátora. Použití initrd není.

Překrývat etc je zbytečná komplikace oproti použití initrd. Navíc překrytý etc se nedá efektivně spravovat. Je to nehorázná prasárna, navíc by se to de facto spravovalo stejným způsobem jako teď initrd, který je ale naštěstí nepotřebuje vlastní partition.

Držet v rootfs jen potřebné věci je prakticky nemožné, protože umístění souborů řeší distributor. Naopak initrd se generuje na konkrétním stroji podle potřeby (a dá se případně doladit aniž by se udělal bordel na disku).

Dodělat IO do kernelu a umožnit zadávání passphrase k rootfs by bylo možné. Nicméně by to bylo duplicitní k init podpoře passphrase, protože nemusí být
šifrovaná jenom root partition. Nehledě na to, že použití initrd umožňuje
udržet kernel čistší, když toto implementovat nemusí.

„Čeho tak úžasného teda Linux tím initrd dosáhl?“

Mně výše uvedené (a po několikáté zopakované) jako opodstatnění pro initrd stačí. Navíc jak si utřiďuju myšlenky, abych to dokázal sepsat, tak se mi čím dál tím víc zdá initrd jako nejčistší možné řešení výše uvedených usecases.

A jakékoli překrývání neprázdných adresářů a duplikace mezi RW filesystémy mi přijde čím dál tím víc jako extrémně špatné řešení.

„A proč jej používá i v situacích, kde nemá žádné pádné opodstatnění?“

Protože je to jednodušší než detekovat situace, kdy initrd není potřeba? Protože jeden způsob se na jedné distribuci lépe otestuje a je méně náchylný na chyby?

Každopádně díky za inspiraci, takhle jsem se tím nikdy neprobíral, možná to časem zužitkuju v nějakém článku :).

> To by se dalo považovat za fatální neznalost.

Dobře, nechám se poučit. Kde je problém?

> Duplicitní z hlediska RAM nejsou. Zhlediska disku a no, ale to je prkotina.

Jsou duplicitní z hlediska vývoje. O disku by mě fakt nenapadlo mluvit, tak padlej na hlavu nejsem.

> Na mém systému (64bit fedora) má méně než 5 MB

Bezva. 6M k dobru :)

> jestli tvé úmyslné ignorování již napsaného není samo o sobě urážkou. Jde o to, čemu říkáš bootovací partition.

Hele, popravdě mi trochu dochází trpělivost.

Jako je hezký, že mě chceš poučovat o mých neznalostech, to se vždycky hodí, ale bez servitků řečeno, mě sere, když napíšeš tohle po tom, co jsem tady už X-krát popsal, co myslím bootovací partišnou.

Sorry, takhle ne. Takže na zbytek nereaguju a tohle jsem jakože neslyšel, ok?

„Dobře, nechám se poučit. Kde je problém?“

Třeba v tom, že init systémy na linuxu používají úplně jiné soubory a je jich podstatně víc.

„Jsou duplicitní z hlediska vývoje. O disku by mě fakt nenapadlo mluvit, tak padlej na hlavu nejsem.“

To bude únavou, zaměnil jsem v tvé větě loader za initrd. O duplicitě v loaderu už jsem psal. Tam jsou tvé požadavky na jeden FS a dva formáty disku v linuxovém ekosystému nesplnitelné. Nezávisle na initrd.

„Hele, popravdě mi trochu dochází trpělivost.“

To není můj problém. Já tu projevuju trpělivost v extrémním množství tím, že ti opakuju argumenty, které jsi se rozhodl ignorovat.

„Sorry, takhle ne. Takže na zbytek nereaguju“

Beru to jako výraz uznání. Vzhledem k tomu, jakou jsem si dal práci s pečlivým sepsáním argumentů, že jsi zjistil, že mám pravdu. I když způsob vyjádření je pro mě trošku nezvyklý.

> Třeba v tom, že init systémy na linuxu používají úplně jiné soubory a je jich podstatně víc.

No dobře, tak teda ať neumřu blbej, které všechny soubory z /etc používá například takový Arch Linuxový init předtím, než spustí první řádku prvního startovacího skriptu?

Já mám v /etc/inittab (kterej jsem nenapsal, ok, to bylo zásadní opomenutí :))) tohle:

rc::sysinit:/et­c/rc.sysinit
rs:S1:wait:/et­c/rc.single
rm:2345:wait:/et­c/rc.multi
rh:06:wait:/et­c/rc.shutdown
su:S:wait:/sbin/su­login -p

Jaké jiné soubory v /etc teda používá? A zopakuju ještě jednou: /etc může přemountovat HNED jako první věc.

Jinak velmi děkuju za trpělivé vysvětlování a upozorňování na moje neznalosti, ale už mi to fakt přijde mírně v komické rovině. Takže za mě shrnuju takhle:

Dobrali jsme se složitě k tomu, že initrd je dobré na to, že:

1. umožňuje nemít některé věci natvrdo v kernelu, ale mít je jako modul. Odhadem se tím ušetří nějaký ty jednotky megabajtů. Což je v dnešní době velký úspěch.

2. umožní Linuxu zprovoznit root na LVM, přestože FreeBSD má root na zfs i bez něj

3. umožní Linuxu mít šifrovaný root, přestože FreeBSD ho má i bez něj: http://www.wanda25.de/geli.html

4. šifrovaný disk bych sice mohl udělat i na Linuxu jinak, ale to bych měl duplicitních asi tak 5 (ať nežeru) souborů v /etc, což je děsná prasárna a komplikace.

5. bootování ze sítě je na Linuxu bez initrd složité, přestože FreeBSD na to má jednu pár kilobytovou utilitku.

Prostě initrd umožňuje obrovskou flexibilitu.

A cena, která se za to platí, je jednoduchá (srovnej z hrůzostrašností v bodu 4!): 1. udržuju image toho, co už v systému mám.
2. udržuju spousty sriptů a konfiguráků, abych věděl, co tam mám mít
3. na generování potřebuju zvláštní software, kterej se čas od času ukáže jako naprd, tak pro jistotu napíšu novej
4. občas se ukáže, že to zas tak geniální nápad nebyl, tak to radikálně změním i v kernelu

Takže tímto děkuji za trpělivé poučování, pečlivé sepsání argumentů a zejména velmi důkladné naslouchání, přes všechny moje kolosální neznalosti.

Dík, myslím, že už mi to opravdu došlo a nebude to potřeba znovu opakovat.

Jo a nezpomeňme ještě na poslední bod

5. tato úžasná flexibilita je možná jenom díky tomu, že jsem všechen ten kód, co by bylo tak hrůzostrašné mít v jádře, napsal ještě jednou pro úplně jiný (mini)kernel, který se jmenuje Grub.

Arch Linux nepoužívám. Vše ostatní už jsem rozepsal do detailu i s odůvodněními, proč se některé věci řeší jiným způsobem než ve FreeBSD. Každopádně jsem si tím docela slušně utřídil myšlenky, za což ti děkuju. Pokud máš pocit, že to tobě nic nepřineslo, budiž.

Co mě na tom všem překvapuje je, že máš tolik argumentů proti initrd a tolik argumentů proti množství oddělených modulů kernelu, že by člověk čekal, že mě to přesvědčí, že linuxový způsob je úplně mimo a řešení ve freebsd je jediné správné. Ale nestalo se tomu tak, a to ač mi freebsd jinak v mnohém vyhovuje.

> Arch Linux nepoužívám.

Asi není potřeba používat Arch Linux na to, aby člověk pochopil, že když první řádek prvního spuštěného init skriptu přemountuje /etc, tak se z toho svět nezhroutí.

Ale asi to tak není, jenom mám kolosální neznalosti :)

> Co mě na tom všem překvapuje je, že máš tolik argumentů

Ne. Mám jediný: je to zbytečně překombinované na to, že to neumí v podstatě nic zásadního, co by nešlo jednodušeji udělat jinak.

Jestli máš pocit, že zaznělo hodně argumentů, tak to nebyly argumenty proti initrd, ale argumenty proti nepravdivým argumentům pro initrd.

Proti mám opravdu jenom ten jeden.

> řešení ve freebsd je jediné správné

Není jediné správné. Žádné řešení není "jediné správné". Bootování ve FreeBSD je jiné, podstatně primitivnější a přesto umí zjevně plus mínus to samé.

> že by člověk čekal, že mě to přesvědčí [...] Ale nestalo se tomu tak,

A tak na tom zase není nic divného, člověk by taky čekal, že když mají Linuxáci tolik argumentů, proč je Linux lepší než Windows, tak to někoho přesvědčí... Ale nestalo se tomu tak. Na desktopu pořád jednotky procent :)

Vzhledem k tomu, že už jsme přešli v tlachání, tak ještě jednou díky a přeju dobrou noc.

Dobrou.

> a rád se dozvím něco, co současný linuxový svět přesahuje

Jako to v tomhle tématu asi nečekej, FreeBSD určitě nemá nějaký geniální systém bootování, nad kterým by sis cvrknul :) (teda možná kromě toho, že část loaderu je napsaná ve forthu a proto je tak flexibilní a přitom malinká)

Jestli v tomhle ohledu může FreeBSD nabídnout (podle mýho skromnýho pohledu, nejsem žádnej guru), tak právě to, že méně je někdy více...

Ja totiž právě zas mám pocit, že udržování té děsivé infrastruktury kolem initrd nemá __hlavu a patu__ ;)

„Jako to v tomhle tématu asi nečekej, FreeBSD určitě nemá nějaký geniální systém bootování, nad kterým by sis cvrknul :) (teda možná kromě toho, že část loaderu je napsaná ve forthu a proto je tak flexibilní a přitom malinká)“

Ono je dobré si uvědomovat, že Linux není BSD, že má zcela odlišný ekosystém, zcela odlišný způsob vývoje (myslím tím nejen kernel, ale i samotné distribuce)
a vůbec spousta věcí se řeší úplně jinak.

„Ja totiž právě zas mám pocit, že udržování té děsivé infrastruktury kolem initrd nemá __hlavu a patu__ ;)“

Chápu, ale složitost infrastruktury se odvíjí právě od možností, jaké ten systém nabízí. A teď je postavený možná krkolomně, ale i tak natolik univerzálně, že
není problém initrd rozšířit o jakýkoli usecase někdo vymyslí.

Každopádně je dobré, že veškeré komplikace padaní na hlavu vývojářů distribucí a ne administrátorů systémů nebo uživatelů.

Jo a ještě ty embedded platformy jsem zapomněl, sorry za tři posty...

Jasně, že embedded bootují hodně nestandardně. Ale spíš mi šlo o princip: je hezký, když máš jedno stupidně jednoduchý řešení (univerzální ;), který pak můžeš použít víceméně všude, právě proto, že je tak stupidní. Jakmile máš řešení překombinovaný, který má spoustu předpokladů a začne se masově používat, tak se zapomene na to, že tam ty předpoklady vlastně jsou (na normálních platformách se neprojeví).

...no a pak dochází k takovým věcem, jako že se zjistí, že vlastně nejde nabootovat, když není namountovaný /usr, což se do té doby považovalo za normální věc...

...no a aby to teda šlo, když to nejde kvůli těm zapomenutým předpokladům, tak se vymyslí další konina, která do systému zavede zase kupu dalších předpokladů. .. a celá tahle šará jde do čímdál většího kopru. Windows budiž odstrašujícím příkladem.

„Není žádnou chybou duplikovat jeden FS (viz níž), ale je imho úplně zbytečný duplikovat kód dvaceti filesystémů.“

Jak myslíš. Ale pokud máš pocit, že je možné v celém linuxovém světě prosadit jedno konkrétní rozložení disku a jeden konkrétní filesystém, tak bych tě rád upozornil, že jsi na omylu.

„KERNEL (!!!!!) si tu partišnu namountuje (driver toho jednoduchýho fs má natvrdo)“

A kde má driver na řadič disku a související moduly? Popřípadě na řadič sítě, pokud by rootfs byl čistě náhodou ze sítě?

„Ta deklarovaná univerzálnost je ÚPLNĚ STEJNÁ“

Umět bootovat jen z jednoho FS nemá s univerzalitou nic společného.

„2. nic se nerozbaluje do ramdisku -> rychlejší boot, míň paměti“

Ve skutečnosti je to po bootu víc zabrané paměti (zakompilované drivery).

„1. / musí být na jednoduchým FS, kterému jednoduchý loader rozumí“

(jediný podporovaný fs, jediné podporované rozložení disku)

Takovéhle požadavky linuxovému světu nevnutíš a nezabráníš použití alternativních FS a alternativních rozložení disku a tím i modulárních
bootloaderů s podporou většího množství FS a rozložení.

„3. je potřeba jedna partišna navíc (pokud mám GPT nebo BSD partišny, žádný problém to není)“

Podle mě jsi zapoměl zdůvodnit, jaktože FS smí být pouze jeden, zatímco formátů disku smí být vícero.

„4. pokud z nějakýho důvodu potřebuju v / držet nějaký data, vyžadující speciální zacházení (např. šifrovaný /etc), musí se při nejbližší příležitosti tenhle adresář přemountovat z jinýho úložiště.“

V tom případě ale musím mít v /etc základní věci a tudíž bude celý ten podadresář duplikovaný. To mi přijde na údržbu podstatně složitější než initrd.

„4 vypadá hrozivě, ale není to vůbec žádnej problém, protože přemountovat to můžu hned - klidně jako hnedka první věc po spuštění /sbin/init“

Takže ještě budu muset řešit duplikování konfigurace sysvinit a/nebo systemd.

„Tak pokud si už rozumíme a chceš pokračovat v diskusi, omezme se prosím na téma "proč je bootovací partišna špatná a v čem je initrd "partišna" lepší" a vyhněme se prosím větám typu "popisuješ dojmy".“

Nejednalo se o útok, ale o to, že ty máš určitou představu, jak to někde funguje a jak to fungovat má. Tu představu považuješ do jisté míry za dogma.

Pokud se chceš naučit něco nového o bootování na linuxu, máš možnost. Pokud mi chceš říct něco nového o tom, jak to bootování může fungovat, taky budu rád.

Ale točit pořád dogmata:

1) Zdrojový kód bootloaderu smí implementovat pouze jeden konkrétní filesystém.

2) Zdrojový kód bootloaderu smí implementovat ... rozložení disku.

3) Duplicita souborů v initrd je špatná.

4) Duplicita konfigurace sysvinit/systemd v /etc je v pořádku.

5) ...

To je tak trochu o ničem, nemyslíš?

> ty máš určitou představu, jak to někde funguje a jak to fungovat má. Tu představu považuješ do jisté míry za dogma.

Ne. Já zdůvodňuju, proč podle mění není initrd nutné a ve většině případů přináší víc komplikací než užitku.

Dál se prosím omezme na téma "v čem je initrd lepší než minimalistická / partišna s nějakým jednoduchým filesystémem".

Pokud si nerozumíme v tom, že věc z prvního odstavce jde redukovat na věc druhého odstavce, navrhuji diskusi ukončit.

A čo si predstavujete pod takým pojmom "minimalistická partišna", Kefalín?

Partišna obsahující vše, co je potřeba k dalším fázím bootu.

Aha, no to jsme tedy opravdu moc nepokročili. Takže stávající / zduplikujeme do /boot, ano? A já měl dojem, že vám hrozně vadila ta duplikace. :P

A není náhodou místo opětovného vymýšlení kola lepší přimountovat UEFI oddíl, zkopírovat tam ten kernel a initramfs, vytvořit jednořádkový /EFI/arch/linux­.conf a nabootovat? :-)

>> Takže stávající / zduplikujeme do /boot, ano?

Prosím, opravdu se zkuste držet toho, co jsem napsal. O duplikaci něčeho taky myslím nebyla řeč.

„Ne. Já zdůvodňuju, proč podle mění není initrd nutné“

Tak to je ovšem zvláštní věnovat tolik úsilí zdůvodňování něčeho tak samozřejmého, na čem se od začátku shodneme.

„a ve většině případů přináší víc komplikací než užitku.“

A tohle je takové statistické tvrzení, které vůbec nic nepřináší. Ono totiž moc nezáleží na tom, jestli je těch případů většina nebo menšina, ale jak moc jsou z hlediska vývoje toho systému významné.

„Dál se prosím omezme na téma "v čem je initrd lepší než minimalistická / partišna s nějakým jednoduchým filesystémem".“

K tomuhle tématu už jsem této diskuzi napsal vše potřebné.

> Tak to je ovšem zvláštní věnovat tolik úsilí zdůvodňování něčeho tak samozřejmého, na čem se od začátku shodneme.

No ono to asi bude tím, že jsem reagoval většinu času na výtky, které byly pro věc nepodstatné a tímpádem jsme se k jádru dostali až teď.

Stejně je ale zajímavé, že to je taková samozřejmost, když to "není realita" :)

Btw, můžeš se pokusit to vysvětlit Lolovi, který s tím zjevně nesouhlasí.

„Btw, můžeš se pokusit to vysvětlit Lolovi, který s tím zjevně nesouhlasí.“

To ti s radostí přenechám :).

Takmer na všetkom mám Gentoo. Už viac ako rok mám na všetkých strojoch /usr na zfs a pre pripojenie /usr si kernel potrebuje potiahnuť knižnice z /lib. / mám väčšinou xfs. Na notebooku to už mám vyriešené, aj / je zfs, bootujem s initramfs. Na serveri ma čaká výmena jedného disku, pri tej príležitosti urobím to isté (/ na zfs) a potom ma to isté čaká aj na desktope. Nie je to nič hrozné, ale nerád zasahujem do niečoho, čo bez problémov funguje.

Bohužel v posledních letech v rámci "pokroku" dochází v distribucích k dost nepochopitelným a idiotským "vylepšením".
Nejde jen o debilizaci grafických prostředí, ale právě i o záležitosti z nichž jednu(naštěstí tu méně významnou) popisuje tento článek. Elegance, jednoduchost, kontinuita a spolehlivost Unixu se vytrácí a stále více se to podobá nepřehledné změti přeplácaných neprůhledných Windows.
Snad je to tím, že dochází k výměně generací a nejen distribuce začínají ovlivňovat děti ovlivněné Microsoftem :-(

V podstate souhlasim.

Jestli to chteji udelat, tak "koser" by bylo udelat novy draft FHS a ten se pokusit schvalit, ale na druhou stranu zabrante tomu v takove komunite jako je otevreny software.

- vetsinu systemu mam s oddeleny /usr, /var, /tmp, /home, /
- chci oddelene systemove veci od lokalne instalovanych

V clanku me fascinovalo vyjadreni ArchLinuxu: "Nezajímá nás FHS. Je zastaralé, irelevantní a mrtvé", beru to skoro jako urazku od vyvojaru teto distribuce v jiste slova smyslu je to na facku, ale nerad bych nekoho urazil berte s rezervou.

Jestli se nemylim, pak FHS 3.0 draft uz existuje (nevim jestli je tam tohle uz zakomponovano). To je jen nekomu nechtelo cekat, az to bude schvaleno...

A zminovat v tehle situaci jako "vyhodu" tehle lib-bin-sbin sarady lepsi kompatibilitu s jinyma unix/linux systemy povazuji od fedory za spatnej vtip.

Instalovat do /home? Tady byl nekdo prilis dlouhou na slunicku...

a od čeho máš asi adresáře /usr/local a /opt? Popř /usr/local/opt; /usr/games a /usr/local/games?

>> Elegance, jednoduchost, kontinuita a spolehlivost Unixu se vytrácí a stále více se to podobá nepřehledné změti přeplácaných neprůhledných Windows.

Naštěstí jsou tu pořád ještě *BSD systémy, kde se takové zhůvěřilosti dějí v daleko menší míře.

takze mit knihovny a binarky jen na jednom miste je preplacanost? lulz

vrchol elegance a jednoduchosti je predpokladam mit v $PATH 20 cest :P

Přesně tak. Kontinuita, věci jsou stále na svých místech ...
Kdo chce dodržení tradic, pro toho je FreeBSD.
Kdo chce být stále překvapován ... ;-)

>> Kdo chce být stále překvapován ... ;-)

Nebo taky "kdo chce neustále řešit workaroundy pro rozjetí něčeho, co se rozbilo workaroundem workaroundu, kterým se obchází špatná řešení zvolená v minulosti..."

Poslední dobou si dost často říkám, že kdyby se Linuxová komunita víc věnovala promýšlením řešení, než překotné implementaci nespecifikovaných a nedomyšlených věcí, prospělo by to úplně všem...

proč jsem si vzpomněl na projekt GNU (který zřejmě nikdy nebude dokončen, protože vždy když je hotova aspoň něco málo, přijde někdo s lepší a domyšlenějším nápadem a je proto třeba to implementovat od základu místo již existujících řešení)?

Myslíte Hurd? Ten se IMO potácí v problémech slepic a vajec.

jj, to mám přesně na mysli. Ale ani tak to není odpověď na mojí otázku...

Koukam na ty "vyhody" ktere (jak uvadi fedora) tato zmena prinese, a nevim jestli se smat nebo brecet. Nejlepe to tam snad popsal nakej stevea:

"...no major problems nor great value..."

Presne to si take myslim. Lidi budou breptat, presto si casem zvyknou, jenze to vlastne neprinese vubec nic kvuli cemu by melo smysl do tehle zmeny jit. Jestli nekdo povazuje system za prehlednej kdyz nacpeme /lib /bin /sbin do /usr/ (a v / ponechame linky), tak potes panbuh! Taky mi neni jasne, o jake "kompatibilite" s jinymi unix/linux systemy tam mluvi, kdyz vlastne vybizeji lidi aby si nevsimaly FHS a a udelaly si to po svym...

Ten program se jmenuje env a měl by mít cestu /usr/bin/env. Třeba místo #!/usr/bin/python se píše #!/usr/bin/env python. Obecně je to doporučovaný postup, protože nikdy nevíš, jestli na daném systému není něco umístěno třeba v /usr/local.

Přílišné slučování je na škodu, co když někoho napadne sloučit bin s sbin? Bezpečnostní dopady žádné, zjednodušší se konfigurace $PATH (stejná pro uživatele i admina).

Je otázkou co kdo z nás považuje za přílišné. U mě je např adresář /opt je u mě link na /usr/local/opt a /usr/games je link na /usr/local/games a to je mp na /dev/sda4. Je tam ještě pár adresářů, které hodlám trošku poupravit, ale to počká až po aktualizaci na novou verzi Debianu.

Jinak já jsem pro, také mám rád stejné věci na jednom místě. Pokud to však může někomu dělat potíže (jak tu pár lidí už poznamenalo) určitě by se to dalo nějak pořešit nějakým nastavením pro instalační systém.

Akorát bych tak hulvátsky neposílal do temných míst existující standardy

No to je argument jak noha.

Standardní řešení existuje, ale já si nepamatuju, jak se ten příkaz jmenuje, tak ho nepoužívám a jsem rád, že se to vyřeší jinak.

Lze se na to dívat i jinak: proč zpomalovat všechny skripty tím, že se před interpreterem spustí ještě jeden program (totiž env), když by stačilo dohodnout se na pevné poloze každého interpreteru.

Spoustu věcí by se vyřešilo, kdyby se lidi uměli dohodnout. Jenže neumí. Daleko větší cool-faktor, než se dohodnout na standardu, má, když si každý Lojza udělá "svou distribuci" a vymyslí si všechno podle toho, jak to on považuje za geniální.

Bohužel. A možná proto ta Arch dělá tak "na hulváta". Prostě se to uvede do praxe a uvidí se.... Ono v Linuxu, kde do všeho kecá až moc lidí naráz to asi kolikrát jinak ani nejde. A možná je to i dobře.