- This topic has 297 hozzászólás, 23 résztvevő, and was last updated 16 years, 11 months telt el by
.
-
Bejegyzés
-
Figyelj, Zoltán22 ! Én TUDOM (most már…), hogy elméletileg és nagyjából (!) melyik hagyományos könyvtár mire való. Tudja ezt Hisham is. Épp csak ennek manapság már nincs értelme, mert ki lehet találni jobbat is! Erről Hisham írt egy remek cikket, le is fordítottam (nem kis munkával) magyarra, itt olvashatod:
http://www.gobolinux.org/index.php?lang=hu_HU&page=doc/articles/clueless
de ideidézem belőle a legfontosabbat:„Oka van annak, hogy a dolgok olyanok, amilyenek ”
Ezt valamit, amit állandóan hallok, gyakran követi egy magyarázat a /, /usr és /usr/local, és/vagy a /bin és /sbin közti különbségről. Értem a különbséget1. Ha eltöröltem ezt a három szintű megkülönböztetést, annak az az oka, hogy hiszek abban, miszerint van más mód is azon problémák orvoslására, amik e hagyományos megkülönböztetést életre hívták. Egy GoboLinux rendszerben semmi érv nem szól amellett, hogy legyen különálló /usr és /usr/local azért, hogy elkülönítse a disztribúció által szállított programokat azoktól, amiket a felhasználó fordított magának. Mindegyik program természetes módon elkülönített, és pontosan ez is a legelső helyen említhető szándékunk azok közül, melyek végül a GoboLinux létrejöttéhez vezettek.
Az a történelmi ok, amiért az Unix-rendszerek tartalomjegyzékeinek egy része közvetlenül a gyökérkönyvtárból ered (/bin, /lib, /sbin), ellentétben azokkal amik a /usr könyvtárból nyílnak, nos az nem más, mint hogy így módodban áll bebootolnod egyfelhasználós üzemmódban, csupán ezen, a gyökérből nyíló fájlokat használva, megjavítandó velük a /usr könyvtárfa esetleges hibáit. Ez azonban csak „vallási hittétel”. Amikor meg kell mentenem a rendszeremet, inkább egy teljesértékű Linux rendszerrel felszerelt LiveCD-t használok, ami még grafikus környezetet is biztosít a számomra, az megengedi nekem, hogy böngésszem a világhálót és ott keressek megoldást a problémámra, és egyáltalán, egy teljes rendszer minden lehetőségét felhasználhassam a javítás érdekében. Tisztában vagyok azzal, hogy mi volt az értelme a régi rendszermentési megoldásnak évtizedekkel ezelőtt, de mostanság már sokkal jobb megoldással is rendelkezünk.
A bin és sbin közti megkülönböztetésének nincs értelme a jelenlegi kontextusban. A történelmi evolúció őrült önkényes megkülönböztetésekre vezetett, mint például a ping és traceroute külön tartalomjegyzékbe helyezése (képtelen vagyok felfogni, miként tarthatja valaki bármiképp is különböző programosztályba tartozónak e kettőt).
Egy Unix-rendszer az engedélyek rendszere. Ha az az óhaj, hogy valamely parancs csak rendszergazdai joggal legyen futtatható, akkor a megoldás: chmod 700 a megfelelő állományra, és kész. Azt gyanítom, hogy a programok megkülönböztetésének hagyományos rendszerét talán amiatt találták ki, hogy csökkentse a programok számát a normál felhasználók $PATH-jában. A mai Linux rendszerekben, lévén hogy akad akár 400 vagy 500 program is a $PATH-odban, ennek a megkülönböztetésnek semmi értelme.
Utolsó érvként megemlíthető, mindazonáltal, ami a Linux rendszereket a mai napig is jellemzi: a partícionálás és a távoli menedzsment. Ez ugyanannak a dolognak két különböző oldala, és – különösen a távolról menedzselhetőség – a szememben a kritikusaim legjogosabb aggodalma. Az erről szóló vitákra a legfrappánabb érvelés azonban, úgy vélem, az, hogy „a merevlemezek ma olcsók, és a jó teljesítmény érdekében valószínűleg amúgyis helyben lesz telepítve minden programod”. Bár egyetértek ezzel, de szintúgy megértem azokat is, akik szeretnének dolgokat központosítani, adminisztrációs célok érdekében. Ám egy aránylag nem mindennapos feladat érdekében tovább bonyolítani az egész rendszer komplexitását, hát az általában nem igazán jó dolog, sőt, a hagyományos Unix-megoldás még ezesetben sem elég általános: mi van, ha három vagy négy ablakkezelővel rendelkezel? Telepítesz egyet a /usr-be, egyet a /opt-ba, azután mi lesz? Ott a hagyományos Unix-struktúra. Valójában, a nagyobb Unix-hálózatok többségében amivel kapcsolatba kerültem, a helyi konfigurációk igényelték az Unix-hierarchia nem-standard tartalomjegyzékekkel való kibővítését.
Szerencsére, hála a LiveCD-nek, manapság már a technológiai haladás egy olyan fokát értük el, ami a probléma egy igazi megoldásaként szolgál: ennek neve angolul az „union mount” {bocs de nem találtam megfelelő magyar kifejezést rá – a fordító megjegyzése}, ami „overlay filesystem” {talán „átlapolt fájlrendszerek”?} néven ismert. Az ötlet az, hogy több partíciót is felcsatolhatsz ugyanabba a tartalomjegyzékbe. Ezáltal megtartható a /Programs azon értelme, hogy ez „a rendszerben elérhető programok összgyűjteménye”, függetlenül azok aktuális fizikai elhelyezkedésétől. A fájlrendszerek is pusztán absztrakciók (nem említünk fájlokat a sávjuk, szektoruk és cilinderük alapján), ez tehát pusztán további haladó előrelépés. Az átlapolt fájlrendszerek nagyon rugalmasak: a rendszeradminisztrátor például helyszínspecifikus beállításokat rögzíthet alapértelmezésként az állományok számára. Sajnos érthetetlen okokból ez nincs általánosan elterjedve. A Plan 9 operációs rendszer alapvető fájlrendszerkezelő műveletei közül az egyik a bind parancs (A Plan 9-ben például nincs szükséged $PATH változóra, mert minden tartalomjegyzéket, ami végrehajtható állományokat tartalmaz, egyetlen mappában fognak össze). Az átlapolt fájlrendszer egy Linux alá készült implementációja az „ovlfs”.
Figyelj, Zoltán22 ! Én TUDOM (most már…), hogy elméletileg és nagyjából (!) melyik hagyományos könyvtár mire való. Tudja ezt Hisham is. Épp csak ennek manapság már nincs értelme, mert ki lehet találni jobbat is! Erről Hisham írt egy remek cikket, le is fordítottam (nem kis munkával) magyarra, itt olvashatod:
http://www.gobolinux.org/index.php?lang=hu_HU&page=doc/articles/clueless
de ideidézem belőle a legfontosabbat:„Oka van annak, hogy a dolgok olyanok, amilyenek ”
Ezt valamit, amit állandóan hallok, gyakran követi egy magyarázat a /, /usr és /usr/local, és/vagy a /bin és /sbin közti különbségről. Értem a különbséget1. Ha eltöröltem ezt a három szintű megkülönböztetést, annak az az oka, hogy hiszek abban, miszerint van más mód is azon problémák orvoslására, amik e hagyományos megkülönböztetést életre hívták. Egy GoboLinux rendszerben semmi érv nem szól amellett, hogy legyen különálló /usr és /usr/local azért, hogy elkülönítse a disztribúció által szállított programokat azoktól, amiket a felhasználó fordított magának. Mindegyik program természetes módon elkülönített, és pontosan ez is a legelső helyen említhető szándékunk azok közül, melyek végül a GoboLinux létrejöttéhez vezettek.
Az a történelmi ok, amiért az Unix-rendszerek tartalomjegyzékeinek egy része közvetlenül a gyökérkönyvtárból ered (/bin, /lib, /sbin), ellentétben azokkal amik a /usr könyvtárból nyílnak, nos az nem más, mint hogy így módodban áll bebootolnod egyfelhasználós üzemmódban, csupán ezen, a gyökérből nyíló fájlokat használva, megjavítandó velük a /usr könyvtárfa esetleges hibáit. Ez azonban csak „vallási hittétel”. Amikor meg kell mentenem a rendszeremet, inkább egy teljesértékű Linux rendszerrel felszerelt LiveCD-t használok, ami még grafikus környezetet is biztosít a számomra, az megengedi nekem, hogy böngésszem a világhálót és ott keressek megoldást a problémámra, és egyáltalán, egy teljes rendszer minden lehetőségét felhasználhassam a javítás érdekében. Tisztában vagyok azzal, hogy mi volt az értelme a régi rendszermentési megoldásnak évtizedekkel ezelőtt, de mostanság már sokkal jobb megoldással is rendelkezünk.
A bin és sbin közti megkülönböztetésének nincs értelme a jelenlegi kontextusban. A történelmi evolúció őrült önkényes megkülönböztetésekre vezetett, mint például a ping és traceroute külön tartalomjegyzékbe helyezése (képtelen vagyok felfogni, miként tarthatja valaki bármiképp is különböző programosztályba tartozónak e kettőt).
Egy Unix-rendszer az engedélyek rendszere. Ha az az óhaj, hogy valamely parancs csak rendszergazdai joggal legyen futtatható, akkor a megoldás: chmod 700 a megfelelő állományra, és kész. Azt gyanítom, hogy a programok megkülönböztetésének hagyományos rendszerét talán amiatt találták ki, hogy csökkentse a programok számát a normál felhasználók $PATH-jában. A mai Linux rendszerekben, lévén hogy akad akár 400 vagy 500 program is a $PATH-odban, ennek a megkülönböztetésnek semmi értelme.
Utolsó érvként megemlíthető, mindazonáltal, ami a Linux rendszereket a mai napig is jellemzi: a partícionálás és a távoli menedzsment. Ez ugyanannak a dolognak két különböző oldala, és – különösen a távolról menedzselhetőség – a szememben a kritikusaim legjogosabb aggodalma. Az erről szóló vitákra a legfrappánabb érvelés azonban, úgy vélem, az, hogy „a merevlemezek ma olcsók, és a jó teljesítmény érdekében valószínűleg amúgyis helyben lesz telepítve minden programod”. Bár egyetértek ezzel, de szintúgy megértem azokat is, akik szeretnének dolgokat központosítani, adminisztrációs célok érdekében. Ám egy aránylag nem mindennapos feladat érdekében tovább bonyolítani az egész rendszer komplexitását, hát az általában nem igazán jó dolog, sőt, a hagyományos Unix-megoldás még ezesetben sem elég általános: mi van, ha három vagy négy ablakkezelővel rendelkezel? Telepítesz egyet a /usr-be, egyet a /opt-ba, azután mi lesz? Ott a hagyományos Unix-struktúra. Valójában, a nagyobb Unix-hálózatok többségében amivel kapcsolatba kerültem, a helyi konfigurációk igényelték az Unix-hierarchia nem-standard tartalomjegyzékekkel való kibővítését.
Szerencsére, hála a LiveCD-nek, manapság már a technológiai haladás egy olyan fokát értük el, ami a probléma egy igazi megoldásaként szolgál: ennek neve angolul az „union mount” {bocs de nem találtam megfelelő magyar kifejezést rá – a fordító megjegyzése}, ami „overlay filesystem” {talán „átlapolt fájlrendszerek”?} néven ismert. Az ötlet az, hogy több partíciót is felcsatolhatsz ugyanabba a tartalomjegyzékbe. Ezáltal megtartható a /Programs azon értelme, hogy ez „a rendszerben elérhető programok összgyűjteménye”, függetlenül azok aktuális fizikai elhelyezkedésétől. A fájlrendszerek is pusztán absztrakciók (nem említünk fájlokat a sávjuk, szektoruk és cilinderük alapján), ez tehát pusztán további haladó előrelépés. Az átlapolt fájlrendszerek nagyon rugalmasak: a rendszeradminisztrátor például helyszínspecifikus beállításokat rögzíthet alapértelmezésként az állományok számára. Sajnos érthetetlen okokból ez nincs általánosan elterjedve. A Plan 9 operációs rendszer alapvető fájlrendszerkezelő műveletei közül az egyik a bind parancs (A Plan 9-ben például nincs szükséged $PATH változóra, mert minden tartalomjegyzéket, ami végrehajtható állományokat tartalmaz, egyetlen mappában fognak össze). Az átlapolt fájlrendszer egy Linux alá készült implementációja az „ovlfs”.
Bbt wrote:Ez amolyan egyfelhasználós rendszerszemlélet.
Több jogosultsági szintnél igenis érdmes és kell is különválasztani.
Biztonsági kérdéssé válhat még az is, hogy egy adott proram fentlétérő ne is értesülhessen a júzer.Ma már nincs ennek létjogosultsága.
Még a láthatóság kérdése is megoldható, de a rendszer hibája nélkül úgysem tud hozzáférni a júzer… bizt. hiba esetén (amikor valaki rendszg-i jogosultságot szerez) meg úgyis mindegy. (Jó, persze az nem olyan egyszerű… :))))Bbt wrote:Ez amolyan egyfelhasználós rendszerszemlélet.
Több jogosultsági szintnél igenis érdmes és kell is különválasztani.
Biztonsági kérdéssé válhat még az is, hogy egy adott proram fentlétérő ne is értesülhessen a júzer.Ma már nincs ennek létjogosultsága.
Még a láthatóság kérdése is megoldható, de a rendszer hibája nélkül úgysem tud hozzáférni a júzer… bizt. hiba esetén (amikor valaki rendszg-i jogosultságot szerez) meg úgyis mindegy. (Jó, persze az nem olyan egyszerű… :))))VectoR wrote:Ennek a topic-nak nem sok értelme van, de abban egyetértek violazoli-val, hogy a jelenlegi Linux FS felépítés egy nagyon kaotikus valami. Javítani, egyszerűsíteni kellene, de annyira bele van bonyolódva mindenki, és annyira félnek attól, hogy „lewinezik” őket, hogy senki nem meri piszkálni. Egyenlőre….
Én régebben elkezdtem foglalkozni a dologgal ami a Linux hasonló területeit érinti, de mivel nem találtam rá megfelelő embereket a projekt (linuxtodo.org), egyenlőre alszik. De a lényeg, hogy tényleg kellene fiatalítani pár dolgot és a fájlrendszer felépítése az egyik…. Mellékeltem egy ilyen „LinuxTODO.org javaslatot” erre a problémára és képet a portál tervéről, hátha kedvet kap valaki.Nem nagyon értelek, VectoR! Most nagyon meg vagyok lepve (hogy magyarosan fogalmazzak…). Ha neked is szívügyed a fájlrendszerhierarchia átszabása, miért nem csináltál valami ilyesmit a BP-ben is?!
Továbbá. Ha ezt komolyan gondolod, miért nem veszed fel a kapcsolatot a gobós fiúkkal?! A mellékelt képen látható hierarchia sok szempontból nagyon hasonlít a gobóéra. Persze nagyok a különbségek is. A dolog különben úgy áll, hogy ha meg akarjuk őrizni a kompatibilitást a régi hierarchiához készült progikkal, akkor megkerülhetetlen a symlinkek használata. Ha viszont symlinkezünk, akkor akár nagyobb változtatásokat is végrehajthatunk a fájlrendszeren, ezesetben viszont fogalmam sincs róla, minek hagytátok meg a tervezetben a bin és sbin közti különbségtevést.
Én azt hiszem, bátor húzás volna, ha a BP következő kiadása kissé késne, kizárólag azért, hogy azt úgy csináld meg, hogy az ne a nemtudomhogymicsoda disztróra épüljön mint most (talán redhat?), hanem a gobolinuxra, legalábbis a fájlrendszerhierarchiáját illetően. Ha kicsit is beleásnád magadat a gobóba, rájönnél, hogy tök jó. És ezesetben én természetesen azonnal és a tőlem tellő legteljesebb igyekezettel támogatnám a prodzsektedet (na nem pénzzel mert az nekem sincs, de felraknám a disztródat, lennék béta- sőt alfatesztelő, készítenék csomagokat alá, meg ilyesmi, akár doksikat is írnék róla), annak ellenére, hogy amúgy számomra hányingert keltő a windows-kinézet. De megértem, hogy üzletpolitikai okokból erre szükség van. (Különben is, mi sem akadályozna meg benne, hogy feltegyem alá kedvenc SithWM ablakkezelőmet, s akkor már subidubidú minden).
Nem tartom lehetetlennek, hogy idővel akár főállású alkalmazottad is lehetnék. Jó érzés volna ezzel nemcsak pénzt keresnem (valamiből nekem is muszáj megélni…), de ha közben úgy is érezhetném magamat, mint aki egy Nagy és Haladó Ügy támogatója és egyik élharcosa!Aztán, amikor már elkészült e disztród, kitanultad a „gobóskodást”, akkor lehet változtatgatni a gobós hierarchián is, annak alapján, milyen tapasztalatokat szűrtél le belőle. Biztos lehet javítani azon is. Én nem állítom, hogy az a felülűberelhetetlen csúcs, csak azt, hogy jobb bármi másnál, ami jelenleg van.
Az kissé csalódást keltő volt, hogy elmentem a linuxtodo.org címre, de csak valami angol nyelvű kép fogadott, ami ha jól sejtem olyasmit jelent, hogy fejlesztés alatt van. Pedig amúgy jól néz ki… az meg aranyos, ahogy a baloldali cikkben az áll, hogy 2020.január elsején indítottátok útnak ezt a portálrendszert… utazás a jövőbe! Szóval szerettem volna regisztrálni, de nem lehetett. Kár.
Azt sem értem, ha ilyesmin morfondírozol, miért mondod, hogy ennek a topiknak nem sok értelme van. Felfoghatatlan a számomra. Én úgy vélem, minél több erről a morfondír, annál nagyobb az esély rá, hogy valami jó kisül belőle.
VectoR wrote:Ennek a topic-nak nem sok értelme van, de abban egyetértek violazoli-val, hogy a jelenlegi Linux FS felépítés egy nagyon kaotikus valami. Javítani, egyszerűsíteni kellene, de annyira bele van bonyolódva mindenki, és annyira félnek attól, hogy „lewinezik” őket, hogy senki nem meri piszkálni. Egyenlőre….
Én régebben elkezdtem foglalkozni a dologgal ami a Linux hasonló területeit érinti, de mivel nem találtam rá megfelelő embereket a projekt (linuxtodo.org), egyenlőre alszik. De a lényeg, hogy tényleg kellene fiatalítani pár dolgot és a fájlrendszer felépítése az egyik…. Mellékeltem egy ilyen „LinuxTODO.org javaslatot” erre a problémára és képet a portál tervéről, hátha kedvet kap valaki.Nem nagyon értelek, VectoR! Most nagyon meg vagyok lepve (hogy magyarosan fogalmazzak…). Ha neked is szívügyed a fájlrendszerhierarchia átszabása, miért nem csináltál valami ilyesmit a BP-ben is?!
Továbbá. Ha ezt komolyan gondolod, miért nem veszed fel a kapcsolatot a gobós fiúkkal?! A mellékelt képen látható hierarchia sok szempontból nagyon hasonlít a gobóéra. Persze nagyok a különbségek is. A dolog különben úgy áll, hogy ha meg akarjuk őrizni a kompatibilitást a régi hierarchiához készült progikkal, akkor megkerülhetetlen a symlinkek használata. Ha viszont symlinkezünk, akkor akár nagyobb változtatásokat is végrehajthatunk a fájlrendszeren, ezesetben viszont fogalmam sincs róla, minek hagytátok meg a tervezetben a bin és sbin közti különbségtevést.
Én azt hiszem, bátor húzás volna, ha a BP következő kiadása kissé késne, kizárólag azért, hogy azt úgy csináld meg, hogy az ne a nemtudomhogymicsoda disztróra épüljön mint most (talán redhat?), hanem a gobolinuxra, legalábbis a fájlrendszerhierarchiáját illetően. Ha kicsit is beleásnád magadat a gobóba, rájönnél, hogy tök jó. És ezesetben én természetesen azonnal és a tőlem tellő legteljesebb igyekezettel támogatnám a prodzsektedet (na nem pénzzel mert az nekem sincs, de felraknám a disztródat, lennék béta- sőt alfatesztelő, készítenék csomagokat alá, meg ilyesmi, akár doksikat is írnék róla), annak ellenére, hogy amúgy számomra hányingert keltő a windows-kinézet. De megértem, hogy üzletpolitikai okokból erre szükség van. (Különben is, mi sem akadályozna meg benne, hogy feltegyem alá kedvenc SithWM ablakkezelőmet, s akkor már subidubidú minden).
Nem tartom lehetetlennek, hogy idővel akár főállású alkalmazottad is lehetnék. Jó érzés volna ezzel nemcsak pénzt keresnem (valamiből nekem is muszáj megélni…), de ha közben úgy is érezhetném magamat, mint aki egy Nagy és Haladó Ügy támogatója és egyik élharcosa!Aztán, amikor már elkészült e disztród, kitanultad a „gobóskodást”, akkor lehet változtatgatni a gobós hierarchián is, annak alapján, milyen tapasztalatokat szűrtél le belőle. Biztos lehet javítani azon is. Én nem állítom, hogy az a felülűberelhetetlen csúcs, csak azt, hogy jobb bármi másnál, ami jelenleg van.
Az kissé csalódást keltő volt, hogy elmentem a linuxtodo.org címre, de csak valami angol nyelvű kép fogadott, ami ha jól sejtem olyasmit jelent, hogy fejlesztés alatt van. Pedig amúgy jól néz ki… az meg aranyos, ahogy a baloldali cikkben az áll, hogy 2020.január elsején indítottátok útnak ezt a portálrendszert… utazás a jövőbe! Szóval szerettem volna regisztrálni, de nem lehetett. Kár.
Azt sem értem, ha ilyesmin morfondírozol, miért mondod, hogy ennek a topiknak nem sok értelme van. Felfoghatatlan a számomra. Én úgy vélem, minél több erről a morfondír, annál nagyobb az esély rá, hogy valami jó kisül belőle.
Felmerült bennem ezek után, hogy a macskámat átkeresztelem gobóra.
Bár szerintem megsértődne, mert egy fekete macska ezzel a névvel elég hülyén fest.Szerintem a blackPanther-be egypár ubuntus megoldást is át kéne emelni, VectoR oda van értük. ;D ;D ;D
Felmerült bennem ezek után, hogy a macskámat átkeresztelem gobóra.
Bár szerintem megsértődne, mert egy fekete macska ezzel a névvel elég hülyén fest.Szerintem a blackPanther-be egypár ubuntus megoldást is át kéne emelni, VectoR oda van értük. ;D ;D ;D
VectoR wrote:De a lényeg, hogy tényleg kellene fiatalítani pár dolgot és a fájlrendszer felépítése az egyik…. Mellékeltem egy ilyen „LinuxTODO.org javaslatot” erre a problémára és képet a portál tervéről, hátha kedvet kap valaki.
Most nem igazán értem, hogy az „LDS FS Suggestion” miben olyan egyszerűsítés meg javítás. Ha jól látom, lényegében annyi történt, hogy a root-könyvtár rendszerszerű könyvtárait (boot, dev meg ilyenek) benyomtad egy /System könyvtárba. Ezt még a bP-n is könnyű megvalósítani: ha jól gondolom, az rpm –root opciója lehet erre a megoldás vagy pedig chroot-ban történő telepítés.VectoR wrote:De a lényeg, hogy tényleg kellene fiatalítani pár dolgot és a fájlrendszer felépítése az egyik…. Mellékeltem egy ilyen „LinuxTODO.org javaslatot” erre a problémára és képet a portál tervéről, hátha kedvet kap valaki.
Most nem igazán értem, hogy az „LDS FS Suggestion” miben olyan egyszerűsítés meg javítás. Ha jól látom, lényegében annyi történt, hogy a root-könyvtár rendszerszerű könyvtárait (boot, dev meg ilyenek) benyomtad egy /System könyvtárba. Ezt még a bP-n is könnyű megvalósítani: ha jól gondolom, az rpm –root opciója lehet erre a megoldás vagy pedig chroot-ban történő telepítés.
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz