Sjednocení /bin a /usr/bin

Přišel s tím Solaris...

Windora... to je chytry, to si vymyslel sam?

A kdyz chci mit /usr na jiny partisne nez je root, tak ji jako namountuju jak kdyz nebudu mit /bin? To je ale genialni napad zase...

Zkus initramfs...

to podla http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken nieje mozne ani teraz

to se tyka pouze systemd

To není ani trochu pravda. Systemd (jak je též zmíněno v odkazovaném článku) nemá s odděleným /usr vůbec žádný problém. Jen tak nějak z dobré vůle vyhazuje varování, aby si uživatel důkladně popřemýšlel, jestli ten oddělený /usr potřebuje (pokud ano, může varování vesele ignorovat).

Bohužel totiž ostatní komponenty systému (zejména udev) v nepřítomnosti /usr tiše vybuchnou a uživatel na to přijde, až když řeší, proč mu netiskne tiskárna či neakceleruje grafika (kvůli špatným ACL na /dev/ souborech).

to se tyka pouze systemd

V první řadě je třeba se zamyslet, jestli je pro to relevantní důvod. Sám jsem před pár dny prošel migrací /usr ze separátního FS na root FS na jedné ze svých stanic. Předchozích mnoho let jsem tvrdošíjně vytvářel oddělené /usr, aby byl co nejmenší a tudíž obtížně zničitelný root fs; taky jsem reportoval spoustu chyb ve všemožných komponentech způsobených odděleným /usr. Konečně jsem ale dospěl k názoru, že dostatečně pádný důvod pro oddělený /usr nemám a nestojí mi to za tu práci.

Jediná rozumně znějící motivace pro separátní /usr je jeho sdílení mezi více stroji a v tomhle případě právě navrhovaná změna je krok správným směrem (všechna sdílitelná readonly data z / se přesunou na /usr a na kořeni zůstane jen konfigurace). V takovém případě pak je třeba mít potřebné utility pro mount /usr v initramfs, stejně jako tomu bylo doposud s rootfs (binárky z rootu se tedy přestěhují buď do /usr nebo initramdisku podle toho, jestli jsou či nejsou třeba k přimontování /usr).

Napadá-li někoho jiný důvod pro separátní /usr, který stojí za tu práci, sem s ním.

Nedostatek mista na lokalnim ulozisti u embedded zarizeni, kdy presunuti /usr na nfs usetri spoustu mista a zaroven umozni se systemem pracovat v pripade vypadku site.

Embedded zařízení se to vůbec netýká, tak si každý zbastlí nějakou hrůzu tak, jak umí, a krom toho se vůbec nepoužívá udev, ale přinejlepším mdev, případně nedejbože statický /dev.

Pokud na nich nechcete provozovat treba debian, pak chapu, ze vam to je jedno.

Myslim, ze to mam nastudovane (koneckoncu par portu na obskurni architektury mam za sebou) ale moc rad se dozvim, jak treba nahrajete initramfs v CFE bootloaderu, ktery to neumi.

V jedno prispevku napisete, ze to Debian ma vychytane a v druhem, ze nevite a ze je vam to ukrade. Tak jak to tedy je? Zacinam mit pocit, ze nejste kompetentni to vychytanost posuzovat.

A proc jste se tedy zapojoval do diskuze o embedded, kdyz vas nezajima a neorientujete se v ni? A jeste takovym neprijemnym zpusobem.

A kde tak remcam? Muj prvni prispevek je reakce na Tomáše Trnku, ktery se ptal:

"Napadá-li někoho jiný důvod pro separátní /usr, který stojí za tu práci, sem s ním."

a proto jsem mu rekl, ze to je sikovne u embedded zarizeni, protoze pak muze veci, ktere nejsou nezbytne nutne pro chod systemu, umistit na sitove uloziste. Je to konfigurace, kterou sam pouzivam, a prijde mi prakticka. Protoze ji pouzivam k plne spokojenosti, jsem si jist, ze jsem si nestezoval, ze to nefunguje -- to by preci nedavalo smysl!

tradicne unixovy system ma byt schopen nabootovat bez /usr, /usr si muze mountovat treba pres nfs.

je to smesne, zlaty bsd, tak to stale maji tak, jak to ma byt. (i kdyz /usr/local/etc na freebsd se me nikdy nelibilo!)

/usr si muze mountovat treba pres nfs.

Nejní nad to si to důkladně přečíst, viď. Zejména tuhle část:

Example: /usr Network Share

With the merged /usr directory we can offer a read-only export of the vendor supplied OS to the network, which will contain almost the entire operating system resources. The client hosts will then only need a minimal host-specific root filesystem with symlinks pointing into the shared /usr filesystem. From a maintenance perspective this is the first time where sharing the operating system over the network starts to make sense. Without the merged /usr directory (like in traditional Linux) we can only share parts of the OS at a time, but not the core components of it that are located in the root file system. The host-specific root filesystem hence traditionally needs to be much larger, can not be shared among client hosts and needs to be updated individually and often. Vendor-supplied OS resources traditionally ended up "leaking" into the host-specific root file system.

Opravdu nesnáším výkřiky typu "má být schopen", "jak to má být" bez nějakého podložení. Ono to totiž spíš je "já si myslím, že by mělo ..." a to už je rozdíl, protože o druhé variantě se dá diskutovat proč a jak.
Docela by mně totiž zajímalo, kolika lidem by stačilo to, co mají v /sbin a /bin na nějakou plnohodnotnou opravu nebo něco podobného. Ano, fsck a pár drobností ano, ale zbytek je na /usr (joe,ssh,mc,rsyn­c,...). Stejně při opravě FreeBSD první řeším mount /usr, protože bez něj jsem jak bez ruky. Proto si myslím, že spíš než lkát na tím, že systém má najet bez /usr, je lepší se zamyslet, proč a co s tím. Já mám na každém Linuxu nainstalovaný RipLinux (jsou to dva soubory v /boot a spustit se dají v nejhorším z grubu z cmdline). Tedy, pokud bych měl k dispozici věci, ze kterých mi najede /, mám k dispzoici i kompletní RipLINUX (vše má v initrd image, nepotřebuje nic dalšího). A rovnou mám k dispozici systém, kde funguje vše, co potřebuju a když nechci, nemusím mountovat ani ten /...

P.S. A je i zajímavá nekonzistence mezi tím, že to mají jak to má bát a přesto se nelíbí /usr/local/etc ... :-)

To ze ty mas jinej nazor, ale vubec neznamena, ze to tak byt nema, respektive ze to tak nebylo od zacatku navrzeno jako v tomhle pripade, jak uz napovida i samotny nazev adresare /usr
Mozna by neskodilo si o tom neco precist: http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

A přesně opačně, to že někdo má jiný názor, neznamená, že to tak má být. FHS samozřejmě znám a souhlasil bych, kdyby někdo říkal, že podle FHS to tak má být, pak by se dalo spekulovat o tom, esli to chtějí mít podle FHS nebo ne. I když se musím přiznat, že si nevzpomenu, zda je proti FHS, aby ty adresáře byly jako linky...
Stejně tak se nebráním myšlence, že to tak bylo navrženo od počátku. A už vůbec neřeším, jestli je to lepší nebo ne, jen prostě říkám, že nemám rád proklamace typu "něco má nějak být" bez podložení proč.

Na to je jednoducha odpoved: ano, ma to tak byt, protoze to tak bylo navrzeno. A ne linky by snestacily, to pak uplne ztacelo smysl...

Ta odpověd je už lepší. A teď se můžem začít bavit, jestli je potřeba držet se toho, jak to bylo navrženo.
A jestli by stačily linky, to je pak otázka, proč se to rozděluje. Jestli kvůli přehlednosti, kvůli tomu, aby všichni (uživatelé i programy) věděli, kde co hledat nebo kvůli tomu, aby si to člověk mohl dát na samostatnou partition (že bych si dal /etc na samostatnou partition a mountoval ji později?).

Samozrejme neni se toho nutne drzet. Je mozny se vyprdnout na tuhle adresarovou strukturu uplne. Jedna distribuce kdysi mela adresarovou strukturu podobnou Windows.
/etc samozrejme na jinou nez root partiotion dat nemuzes. Ten je narozdil od /usr k nabehu zakladu systemu potreba.
Ale proc to menit za linky? Pokud adresare /bin, /sbin a /lib ve filesystemu nechci pouzivat, tak proc tu zmenu neudelat poradne a nesmazat je uplne?

Mně osobně se líbí idea mít ty věci na jednom místě a nacpat linky všude tam, kde by to mohl někdo/něco hledat. Aspoň nebudu muset při psaní scriptů pořád koukat, jestli je sed/grep/ls/--- v /usr/bin nebo jen v /bin :-)

To je presne ten duvod, proc mne by se to vubec nelibilo. Takovejhle bordel, kdy by to kazdej psal jinak...

to mě zaujalo, můžete to rozvést? Načítáte z grubu idso obraz nebo? díky

Dlouhodobý problém je v tom, že některé binárky jsou kompilovatelné/in­stalovatelné hned z několika balíčků, a mají odlišnou funkčnost (podpora některých přepínačů atd). Často se pak stává, že je důležité odkud daná binárka je. V distribucích jako je debian je to prostře vyřešeno tak, že se o původ dotyčného cmd nástroje stará správce distribuce.

Co se BSD týče, tak ty často mají právě BSD nástroje v /bin a pak v /usr/bin nebo /usr/local|pkg|co_j­a_vim/bin nástroje GNU. Dobrá je třeba distribuce slackware, která má z důvodů kompatibility několik verzí taru zároveň. (tak tomu alespoň bylo).

A důvody ? To je jednoduché, každá distribuce / systém má nějaký svůj minimalistický základ, který je funkční. Ale to neznamená, že obsahuje standardní resp. plně použitelné nástroje. Krásným příklad může být takový sh, ash, bash atd.

A co takhle sjednotit jeste /usr/local/bin ?

Mám takový dojem že ani pes by po něm neštěknul. :-) Akorát u BSD mají pocit, že /usr/local je výborné místo, kam všechno z ports nacpat.