Egyszerűsítené a fájlrendszer elrendezést a Fedora az F17-re

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

Összefoglalva, a Fedora projekt azt tervezi, hogy a /(s)bin és a /lib könyvtárak tartalmát beköltözteti a /usr/bin valamint a /usr/lib (ahol szükséges ott /usr/lib64) alá, a root fájlrendszeren pedig csak egy symlink-et hagy az új helyekre. A javasolt projekt tulajdonosai a Red Hat alkalmazásában álló Harald Hoyer és Kay Sievers. A megvalósítást a Fedora 17-re tervezik. A projekt jelenleg 10%-os megvalósulásnál tart.

Az elképzelés valami ilyesmi: 


/
|-- etc
|-- usr
|   |-- bin
|   |-- sbin -> bin
|   |-- lib
|   `-- lib64
|-- run
|-- var
|-- bin -> usr/bin
|-- sbin -> usr/bin
|-- lib -> usr/lib
`-- lib64 -> usr/lib64

A javaslat szerint a változtatás számos előnnyel járna a Fedora számára:

  • Egyszerűbb és tisztább fájlrendszer elrendezés a teljes kompatibilitás megőrzése mellett
  • Az operációs rendszer és a host specifikus erőforrások egyértelmű elszeparálása
  • stb.

További részletek itt.

( blackluck v | 2011. 11. 07., h – 14:13 )

Szoval kernel-bol kell majd megoldani a /usr mount-ot is annak aki kulon valasztja?
Mert jelenleg ilyenek h mount, lvm es tarsai parancsok pont a /bin /sbin alatt vannak, vagy /lib/modules alatt a modulok...

( manfreed (nem ellenőrzött) | 2011. 11. 07., h – 14:16 )

hol a home? :)

Egyébként tetszik az ötlet.
Most már csak rá kellene venni a többi disztrót, hogy egységesen kövessék a változtatásokat, a releváns fejlesztőket, hogy az új helyet használják, és akkor 10 év múlva meg is lehet szűntetni a symlinket.

Örömmel fogadnék egy mozgalmat is, ami rendet rakna a home mappában, hogy a programok ne szemeteljék tele: Ott a .cache, és a .config, ne hozzon már létre minden program egy .programneve mappát....

Jah, tényleg sokkal jobb, ha a .config és cache alá pakolnak ugyanúgy mappákat :-D Majd ha a firefox is oda tolja a cache-t, meg a thunderbird a leveleit, az milyen jó lesz... Nekem teljesen megfelelt, hogy az egy programhoz tartozó dolgokat nem több mappában szétosztva találtam meg. Nem mintha annyira zavarna, meg mondjuk az autostartot pl. könnyebb így megoldani több DM-re, de sok előnyét ezen kívül nem látok.

Ja igaz, félreértettem, amit manfreed írt. Azt hittem, ő inkább kidobná a sok rejtett mappát máshová.
A home rendezése valóban jó ötlet. Ha minden eggyel lejjebb, mondjuk egy .settings nevű könyvtárba menne, már az is jó lenne. Ellenben ezt lehet fordítva is csinálni: a fontos dolgokat kell 1-2 könyvtárral beljebb tenni. Pl. nekem a Mint (azaz Ubuntu) által alapból létrehozott könyvtárokon (Dsektop, Music, Videos, ...) kívül csak 4 saját könyvtáram van.

"Egységes struktúra, ami egy programhoz tartozik cache, config, temp, lock file, naplók, stb az egy mappában van."

A baj, hogy ez az egy mappa ott van, ahol élsz. A home-odban. Nem a configok külön pakolása a lényeg, hanem az, hogy legyen egy mappa (jelen esetben teljesen jó okból kettő van*) amikben ezek gyűlnek, hogy a home mappád tiszta legyen.

* .config és .cache. Nagyon jó, hogy külön van választva, utóbbit lehet törölgetni végülis csak cache, az nem fontos. És nagyon jó, hogy csak ez a kettő van (ez a kettő van?), mert nem kell több. Szerintem.

-1

En annak a hive vagyok, hogy minden program kulon mappaba szemeteljen, de csak oda. Mert ha valami gubanc van, akkor fogom, leirtom a .thunderbird mappat, es kesz, IMAP szerverek mellett semmilyen szomorusagom nem szarmazik a dontesbol. De pl. egy evolution-nal ugy kell osszebanyaszkodni a profilt, ha eppen totalisan meghalja magat.
Mac eseteben peldaul egesz jol mukodik a dolog, ott a Library/Application Support mappa alatt nagyon szepen elfernek ezek a mappak.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem beszélve arról, hogy milyen egyszerű is így mondjuk a thunderbird profilját átvinni valahova. Vagy pl anno mikor migráltam archra, nem kellett újrakonfigolni se a skype-ot, se a firefoxot, stb, csak átrántottam (tbirdnél csak átlinkeltem) a mappájukat és használatra készek voltak.

Szerintem nyitott kapukat döngetsz. Van .config, .local például. Amkor az mc-t 4.8.0-ra frissítettem, akkor indításkor közölte, hogy az eddigi .mc-t szétszedi, s bepakolja a .config, .local alá, s mintha az derengene, hogy freedesktop.org-ra hivatkozott mentegetőzésképp. :)

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Tudom, hogy van, csak semmi nem készteti a programozókat (látszólag), hogy használják. Így aztán néhány jófej program (mc, chromium) mappája jó helyen van, de nagyon sok .mappa, sőt! .fájl van a ~/-ben simán. Komolyan mondom, fel fogok keresni MINDEN upstreamet, és egyesével mindegyikre bugreportolok, amelyik nem a ~/.config-ba dolgozik.

( crystal88 | 2011. 11. 07., h – 14:16 )

én azt nem értem, hogy a "teljes kompatibilitás megőrzése mellett" hogy lesz, ha nem ott lesznek a dolgok ahol eddig voltak

( taxy | 2011. 11. 07., h – 14:21 )

A következő lépés pedig az opt könyvtár átnevezése Programs könyvtárrá... :)

Nálam most csak ezek:
browser.download.dir
browser.download.lastDir
dwhelper.storagedirectory
print.print_to_filename
print.printer_Nyomtatás_fájlba.print_to_filename

De pl. a downloadhelper is csak akkor működött, ha megvolt a symlink (ez esetben linuxon usernév átnevezés volt csak)... Gusztustalan, de nem számít, mert akkor nem kell agyalnom, melyik rendszeren vagyok, ha épp nem $HOME-ot írok :)

( hory v | 2011. 11. 07., h – 14:29 )

Ha mar egyszerusites, minek egyaltalan /usr, vagy 'lib64'? Lehetne egy ilyesmi:


/
|-- etc
|-- bin
|-- lib
|-- run
|-- var

A lib/lib64 szeparacionak nem latom ertelmet, egy disztrib vagy 64 vagy 32 bites. A compatibility 32 bites libeket el lehet dugni barhova, alapvetoen csak backwards compatibility miatt vannak a rendszerben.

( Zsugabubus | 2011. 11. 07., h – 14:30 )

Na, múltkor a /run azért jött létre, mert a /var lehet külön mountolva. Ha a /usr van különválasztva, akkor most mi lesz?

Úgy tudom, hogy systemd-s felállásnál már most is követelmény, hogy a /usr az initramfs alól legyen mountolva.

Ez volt a kegyelemdöfés: mindent megmagyarázott. Köszönöm.

Tegyük még hozzá, hogy az initramfs újabban két összefűzött xz állományból áll, amit egyszerűen nem lehet a jelenlegi userspace tool-okkal szétválasztan -- legalábbis ha eltekintünk a hex editoroktól. (A belső felépítés is hajmeresztő, de azt most hagyjuk.) Mi sem könnyebb, mint egy ilyen initramfs-ben hibát keresni!

( nevergone v | 2011. 11. 07., h – 15:06 )

Szerintem a titkos, GoboLinux-közeli partizánok műve…! :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

( uid_19064 | 2011. 11. 07., h – 16:14 )

<szentségtörés>
/
|-- Programs
|   |-- bin
|   |   |-- Firefox
|   |   |-- LibreOfficeWriter
|   |   `-- Thunderbird
|   |-- Mozilla
|   `-- LibreOffice
|-- Users
|   |-- Apa
|   |-- Anya
|   `-- Pistike
|-- Storage
|   |-- dvd
|   `-- FényképekMentés
`-- System
    |-- bin
    |-- cfg
    |-- lib
    `-- tmp

(És még szóközök is lehetnének benne, meg lefordított könyvtárnevek... OMG, tiszta Windows)

Ha azt akarjuk, hogy a Linux a desktop-on is elterjedjen, akkor pl. azzal kellene kezdeni, hogy a file system-et végletekig leegyszerűsítsük. Nem szabadna, hogy opciók legyenek a tekintetben, hogy melyik program hova települ vagy pakolja a dolgait vagy hol keres library-t.
A végfelhasználó (az valódi, egybites user) egyszerű használatot akar. Ha meglátja a mostani Linux file rendszert, megijed, mert mindenféle érthetetlen rövidítésekkel van tele. Meg mi a különbség a bin, az sbin, a usr/bin és az usr/sbin között? Mi a franc az az etc és miért vannak benne baromi fontos dolgok, ha az a neve, hogy egyebek?
A cikkbeli javaslat jó, de nem elég. Amíg a Linux nem lesz egyszerű, mint a faék, addig ne álmodozzunk itten world domination-ről.
</szentségtörés>

Hat, igazabol nem. Az LD_LIBRARY_PATH eleve egy nem hasznalt dolog, a /etc/ld.so.conf tarolja azokat a mappakat, amikre te gondolsz.
A PATH meg windowson is pont ugyanolyan hosszu, viszont ha implicite tartalmazna az exe sajat mappajat, az sokmindent megoldana.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Én nem örülnék, ha a "setétuser" kedvelné a Linuxot. Egyszerűen a Linux szerintem maradjon valamilyen szinten a hozzáértők rendszere. Ha megjelenne néhány hiánypótló szoftver akkor tökéletes, és a sokszínűsége, és a szemlélete miatt egy fajta alapbiztonságot tartalmazó kiváló munkaoprendszerré válhatna. Sőt én annak örülnék igazán, ha Pl a Linux valahogy a "tudományos világ" rendszere lenne, a windows pedig a maradéké. Tudom hogy sok ember szemében ez megbotránkoztató, és idiótaság, de szerintem mint ahogy az autóknál is nincs univerzális autó, de van jó terepjáró, jó teherautó, jó családi ..... Ez a számítógépes rendszereknél igaznak kellene, hogy legyen.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

A végfelhasználó (az valódi, egybites user) egyszerű használatot akar. Ha meglátja a mostani Linux file rendszert, megijed

Nem látja meg. Ha meglátja, akkor már veszett fejsze nyele az egész. A r=1bit-nek seggkinyalós rendszer kell, ahol nem szembesül a rendszer könyvtárneveivel.

Itt hol vannak a libek?
Ha minden programnak külön mappája van, akkor mindegyik bekerül a path-ba, vagy hogy lehet indítani őket? Ikonról persze, mint win alatt, vagy abszolút fájlnevet használva?
Szép dolog a systemet külön tenni, de mi számít systemnek? Egy mc system? Egy whois? less, more? Hova kerülnek a nem system configok (nem az useré). Program mappájába? Akkor hova kerülnek a nem programokhoz tartozó configok? Libek configjai ha van valamelyiknek?
Storage: már van, csak /mediának hívják :)

No de nem ez a lényeg :)

Ha tényleg azt akarjuk, hogy az user ne a fájlrendszerrel szenvedjen, akkor olyan szinten át kell gondolni az egész fáljrendszert, amire eddig nem volt példa. Az apple lépett valamit az IOS eszközökön, és eltűntette. Ugyan az alkalmazások tartalmazhatnak mappákat és fájlokat, amiket valahogyan a felhasználó felé mutatnak, lehet nem fájlként, de lényegében nincs fájlrendszer ios-on. Egyrészt sokan utálják emiatt, másrészt kényelmetlen tud lenni már a mobilon is, nem hogy desktopon.

Csinált ilyesmit a google is a chromebookjával, ott sincs közös fájlrendszer, csak az egyes webappok saját fájlrendszere. Használható arra amire kitalálták, de ez sem az igazi komoly dekstopra.

Ha egyszer valaki komolyan gondolja a fájlrendszer újrastruktúrálását, akkor messzebb kell menni annál, hogy néhány fájlt máshova pakolunk. Teljsen máshogy kellene nekiállni, és más féle módon megközelíteni a dolgot. Egyszer biztos kitalálták, hogy milyen jó dolog a fáljrendszer, de rengeteget változott a világ. Nagyon sok dolog nem úgy működik, ahogy a fájlrendszer rendelkezésünkre bocsájtja az adatokat.

A felhasználó elé nem mappákat, és fájlokat kell szórni, nem xlst-ket, és pdf-eket, hanem dokumentumokat, amik vagy prezentációk, vagy kiadványok, nem jpg kell neki, hanem fotó, nem svg, hanem vektoros grafika, stb. A felhasználónak nem fáljrendszer kell, hanem egy egységes felület ami dokumentumtípusokat ismer, kezel, típustól függően tulajdonságokkal, és rengeteg metaadattal, ahol a szövegfájl mérete nem feltétlenül 2 giga, hanem 20 oldal, 200 szó, és emellett lehet 2 giga (jézusom, milyen szövegfájl ez?), ahol egy zene egy zene, aminek albuma, és előadója van, és nincs olyan, hogy az most a zene mappában van, vagy a music-ban, az ugyanúgy zene, és ha zenékkel dolgozol, akkor meg kell hogy találd.

Korábban felhoztam egy cimke alapú fájlrendszer ötletét, de mindenki lehurrogott, és belegondolva, ha nekem kéne lefeljesztenem, akkor vakarnám erősen a fejem. De valami olyasmi lenne a járható út de szerintem a fenti néhány sorral összevegyítve lenne valamilyen járható út belőle. Egy olyan "fájl" rendszer ahol olyan dolgokat amiket több (több tíz) dologgal írunk le, nem egy helyre próbáljuk kategoriálni.

És persze vannak programok, rétegek, amik próbálják eltakarni, azt hazudni, hogy szebb a világ, de nem plusz réteg kellene, az alapoktól kellene támogatni. Jó példa a windows, ahol az Asztal-t Desktop-nak hívják, de te Asztalnak látod. Ugyanígy a Felhasználók nevű mappa valójában Users, és amint nem intézőben böngészed a fájlokat csak lesel, hogy mi van? (mármint win7 alatt).

Lehet tiltakozni? Élnék vele. :)

A felhasználónak nem fáljrendszer kell, hanem egy egységes felület ami dokumentumtípusokat ismer, kezel, típustól függően tulajdonságokkal, és rengeteg metaadattal, ahol a szövegfájl mérete nem feltétlenül 2 giga, hanem 20 oldal, 200 szó, és emellett lehet 2 giga (jézusom, milyen szövegfájl ez?), ahol egy zene egy zene, aminek albuma, és előadója van, és nincs olyan, hogy az most a zene mappában van, vagy a music-ban, az ugyanúgy zene, és ha zenékkel dolgozol, akkor meg kell hogy találd.

Én byte-ban gondolkodom. Az sohasem érdekelt, hogy egy dokumentum hány ember által olvasható szó - értsd: nem 16 bitet értek a szón -, de az igen, mennyi helyet foglal a HDD-n, pendrive-on. Aztán biztos, hogy jó az, ha a filmekre keresve a pornó, a mesefilm, az akciófilm és a családi kirándulásról készült video egyszerre jelenik meg a listában? Mert úgy gondolom, jobb az, ha a ~/Video alkönyvtár alatt vannak mesék, akciófilmek, aztán teszem azt, van egy ~/.valami/asszonnyal_huncutkodas alkönyvtár. Szerintem. :)

Jó példa a windows, ahol az Asztal-t Desktop-nak hívják, de te Asztalnak látod.

Remek. Ezek után nagy nehezen kivadászod az elérési utat, beírod a cd parancs argumentumába, és őrjöngesz, hogy miért nem működik. Igazán nagyszerű ötlet. Az efféle ámokfutások miatt utálom a Windows-t. Mindent jobban akar nálam tudni, ki akarja találni, hogy én mit akarok, de nem, mert én tényleg azt akarom, amit mondok neki, s tényleg úgy, ahogy mondom, az meg az én dolgom, hogy miért, még ha szokatlan is, amit épp csinálok.

Épp ma szívtam egy ismerősöm gépén azzal, hogy hülye intéző elrejtette az ismert filetípusok "kiterjesztését". Egy firefox-valami nevű file-t átneveztem update.mar nevűre. Rossz érzésem támadt, megnéztem terminálon is. Hát persze, hogy update.mar.mar volt a file neve, mi más. Ezután csépeltem be a

ren update.mar.mar update.mar

parancsot. Mondjuk előtte mv-t írtam, de az nem működött. :)

és amint nem intézőben böngészed a fájlokat csak lesel, hogy mi van

Talán az alkalmazásnak nem kellene mást mondania, mint a valóság. Meg egyáltalán, az alkalmazás ne változtasson semmit, adja fel bután a directory- és filenevet.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

"Talán az alkalmazásnak nem kellene mást mondania, mint a valóság."

Igen, pont ezért mondom, hogy a valóságnak kell lennie másnak. Írták lejjebb, hogy paradigmaváltás kell, és egyetértek vele, viszont azt nem úgy kell csinálni ahogy most próbálják (amin kiakadtál, hogy az intéző elrejt dolgokat, meg máshogy írja).

"Én byte-ban gondolkodom."

Én is. És hasznos információ a bájt is, de egy dokumentumnál van más hasznos dolog. Talán jobb példa lett volna az mp3, ahol senkit sem érdekel a fájlnév, az id tagek fontosak, de hogy pontosítsak: nem szabadna id tageknek lenni, hanem a tulajdonságokat a fájlrendszernek kellene ismerni és kezelni, és ne csak a rhythmbox tudja a track-01.mp3-ról, hogy az épp egy AC/DC szám.

" Aztán biztos, hogy jó az, ha a filmekre keresve a pornó, a mesefilm, az akciófilm és a családi kirándulásról készült video egyszerre jelenik meg a listában? Mert úgy gondolom, jobb az, ha a ~/Video alkönyvtár alatt vannak mesék, akciófilmek, aztán teszem azt, van egy ~/.valami/asszonnyal_huncutkodas alkönyvtár. Szerintem. :)"

Igen, ez egy probléma, de már most létezik. A windows-ban a slideshow widget ha jól emlékszem kérdés nélkül minden képet bedobott az oldalsávba, amit a dokumentumok közt talált, a különféle albumrendezgető programok is csak végigscannelik az egész gépet, aztán utólag rejtegetheted a pornót. De tudod a pornóvideó az videó, akármit csinálsz, ha rákeresel a videókra, akkor meg fogod találni, mindegy hova teszed. A kérdés az, hogy miért is keresnél rá a videókra? Mit keresel pontosan, amikor ilyet teszel? Amikor meséket keresel akkor ilyesmiket nyiss meg: "Mesék", "Filmek", "Sorozatok". Egyébként ha 2 percnél tovább gondolkodik az ember egy ilyen fájlrendszer koncepcióján, akkor több dolog is felmerül, de nem hiszem, hogy túl sok gondolkodás kellene ahhoz, hogy megoldást találjunk a problémára. Lehetne például rejtett cimke, amibe tartozó dolgok nem jelennek meg (mint a rejtett fájlok most).

Értem, amit mondasz, ugyanakkor túl technokrata vagyok ehhez. Én szeretem látni az alsóbb rétegeket, kellenek az efféle kapaszkodók. Nem szeretem azt, ha a gépem egy katyvasz, aztán majd jól megtalálja, ami szerinte nekem kell. Majd én eldöntöm, mit hova teszek. Az sem véletlen, hogy nem használom sem a KDE-t, sem a Gnome3-at. Maradok az Xfce-nél. Egyszerű, gyors - na ja, pláne egy AMD Phenom II X4 955 CPU-val -, mindent tud, és nem okoskodik feleslegesen.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

( emberk | 2011. 11. 07., h – 17:21 )

Nem látom egy világmegváltó ötletnek, sőt. Elvileg arról szól a dolog, hogy /lib /bin /sbin a rendszerszintű cuccokat tartalmazza míg a /usr alatt ugyanezek a kiegészítő programoknak állnak rendelkezésre. Szerintem ezzel, hogy külön könyvtárban vannak a jogosultság kezelése sokkal egzaktabb. Az tény, hogy a filerendszer bonyolultabb. Tehát amit nyernek a kevesebb könyvtárral azt bukják a jogosultságok átláthatóságánál. A fene tudja, hogy melyik a jobb.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

( pinyo_villany | 2011. 11. 07., h – 17:40 )

"Az operációs rendszer és a host specifikus erőforrások egyértelmű elszeparálása"

hmm, /lib/modules/.... ahham

akkor vegyek at a bsd-s valos 3 retegu strukturat:

P={lib{,exec,data},{,s}bin,etc}

/$P -> OS es OS mukodesehez szukseges dolgok
/usr/$P -> az OS-sel szallitott felhasznaloi dolgok
/usr/local/$P -> a user altal telepitett programok
___
info

( termih | 2011. 11. 07., h – 18:26 )

Egy újabb felesleges dolog. Működik. Minek hozzányúlni?

Jó volt böngészőkben a http://.
Jó volt a Ferihegyi Repülőtér.
Jó volt a MSO 2003 eszköztára.
Jó a GNOME 2!
Jó az orbáncfű szimpla teafűként. (A gyógyszergyárak valami igen spéci kivonatot csináltak belőle, és most azt mondják, micsoda gyógyító erő mert orbáncfű kivonatot tartalmaz. Nem emlékszem mire jó, a reklámból ennyi ragadt meg.)

De sorolhatnám a felesleges dolgok tárházát. Most csak ez jutott eszembe. Persze ismerem a szabályt: "Nincs probléma, nincs profit" (Profit alatt nem csak pénzt kell érteni). Na meg, ha van mozgás, akkor van élet. Ha nincs mozgás az élet megszűnik egy projekt, egy szoftver, egy termék körül.

a példáiddal nem szeretnék külön foglalkozni, maradjunk a fedorás fájlrendszer-ámokfutásnál. hadd csinálják! majd használsz valami olyan disztrót, ahol a régi szokások megmaradnak. ha pedig bejön a fedora/RH 'találmánya', és egy cégvilággal megtámogatott gobolinux lesz belőle, ÉS még a tetejébe jó lesz, akkor nyertünk egy választási lehetőséget. szerintem a jelenlegi struktúra átlátható, kezelhető, és megszoktuk. ha a másikról kiderül, hogy valami hatalmas előnye van, akkor két jó közül választhatok.

az első mondatomban használtam az 'ámokfutás' szót. erről jutott eszembe, hogy a Canonicaltól nem láttam még ágyúval verébre változtatásokat (valami olyat csináltak, hogy a /var/run lekerült /run-ba, FIXME). van mostanában valami világmegváltás náluk?

Ezt senki nem állította. A változás szükségszerű. A változás hozza az életet. De ebben a világban lehet többféle iránya. Az _irányok_ azok amik lehetnek jók vagy rosszak.

Ha vannak emberek akik valami szörnyen rosszat tesznek, akkor a "cselekvés" rossz? Tiltsuk be a cselekvést?

( wachag | 2011. 11. 07., h – 21:05 )

Előbb megcsinálhatnák, hogy működjön az mplayer lejátszás rendesen, ha nincsen gnome-om vagy kde-m. Értsd: pulseaudio gondok...
:-)

( uid_228 | 2011. 11. 07., h – 22:11 )

Ahogy látom, újabb mérföldkőhöz érkezett a "mit lopunk még el a Solarisból és kúrjuk széjjel"-mozgalom. :)))

A srácok nem vették észre, hogy ott van egy külön /sbin arra, hogy föl tudja húzni a rendszert és a root fölötti többi filerendszert? :)

--
Java apps are nothing more than sophisticated XML-to-exception converters.

nekem még a home is a / eszközén van, van egy swap, és van egy óriási adattár-rész (desktopról beszélek). szerintem a $HOME alatti configok újragenerálása kényelmesebb rendszerváltásnál vagy újrainstallálásnál, minthogy a $PROGRAM n-edik verziója egy másik disztró $PROGRAM-jának m-edik verziójával a konfig szinten akadjon, és kézzel kelljen a konfigfájlokat bogarászni, hogy melyik beállítás nem megfelelő. dual boot esetén is ezért kap mindegyik / saját home-ot (ez móricka-megfogalmazás, de értitek). ennek van valami hátulütője?

( poliverzum | 2011. 11. 08., k – 01:10 )

Valami már van, de ez még nem az igazi — több kell ennél, gyerekek!

Csak azt nem értem, miért akarják újra feltalálni a GoboLinuxot. Ott már egyszer szépen megoldották ezt a fájlrendszer-mizériát. Mert az biztos, ha egy kicsit jobban "nekifeküsznek" a kérdésnek, a gobóig jutnak el.
-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

Igaz, hogy a Gobo fejlesztése eléggé belassult az utóbbi időben (gondolom a fejlesztőknek sok más dolguk is volt/van, pld létezik magánéletük is), de attól amit eddig megcsinált, még kétségkívül haladó kezdeményezés, s könnyen el tudom képzelni, hogy valamelyik másik disztró felkarolja/átveszi a Gobo eszmeiségét/szellemiségét, s ott folytatja, ahol a Gobo abbahagyta.
-------------
Blogom: http://violazoli.blogspot.com
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

A rootless Gobo-nak talán van jövője, ha megtanul deb, és rpm fájlokat készíteni. Nem tudom, még nézegetem. Az a jó benne, hogy forrásból tud telepíteni, és kezeli a függőségeket. Az is jó benne, hogy a fordításhoz szükséges csomagokat nem kell rendszer szinten telepíteni. Viszont rettenetesen el van bonyolítva.

( iron v | 2011. 11. 08., k – 15:11 )

Miért van nekem ilyen OSX érzésem a hierarchia láttán? :D