Az Alpine Linux usr összefésülést tervez

Fájlrendszer, NAS, storage

Az Alpine Linux Technical Steering Committee (TSC) úgy döntött, hogy megváltoztatja az alap fájlrendszer-hierarchiát. A jövőben a /lib, /bin és /sbin szimbolikus linkek lesznek a /usr alatti megfelelőikre, és minden csomag a /usr útvonalak alá kerül telepítésre. Egyelőre a /usr/bin és a /usr/sbin továbbra is önálló elérési utak maradnak, de ez változhat, ha frissül a Filesystem Hierarchy Standard (FHS).

[...]

Az összevonás a novemberre tervezett Alpine 3.23 kiadásban fog megtörténni; a nem összevont rendszereket 2027 májusában, amikor a 3.22 eléri az életciklusa végét, nem támogatottnak tekintik.

Részletek itt.

( persicsb | 2025. 10. 02., cs – 15:23 )

Azaz majdnem visszatérnek az eredeti Unixhoz.
Az, hogy a /bin egy symlink a /usr/bin-re, a System V-ben jött be a Unixba.

( bimi3 | 2025. 10. 02., cs – 17:58 )

A Fedora ezt már meglépte. A gyökérkönyvtár szimlinkelve van, jelenleg így fest:

bin -> usr/bin
lib -> usr/lib
lib64 -> usr/lib64
sbin -> usr/sbin

Arch, Debian, Ubuntu is. Eredetileg az /bin, arra szolgált, hogy a csak a root partícióról bootolható legyen a rendszer, és jelen legyenek rajta a legszükségesebb binárisok (mount, fsck, su, stb.), ha a /usr-hez tartozó partíció nincs felcsatolva. A Unix fénykorában, PDP11/VAX gépeken kis HDD-k voltak, 10-20 megásak, szét kellett aprózni mappákra, amik másik lemezen fértek csak el. Ma már, a nagy háttértárak korában felesleges ez a sokfelé osztogatás, ezért mindent a /usr/-be tesznek, a többi meg symlink, hogy ha adott programok azon az ősi helyen keresnék, akkor is elérhető legyen. Ha meg a /usr külön partíción van, és valami miatt nem csatolható, pl. fájlrendszerhiba, akkor meg így járás esete van, nem fog bootolni a rendszer. Szerk.: hacsak az initramfs meg nem oldja, az is van már a legtöbb disztrón.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( jimmy399 v | 2025. 10. 02., cs – 18:24 )

Debian is megtette már egy jó ideje...

Épp fel akartam háborodni, és mit látok:

lrwxrwxrwx   1 root root       7 May 20  2022 lib -> usr/lib
lrwxrwxrwx   1 root root       9 May 20  2022 lib32 -> usr/lib32
lrwxrwxrwx   1 root root       9 May 20  2022 lib64 -> usr/lib64
lrwxrwxrwx   1 root root      10 May 20  2022 libx32 -> usr/libx32

Szóval... ha eddig nem tűnt fel nekem, akkor kit érdekel :)

( asch v | 2025. 10. 02., cs – 20:22 )

Emlekszik meg valaki, hogy mit jelentettek ezek a folderek es mit kene jelenteniuk most?

Hogyne. Egyfajta stabilitást. A /bin, /sbin, és a hozzá tartozó lib könyvtárak arról szóltak, hogy egy minimális rendszer akkor is elinduljon, ha nem mountolt sikeresen az /usr. Aztán valaki kitalálta, hogy kár külön szedni, és egyberakták, mondván, hogy majd az initramfs úgyis megoldja, vagy ha ez neked nem tetszik, akkor ne tedd külön partícióra az /usr-t.

Nem az volt az oka hogy amikor egy gépen rengeteg felhasználó volt akkor ha bővíteni kellett a tárhelyet akkor csak átmásolták egy nagyobb vinyóra és újramountolták?

A kérdés egyébként jogos hogy 2025-ben önmagában ez mennyire valós usecase (akár a sok user mint elképzelés). 

Az is lehet, hogy egyszerűen akkor még nem voltak elég nagy diskek.

Aztán régen még szempont volt, hogy melyik partíció/fájlrendszer melyik cilindereken lakik.

Még ilyenek is voltak: https://docs.oracle.com/cd/E19253-01/817-5093/disksconcepts-29477/index…

Manapság... általában nincs rá szükség. Szerintem.

Közben módosítom, mert ez talán a /home-ra adna választ, a /usr-ben ha jól emlékszem a programok vannak, akkor meg mi a use case? A rengeteg program amit feltelepítenek, az alól elfogy a tárhely? Hát ennek túl nagy realitását nem látom, ha csak nem 50 gigás játékokat akarna valaki telepíteni, bár talán az se a /usr/-be megy hanem mondjuk a /opt-ba, vagy már a jó ég tudja hogy mi a szabály, akkor egy katyvasz az egész. Lehet érdemes lenne újragondolni hogy mire van valóban szükség 2025-ben és nem 1970-ben.

Az a vicces, hogy mostanában pont, hogy egyre több értelme van megint. Úgy elkezdett hízni az /usr mappa, mintha nem lenne holnap, nekem a gyökér fájlrendszer össz foglalásának szerintem 60-70%-át a /usr teszi ki. Pl Java alapú cuccok függőségei, NodeJS alapú cuccok függőségei, stb. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Ugyanakkor az a gond, hogy összevissza vannak a függőségek, talán a /sbin-ből is volt /usr/, így visszamenni már nagyon nehéz.

Ami nagyobb probléma, hogy sokszor a /tmp-re végtelen tárhelyet várnak el (implicit módon, tárhely elvárások feltüntetése nélkül) vagy a / része, a /var is része a /-nek.

sokszor a /tmp-re végtelen tárhelyet várnak el

Ki várja el a végtelen tárhelyet? Ha van olyan processz, ami oda dolgozik, és a processz "végtelen sokáig" fut, akkor valóban végtelen tárhely kell oda. Amúgy szerinted, ha van egy nagyon sokáig, akár évekig folyamatosan futó processz, akkor az a processz mit feltételezzen, hova tud dolgozni, ahol van elegendő tárhely?

Hiába létezik a Filesystem Hierarchy Standard, ha ezt sem az üzemeltetők, sem a szoftverfejlesztők nem tartják be.

Én egységsugarú fejlesztőként melyik directorytól várhatom el, hogy a processzem tud oda írni hosszú távon, sok adatot? Amíg minden egyes üzemeltető máshogy képzeli ezt el, és akár a /home-ot teszi naggyá, akár a /usr/-t, akár a /opt-ot, vagy a /srv-t, addig eléggé szar a szoftverfejlesztők élete. Láttam már olyat is, ahol /mnt/data, /storage volt az a tárhely, ami a változó adatoknak volt szánva. Mi lehet a jó alapértelmezés szerinted? És mit csináljon a szoftveres, ha az üzemeltetés nem hajlandó követni az FHS-t, mert van neki belső megszokása erre?

Telepítesz egy alkalmazást és elhasal, keresgélés stb után kiderül, hogy neki "sok" tárhely kell a /tmp-be.

FHS: "/tmp: Often not preserved between system reboots and may be severely size-restricted."

Nyilván a "size-restricted" mást jelentett 30 éve, de még mai viszonyok között sem egyértelmű, a gondom azzal van, mikor egy alkalmazás azt feltételezi, hogy oda akár GB-okat fog tudni pakolni.

Neked egységsugarú fejlesztőként az lenne a feladatod elsősorban, hogy leírd az elvárásokat (ne csak annyit, hogy az alkalmazásnak 5GB tárhely kell, hanem azt is, hogy hol, beleértve a kicsomagolási folyamatot), még jobb, ha a TMP tárhely átirányítható például egy dokumentált változóval. Az pedig hab lenne a tortán, ha telepítés előtt felméri a rendelkezésre álló tárhelyet és szól, ha valahol nem elegendő, de ennek visszafejtésével azért lehet játszani.

Az FHS-ben sehol nincs szó arról, hogy a /tmp erősen tárhelykorlátos lenne:

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s18.html

 

nyilván lehet mondani, hogy impliciten mindegyik directory-ra igaz, hogy erősen tárhelykorlátos, de továbbra is kérdem: mi az, amiről feltételezhetjük, hogy nem az?

Minden csomag telepítési scriptjét meg a futtatását szét kéne paraméterezni, hogy akkor most hova is tegye az X, Y és Z típusú fájlokat?

Szeretnél-e egy ilyen rendszert üzemeltetni, ahol minden programot kézzel egyesével be kell állítanod, hiszen nincsenek használható alapértelmezések, a szoftverek nem tételezhetnek fel semmit arról, hogy hol milyen tárhely van?

Konvenciók és szabványok nem véletlenül léteznek.

a TMP tárhely átirányítható például egy dokumentált változóval.

Mondjuk erre való a virtualizáció, a konténerek meg sok minden más absztrakció. De még akár a chroot is, ha te azt szeretnéd, hogy az adott processz másként lássa a fájlrendszert.

Én innen vettem: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard. A tiéd nyilván erősebb, mert linuxfoundation.org domainen van. De igazából tök mindegy, hogy mekkora, a /tmp lehet egy korlát, mint ahogyan bármelyik másik fájlrendszer is.

Minden csomag telepítési scriptjét meg a futtatását szét kéne paraméterezni, hogy akkor most hova is tegye az X, Y és Z típusú fájlokat?

...

Nyilván nem erről van szó, csak most kicsavarod, valószínűleg inkább nem akarod megérteni.

Ha az üzemeltető kap egy telepítőt, akkor az üzemeltető tudja, hogy hol mekkora tárhely szükséges ahhoz, hogy az az alkalmazás feltelepüljön. Ha /opt alá megy 5GB, akkor tudja, hogy a /opt alatt legyen szabad 5GB. Ha előtte a /tmp-be mindent kicsomagol, akkor tudja, hogy a /tmp-be is kell 5GB szabad hely. Ha a /tmp alatt nincs 5GB, akkor az üzemeltető tudjon adni egy ideiglenes 5GB tárhelyet, ahova kicsomagolódik telepítés alatt, pl. export TMP=/var/tmp.

Szerintem nem olyan bonyolult ez.

Ugyebár azért nem olyan egyszerű ez - a tmp az legyen nagy.

Ugyanis egy alkalmazás, amikor letöltöd, lehet az tgz, rpm, deb, akármilyen formátum, az egy archívum, amit valamilyen ideiglenes helyre ki kell csomagolni, hogy a telepítője tudjon dolgozni.

Mert ugye utána már a telepítő rakhat a /var-ba, a /lib-be, a /bin-be, a /sbin-be, a /etc-be stb. meg akárhová is fájlokat, ha eredeti UNIX logikával működik. Ha meg modernként, jól viselkedik, akkor /etc meg /opt és kész.

Azaz aminek biztosan kell nagy hely, az a /tmp és a /opt, nem is értem, hogy miért nem kézenfekvő ez mindenki számára.

tgz/rpm/deb tipikusan végleges helyre csomagolódnak ki.

Én pedig azt nem értem, hogy miért nem kézenfekvő a fejlesztők számára, hogy üzemeltetéshez nem árt tudni, mekkora a "nagy" és hol nagy. Lásd mikor 2020-as években is azt írják még egy alkalmazás rendszerkövetelményeibe, hogy RAID10-es tömbön legyen elhelyezve.

A /tmp azért nem nagy az emberek fejében, mert az jobb helyeken ramdisk, ugyanis az a feladata, hogy gyors legyen, nem pedig hogy nagy legyen.

Ha nagy temp könyvtár kell, akkor /var/tmp, lévén a /var az ami a változó adatok számára van fenntartva.

A /opt az opcionális programok számára van fenntartva, és ez az a hely, ahol a két filozófia csatája miatt rumli van.

Az egyik filozófia szerint a program binárisa menjen a helyére, /bin, /sbin, /opt/programneve, és ha szükséges, akkor legyen vele kibővítve a PATH, de a program által használt adatok ne a program mellett legyenek, hanem egy erre dedikált helyen, /var/programneve, /data, /storage, és hasonló helyeken, mert ezekhez nem ritka, hogy az ember becsatol FC -n egy távoli storage -ot, mert az fog több tíz terát tárolni, nem pedig a /opt, pláne nem a /tmp.

Logok ugyanígy, normális program vagy közvetlen a syslogba logol, vagy a /var/log/programneve állományba.

A másik filozófia, hogy /opt/rogramneve alatt van a bin, lib, conf.d, db, data, log meg akármilyen alkönyvtárak, és így a programmal egy alkönyvtárban kompakt módon van tárolva a programhoz szükséges minden adat és függőség.

Egy kis program, ami csak pár MB adatot tárol nekem nem fáj, ha így van, de estünk már bele olyanba, hogy a a fejlesztőcég debug logot állított be, így a /opt/programneve/log könyvtárba nem a szokásos alig-valami került, hanem elég hamar felzabálta a /opt LVM kötet teljes területét. Kevés a hely? A /var kötet ami nagy, mert ott laknak az adatok, például a log állományok, tessék oda logolni, ahova szokás.

Persze, ha valahol meg az a szokás, hogy a /var csak dísznek van, és minden cucc a gépen a /opt/programneve alatt van, és oda is termeli az állományait, ott majd a /opt lesz nagy, lehet így is, csak ezt jó előre tudni.

Ha fejlesztő vagy, és ezzel szívsz, akkor javaslom számodra, hogy vezesd ki a konfigurációs állományodba, hogy:
logdir = /var/log # or /opt/programneve/log
datadir = /var/programneve/data # or /opt/programneve/data
ramdisk = /tmp
tempdir = /var/tmp # or /opt/programneve/tmp

és a többi releváns könyvtáradat. Valamint induláskor kérdezd le a temp könyvtárt hordozó kötet szabad kapacitását, mert simán lehet, hogy valaki a /tmp -re állítja be, ami meg aztán mondjuk 128MB ramdisk, vagy valami hasonló.

Volt olyan szállítónk, aki úgy akart linuxos programot hozni, hogy feltételezte, hogy a / az egyetlen kötet, és nem értette, hogy miért van LVM -el több részre szedve. Hát, nem volt hosszú életű a kapcsolatunk.

Nem csak volt, van is /usr/sbin. A /tmp mountolható külön is, vagy akár lehet tmpfs-re tenni, nesze neked végtelen :D A /var megkerülhetetlen, de egyes könyvtárakat nyugodtan tehetsz más partícióra, a /var/log szokás is, de mióta docker van, megfontolandó a /var/lib vagy a /var/lib/docker is.

tmpfs és végtelen pont nem feltétlenül szerencsés felállás, akkor már jobb lehet egy dedikált, ideiglenes virtuális lemez ha virtuális gépről van szó. De nem is erről szólt a megjegyzésem, hanem a káoszról, ami a struktúrát övezi: sokan nem vesznek arról tudomást, hogy a / normál esetben nem feltétlenül olyan, mint egy C: meghajtó. És nem is kellene olyannak lennie, mint ahogy jobb helyen azért a Windows alatt is vannak különféle célra dedikált meghajtók. A Linuxos struktúrában pont az a jó, ha arra van igény, könnyen külön lemezterületre tudsz terelni valamit. Ez például egy Exchange és Sharepoint esetén közel sem annyira triviális.

De láttam már /var-t, köszönöm, a fentieken kívül is sokféleképpen lehet még ragozni a témát.

Több lehetséges ok van/volt

Több érv volt amellett, hogy az /usr egy külön, csak olvasható partíción legyen, így egy esetleges behatolásnál nehezebben volt módosítható (tudom, ha valaki már root, akkor mindent megold). Volt olyan lehetőség is (kisméretű diskek esetén), hogy az /usr-t hálózati meghajtóra (NFS) tették, és egyszerre több rendszer volt képes ugyanazt a megosztást használni (természetesen csak olvasható módon). És még lehetne néhány indok, amelyeket nem ismerek vagy már elfelejtettem.

( DirtY_iCE | 2025. 10. 02., cs – 20:43 )

Amugy csak en nem ertem hogy miert mindenki symlinkeli a /bin-t meg tarsait a /usr-be, es nem az /usr-tol akarnak megszabadulni (azaz /usr/bin kene symlink legyen az /usr-re, stb). Kb csak azert van /usr mert a pdp-11-be nem lehetett eleg nagy disket rakni.

I hate myself, because I'm not open-source.

"The story of the laser printer, a technology developed by PARC’s Gary Starkweather, epitomizes the poor communication between the research laboratory and corporate headquarters that resulted in Xerox’s inability to capitalize on PARC innovations. Starkweather, a researcher at Xerox in the mid-1960s, had an idea to use lasers in Xerox’s copiers. Starkweather realized that short exposures, on the order of a billionth of a second, from a laser could replace the copier’s traditional light source. More important, a laser-driven copier could also serve as a printer, taking an image from a computer screen and capturing it on paper. No longer would computer printers be restricted to producing text and approximating images with standard typographic characters. Instead, anything displayable on a computer monitor could be printed. The idea of “what you see is what you get” (WYSIWYG) would work on paper as well as the monitor. Unfortunately, at that time Xerox saw no point in innovating when their current technology worked so well. Only intervention by Goldman saved the idea when he had Starkweather transferred to PARC in 1971. By early 1972 a working prototype existed—but Xerox did not bring it to market until 1977. The laser printer soon became a best-selling product."

A  Alto-t is kifejlesztették, majd megmarat kutatási projektnek évekig, ahelyett, hogy megpróbálták volna  kereskedelmileg sikeres termékké tenni. Gyakorlatilag a következő évtizedek legnagyobb technológiai újításán, a grafikus ablakozós személyi számítógépen ültek, és közben fénymásolókat gyártottak. 

Azért, mert a /share hülyén is nézne ki, plusz van ahol oda a SMB/NFS/stb megosztásokat teszik ki, mert az a logikusabb. Szerintem ez jó így, könnyebben is kezelhető, egy helyen van a rendszer (egy mappában), logikusabbnak is tűnik.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

En is pont ezt gondoltam.

A /-ben a "nagy" dolgok vannak, mint /tmp, /dev/, /etc, /home, /mnt, /net, /proc, ...

A /usr -be mehet a komplett OS. Es akkor apparmor/selinux extra vedelem is holtegyszeru.

Es igy az OS maga igazabol csak 1 dolog a sok kozul, ahogy a valosagban is. Ugye akar le is torolheted, nem veszitesz semmit - ujrahuzod, kesz, megvan minden repo-kban, apt-get es kesz is vagy.

A /usr -be mehet a komplett OS.

Hol ér véget az OS, és hol kezdődnek a felhasználói programok?

A LibreOffice vagy a Firefox az OS része? Egy Spotify flatpak az OS része? Vagy csak a GNU coreutils az OS?

Pl. a vscode miért ne a /opt-ba települjön? Az a helye az FHS szerint. Vagy épp hova települjön bármely 3rd party alkalmazás, ami nem az OS vendor csomagtárolóiból jön?

Nem ertem, ez alapjan a /dev meg /proc meg /sys meg /boot is mehetne az /usr-be mert az is az oprendszer resze (hogy ebbol egy par az csak virtualis fs az ilyen szempontbol mindegy). A /-be meg maradna kb az /etc, /home, /mnt, /opt, /tmp, /usr, /var. Igazabol az is marha jo kerdes hogy a /root az miert van ott es miert nem a /home-ban (kb csak azert hogy ha a /home kulon particio es jo ha a root be tud lepni ha nincs /home, de ez megint kicsit hajaz a /usr kulon fs-en kerdeskorre).

Edit: ja de vannak ilyen marha jo directoryk mint /usr/var meg /usr/local ahol borul az egesz elkepzeles.

I hate myself, because I'm not open-source.

Az /usr/var tényleg hülyeség, az /usr/local viszont nem. Oda mehetnek azok a binárisok, (az /usr/local/lib könytárba meg a libjeik) amelyek nem a disztribúcióból jönnek, hanem valahonnan máshonnan (pl. forrásból fordítva). Szerencsés esetben ezeknek a változó adataik meg a /var/local-ban vannak.

Lehet, hogy egyszerűbb lenne, de nem így alakult ki. De a /local szerintem értelmetlen, az egy alternatíva lenne az /opt-hoz, az /opt pont így műkodik. Én Debiant használtam a legtöbbet (most is), ott nem az /opt a megszokott, hanem a különféle local dolgok, ahogy leírtam korábban.

Szerintem az FHS egy csomó helyen eléggé nem jó, pl ez a része eléggé sokféleképp értelmezhető, de az a gyakorlat, hogy egyszeri random vendorokat leszámítva senki le se szarja az /opt-t, az alapvetően nem jó.

Ugye az /usr/local tree definíció szerint "The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr."

Most attól tekintsünk is el, hogy ha locally, akkor mi a fosért lehet használni data share-re hostok között, az érdekesebb kérdés, hogy mi a pöcsöt jelenthet az installing locally.

Ugye a másik oldalon "/opt is reserved for the installation of add-on application software packages."

Én személy szerint rule-of-thumb azt mondanám, hogy nem az /usr/local kéne legyen a default helye a valahonnan máshonnannak, oda az megy, amit tényleg kicsi kezeddel legózol oda valahogy. A többinek meg az ilyen ppa, aur, koju (including kb az ilyen gyűjteményes extrákat is mint epel*) valójában alapvetően az opt alá kellene dolgozni.

Racionálé: A definíciók szarok, de az egy jó közelítés talán, hogy a system része az, ami a distró repóiban lakik. A local definíciónak fontos része az, hogy ne bassza már el a csomagkezelőből jövő update, amit oda tettem a kicsi kezemmel. Egyrészt szerintem ez fölöslegesen restriktív arra nézve, hogy miért csak a system updatek ne basszák el, amit kézzel odatettem, másrészt a gyakorlatban ez nagyon sokszor egyébként is össze van gabajodva, mert ugyanaz a csomagkezelő, és függőségi fák is épülnek egymásra. Sokkal fontosabb határvonal a csomagkezelő vs máshogy, mint a többi. Meg hát azok egyébként is sokkal inkább add-on ok, mintsem locally installedek (ami eleve egy teljesen kretén megfogalmazás, de minimum rettenetesen idejemúlt)

*kivéve, ha frissebbet hoz valamiből, akkor az /usr alá kell tenni szabály szerint. Amit értek, hogy miért tűnt jó ötletnek, de egyébként landmine erősen.

 

----

De eredetileg valójában csak azt akartam mondani, hogy egy csomóan nem tudják, hogy az /opt/bin|lib|include|man... reserved szintén az adminnak, szóval ja :)

de az egy jó közelítés talán, hogy a system része az, ami a distró repóiban lakik.

Ezzel nem tudok egyetérteni.

Az egész FHS úgy kusza, és aluldefiniált, ahogy van. A kiindulópont az, hogy nem definiált, hogy mi az, ami az operációs rendszer része.

Az, amire az adott disztribúció támogatást ad?

Vagy az, aminek a megléte nélkül el sem indul egy egyszemélyes, root munkamenet?

Miért része mondjuk az operációs rendszernek a Firefox meg a Libreoffice attól, hogy az adott disztribúció újracsomagolva telepíthetővé teszi a saját tárolóiból? 

A local definíciónak fontos része az, hogy ne bassza már el a csomagkezelőből jövő update, amit oda tettem a kicsi kezemmel.

Igen, ez egy fontos dolog, de akkor a /etc-ben lévő fájlokat eleve nem is szabadna módosítanod, csak hozzáadni configdir jelleggel. Hiszen azokat a rendszer szállította, az ettől eltérő, lokális módosításokat jó lenne elkülönítve tárolni. Persze ehhez az is kellene, hogy minden szoftver támogassa ezt.

Kusza és aluldefiniált az egész, aki azt gondolja akár üzemeltetőként, akár fejlesztőként, hogy valaminek az X helyen van a helye, az téved igazából. Főleg mivel az X disztró így csinálja, az Y meg úgy.

Ezzel nem tudok egyetérteni.

Mármint imho...

Miért része mondjuk az operációs rendszernek a Firefox meg a Libreoffice attól, hogy az adott disztribúció újracsomagolva telepíthetővé teszi a saját tárolóiból? 

Mert együtt jön, és egységesen kezeli a disztribútor a minden mással is. És a gyakorlatban szerintem ez a valódi lényeges vízválasztó, hogy ki az, aki azokért a filokért felel. 

Az egész FHS úgy kusza, és aluldefiniált, ahogy van. A kiindulópont az, hogy nem definiált, hogy mi az, ami az operációs rendszer része.

Kusza és aluldefiniált az egész, aki azt gondolja akár üzemeltetőként, akár fejlesztőként, hogy valaminek az X helyen van a helye, az téved igazából. Főleg mivel az X disztró így csinálja, az Y meg úgy.

Igen, szerintem is, ezzel is nyitottam.

Igen, ez egy fontos dolog, de akkor a /etc-ben lévő fájlokat eleve nem is szabadna módosítanod, csak hozzáadni configdir jelleggel. Hiszen azokat a rendszer szállította, az ettől eltérő, lokális módosításokat jó lenne elkülönítve tárolni. Persze ehhez az is kellene, hogy minden szoftver támogassa ezt.

IMHO a konfiguráció az egy elkülönült történet, ér más szabályoknak lenni erre nézve. Ez már nem feltétlen az FHS dolga, ez már inkább az update policy és környéke, meg software dependent, ahogy mondod. Nyilván mindenkinek van erre valami generic stratégiája, de az már inkább a csomagkezelő földe. Nem is lenne mindenhol értelmezhető a config dir stratégia, de sokkal több dolognak kéne támogatni, mint amennyi teszi.

Szerintem a frissítés ugyanolyan telepítést jelent, mint amikor frissen telepítesz valamit, úgy kéne kezelni.

Főleg azért, mert egy verzióváltásnál (legyen mondjuk ez egy diszt-upgrade, vagy akár csak egy rolling release esetén egy nagyobb frissítés), egy adott program fáljai teljesen megváltozhatnak, mind helyüket, mind tartalmukat tekintve.

Azaz az, hogy eddig létezett a program egyik verziója esetén a fájlok egy halmaza, most meg létezik egy (akár lényegesen eltérő) másik halmaza.

Emiatt eleve nem lenne szabad a csomag által szállított, azzal telepített fájlokba belenyúlnia a felhasználónak, maximum csak felülbírálni/kiegészíteni azt, új fájlok létrehozásával, amelyek biztosan nem részei a csomag fájlainak sem most, sem a jövőben.

De ugye ezt a legtöbb szoftver nem tudja.

Ugyebár a mindenféle atomian frissített szoftver esetén próbálnak efelé menni, fájlrendszer rétegekkel, de még nem tartunk ott, ahol kéne. Pont azért használják a rétegeket, symlinkeket, mert nincs éles elkülönítés, és trükközni kell.

Amikor meg oda jutunk el, akkor igazából kiderül, hogy kétféle felső szinrtű mount point kell a szoftvereknek: a telepített programoké, amelyek a user számára nem írható, meg a user számára a felülbírálások/kiegészítések és használat során keletkező fájlok. Minden ezen két hierarchia alá kellene, hogy menjen. Akár lehet ez /sys (tudom, ez a virtuális fájlrendszer másra van használva) és /usr, vagy valami hasonlók.

Jaj bocs hulyeseget irtam, nem unrar hanem rar.

annyira nem nagyon része az OS-nek

Jo de ez ilyen eleg megfoghatatlan indoklas. Most egy chromium vagy libreoffice miert resze jobban az OS-nekmint mondjuk a rar? A cuda az meg a legjobb, mert pl. ha leforditod az ffmpeg-et a cuda use flaggel, akkor meg hirtelen egy system library fog dependelni egy /opt-ban levo cuccra.

I hate myself, because I'm not open-source.

Szerintem az /usr/local lenne a forrásból felrakott dolgok helye, az /opt pedig a bináris bloboké, amelyek nem illeszkednek a fájlrendszer-struktúrába (pl. /usr/local/share, /usr/local/doc)

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

A /opt alatt nincs bin, lib stb, ott tipikusan egy mappa egy alkalmazás elvet követi. És akkor az alatt van az alkalmazásnak a saját bin, lib stb mappája.

A /usr/local alatt van bin, lib stb, ott szét is lehet/kell szedni.

Azaz

/usr/local/bin/app1bin
/usr/local/lib/app1.so

/opt/app2/bin/app2bin
/opt/app2/lib/app2.so

Nalam van /opt/bin es onnan be vannak symlinkelve a rendes executableok.

De mindenesetre most az van hogy van 2 binaris lehetoseg (disztrobol jon vs valami local cucc, egy mappa kell neki vs szet lehet szorni sok helyre), ennek van 4 lehetseges opcioja, ebbol haromra csinaltunk egy mappat, a maradek meg jobb hijan altalaban megy az /opt-ba, de igy meg kesze-kusza lesz.

I hate myself, because I'm not open-source.

Végül is nincs rá indok, hogy miért nem fordítva csinálják, de a lényeg, hogy a kettő közül valamelyik felesleges ma már. Az OpenBSD is telepítésnél még a default partícionálási sémánál ragaszkodik, hogy minden mappát más szeletre akar tenni, még az X11-et is. Ez is egy régi beidegződés, szintén ugyanezen korszakból, hogy a PDP-11-ben csak pár magás HDD-k voltak. A /var-t külön partícióra tenni is csak szerveren van értelme, hogy a logok ne tudják a helyet megenni, meg deszktopon nem árt, ha ~ külön van, hogy újratelepítésnél ne kelljen mentegetni belőle az adatokat. Meg ugye a boot, EFI partíción külön kell legyen, de minden más mehet egybe ma már.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( whitehawk v | 2025. 10. 02., cs – 20:44 )

Szerkesztve: 2025. 10. 02., cs – 20:45

-

Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش