Názory k článku Kam mizí adresáře /bin, /sbin a /lib a proč už je nepotřebujeme?
-
Velká výhoda /usr je, že sdružuje soubory podobného charakteru -- věci pocházející z nainstalovaných balíčků / SW, které se za normálního provozu nemění, kromě aktualizací systému.
To dělá pohodlným spoustu scénářů typu stavím farmu identických kontejnerů, tak jim namountuji společné read-only /usr, ale každý má svůj /var. Nebo v embedded mám /usr na read-only oddílu, který se aktualizuje celý naráz A-B metodou, /etc a /var mám zvlášť. Ano, to samé by se dalo řešit i s /bin, /sbin/, /lib, atp., ale už musím řešit několik adresářů místo jednoho. Nebo např. můžu mít /usr oddíl chrnáněný nějakým checksumováním typu dm_verity.
Navíc některé adresáře jsou tradičně jen v /usr, např. /usr/share. Takže /usr by mi stejně zůstalo. Pak přesunout všechno do něj se zdá být čistší a přehlednější.
A spousta linuxových distribucí /usr merge zvládla bez problémů, např. Arch.
-
k3dARStříbrný podporovatelnezkoumal sem jak to *buntu vyresilo kdyz Debianu na kterem je zalozene to "nejde", nicmene mam v Xubuntu 22.04:
bin -> usr/bin
lib -> usr/lib
libx32 -> usr/libx32
lib32 -> usr/lib32
lib64 -> usr/lib64
sbin -> usr/sbin -
/usr merge stale zachovava symlinky v /.
Problem debianu je, ze cast balickov uz presla cez /usr merge a cast nie. Niektoe nainstalovane systemy su prepnute na merge, niektore nie. Potom balicky zbuildovane na systeme s merge nefunguju na systemoch bez merge -- jednoducho, jeden velky bordel.
Fedora mala flag day v roku 2012 a odvtedy je to vyriesene a uz sa to viac neriesi. Debian, o 11 rokov neskor, stale ano.
-
Ono bez symlinků to asi nepůjde nikdy, vzhledem k tomu, kolik poletuje po světě skriptů s `#!/bin/bash`. Myslím, že problém debianu je v tom, že po vytvoření symlinků, se pořád leckteré balíčky snaží instalovat soubory do /bin/, které se skrz symlink dostanou do /usr. Kdyby všechny balíčky instalovaly soubory do /usr a symlinky byly jen pro runtime použití (tak to koneckonců dělá Arch), nebyl by to takový problém.
-
k3dARStříbrný podporovatel
se pořád leckteré balíčky snaží instalovat soubory do /bin/, které se skrz symlink dostanou do /usr.
mozna mi neco unika, ale jak se soubor intalovany do /bin ( ktery je symlink do /usr/bin/ ) muze dostat do /usr/ ?
-
DannyStříbrný podporovatelVsak nektere systemy to tak delaji uz davno tomu (treba Solaris)... fakt neni duvod curat proti proudu :-)
-
Kdyz sem s unixem pred nekolika desetiletimi zacinal, ptal jsem se starsich kolegu proc tomu tak je. Meli 1000 jasnych/zdanlive nevyvratitelnych argumentu. Nedej Boze, ze bych s nimi chtel diskutovat - umlatili by me knizkami!
Ale vlastne jsem citil, ze jsou si sami nejisti a ze ten chaos nema realne opodstatneni.
Takze diky za uvod clanku - 20 let si myslim podobnouhloupost - proste doslo misto na disku/v kombinaci s lidskou lenosti...
unix je chaos, ale nekdy je to i legrace -
Ale byli si jisti, teda minimalne nekteri z nich. Ty ostatni to bylo potreba naucit tak, aby neco zbytecne nepos...li :-)
Ukladat ruzna data v opensource systemu muze skoncit totalnim chaosem, pokud se nedodrzuje nejaky system. Mysleno jakykoliv system.
Pro adminy vzdy platila zasada "keep it stupid simple" soucasne se zasadou "vzdycky si zvol system, a dodrzuj ho, dokud to jen bude mozne. Az nebude, pak peclive zvol novy, a opet, dokud to pujde, dodrzuj ho".
Hlavnim duvodem pro zmenu je IMHO virtualizace a kontejnerizace. Ve virtualizaci je trend jasny - zbavit se low-level utilit a tuny separovanych konfiguraku ve prospech jednoho a vseobjimajiciho systemd (ktery pujde jednou komplet nastavit + exportovat/importovat automatizovane a "zvenci" virtualizovaneho systemu) , a zjednodusit tak OS az na dren.
Obdobne v kontejnerizaci historicke rozdeleni disku jen zbytecne pridava na slozitosti.
Tomu aktualni snahy zbavit se historickeho standardu pro FS hierarchy odpovidaji.
Je to i generacni problem - mladi stary system neznaji a opravnene nechapou, komercni sfere kvuli virtualizaci a kontejnerizaci vyslovene vadi, a stari se proste snazi drzet zavedeneho a standardizovaneho systemu, dokud to bude jen trochu mozne.
-
A nejsou to jen cesty k interpreterům. Nedávno jsem si třeba užil spoustu "legrace", když se v openSUSE snažili přestěhovat moduly jádra do
/usr/lib/modules. Právě proto mám podezření, že by nakonec možná bylo praktičtější udělat usrmerge naopak. Přeci jen těch míst, kde je natvrdo zadrátovaná cesta do/usr/*bude IMHO pořád mnohem méně.Některé detaily ale nejsou špatné. Líbí se mi třeba idea, že defaultní konfigurační soubor z distribučního balíčku bude v
/usr/etca v/etcpřípadný override pro konkrétní systém. Jen se to zatím bohužel moc neujalo u upstreamových projektů a tam, kde to funguje, nepanuje moc shoda ohledně toho, jak se ty dvě konfigurace mají skládat dohromady. -
To je ale něco jiného. To, o čem jsem psal, je pokus o trochu chytřejší řešení problému, kdy se při updatu mění konfigurační soubor, který je součástí balíčku, ale na daném systému ho admin upravil. Myšlenka spočívá v tom, že místo kontroly, zda je soubor upravený, a vytváření *.rpmsave nebo *.rpmnew balíčky konfigurační soubory vůbec neinstalují do
/etc, ale do/usr/etc, kam pro změnu zase vůbec nesahá uživatel resp. správce systému. Pokud ten chce svou vlastní konfiguraci, vytvoří si svůj soubor v/etc. -
Coz je prusvih daleko horsi ...
Protoze kdyz (normalni) distro zmeni konfiguracni soubor, tak je admin nejak informovan o tom, ze je treba udelat nejaky ten merge, a v ramci toho si samozrejme i zjisti, co ze se to vlastne meni.
Kdyz se to zmeni "samo a potichu" tak to samozrejme znamena, ze se taky sama a potichu zmeni konfigurace aplikace = prestane to fungovat.
-
Filip JirsákStříbrný podporovatelTo, jestli se konfigurační soubor změní tiše nebo s nějakým upozorněním ovšem vůbec nezáleží na cestě, kde je ten soubor uložený.
-
A je zase vidět jak to zase nedomysleli.
/usr má prostě blbý název na to co obsahuje
Měl se udělat úplně nový adresář (/prg, /apl, /os ...) a do něj vše transformovat ...
Hned by bylo jasné co je upraveno, co ne a neobsahovalo by to zmatečné USER ... ale takhle se zase udržují umělá pravidla u kterých dokonce víme proč vznikla a proč jsou špatně.
-
-
Humanoid č. 1264054 - poruchovýStříbrný podporovatel
A přesně tak to chápe i každej Widlák (Windowsák), a pak se jako já diví, proč je v usr i bin :-))
-
jose1711Stříbrný podporovatel
dakujem za objasnenie (mozno by ste mohli doplnit tuto informaciu aj do clanku)!
-
Navzdory na první pohled absurditě tohoto řešení, tak třeba na MacOS se to tak do určité míry dělá (doufám, že jsou mé informace dostatečné).
Duplicita, která tím přirozeně vzniká je řešená na úrovni FS a OS.
Neřeší to úplně všechny nedostatky (stále se musí stahovat celej img aplikace, ale i to by se asi dalo řešit). Na druhou stranu to má výhody v blbuvzdornosti. Pokud se ti "rozbije" systém, tak to bude "jen" neefektivní. -
NeXT/macOS zacal s aplikacnymi bundles, ale nie je to 100%.
Ano, niektore aplikacie mozu byt ako bundle, instaluju sa umiestnenim do priecinka, odinstaluju sa zmazanim. Zmazanim zanechavaju za sebou bordel v pouzivatelskom priecinku (~/Library), kam ukladaju svoje preferencie. Preto ma napriklad brew cask parameter --zap, ktory zmaze aj zname subory, co po sebe aplikacia zanechava.
Mnohym aplikaciam to vsak nestaci. Bud dotahaju a skladuju bordel v /Library/Application Support (ekvivalent /usr/share), zaregistruju svoje sluzby v /Library/LaunchDeamons alebo /Library/LaunchAgents (a to aj napr. Microsoft Office si zaregistruje updater), kedysi mohli mat moduly do jadra (napr. Virtualbox), plus mnoho dalsich prilezitosti ako mat subory mimo bundle... co vsetko vyzadovalo instalator a odinstalator.
Takze prave toto je na MacOS jeden velky bordel.
-
Možná je to trochu mimo, ale nemohu si odpustit poznámku: nazývat adresář
(directory) nebo adresářový strom (directory tree) vágním výrazem složka je
zavádějící a podle mě i hloupé. Tuto vymyšlenost neprofesionálních
lokalizátorů MS-Win* a podobných "systémů" bohužel nikdo nekorigoval,
takže se to rozšířilo jako rakovina, kterou už asi nikdo nevyřízne... -
Docela by mě zajímalo, jak budou odhalovány takové implementační detaily, že /bin/sh je už docela dávno na Linuxu symlink do /usr/bin/bash (či /bin/bash) nebo kam, ale právě proto, že je volán SH, tak se BASH přepnul do SH-strict módu, kdy vám BASH-like features byly nepřístupné - řešil to právě BASH podle argv[0]. Také /usr/bin/mail býval symlink do /usr/sbin/sendmail a Sendmail se podle toho choval. Takových archaických mastodontů je podstatně více - v XFree86 (jasně, umřelo to:-)) či v Motifu to bylo také (zdravím IRIX, Ultrix, UnixWare či SunOS) atd. Tohle všechno je buď na propadlišti dějin nebo opravdu vyřešeno?
PS: Ty cesty píšu z hlavy, o přepínání 'módů' aplikací tímto způsobem jsem přesvědčen neboť jsem si s tím ve své době užil při řešení obskurních problémů zejména při přechodu mezi různými UNIX-like systémy kopec 'legrace'.
-
Jen malá poznámka na okraj.
Utilita mail (nebo někdy mutace mailx) je univerzální (i když primitivní)
MUA (mail user agent), kdežto sendmail sice funguje i jako MSA (mail
submission agent), ale je to hlavně MTA (mail transfer agent) s podporou
pro pluginy typu MDA (mail delivery agent). Proto by asi jen velmi těžko
mohl být kdekoliv mail symlinkem na sendmail, protože jím se doručená
e-pošta (mailbox nebo maildir) prezentovat nedá. -
Hlavně se sice oba ty příkazy dají použít k neinteraktivnímu odeslání e-mailu (např. ze scriptu) a oba dostávají jako argumenty adresy příjemců, ale každý funguej jinak:
maildostává na standardní vstup jen tělo e-mailu (bez hlaviček) a údaje pro hlavičky (např. subject) se předávají pomocí dalších parametrů (např.-s); ke generování hlaviček se použijí i ty adresy z příkazové řádky. Oproti tomusendmaildostává na standardní vstup kompletní mail včetně hlaviček a v podobě, ve které půjde ven; adresy předané pomocí argumentů se použijí pouze pro "obálku" a v hlavičce mohou být i úplně jiné.Příkaz
mailje většinou jednodušší na použití,sendmailse ručně a ve skriptech používá spíš jen když mi e-mail vygeneruje nějaký jiný nástroj (např. "git format-patch"), jinak slouží spíš jako de facto standardní rozhraní k místnímu MSA/MTA pro software, který generuje kompletní maily včetně hlaviček. -
Koncept sdílených knihoven neumožňuje odděleně udržovat a provozovat obsah adresářů /lib a /usr/bin. Jejich obsah musí být synchronní, jinak to nebude fungovat.
Toto je blbost. Pri prekladu programu se pomoci parametru --dynamic-linker da vybrat, jaky linker se pouzije pri spousteni programu. Muzu tedy prelozit vsechny programy v /bin s linkerem /lib/ld.so a programy v /usr/bin s linkerem v /usr/lib/ld.so a tyto 2 rozdilne linkery nakonfigurovat pro rozdilne vyhledavaci cesty ke knihovnam.
-
Petre, me konkretne tyhle snahy prijdou asi tak stejne posetile, jako snahy peclive hasit popelnik, kdyz hori cely barak.
Je sice hezke, ze se nekdo (?) snazi zbavit prebytecnych adresaru, ale uprime organizace Linuxoveho filesystemu je s odpustenim tak velky mrdnik a cochcarna, ze otazka duplictnich adresaru aka /bin, /usr/bin a /usr/local/bin (atd...), nebo vubec oduvodnitelnost existence /usr ci /opt, je opravdu ten nejmensi problem, ktery podle me Linuxove systemy na tomto poli maji. Staci se podivat na ten bordel co delaji programy v ~. Nebo jak jsou konfigurace a data organizovany v adresarich /etc /usr/share. Kdyz chces pracovat s konkretnim programem (ci nejkym objektem - kdyz proste predne vis co hledas) tak treba neco najdes. Ale kdyz mas jen predstavu co ches najit tak to muze byt pekne zapeklity orisek ci rovnou za nesplnitelny ukol. A jak ti s tim pomuze organizace dat v techto adresarich? Dost casto pramalo. Me osobne treba toto prijde jako mnohem vetsi problem nez existence tri, ctyr adresaru pro spustitelne soubory.
Poslednich cca 10 let si vsimam, ze Linuxova komunita (pokud vubec kdy nejaka byla) se rozpadla na decentralizovany system suverenich komunit tocicich se kolem nejakych projektu a pramalo se zajimaci o problemy a potreby tech ostatnich komunit. V Linuxovych sytemech je obsazeno a zarizeno vse podle toho, co do nich da tvurce konkretniho distra, jak to vytvori a nastavi autori jednotlivych programu a ruznych subsystemu a pak jeste podle toho, jak kdo dostatecne hlasite a vytvale rve. Tvurcu nezavyslich na komunitach, kteri jsou schopni videt Linuxove systemi s nadhledem je malo a jsou v dost obtizne situaci. Konec koncu, schyza kolem X a Waylandu je toho jen krasnym dokladem. Takze by me zajimalo, kdo pripadne zmeny vubec prosadi do praxe. Tri mainstreamova distra a zbytek Linuxoveho sveta si to bude delat dal po svym, ci(li) po staru. Vysledek? Dalsi nekompatibilta a rozdily, jako by tech soucasnych nebylo malo.
-
Když potřebuji u konkrétního softu, kde co najdu, na debianu/ubuntu obvykle zjistím název balíku přes dpkg -S a pak si vyjedu seznam jeho souborů přes dpkg -L. Ostatní balíčkovače mají podobnou funkci. Konkrétně problém různých umístění mě na linuxu nepálí. Ale jo, nejsem vývojář softwaru pro libovolné linuxy, takže se nemusím rozhodovat, co kam dát.
-
Timhle zpusobem typicky nezjistis, kde je konfigurace. A jak predrecnik velmi spravne podoktnul, je to nehorazny megabordel. O to vetsi, ze pokazde prijde nekdo "chytrejsi" a vymysli, ze by se to melo nekam presunout, coz pak vede jen k tomu, ze se ten bordel znasobi.
Neni pak zadnou vyjimkou, ze ty zmenis nekde konfiguraci protoze tam si ji menil vzdy ... a pak zjistis, ze to nema zadny efekt, protoze v mezidobi nekdo vymyslel, ze to nebude v /etc, ale treba ve /var.
-
Automaticky to nezjistím, ale z výpisu souborů debianího balíku je obvykle na první pohled vidět, kde jsou konfigy (např. /usr/share globální + /etc/ lokální - minimálně ukázky). Když se to přesune, opět dpkg -L na aktuálním balíku ukáže /var místo /etc. Neříkám, že je v tom pořádek či systém, ale nepřijde mi to jako zásadní problém.
Daleko nepříjemnější je změna konfigurace konkrétního balíku mezi verzemi, kdy se musí služba po službě po větším dist-upgradu ručně překonfigurovávat. Ale těžko tomu zabránit, pokud se nemá vývoj úplně zastavit.
8. 6. 2023, 09:49 editováno autorem komentáře
-
L.Stříbrný podporovatel
To ale máš 10 let ty stejné Windows bez aktualizací, ne? Nastavení ve Woknech je peklo. Nelogické a navíc ho Microsoft neustále překopává. Takže málokdy se mi stane, že potřebuju něco méně obvyklého nastavit a je to na stejném místě jako minule. (Nejsem admin, jen uživatel.)
Zrovna to IP jsem teď vyzkoušel... no, proklikal jsem se k němu, ale ten dialog jsem v životě neviděl.
8. 6. 2023, 12:39 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatel
Nejlepší věc, kterou Microsoft v nastavení udělal, je fulltextový vyhledávač. Není potřeba zjišťovat, kde které nastavení je – stačí si pamatovat, pod jakým klíčovým slovem ho hledat. (Někdy mám pocit, že se to nastavení nestěhuje jen s novými verzemi Windows, ale že to závisí i na dni v týdnu nebo fázi měsíce.)
-
k3dARStříbrný podporovatel
a pokud se nepletu, napr. k autologin (ne smazamani hesla) se neda doklikat, ale musi se pustit netplwiz.cpl :-)
-
/etc/network/interfacesZhodou okolnosti, konfiguracia siete je jednou z veci, kde je debian, povedzme to diplomaticky, sa zastavil cas a dodrziava tradicie z 90-tych rokov. RHEL stihol prejst krokmi: a) zmena na NetworkManager (s pluginom, ktory ukladal konfiguraciu do tradicnych redhatovskych konfigurakov), b) deprecation tohto pluginu a c) odstranenie tohto pluginu, s konfiguraciou len cez standardny NetworkManager.
-
ten konktretny stroj na ktorym som si trhal vlasy to mal v NetworkManageri a teraz pre istotu som sa pre istotu uistil, ze o sebe pri prihlaseni tvrdi, ze to je Debian :).
Rozhodne to nebolo v interfaces, pretoze tam som to hladal samozrejme ako prve.Tu konfiguraciu v NetworManageri som napokon nasiel rano cez grep.
Co uznavam, ze na Windowsoch nie je pouzitelna strategia :). -
V pripade NM sa treba naucit pouzivat nmcli, ved je tu len nejakych 19 rokov... ;). NM totiz moze mat pluginy na ukladanie konfiguracie, takze aj ked system pouziva NM, ulozene to teoreticky moze byt vselikde.
Horsie je, ked to niekto zoberie ako Canonical a natlaci tam dalsiu zbytocnu vrstvu, ako netplan.
-
Vsak chtit konzistenci po linuxu :-))) Nez nekdo vymysli "konzistentnejsi" nove reseni a rozmrcasi stavajici system s cilem lepsi konzistence
NM dobry sluha na desktopu( po tom co pan simerda vymetl augiasovy chlevy), zly na serverech.
Uz jsem par NM only server konfiguraci taky videl u startupu.
Delat pak nejake zmeny config managementem nad jiz existujici konfiguraci NM je za trest.
Nikdo z adminu poradne netusi jak nm funguje uvnitr a v jake fazi si pod sebou uriznou vetev - startupy vetsinou na out of band management kaslou. -
Vsetko prebieha nejakym vyvojom a zrovna NM bol vyraznym krokom vpred. Ano, konzervativnym distribuciam dokaze trvat dekadu, kym nieco uzitocne adoptuju a konzervativnym adminom potom dalsiu dekadu, kym si to vsimnu, ale prave to je jeden z faktorov, co sposobuje tu roztriestenost.
A ktory to config management ma problem s NM?
-
Saltstack.
Ale zatim je to jedno vsechny RH masiny maji uz z provizioningu NM_MANAGED=no nebo tak nejak. Az to prestane fungovat - na coz se prijde pri akceptacnich testech - tedy minimalne 1-2 rok pred nasazenim tak bude dost casu otriskat nefungujici veci co potrebujeme redhatu o hlavu. Resili jsme nefunkcni bonding s ip aliasingem a DCB.
Na tom vsem je nejdebilnejsi ze kazdou sitovou konfiguraci je treba rozebrat, sepsat risky, udelat upgrade testy a byt extra opatrny. Pokud by NM fungoval, tak prechod bude trvat tak 5 let optimisticky. A to se tomu bude venovat clovek full time vcetne callu s inzenyrem u RH aby si spravili svoje lejna.
Jeste jsem ani netestoval scenare typu mam 4 portovou kartu a jsou tam tyhle sfp. Mam 4 x 4 portove karty a jednu z nich prekonfiguruji a zmeni se logicke interface - jak na ne navesit predchazejici konfiguraci. A 2x4portova karta je uplne bezny default u vetsich serveru.
-
Možná proto mi na novém Debianu nefunguje korektně nainstalovaný TeX. Všechno tam je, ale "najde" se jen základní anglický TeX. Csplain, LaTeX, pdfLaTeX a další to nenajde, i když v systému jsou (to se dá s právy roota ověřit).
On ten TeX je docela konzervativní (až nesmyslně). Kdysi jsem instaloval z CD TeX na starší PC a nechtělo to fungovat. Po nějaké době jsem zjistil, že se nainstalují všechny možné soubory, ale samotný TeX při instalaci končí hláškou, "že je moc starý". Nakonec jsem to vyřešil změnou datumu v PC asi o dva roky zpět, nainstalovalo se to korektně a zpětné nastavení správného to už přežilo.
Vzhledem k tomu, že práce se soubory v TeXu tvoří řádově desítky procent toho, co na počítači dělám, je pro mě nový počítač s novým Debianem totálně k ... a musím stále dělat na starém a pravidelně zapalovat svíčičku u kapličky, aby ještě vydržel.A v takovém případě je, pochopitelně, otázka, zda je uvedená změna skutečně takový přínos. Obávám se, že všechny balíky, které budou potřebovat původní adresářový systém, se nedají vychytat a upravit. Asi by bylo optimu blízké mít možnost balíky kompatibilní s "novými" pravidly nainstalovat "po novu" a ty, které s nimi kompatibilní nejsou, mít možnost nainstalovat "postaru". Minimálně pár cyklů verzí, než bude zaručené, že všechny balíky "po novu" nainstalované budou funkční.
ČLÁNKY DO MAILU