Fedora chce zrušit rozdělení /usr/bin a /bin

Fedora chce zrušit tradiční linuxové oddělení /bin a /usr/bin a /lib a /usr/lib (a to samé s /sbin). To samé už udělal Solaris a zároveň by díky symbolickým odkazům byla zachována kompatibilita. Celkově by se věci i zjednodušily.

28.1.2012 00:03 | Luboš Doležel (Doli) | Zajímavý projekt

Komentáře

[Adam]

Vie mi niekto vysvetlit z historickeho hladiska preco existuje /bin a /usr/bin a /lib a /usr/lib? lebo /usr/local/* mi je vcelku jasne a ma to logiku ale toto nie...

[Ruža Becelin]

Strucne receno - /bin, /lib a /sbin byvaly na systemovem disku a obsahovaly vsechno, co administrator potreboval k oprave systemu, zatimco /usr byval na samostatnem oddilu/disku/poli a pripojoval se az pozdeji...

[luky]

hlavne casto byval na siti a sdileny, aby se usetrila kapacita.

[lertimir]

A také celý strom /usr byl mnohdy připojován jako reade only.

[Tom]

Pokud vim, jde o historicke rozdeleni - /bin a /sbin byly primo na zakladni partition, byly tam zakladni binary a do /usr se montovala dalsi partition. Takze / mohl byt maly disk.

[Peter Fodrek]

pokial viem

tak plati dohoda

bin -spustatelne suboru beznym uzivatelom sbin -spustatelne suboru superuzivatelom (rootom) lib - kniznice k programom

/ - casti, ktore su potrebne na start systemu resp. nie su konfigurovatelne istalatorom distribucie a musia byt vzdy nainstalovane /usr - casti nainstalovane balickovacim systemom distribucie-volitelne instalacia /usr/local - programy instalovane uzivatelom zo zdrojovych suborov /opt -programy z repozitarov tretich stran

videl som uz distribucie, ktore mali /usr/local a /opt naopak preto si myslim, ze skor tieto dava adresare bz sa mali zlucit..

[rastos]

Filesystem Hierarchy Standard

[x]

V parodiich na OS a Unix to neni poradne popsano v man, takze to vypada, ze to je jedno, ale nema byt:

/bin/      User utilities fundamental to both single and multi-user
                environments.  These programs are statically compiled and
                therefore do not depend on any system libraries to run.

/usr/bin/      Common utilities, programming tools, and
                          applications.

/usr/sbin/     System daemons and utilities (executed by users).

  /sbin/     System programs and administration utilities fundamental to
                both single and multi-user environments.  These programs are
                statically compiled and therefore do not depend on any system
                libraries to run.

[pavlix]

These programs are statically compiled and therefore do not depend on any system libraries to run.

Mám dojem, že jsi trošku offtopic, protože tohle v drtivé většině linuxových distribucí vůbec neplatí. Na nějaké staticky linkované binárky si tu (skoro) nikdo nehraje.

[lukve]

mam taku malu otazku .. mne napriklad pride nelogicke ze moduly jadra su v /lib/modules a nie napriklad v /boot ako to ma napriklad FreeBSD.

teda nieco v style

 

/boot/vmlinuz-3.1.0

/boot/modules/3.1.0/*

 

potom by to malo tu vyhodu ze vykonna cast jadro a moduly by sa dali dat na samostatnu /boot particiu

[SPM]

Zase by ta /boot partišna musela být poměrně velká... na několika strojích mám jenom pár MB boot a zbytek už je na lvm; pokud bych takhle chtěl mít několik kernelů, tak bych /boot musel výrazně zvětšit.

[vencas]

Moduly jádra nejsou k nabootování (tj. co přečte a puistí lilo/grub) potřeba, natahují se běžícím, nabootovaným jádrem až z disku. Na /boot by se tak zbytečně plýtvalo místem. Zadruhé technicky jsou moduly knihovny, takže do /lib patří.

Dnes je to asi víceméně jedno, protože initramdisk mnohé moduly z /lib/modules obsahuje nakopírované (a zkomprimované); ale v dřevních dobách, které ještě trochu pamatuju, se ovladače pro FS a řadiče disků musely zakompilovat do jádra, aby se jádro pak mohlo dostat k dalším modulům.

[Michal Kubeček]

Dnes je to asi víceméně jedno, protože initramdisk mnohé moduly z /lib/modules obsahuje nakopírované

Obsahuje ale jen ty, které jsou potřeba před přimountováním kořenového filesystému, což je jen velmi malá část.

[pc2005]

Kdyby byly moduly jádra na stejném úložišti jako jádro (u embedded klidně 8MB ve flash), tak by mohly být rovnou v jádře.

[blami]

A to klidne muzou ne?

[pc2005]

Když budou přímo v jádře, tak se budou špatně updatovat, stejně tak jako když budou spolu s ním na nějaké NAND flash natvrdo zapájené na desce.

[Gilhad]

To nemusí být vždy pravda - jednak můžu mmít systém určený k běhu na různých HW, pak mám v modules ovladače pro mraky síťových karet, zatímco na konkrétním stroji se použije jen ten jeden (dva, tři ...) který je potřeba (obdobně ostatní HW), druhak se někdy hodí modul vyhodit a znovu nahrát, pokud v něm něco pochcípne, nebo se ne zcela dobře chová, třeťak můžu (pokud mám té paměti extra málo) zavádět moduly jen pro aktuálně používaný HW a jakmile ho nepotřebuju, tak je zase z paměti vyházet.

Na normálním desktopu to sice nebývá potřeba, ale jsou situace, kdy se to hodí.

[pc2005]

Hmm myslím, že sis vybral vlastnost, o kterou jsem v postu neuvažoval .

/boot na FAT, tohle kernel/drivers/leds/ledtrig-heartbeat.ko na fat nenacpeš (nebo se to nebude líbit microsoftu). Kdybych měl všechny moduly pro všechny varianty v /boot, tak bude /boot dost velkej. Proto by nebylo dobré cpát moduly na stejnou partišnu jako jádro.

[David Jaša]

Všechny moduly potřebné k bootu jádra v /boot jsou - zabalené do initrd.

[pavlix]

mne napriklad pride nelogicke ze moduly jadra su v /lib/modules a nie napriklad v /boot ako to ma napriklad FreeBSD.

O FreeBSD nevím, ale v kontextu Linuxu je to totální nesmysl.

Moduly jádra se zavádějí za běhu systému, ne při bootu. Oddíl /boot se naproti tomu za běhu vůbec nepoužívá a ani není potřeba ho mít namoutnovaný (výjimkou budiž rekonfigurace bootloaderu či instalace nového jádra).

Mělo by to jen samé nevýhody, jako zbytečné zvětšení /boot apod. Moduly jsou tam, kam patří, mezi ostatními moduly/knihovnami.

[CiV]

To same se da ocekavat v openSUSE 12.2

diskuse na opensuse-factory

[Michal Kubeček]

IMHO je ještě předčasné to tvrdit. Greg, který s tím přišel, není jako lidé kolem systemd, takže to nebude tlačit přes mrtvoly a bude chtít nejdřív dosáhnout nějakého konsensu. Takže stát se to může, ale rozhodně bych přesun už ve 12.2 ještě nebral jako hotovou věc.

[David Jaša]

není jako lidé kolem systemd

Na fedoří konferenci v Brně bude mít Rainer Gerhards (autor rsyslogu) přednášku mj. na téma "rsyslog vs. journald - myths and facts.". Su zvědavej, jestli Lennart vydrží mu neskákat do řeči.

[SPM]

Jenom jestli to nedopadne stejně, jak chtěli přejmenovávat ethX :)

[blami]

To taky udelali. Alespon na mem notebooku eth0 ve Fedore neni (a pekne me to stve).

[Solitary]

Ted je to em1 ... jaky byl vubec duvod? Bez otazek jsem tento fakt prijal, tak by me to zajimalo.

[8an]

Očíslování síťových rozhraní závisí na tom, v jakém pořadí se natáhnou moduly, což od přechodu na udev hotplug může být úplně náhodné. První pokus o řešení bylo ukládání MAC adres, ale s tím jsou zas problémy při výměně hardwaru: u serverů je běžné, že pokud se něco rozbije, technik od dodavatele v rámci podpory přiveze nový a přehodí disky. Jenže kvůli změně MAC by se pak nenakonfigurovala síť a server by nefungoval, dokud by ho správce nepřijel nastavit. V RedHatu proto hledali lepší řešení a inspirovali u FreeBSD, kde se jméno liší podle ovladače a ovladač čísluje rozhraní deterministicky např. podle pořadí na sběrnici.

[Ruža Becelin]

Na mem Dellu mam p5p1, coz je jeste vetsi narez...

[michich]

Karta v 5. PCI slotu, 1. port na kartě.

[Ruža Becelin]

Coz je fajn u serveru, ale u jednoportove PCIex integrovane sitovky zbytecne. Zajimave, ze kdyz do toho sameho PC vrazim PCMCIA kartu, tak je to najednou eth1...

Ono na tohle tema bylo diskuzi dost, ja se klonim k nazoru, ze kdy mi shorely sitovky a nahradil jsem je jinymi, tak se zase jmenovaly eth0-X, zatimco Solarisi e1000g0 je fajn, kdyz chce clovek vedet hned, co ma za typ sitovky, ale hur se nahrazuje.

Jenze dneska uz je to pase, od te doby, co mame udevd, je vymena sitovek fakt zazitek...

[Mti.]

aha.. tim se vysvetluje to p10p1 na mem skromnem desktopu

[michich]

To obvykle znamená, že BIOS lže. Čísla slotů podle BIOSu se dají vyčíst z dmidecode.

[Mti.]

no... uprimne... hadat se s mocnym BIOSem nebudu, stejne sem ten interface strcil do bridge a odkazuji se uz jen na br0

[pavlix]

V RedHatu proto hledali lepší řešení a inspirovali u FreeBSD, kde se jméno liší podle ovladače a ovladač čísluje rozhraní deterministicky např. podle pořadí na sběrnici.

To jako že mi ethernet a wifi ovládá stejný ovladač? Dříve jsem měl eth0 a wlan0, teď mám em1 a em2.

[x]

Ze maji v RH ruce doleva je znamo dostatecne. Neumi ani opisovat. Na BSD neni WiFi rozhrani napr. od Intel nikdy em jako je tomu u LAN rozhrani, ale jsou to iwi, iwn, iwh atd. (zalezi na chipu).

Navic FreeBSD nedavno preslo na zpusob, ze sice je treba fyzicky iwn0, ale pomoci ifconfig se vytvori wlan0 a az pak se s tim pracuje.

[pavlix]

IMO děláš FreeBSD medvědí službu.

[Michal Kubeček]

FreeBSD, kde se jméno liší podle ovladače a ovladač čísluje rozhraní deterministicky např. podle pořadí na sběrnici.

Což je koncepce, která byla v Linuxu po zralé úvaze opuštěna, protože to obecně ani teoreticky nejde udělat tak, aby ta jména byla persistentní. Takže je lepší hned od začátku přestat předstírat, že to jde.

[CET]

Očíslování síťových rozhraní závisí na tom, v jakém pořadí se natáhnou moduly, což od přechodu na udev hotplug může být úplně náhodné. První pokus o řešení bylo ukládání MAC adres, ale s tím jsou zas problémy při výměně hardwaru: u serverů je běžné, že pokud se něco rozbije, technik od dodavatele v rámci podpory přiveze nový a přehodí disky. Jenže kvůli změně MAC by se pak nenakonfigurovala síť a server by nefungoval, dokud by ho správce nepřijel nastavit. V RedHatu proto hledali lepší řešení a inspirovali u FreeBSD, kde se jméno liší podle ovladače a ovladač čísluje rozhraní deterministicky např. podle pořadí na sběrnici.

Hmmm, a co kdyz prehodi disk do serveru, kde nejsou emX sitovky, ale vicX sitovky? Nebo jinak, vezmu system ze stareho HW a zkopiruju na novy HW. Bohuzel musim zmenit vsechno, kde se vyskutuje emX. Kdyz mam ethX, tak mi proste zustane ethX, jenom po zkopirovani systemu smazu /etc/udev/rules.d/*permanent-net*rules (jasne, obcas na to taky zapomenu, ale lepsi po bootu smazat jeden soubor, nez hledat konfigurace zavisle na jmenu zarizeni). Chtelo by to jeste lepsi system, mozna opravdu podle poradi na sbernici, jenze dokud se nenatahnou vsechny moduly, tak system nevi, kolik ma sitovek (nebo vlastne vi, protoze zna kod sitove karty, tak by to mozna slo). Jinak, nikomu nic nebrani ten udev script prepsat, aby ty sitovky cisloval jinak ... scriptik by mohl project sbernice od ISA, PCI, PCI-e, USB atd, vyfiltrovat sitovky a pak cislo vygenerovat podle toho, kolikata je sitovka v poradi. To musim zkusit:)

[x]

Pro sitovky se to dela lidsky, ze nic neni treba prepisovat viz. napr. http://www.openbsd.org/faq/pf/macros.html#macros Samozrejme pokud je instalor a spravce debil, tak se prepisovat musi, protoze nepouzije dostupne.

Pro disky je tady DUID a plati tak to same, ze se nemusi na fstab sahat nebo se hrozit co vyplivne udev

[Michal Kubeček]

A když to všechno vychytáte a odladíte, tak se jednoho dne stane, že se kvůli hardwarové nebo softwarové chybě jedna (první) nenainicializuje a všechny ostatní se posunou…

[jiri.one]

ono to jde jednoduse vypnout: System Administrators may disable this feature by passing "biosdevname=0" on the kernel command line.

[Vykook]

Proč? Pojmenování podle driveru, jako je to v BSD je o mnoho lepší a přehlednější.

[SPM]

Hmm, jsem naposled slyšel, že to chtěj udělat, ale že to udělali už ne; tak jsem myslel že to vyšumělo a zřejmě asi ne :) no, hlavně že z toho aspoň neudělali "Připojení k místní síti XX"

[vencour]

Přehlednější možná. Univerzálnější nee.

[Vykook]

Nevím jak v Linuxu, ale ve FreeBSD si síťovku můžeš přejmenovat.

[Gilhad]

v Linuxu taky. Zejména udev mi tím velice rád přidělává práci

[Milan Lajtoš]

Konečne sa ľady začali lámať. Mohli by sa ešte inšpirovať Gobo Linuxom a Mac OS X-om, ktoré sú v tomto asi tak 15 rokov pred mainstreem distribúciami.

[l4m4]

Pokud je systém instalace software v MS Windows 3.1 (protože takhle to v Gobo funguje, akorát má výrodu unixového filesystému) 15 let před linuxovými distribucemi, tak jen doufám, že se Linux přestane vyvíjet, aby těchto 15 let nikdy nedohnal.

[Ondra]

nebo rovnou NixOS, to je teprv hlina...

[Milan Lajtoš]

To vyzerá dosť dobre! :)

[SPM]

Mac OS X? To jako že se do / napatlaj další věci s názvama jako User a Applications a hlavně s velkejma písmenama, aby tam všechno bylo dvakrát a ještě s debilnim názvem? :) Děkuji, nechci.

[Milan Lajtoš]

Čo tam bude dvakrát? Prosím vysvetliť.

[SPM]

Některý programy v /usr/bin, některý v /Applications, ... je tam toho bordelu ještě víc než na současnym linuxu.

[l4m4]

Nerozumím akorát tomu, proč se věci přesouvají do /usr, namísto z /usr do /.

Zdůvodnění možností /usr na samostatném disku, který se nemusí připojovat a kam se nepíše, tímto přesunem padá. Jednak se /usr připojit bude muset a druhak jsou konfiguráky vymyšleností jako systemd v /lib, tedy teď asi v /usr/lib, tudíž musí být /usr stejně ke psaní jako /etc.

Adresáře jako var, etc, ... zůstanou v /. Adresáře media a srv a run kdovíco se nám v / vesele množí.

Ale bin a lib, ty už tam asi byly moc dlouho nebo co, tak je zapotřebí je vystřídat novými, neotřelými. Jsem zvědav, co zase příští FHS přidá do /.

Bordel.

[lukve]

/proc, /sys, /run

 

by som hodil do jedneho /objects/ kebyze bolo na mne tak ako to ma solaris

takze

/objects/proc/

/objects/sys/

/objects/run/

[Mrkva]

konfiguráky vymyšleností jako systemd v /lib

Co prosím?

[pavlix]

Výchozí konfigurace systemd je v /lib/systemd, přebíjí se uživatelskou konfigurací v /etc. V celku rozumné, že je to zvlášť, kvůli updatům.

Jestli se to přesune do /usr/lib, tak je to pěkná cypovina. Obecně přesouvat /lib, /bin a /sbin do /usr mi přijde pochybné, protože jediný důvod pro existenci /usr je právě vyčlenění uživatelských programů.

Kdyby to bylo naopak a /usr se rušilo, tak neřeknu.

[8an]

Do /usr se přesouvají jen ty věci, které mohou být sdíleny více počítači (např. na NFS). /run je v rootu proto, že je to samostatný filesystém (tmpfs), narozdíl od /var/run. /srv není nic nového.

[David Jaša]

Nerozumím akorát tomu, proč se věci přesouvají do /usr, namísto z /usr do /.

Lennart to docela podrobně vysvětlil na svém blogu. Jedním z cílů je právě sdílitelný /.

[XDFgvasdgweg]

mi pripada /usr zbytecne a dal bych vsecko do /.

nejlepsi to ma plan9, ma unionove adresare, takze do /bin jde nabindovat hafo jinych adresaru a pak je zaruceno, ze vsechny programy se spousteji z /bin a plan9 nepotrebuje zadne promene PATH.

[dad]

bohuzel se to neprosadilo. Kolikrat sem si rikal, ze bych to nasadil u zakazniku, ale podpora ruzneho hardware je problematicka a i podpora rady stand. software - napr. databaze je probem. My jsme u nas tak trochu z legrace udelali malou sit 3 pocitacu s plan9 a je to skutecne takove osvezujici, ze se cely ten system chov jako jeden pocitac.

[Laco]

nech proste vsecko nafutruju do C:/Linux a hotovo :)

[AsciiWolf]

Jo a byl by v tom stejný bordel, jako na Windows.

[vain]

Lol, C:/Linux, dobrý =)

[skunkOS]

Spíš C:\Windows\System32\Linux\

:D

[gtz]

\BSOD\LINUX

[kavol]

hm, zase levá ruka neví, co dělá pravá

hlavněže nedávno jsme začli sjíždět kontroly, jestli věci mimo /usr nezávísí na věcech v /usr, přesně kvůli tomu, co už vysvětlil kolega výše, že /usr nemusí být vždy namountovaný - což je asi situace, kterou hypermegafreecoolin borečci s potřebou vymejšlet šišatý kolo, protože to kulatý už je moc starý, neznají, nicméně jinak je docela běžná u zákazníků enterprise dister ...

[Lol Phirae]

To je dobrý, že jste začali sjíždět kontroly. A řešení je jaký? Přesunout to do rootu? Hmm, a k čemu to je jako dobrý, tohle "řešení"?

[kavol]

To je dobrý, že jste začali sjíždět kontroly. A řešení je jaký? Přesunout to do rootu? Hmm, a k čemu to je jako dobrý, tohle "řešení"?

je to dobrý k tomu, aby sis mohl honit triko, jak jsi mě setřel

jinak pokud tě zajímá realita a ne jen nějaké tvoje haluze na nastartování flejmu, tak řešení je spíš naopak nervat do /sbin a /lib kdejakou blbost, která může bejt v /usr

a pokud to nejde, a z výše uvedeného důvodu(*) to tam musí zůstat, tak to aspoň nelinkovat s každou blbostí, co v systému je, nýbrž udržet si závislosti mimo /usr (ano, v některých případech to nejde, a pak může dojít k té nežádoucí variantě přesunu další věci mimo /usr)

hezkým vedlejším efektem při tom je odhalení pár prasečin, kde jsou natvrdo zadrátovaný cesty

(*) v souvislosti s čímž mi přijde úsměvná argumentace pro změnu zhruba v tom smyslu, že systém mimo /usr je stejně už tak obrovský, že nemá smysl uvažovat o mountování bez /usr, a že kdo to potřebuje namountovat zvlášť, třeba jako system rescue, tak že si stejně má ukuchtit initrd, kde bude mít vše potřebné ... OMG, takže problém, že máme 450 MB (to číslo tam padlo) mimo /usr a nevejde se nám to na kus disku pro to vyhražený, vyřešíme tím, že to přesuneme do /usr a dalších 450 MB navíc zabijeme kopií téhož v initrd, která zřejmě bude potřebovat místo na tomtéž disku, ze kterého jsme to právě odstranili přesunem do /usr, fakt cool logika, nemluvě o tom, že to initrd je potřeba ukuchtit a aktualizovat extra, zatímco věci mimo /usr mají chodit out-of-the-box a jsou v moci balíčkovacího systému

[Lol Phirae]

tak řešení je spíš naopak nervat do /sbin a /lib kdejakou blbost, která může bejt v /usr

Aha. No, takže to chceš zrušit, a proto jseš proti tomu, co je v článku zmíněno? Hmmm... to teda fakt dává smysl - jasná schíza

OMG, takže problém, že máme 450 MB (to číslo tam padlo) mimo /usr a nevejde se nám to na kus disku pro to vyhražený, vyřešíme tím, že to přesuneme do /usr a dalších 450 MB navíc zabijeme kopií téhož v initrd, která zřejmě bude potřebovat místo na tomtéž disku, ze kterého jsme to právě odstranili přesunem do /usr, fakt cool logika, nemluvě o tom, že to initrd je potřeba ukuchtit a aktualizovat extra, zatímco věci mimo /usr mají chodit out-of-the-box a jsou v moci balíčkovacího systému

Ne, vůbec jsi to nepochopil. Jediné, co potřebuješ mít v initrd, jsou nástroje pro připojení ostatních potřebných oddílů (tedy i onoho /usr, pokud nemůžeš bez samostatného /usr žít). Nic dalšího. Což se s přehledem vejde do pár MB.

[kavol]

Aha. No, takže to chceš zrušit,

nauč se číst

Což se s přehledem vejde do pár MB.

jo, takže další frikulín, co někdy v životě viděl tak akorát možná SATA harddisk - tak tos' mohl říct rovnou, nebyl bych se obtěžoval s nějakým vysvětlováním; ostatně to mi mohlo bejt jasný hned po prvním příspěvku, ale holt jsem nezdolnej optimista ...

[Lol Phirae]

jo, takže další frikulín, co někdy v životě viděl tak akorát možná SATA harddisk - tak tos' mohl říct rovnou, nebyl bych se obtěžoval s nějakým vysvětlováním;

Děkujeme za věcný příspěvek. Tos nám těch 450 MB ramdisk opravdu objasnil.

[pavlix]

Děkujeme za věcný příspěvek.

Od tebe v tomhle vlákně zatím nepadl žádný, takže sem s ním.

Tos nám těch 450 MB ramdisk opravdu objasnil.

Je hezké, že se směješ tomu, že jsi něco nepochopil. Když uděláš ze tří stupňů (initrd, rootfs, usr) pouhé dva (initrd, usr), tak zřejmě budeš muset nějak vyřešit původní usecasy pro rootfs, jako je oprava lokálního systému bez /usr.

Jediným argumentem pro tuto změnu, který jsem dosud slyšel, je že je stejně už všechno v initrd. Takže jsou jen dvě možnosti:

a) Všecho co je v rootfs (/bin, /sbin, /lib) je tam nutně potřeba, tím pádem to po zrušení /bin, /usr a /lib bude potřeba kopírovat do initrd.

b) Co je v rootfs navíc oproti initrd, tam vůbec potřeba není. To je opravitelná chyba, po jejíž opravě můžeš provést GOTO (a), ale s menším počtem megabajtů.

Nepočítám, že bys v tomhle vlákně změnil způsob diskutování, ale snad se toho chytí někdo, kdo diskutovat chce :).

[Lol Phirae]

Ne, není to vůbec potřeba cpát do initrd. Jediné co potřebuješ v initrd jsou nástroje na připojení rootfs, resp. /usr. Tečka. Asi si sedíš na kabelu.

[pavlix]

Ne, není to vůbec potřeba cpát do initrd. Jediné co potřebuješ v initrd jsou nástroje na připojení rootfs, resp. /usr. Tečka.

Četl jsi vůbec to, co jsem psal?

Tečka.

Nepsal jsi něco o argumentech?

Asi si sedíš na kabelu.

Dtto.

[kavol]

Ne, není to vůbec potřeba cpát do initrd.

to = ?

Jediné co potřebuješ v initrd jsou nástroje na připojení rootfs, resp. /usr.

a mohl bys tyto nástroje zkusit vyjmenovat?

[Lol Phirae]

Jo, čet. Co prosímtě potřebuješ na tu "opravu bez /usr" krom fsck a busybox? Aby to dalo těch 450 mega. Ježiš to jsou blbiny. Buuuuuue, berou nám /usr. Milujem komplikovat si zbytečně život a nesnášíme initramfs. Buuuuuue, fuuuuuuj, hambaaaaaaa! Kamenujte jeeeee.

[pavlix]

Jo, čet. Co prosímtě potřebuješ na tu "opravu bez /usr" krom fsck a busybox?

Pro pomalejší jedince cituji z komentáře, který jsi tedy údajně četl:

b) Co je v rootfs navíc oproti initrd, tam vůbec potřeba není. To je opravitelná chyba, po jejíž opravě můžeš provést GOTO (a), ale s menším počtem megabajtů.

Buuuuuue, berou nám /usr

Mám podezření, že ti toho uniklo trošku víc. V této zprávičce ani v odkazovaném člálku není o rušení /usr jediného slova.

Navíc jsem někde výše psal, že by mi zrušení /usr přišlo mnohem rozumnější, takže si takzvaně „sereš do vlastního hnízda“.

[Lol Phirae]

Bože. Jasně, zrušíme /usr a všechno to narvem do / - to má logiku. Protože:

$ for i in /bin /sbin /lib /lib64; do du -sh $i --exclude=modules --exclude=firmware; done
7,1M	/bin
15M	/sbin
20M	/lib
4,0K	/lib64

A tak furt marně hledám těch vašich 450 mega co potřebuje tak nutně narvat do initramfs, abyste mohli opravit systém.

Mám podezření, že ti toho uniklo trošku víc. V této zprávičce ani v odkazovaném člálku není o rušení /usr jediného slova.

Ne, neuniklo. Vy tady furt řvete, jak je báječné mít samostatný /usr, protože bagr. Nikdo ještě nepřišel s žádným rozumným use casem, proč je to tak báječné, ale to nevadí. Prostě do /usr to přesouvat nebudem a ne a ne a ne, bueeeeee rozbili mi hračku, já chci mít extra /usr ale nechci tam mít všechno, buuueeeeeeeeee fňuk!

[pavlix]

Bože.

To slova tvá jsou.

~ Jesus Christ superstart (česká verze)

A tak furt marně hledám těch vašich 450 mega co potřebuje tak nutně narvat do initramfs, abyste mohli opravit systém.

Víš co... uděláme dohodu. Ty najdeš a ocituješ příspěvek, kde tvrdím, že je potřeba narvat do initramfs 450 mega... a já ti vše vysvětlím a na nejbližší linuxové akci ti koupím oběd :).

Vy tady furt řvete

Já tady neřvu, a klidně mi můžeš tykat. Jsme v přátelské diskuzi, ne v parlamentu.

a ne a ne a ne, bueeeeee rozbili mi hračku, já chci mít extra /usr ale nechci tam mít všechno, buuueeeeeeeeee fňuk!

Fascinuje mě, kolik se do jednoho tvého komentáře vejde infantilních výkřiků.

[Lol Phirae]

Abych to odcitoval:

v souvislosti s čímž mi přijde úsměvná argumentace pro změnu zhruba v tom smyslu, že systém mimo /usr je stejně už tak obrovský, že nemá smysl uvažovat o mountování bez /usr, a že kdo to potřebuje namountovat zvlášť, třeba jako system rescue, tak že si stejně má ukuchtit initrd, kde bude mít vše potřebné ... OMG, takže problém, že máme 450 MB (to číslo tam padlo) mimo /usr a nevejde se nám to na kus disku pro to vyhražený, vyřešíme tím, že to přesuneme do /usr a dalších 450 MB navíc zabijeme kopií téhož v initrd, která zřejmě bude potřebovat místo na tomtéž disku, ze kterého jsme to právě odstranili přesunem do /usr, fakt cool logika

No, a od té doby marně pátrám, co je tak šíleně nutného v těch 450 mega, co dotyčný hrozně děsně moc nutně potřebuje mít dostupného v initramfs, až bude prý opravovat systém nebo něco podobného, protože je hrozný problém si to připojit. Samozřejmě jsem se dozvěděl kulový.

[kavol]

jj, není nadto překrucovat a vychloubat se, jak neumíš číst - a co kdybych to zvýraznil takto:

OMG, takže problém, že máme 450 MB (to číslo tam padlo) mimo /usr ...

[pavlix]

Abych to odcitoval:

Citace pěkná, ale ten oběd jsi bohužel nevyhrál.

Už na první pohled to jeví stylistické odlišnosti od toho, jak píšu. Jsi si jistý, že jsi ocitoval můj komentář?

[Lol Phirae]

Ne, a já jsem tvrdil, že cituju tvůj komentář? Chtít po tobě pochopit smysl vlákna v diskusi asi bude příliš, že?

[pavlix]

Viz na co jsi odpovídal:

Víš co... uděláme dohodu. Ty najdeš a ocituješ příspěvek, kde tvrdím, že je potřeba narvat do initramfs 450 mega... a já ti vše vysvětlím a na nejbližší linuxové akci ti koupím oběd :).

Chtít po tobě pochopit smysl vlákna v diskusi asi bude příliš, že?

Mohl bych se s tebou předhánět o tom, kdo umí lépe druhého urážet. Ale já to nemám zapotřebí :).

[kavol]

$ for i in /bin /sbin /lib /lib64; do du -sh $i --exclude=modules --exclude=firmware; done

vs

Jediné co potřebuješ v initrd jsou nástroje na připojení rootfs, resp. /usr.

... má to smysl komentovat?

[Lol Phirae]

Jo, okomentuj to. V čem je problém si sakra připojit ten /usr, stejně jako dneska musíš připojit /, abys nabootoval? A kde je těch 450MB tak děsně potřebných do toho tvého initramfs?

[pavlix]

Jo, okomentuj to. V čem je problém si sakra připojit ten /usr, stejně jako dneska musíš připojit /, abys nabootoval?

Vážně chceš dneska sloužit jako úkázka elementární neznalosti? Nebo máš vážně pocit, že si dneska ručně nebo pomocí initskriptů připojuješ /?

[Lol Phirae]

Jo, vážně mám ten pocit, že si ho připojuju z initramfs... Ono by to jinak s tím šifrovaným rootem na LVM šlo dost blbě. Stejně tak není problém udělat totéž s /usr. No, na otázku jsem opět odpověď nedostal.

[Lol Phirae]

Ještě snad konkrétní část toho skriptu (/scripts/local) z initramfs:

mountroot()
{
        pre_mountroot

        # Get the root filesystem type if not set
        if [ -z "${ROOTFSTYPE}" ]; then
                FSTYPE=$(get_fstype "${ROOT}")
        else
                FSTYPE=${ROOTFSTYPE}
        fi

        [ "$quiet" != "y" ] && log_begin_msg "Running /scripts/local-premount"
        run_scripts /scripts/local-premount
        [ "$quiet" != "y" ] && log_end_msg

        if [ "${readonly}" = "y" ]; then
                roflag=-r
        else
                roflag=-w
        fi

        # FIXME This has no error checking
        modprobe ${FSTYPE}

        # FIXME This has no error checking
        # Mount root
        if [ "${FSTYPE}" != "unknown" ]; then
                mount ${roflag} -t ${FSTYPE} ${ROOTFLAGS} ${ROOT} ${rootmnt}
        else
                mount ${roflag} ${ROOTFLAGS} ${ROOT} ${rootmnt}
        fi

        [ "$quiet" != "y" ] && log_begin_msg "Running /scripts/local-bottom"
        run_scripts /scripts/local-bottom
        [ "$quiet" != "y" ] && log_end_msg
}

a překvapivě se to volá z init (taktéž v onom initramfs)

[pavlix]

Z initramfs jo... tam de facto používáš jako rootfs obsah initramfs. Takže dejme tomu by šlo stejně nakládat i s /usr.

Tohle je první věcný argument, který jsem od tebe v tomhle vlákně četl. Takže možná nebudeš takový pako, jak to vypadalo z ostatních komentářů. Tím líp pro tebe :).

No, na otázku jsem opět odpověď nedostal.

Tys mi nějakou pokládal?

[Lol Phirae]

No, na otázku co je za problém takhle připojit /usr. Teda teď konečně jo, ale že to trvalo. Ostatně, dracut z Fedory na tohle má modul, který to zařídí automaticky - zde

[pavlix]

Jojo, teď se s tebou dá konečně mluvit. Dokonce i odkazy na konkrétní věci... v tomto vlákně od tebe dříve nevídané.

+1

Jediný problém je tedy v tom, že ty počítáš s tím, že se za všech okolností použije initrd. Nevím jak teďka, ale ještě nedávno jsem znal hromadu uživatelů linuxových distribucí, kteří se bez initrd obešli.

Jako ono není až tak úplně zásadní, kam se to sjednotí... ale popravdě řečeno jako dnešní linuxák vnímám /usr jako odkladiště věcí, které nejsou potřeba během bootu, tzn. na zmenšení root filesystému.

IMO je to hlavně tím, že je ten adresář pitomě nazvaný, žádní uživatelé v něm nejsou, nejsou tam ani vyčleněné aplikace určené pro uživatele (oproti těm systémovým)... ale to bude asi podobný historický vývoj jako /etc, nebo třeba /proc/sys a podobné věci v /proc, které se netýkají očíslovaných procesů.

Jinak dalším skeptikům jako jsem já, kterým uniká smysl nového sjednoceného /usr doporučuju http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge , sice mě to úplně nepřesvědčilo, ale alespoň jsem prvně v téhle souvislosti četl nějaké důvody k čemu se to vůbec dá použít.

[Lol Phirae]

No initrd není potřeba, pokud si nenacpeš /usr na extra FS. :=P (Teda, pokud je to normální rootfs a ne něco zmíněného typu šifrovaný root na LVM (na RAID).

Obráceně je to samozřejmě blbost (myslím návrh nahoře na zrušení /usr a přesunutí do rootfs, nikdo nemá zájem zasírat si root kravinama typu /include, /local, /share, /src apod., o sdílení přes síť nemluvě. (Už teď tam jsou nesmysly typu /srv nebo /media, nikdy jsem nepochopil k čemu to je dobré, zejm. druhý zmíněný adresář.)

[pavlix]

No initrd není potřeba, pokud si nenacpeš /usr na extra FS. :=P (Teda, pokud je to normální rootfs a ne něco zmíněného typu šifrovaný root na LVM (na RAID).

Fakt je, že triviální případ bez initrd jede, což se může hodit. Je to prostě změna, to lidi nemaj rádi.

Obráceně je to samozřejmě blbost

Není to zdaleka samozřejmé a nikdo neříká, že se musí nutně zrušit /usr celý. Stejně jako nikdo neříká, že to nejde celé přeorganizovat (a pár let symlinkovat à la OS X). IMO bez promyšlení celé struktury tohle nemůžeš napsat. Mně třeba přesvědčilo až to, když jsem zjistil, že takto /usr zahrnuje úplně všechny neměnné systémové zdroje, tzn vše, co jde rozumně označit za read-only (mimo instalaci software).

A docela hodně pomohli i tím, když to přirovnali k /System (či /system pro milovníky lowercase), nebo ještě více informace, že Fedoří balíčky budou (mimo home) používat čtyři systémové adresáře /usr, /etc, /var a /run, z nichž každý má velmi přesně vymezený účel.

Už teď tam jsou nesmysly typu /srv nebo /media, nikdy jsem nepochopil k čemu to je dobré, zejm. druhý zmíněný adresář.

/srv je připravený adresář pro data služeb. Dá se to použít třeba na to, že naházíš veškeré weby, maily, dns a podobné do /srv a zálohuješ ho jako celek. Taky tam můžeš dát data sdílená mezi uživateli, různé repozitáře apod, a nemusíš tím špinit /home. Bez zásahu administrátora je z definice prázdný.

/media je pro automatické připojování (externích) medií. Podle mě lidem nechtěli dělat nepořádek v /mnt, který si tradičně spravovali sami. Název adresáře je celkem obstojný, /mnt může přežít nebo zmizet, ale flashka už dneska patří do /media.

[Gilhad]

znám stovky linuxových počítačů, co dodnes jedou bez initrd :)

[pavlix]

A mají samostatný filesystém mountovaný do /usr?

[Gilhad]

Nemají, protože to nedávalo zrovna v tomhle případě žádnou výraznou výhodu. Stejně jako ji nedávalo initrd.

[pavlix]

Pak je to ale non-issue neboli neproblém :).

[Gilhad]

Neříkal jsem, že by byl problém, říkal jsem že stále jsou tací, kteří intird nepoužívají, že on není jediný :)

[pavlix]

Neříkal jsem, že by byl problém, říkal jsem že stále jsou tací, kteří intird nepoužívají, že on není jediný :)

To ale už trochu utíká z kontextu sjednocení /{bin,sbin,lib} s /usr/{bin,sbin,lib}.

[michich]

hm, zase levá ruka neví, co dělá pravá

Jo? A čí je to chyba? FESCo o UsrMove diskutovalo v říjnu, hned potom o tom byla dlouhá diskuse na devel@ listu. Popularizace UsrMove je myslím více než dostatečná.

hlavněže nedávno jsme začli sjíždět kontroly, jestli věci mimo /usr nezávísí na věcech v /usr

A komu jste o tom řekli? Kde jsou nějaké výsledky? Kde je Fedora feature page FixedUsrDependencies? Kde jsou nějaké informace o tom, jak taková kontrola probíhá? Zkoumáte jenom závislosti ELF binárek (to by bylo nedostatečné), nebo jdete více do houbky?

Moje osobní špatná zkušenost s odděleným /usr: Balík crda před časem instaloval databázi regulačních omezení pro WiFi pod /usr. Míval jsem samostatný /usr oddíl. Nějakou dobu mi trvalo, než mi došlo, proč se nemůžu připojit do některých WiFi sítí. Byly to sítě na kanálech 12, 13. Aby to WiFi karta umožnila, musí se od crda dozvědět, že tyto kanály jsou v ČR povolené. Na mém systému udev našel wifinu dříve než byl připojen /usr. crda v tu chvíli nenašel svoje data. Karta běžela pouze v bezpečném omezeném rozsahu. Samozřejmě se dá říct, že to byl prostě bug a měl být opraven. A taky že byl. Po čase. Jenže to byl úplně zbytečný bug. Díky UsrMove celá třída takovýchto bugů zanikne.

[kavol]

hm, zase levá ruka neví, co dělá pravá

Jo? A čí je to chyba?

a je nutné někoho obviňovat?

FESCo o UsrMove diskutovalo v říjnu

... no ale pokud chceš, tak to hoď na FESCo, jestli jednali v říjnu, neb já jsem na to dle bugzilly hrabal někdy v půlce května, a to je dřív :-p

(nemluvě o tom, že původní problém, na základě kterého to vzniklo, byl reportován dávno předtím, než probublal až k nám)

hlavněže nedávno jsme začli sjíždět kontroly, jestli věci mimo /usr nezávísí na věcech v /usr

A komu jste o tom řekli? Kde jsou nějaké výsledky?

příslušným vývojářům, výsledky jsou v bugzille, samozřejmě

Kde je Fedora feature page FixedUsrDependencies?

není

pardón, nebyl jsem dostatečně explicitní, moje práce se týká RHEL, ne Fedory (laskavý čtenář si pak za domácí úkol zjistí, jak to souvisí, že ty moje pindy nejsou offtopic)

Kde jsou nějaké informace o tom, jak taková kontrola probíhá?

v gitu přímo v testu, obecně o testování na naší wiki

Zkoumáte jenom závislosti ELF binárek (to by bylo nedostatečné), nebo jdete více do houbky?

bohužel, test sjíždí jen ty binárky ... ale lepší než drátem do woka - ty bys asi měl tušit, jaký byl stav testování před pěti lety ...

Moje osobní špatná zkušenost s odděleným /usr: Balík crda před časem instaloval databázi regulačních omezení pro WiFi pod /usr. Míval jsem samostatný /usr oddíl. Nějakou dobu mi trvalo, než mi došlo, proč se nemůžu připojit do některých WiFi sítí. Byly to sítě na kanálech 12, 13. Aby to WiFi karta umožnila, musí se od crda dozvědět, že tyto kanály jsou v ČR povolené. Na mém systému udev našel wifinu dříve než byl připojen /usr. crda v tu chvíli nenašel svoje data. Karta běžela pouze v bezpečném omezeném rozsahu. Samozřejmě se dá říct, že to byl prostě bug a měl být opraven. A taky že byl. Po čase. Jenže to byl úplně zbytečný bug. Díky UsrMove celá třída takovýchto bugů zanikne.

takže chceš říct, že chceš mít regdb narvanou v initrd?

tvůj příklad je po mírné modifikaci krásná ukázka toho, jaká je to pitomina - stačí si totéž představit s tím, že /usr by bylo mountováno právě přes onu wifi

[michich]

a je nutné někoho obviňovat?

Už tvá poznámka o rukách mi připadala jako obvinění autorů UsrMove, že nesledují, co se děje okolo. Asi teda nedozorumění, promiň.

moje práce se týká RHEL, ne Fedory

Je dobré opravovat chyby v RHEL, ale ještě lepší by bylo mít to opravené už ve Fedoře. Jinak se budou muset podobné chyby opravovat znovu v nové major verzi RHEL.

takže chceš říct, že chceš mít regdb narvanou v initrd?

Pokud mountuju / (nebo i /usr, za předpokladu provedení UsrMove) přes wifi, tak ano, jinak ne. Ideální stav bude, že dracut správně pozná, co budu potřebovat k nabootování a sestaví initramfs ze všech potřebných komponent (a nedá tam nic zbytečného navíc).

[kavol]

a je nutné někoho obviňovat?

Už tvá poznámka o rukách mi připadala jako obvinění autorů UsrMove, že nesledují, co se děje okolo. Asi teda nedozorumění, promiň.

to byl obecný povzdech

vpodstatě jde o dvě různé skupiny s různými zájmy, jediná potíž je, že se potkávají u jedné distribuce, a to ještě jenom nepřímo

moje práce se týká RHEL, ne Fedory

Je dobré opravovat chyby v RHEL, ale ještě lepší by bylo mít to opravené už ve Fedoře. Jinak se budou muset podobné chyby opravovat znovu v nové major verzi RHEL.

no, a to je právě ten průšvih - ne každá novinka z Fedory musí jít do RHEL, ale pak je sakra těžké to v RHEL nějak udržovat

takže chceš říct, že chceš mít regdb narvanou v initrd?

Pokud mountuju / (nebo i /usr, za předpokladu provedení UsrMove) přes wifi, tak ano, jinak ne.

mno, bavme se o stavu po přesunu do /usr, takže /usr

Ideální stav bude, že dracut správně pozná, co budu potřebovat k nabootování a sestaví initramfs ze všech potřebných komponent (a nedá tam nic zbytečného navíc).

to je moc hezká myšlénka, leč v praxi má tu vadu, že na to je potřeba křišťálová koule - pokud to má být na míru konkrétnímu hardware, tak musíš vědět, jaký hardware bude použit, což nemusí být splněno ...

kromě toho, chceš pouštět dracut po každém updatu, nebo jak se vypořádáš s tím, že bereš soubory a dáváš je někam mimo správu balíčkovacího systému?

- věřím, že toto již bylo diskutováno, ale ňák to na wiki nevidím

a když jsme u tý wiki, sorry, ale ta argumentace je ve stylu "věř a víra tvá tě uzdraví" ... naopak mě to jen utvrzuje v tom, co jsem napsal kolegovi - představu, že když se mi něco posere, tak "jenom potřebuju vytáhnout rescue CD", bych ještě tak chápal u BFU, ale ne u lidí, co mají moc rozhodovat o takovýchto věcech, u těch bych čekal trošku větší rozhled

v souvislosti s tím rescue je úsměvné, jak přesunem věci "zjednodušujou" (sic!) tím, že je komplikujou - abych mohl systém spravit nemaje ono magické CD, tak kromě normálního initrd pro běžný boot, které mi vykouzlí dracut, musím mít ještě další speciální rescue initrd (a možnost jednoduše systému říct, že má nabootovat s ním), hm, takže software už se nám v tomto případě pouze neduplikuje ale triplikuje ... řekněme WOV!

[michich]

to je moc hezká myšlénka, leč v praxi má tu vadu, že na to je potřeba křišťálová koule - pokud to má být na míru konkrétnímu hardware, tak musíš vědět, jaký hardware bude použit, což nemusí být splněno ...

Takhle dracut funguje už teď - dá se zapnout "hostonly" režim. Pokud hw neznám, tak ano, musím nechat sestavit generický initramfs, který bude větší.

tak kromě normálního initrd pro běžný boot, které mi vykouzlí dracut, musím mít ještě další speciální rescue initrd (a možnost jednoduše systému říct, že má nabootovat s ním), hm, takže software už se nám v tomto případě pouze neduplikuje ale triplikuje ... řekněme WOV!

Ne nezbytně. Bootloader může kernelu předhodit více než jeden initramfs soubor a kernel si je rozbalí všechny do jednoho souborového systému. Duplikaci je možné se vyhnout. Harald něco takového představoval loni na brněnské Red Hat Developer Conference. Ale do F17 tohle bohužel hotové mít nebude.

[pavlix]

Erm... jedna ze známých dobrých vlastností linuxových distribucí je ta, že při dodržení architektury lze instalaci spustit beze změny na jiném stroji.

[kavol]

Bootloader může kernelu předhodit více než jeden initramfs soubor a kernel si je rozbalí všechny do jednoho souborového systému. Duplikaci je možné se vyhnout.

ok, tož beru zpět, jsem pozadu

ale teda mohli se to obtěžovat zmínit (nějakou námitku na toto téma jsem nakonec našel, a v odpovědi to není)

Harald něco takového představoval loni na brněnské Red Hat Developer Conference.

jo, devconf ... škodaže termín koliduje s akcí, která je mi bližší; co jsem dneska slyšel, tak letos by to mohlo být opravdu zajímavé - Lennart aby si snad radši najal ochranku ...

Ale do F17 tohle bohužel hotové mít nebude.

hm, aha

takže ne "může", ale "v divokých mokrých snech pár lumenů se objevuje takovýto rovnák na vohejbák"

hele mně je to na mým stroji docela jedno, mám jednoduchej setup, a dokud to bude pod kapotou fungovat, tak mi nesejde na tom, jestli bude pár bajtů tuhle nebo támhle, když je to furt na jednom disku - ale garantuju ti, že jestli to projde do RHELu, tak to bude masakr

[pavlix]

ale garantuju ti, že jestli to projde do RHELu, tak to bude masakr

Ale nebude :).

[michich]

co jsem dneska slyšel, tak letos by to mohlo být opravdu zajímavé - Lennart aby si snad radši najal ochranku ...

Co jsi to slyšel?

takže ne "může", ale "v divokých mokrých snech pár lumenů se objevuje takovýto rovnák na vohejbák"

Kernel umí převzít více initramfs souborů už dnes, jenomže dracut toho zatím nevyužívá. Rovnák na vohejbák to asi není už proto, že Harald s tím přišel úplně z jiných důvodů a to dříve, než přišel návrh na UsrMove.

garantuju ti, že jestli to projde do RHELu, tak to bude masakr

Kvůli většímu initramfs? We are doomed! DOOOOMED!

[SPM]

Kvůli většímu initramfs? We are doomed! DOOOOMED!

Vzhledem k čerstvosti balíků v RHEL bych se nedivil, kdyby to většina lidí ještě bootovala z diskety :)

[Ruža Becelin]

Urban stories - z diskety jsem naposledy bootoval Windows 2000. RHEL ma dost aktualni baliky na zacatku cyklu, na konci je to (logicky) horsi...

[Radovan Garabík]

GNU HURD to má dávno... teda má len /bin

[Aleš Kapica]

No jo. Jenže to je taky asi tak všechno co má.

[AsciiWolf]

[robotics]

[Ladislav Hagara]

Titulek by se měl přejmenovat, ne Fedora chce zrušit, ale Fedora zrušila. Do verze udev 175 se udevd standardně instaloval do /sbin. V udev 175 se adresář změnil na /lib/udev. Udev > 177 instaluje udevd do /usr/libexec/udev. Lze s tím nesouhlasit, lze s tím polemizovat, ale to je asi vše co s tím mohou ostatní linuxové distribuce dělat. Bohužel budou muset i další distribuce instalovat initrd a initramfs.

[Tomáš Bžatek]

AFAIK libexec chcou zrusit taky. Ne hned, ale jako dalsi krok nekdy v dalsim release.

[pavlix]

A k tomu je zas jaký důvod? Oddělení spouštěných programů od linkovaných knihoven mi přišlo celkem rozumné.

[Tomáš Bžatek]

V /usr/libexec sidli vetsina uzivatelskych demonu, zpravidla poustenych pres d-bus. Ovsem Fedora/RHEL je snad jediny exemplar, ono to rozdeleni je vicemene umele. V /usr/bin je dost velky bordel, tech par binarek uz tomu neublizi. A uzivatel desktopoveho prostredi by mel stejne videt jen desktop files (/usr/share/applications).

[pavlix]

Ovsem Fedora/RHEL je snad jediny exemplar, ono to rozdeleni je vicemene umele.

Asi tak jako každé jiné rozdělení.

V /usr/bin je dost velky bordel, tech par binarek uz tomu neublizi.

Tak tenhle názor podle mě vede do pekel. A navíc za ním stojí mylný názor, že věci z libexec patří do binu.

Zkus třeba toto:

$ ls /usr/libexec/ipsec
addconn     klipsdebug   policy         showhostkey    _updown.mast
auto        look         ranbits        spi            _updown.netkey
barf        newhostkey   _realsetup     spigrp         verify
_copyright  pf_key       rsasigkey      _startklips    whack
eroute      pluto        _secretcensor  _startnetkey
ikeping     _pluto_adns  secrets        tncfg
_include    _plutoload   setup          _updown
_keycensor  _plutorun    showdefaults   _updown.klips

Nebo bysis to představoval v /usr/bin/ipsec/*?

[michich]

Pokud se mají pomocné programy, které nikdy nemá smysl pouštět přímo, někam z /usr/libexec přesunout, tak spíše do /usr/lib/$podadresář/, protože jsou to i podle FHS

object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts.

Nezaznamenal jsem snahu je přesunovat do /usr/bin. Myslím, že Tomáš se mýlí.

[pavlix]

A mají se vůbec někam přesunout? Jako já vím, že knihovny jsou taky „binárky“ a že je to stejný formát, ale co do účelu je rozdíl mezi linkovanou knihovnou a execovanou specializovanou binárkou.

[Miroslav Suchy]

Nejenom Fedora, ale i Debian. Tam se to minimalne diskutuje na mailing listu. Jak daleko pokrocila fakticka implementace nevim.

[Aleš Kapica]

Chraň nás ruka páně..

Fakt nechápu proč mají nějací idioti nutkání do toho vrtat. Místo aby se zaobírali podstatnějšími problémy. Teď je na adminovi, kde co má.

To, že jsou ty systémové věci oddělené od balastu má svůj dobrý důvod. Kupř. zrovna dnes ráno jsem řešil nabouraný systémový oddíl. Disk se zřejmě chystá do věčných lovišť. Takhle jsem odzálohoval nějaké 3GB a mohl přistoupit k opravě. Kdyby to bylo nahňácané všechno v kupě, tak bych se s tím babral asi ještě teď.

[Ruža Becelin]

Teď je na adminovi, kde co má

To tak mozna v pripade, ze si baliky kompiluje sam, jinak je to na tom, kdo dela balicek a jaka je politika distribuce.

[Aleš Kapica]

Nejsem si vědom toho, že by se nějaký balík staral o to, kterém blokové zařízení je na příslušný adresář namountovaný.

Podstatný je fakt, že pokud začnou prasit všechnu binárky páté přes deváté, tak tím akorát přidělají práci s odseparováním důležitých věcí od prkotin.

[Ruža Becelin]

Balik se stara o to, kam ktery soubor nahrat.

Na moji Fedore 16 ma /usr/bin pres 4000 souboru, manualni hledani v necem takovem uz jsem davno vzdal, radsi si na pomoc pozvu man -k, locate, whereis a rpm/yum. Kdyz se do toho prida nejakych 150 souboru z /bin, tak me to fakt neboli...

[Aleš Kapica]

Fajn. Jenže se na to zkus podívat obráceně. Kde je větší pravděpodobnost výskytu chyby? Tam kde je 4000 souborů, nebo tam kde jich je jen 400 a to ještě relativně malých? jak dlouho ti pak potrvá oprava takové ho diskového oddílu. Bez toho abys měl namountovaný adresář /usr se dá fungovat a vzdáleně problém pořešit. Obrázeně to moc nejde.

A co se týče manuálního hledání - sorry, ale najít něco "manuálně" je blesková záležitost, pokud nejsi klikací lopata. Nauč se používat find a grep.

[pavlix]

Kde je větší pravděpodobnost výskytu chyby? Tam kde je 4000 souborů, nebo tam kde jich je jen 400 a to ještě relativně malých?

Zní to sice rozumně, ale bezvýznamně.

[Ruža Becelin]

Sorry, ale z pohledu diskoveho oddilu neni moc rozdil mezi 400 a 4000 souboru. Navic od doby, co musim resit dosluhujici server pripojeny na EMC s 80 exportu je /usr to posledni, co by me brzdilo :-P

A co se tyce manualniho hledani - nemusis hned kousat... Nastroje, co pro vyhledavani pouzivam, jsem vyjmenoval v tom samem odstavci, po find a grep jsem u binarek fakt sahat nepotreboval, to uz muzu rovnout pouzivat strings

[Aleš Kapica]

Tak o tom, jestli to rozdíl je, nebo není, bych se docela hádal. U mě má /usr téměř 9GB, zatím co kořen (a všechno co je na něm) kolem 2,5 GB. A na rychlosti kontroly disku a případné opravě se to pozná docela zřetelně. Nehledě na to, že častěji jsem opravoval nabouraný /usr než kořenový disk.

Jistě, také mám stroje, kde to mám v kupě - jenže ty jsou virtuální a hra na diskové oddíly je u nich vcelku zbytečná. Přesto bych nechtěl aby někdo v zájmu "zjednodušení" struktury stávající schéma rozkopával. Užil jsem si toho bordelu dost u Windows.

[Lol Phirae]

Přesto bych nechtěl aby někdo v zájmu "zjednodušení" struktury stávající schéma rozkopával. Užil jsem si toho bordelu dost u Windows.

Aha. A že je to rozbitý a nefunguje to správně, to je patrně takový "detail"?

[pavlix]

Fakt nechápu proč mají nějací idioti nutkání do toho vrtat.

O idiotech nevím, jmenuj :).

A jinak pro ty, kteří nevědí, proč, jsem tu postoval odkaz, který mi ty důvody dostatečně osvětlil, když jsem sám nevěděl ještě nechápal důvody.

Teď je na adminovi, kde co má.

To zaslouží vysvětlení, co se tedy pro admina změní sjednocením bin, sbin a lib.

Kdyby to bylo nahňácané všechno v kupě, tak bych se s tím babral asi ještě teď.

Nepleť si (ne)schopnost admina s organizací /*bin a /usr/*bin v distribuci.