Vlákno názorů k článku Distribuce slučují adresáře /lib a /usr/lib, je to dobrý nápad? od mat - Článek významu analýzy vlivu konzumace drog filipínské mládeže...
-
Lol Phirae (neregistrovaný)
Ano, těm by to třeba mohlo začít konečně fungovat správně. Viz např. Gentoo Bug 149472
-
Xjmeno363-MEGATROLL (neregistrovaný)
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.
-
Inkvizitor (neregistrovaný)
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.
-
Inkvizitor (neregistrovaný)
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.
-
Inkvizitor (neregistrovaný)
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ší.
-
xyz (neregistrovaný)
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.)
-
"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/ifconfig"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?
-
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...
-
xobot (neregistrovaný)
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ě.
-
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/mirovasuperaplikace, 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.
-
Me (neregistrovaný)
<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.
-
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.
-
Inkvizitor (neregistrovaný)
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 binariesOriginally, /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 /usrJasně, v situaci prasáren A) a B) už to rozdělení nemá smysl a klidně je možný všechno prsknout třeba do /superlinuxbinaries, protože to, co mělo platit, už stejně neplatí. FHS totiž vychází z logiky, která už je stejně rozbitá.
-
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.
-
"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....
-
Petr Ježek (neregistrovaný)
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 ?
:)
