On Sat, Jan 24, 2004 at 09:00:12PM +0200, Ground Zero wrote: > > /usr/i486-linuxlibc1/lib nu e FHS, asa ca te rog sa te duci sa mai > > frunzaresti o data documnetatia, poate chiar o intelegi > Voila.
Sarcasm is lost on you, Pinky. > > Prin _ce_ e mai buna organizarea ta? (sau a celor de la Gobo, whatever) > > In loc sa ai /lib/ ai /System/Links/Libraries/? > > Am /S/L/L in loc de /lib, /usr/lib, /usr/local/lib, /usr/X11R6/lib, > /usr/i386-glibc21-linux/lib si /usr/kerberos/lib, gasite pe un Red Hat. Dintre > care primele 4 sint in FHS daca nu ma insel. Corect, /usr/X11R6/lib este arhaic si urat, dar restul sunt utile. See below. > > Cum separi ceea ce e instalat local de ceea ce face parte din pachete? > > De ce ar trebui facuta vreo distinctie? Ce inseamna "instalat local?" Ceva > esential pentru sistem? Ceva aflat pe o anumita partitie? Instalat local inseamna ceva instalat de admin-ul masinii, si nu de distributie. Ceva ce este particular acestei masini. > Nu orice fisier de pe sistem are legatura cu un anumit pachet? Faci confuzie intre pachetele distributiei, si pachetele pe care le compilezi de mana, si pe care le instalezi in /usr/local/, tocmai pentru a nu suprascrie ceea ce a instalat distributia. > > Aplicatiile de sistem de cele folosibile de useri? > > Prin drepturi, evident, cea mai pragmatica diferentiere si singura care are > importanta IMHO. Daca o aplicatie e "de sistem" dar are voie un user obisnuit > sa o execute ce inseamna? Sincer, de data asta, ai citit FHS? We recommend that users have read and execute permission for everything in /sbin except, perhaps, certain setuid and setgid programs. The division between /bin and /sbin was not created for security reasons or to prevent users from seeing the operating system, but to provide a good partition between binaries that everyone uses and ones that are primarily used for administration tasks. There is no inherent security advantage in making /sbin off-limits for users. > > De cand sunt glibc, kernelheaders, ncurses si readline aplicatii? > > Imi cer scuze. O sa le zic "Packages", daca-mi permiti, bineinteles. (Tot e > bine ca nu le-am zis "Programs" ca in Gobo ca mincam si bataie pe motive de > asociere cu odiosul M$.) :D Sa stii ca m-am gandit ca /Application/ asta al tau functioneaza ca un Program\ Files. :-) > > Sau, cum functioneaza /Appliction? > > Oarecum pe principiul /opt, in sensul ca fiecare pachet e instalat cu > --prefix=/opt/ceva si deci isi regaseste toate fisierele asociate acolo. > Personal am ales sa pun fisierele de configurare si de runtime undeva la comun > (am explicat in primul mesaj din thread). In plus accesul la diverse parti ale > unui pachet (executabile, bibilioteci, headere) se face cu symlinks dintr-un > director comun in /System/Links. Bun, deci tu propui sa inlocuim o impartire oarecum logica, in trei directoare pentru biblioteci, cu una in 100 de directoare, cu symlink-uri intr-un director. De ce? Inteleg ca sunt mai putine directoare and all, dar nu inteleg ce avantaj imi aduce. > Nu, dar sint eu de vina pentru ca autorii e2fstools sint imprastiati? Daca nu > am alternativa inseamna ca e OK? Asta e, ma astept sa fie si pachete mai mult > sau mai putin recalcitrante, ma descurc cum pot. Sa le fie in nas. Daca am > timp ma duc la dezvoltatori si-i trag de mineca. My point exactly. :-) -- Birzan George Violence is the last refuge of Cristian the incompetent -- Salvor Hardin --- Detalii despre listele noastre de mail: http://www.lug.ro/
