Fedora-ontwikkelaars verplaatsen Linux-systeemfolders naar /usr
De ontwikkelaars van Fedora hebben de eerste testversies van versie 17 uitgebracht waarbij een groot deel van de systeemdirectories en de onderliggende bestanden zijn verplaatst van de rootfolder naar de /usr-directory.
In Fedora 17 zijn in de Rawhide-testversies de mappen /bin, /sbin, /lib en /lib64 en de onderliggende bestanden verplaatst van de root-directory naar de /usr-folder. De developers spreken met de herschikking over een unified filesystem. Om problemen met 'oude' Linux-software en -scripts te voorkomen, zal Fedora 17 gebruik maken van doorverwijzende symbolic links in de root-directory.
Met de ingreep, waar binnen de Fedora-gemeenschap lange tijd over is gediscussieerd, stellen de ontwikkelaars de compatibiliteit met opensource GNU-software en diverse Unix-varianten te verbeteren. Zo heeft onder andere het commerciële Unix-besturingssysteem Oracle Solaris een groot deel van zijn systeembestanden al ondergebracht in de usr-folder.
Met de nieuwe indeling zou het mogelijk worden om slechts een klein aantal systeembestanden in een rootpartitie onder te brengen, waarna het besturingssysteem de overige bestanden via een apart mountpoint uit een usr-partitie kan uitlezen. Met name voor virtualisering en cloud computing zou de vereenvoudigde directorystructuur voordelen bieden.
Ondanks de wijzigingen die het Fedora-team wil doorvoeren in de directorystructuur van Fedora 17, hebben andere 'grote' distributies vooralsnog geen concrete plannen om het voorbeeld te volgen. Fedora 17 zal naar verwachting in mei worden uitgebracht.
Reacties (100)
Net zoals onder Mac OS X dus (en BSD?), daar heb je al /lib en /bin in de /usr folder staan ipv in de root.
En onder BSD is /home standaard ook een symlink naar /usr/home
Ja, maar dat is niet handig, om dat home een map voor gebruikersbestanden is...
Raar inderdaad dat (Free)BSD standaard geen aparte partitie voor /home maakt. Meestal komt het er toch wel op neer dat ik het niet eens ben met de defaults van sysinstall en dus eigenlijk altijd wat verschuif maar een slimmere default zou leuk zijn.
de filosofie van FreeBSD is eerder dat, als je zoveel user data hebt, je daar al lang iets snuggers voor bedacht hebt met bijvoorbeeld NFS en bindingen via YP, LDAP, oid.Raar inderdaad dat (Free)BSD standaard geen aparte partitie voor /home maakt. Meestal komt het er toch wel op neer dat ik het niet eens ben met de defaults van sysinstall en dus eigenlijk altijd wat verschuif maar een slimmere default zou leuk zijn.
De meeste machines hebben maar 1 of 2 users buiten root.
[Reactie gewijzigd door arjankoole op 29 januari 2012 22:47]
Een aparte partitie voor /home of /usr/home is soms handig en soms onnodig. Het feit dat je zelf de keuze hebt is toch een prachtige feature?
In BSD heb je alle belangrijke tools om systeem te repareren in de root partitie (fsck, dump/restore/tar, fdisk, bsdlabel, ed), maar ook uiteraard dat wat nodig is om de rest van het systeem op te brengen (dhclient, diverse mount_ commands), kortom een minimaal werkend systeem. Hier wordt goed over nagedacht. Alles wat niet essentieel is zit niet in de root maar onder /usr (of /usr/local voor packages).
Ik keek net even op een Debian systeem en daar geld min of meer hetzelfde.
Ik snap dan ook niet helemaal het voordeel dat Fedora hier probeert te bereiken. Hoe kun je /usr nog een aparte partitie maken als bijvoorbeeld het mount commando niet meer in /sbin staat maar in /usr/sbin? Kip en ei: je kunt /usr pas mounten als /usr gemount is, want daarin staat het mount commando
Ik keek net even op een Debian systeem en daar geld min of meer hetzelfde.
Ik snap dan ook niet helemaal het voordeel dat Fedora hier probeert te bereiken. Hoe kun je /usr nog een aparte partitie maken als bijvoorbeeld het mount commando niet meer in /sbin staat maar in /usr/sbin? Kip en ei: je kunt /usr pas mounten als /usr gemount is, want daarin staat het mount commando
Fout. Weet je wel waar je het over hebt?
Het nieuwe hier is dat /bin, /lib naar /usr/bin etc. is gegaan. Voorheen waren er meerdere /bin structuren. Ook met een rede overigens.
Als je ooit met Linux of Unix in aanraking was geweest had je dat geweten.
Het nieuwe hier is dat /bin, /lib naar /usr/bin etc. is gegaan. Voorheen waren er meerdere /bin structuren. Ook met een rede overigens.
Als je ooit met Linux of Unix in aanraking was geweest had je dat geweten.
Net als linux, komt ook humor in diverse smaken?
Blijkbaar dat Linux Windows achteraangaat ofzoiets 
O, wat doen we weer lekker interressant! Als het even kan kraken we de ander zo af dat die niet meer reageert. Geweldig vind jij je zelf. Je zal best goed zijn in Linux, maar van sociaal fatsoenlijk gedrag, heb je totaal geen kaas gegeten. BAH! Dat is ook de reden dat ik hier bijna nooit meer kom. In één woord: BAH!!!
Voor de Thuisgebruiker biedt 't vooral mogelijkheden om kapot te gaan heb ik 't idee.Met name voor virtualisering en cloud computing zou de vereenvoudigde directorystructuur voordelen bieden.
Hierboven: nee hoor, OSX heeft gewoon een traditionele /bin en /sbin, maar inderdaad geen /lib.
[Reactie gewijzigd door CyBeR op 29 januari 2012 13:34]
Wat gaat er kapot dan?
Het klinkt een beetje als vieze dingen met mieren doen; in welke directory de bestandjes zitten, maar goed.
Het klinkt een beetje als vieze dingen met mieren doen; in welke directory de bestandjes zitten, maar goed.
Met mieren..? Whatever suits your needs zou ik zeggen, maar ik bedank;)
Omdat de user in de /usr map meer rechten heeft, en dus sneller dingen kan verwijderen bijvoorbeeld, terwijl dat wellicht niet de bedoeling is. Natuurlijk moet je, als je in de terminal gaat kloten, weten wat je doet, maar soms gaat er gewoon iets fout, en dan is het fijn als er nog een extra handeling (sudo, toestemming geven, etc) tussen je commando en het uitvoeren ervan zit 
/usr heeft meestal dezelfde rechten als /bin .sbin enzovoort, root is owner, en is de enige die mag schrijven, de rest heeft read en execute.
Inderdaad, eigenlijk is het al een hele tijd achterhaald ondertussen. Het werd vroeger gebruikt om 2 verschillende disks te gebruiken. De /bin stond dan op een kleinere, snelle disk. Bij heel veel distro's is /bin al een symlink ondertussen, als iedereen het toepast, kan in de toekomst die symlink gewoon weg.
En als je nu /usr van een NFS server wilt mounten?
Dan moet je in je initial ramdisk NFS hebben zitten
Ik snap die nodeloze extra laag complexiteit niet. Waarom pivot_root() aanroepen en dan vervolgens alle tools die ook al in initrd zaten naar /usr verplaatsen? Gebruik dan de initrd gewoon als root filesysteem.
Misschien om je initrd gebaseerd is op busybox, en je in je uiteindelijke systeem graag de 'echte' tools wilt.
Ik zie het probleem niet, je kan /usr/bin, /usr/sbin, /usr/home etc. etc. nog steeds op verschillende disks zetten. Of je nu /bin naar een andere disk zet of /usr/bin maakt niks uit. Sterker nog nu is er een /bin en een /usr/bin welke alle twee gevuld zijn, straks worden de twee compleet samengevoegd onder /usr/bin zoals bij een groot aantal Unix varianten al jaren het geval is wat ook andere voordelen bied. Straks kan je zonder veel te klooien /usr/bin op een andere disk kwijt zonder dat je /bin en /usr een separate partitie hoeft te geven.
/lib, /sbin en /bin staan wel degelijk in /usr.[...]
Hierboven: nee hoor, OSX heeft gewoon een traditionele /bin en /sbin, maar inderdaad geen /lib.
Er staat ook /sbin en /bin in /
Mac OS X.7 Server:
server:/ admin$ ls
Applications Shared Items boot mach_kernel
usr System cores net var
Groups Users dev private
Library Volumes etc sbin
Network bin home tmp
server:/ admin$ cd /usr
server:usr admin$ ls
X11 bin libexec share
X11R6 lib sbin standalone
[Reactie gewijzigd door drib83 op 29 januari 2012 13:55]
Fedora had vroeger ook zowel /bin als /usr/bin, zie ook
http://www.pathname.com/fhs/pub/fhs-2.3.html
voor het verschil in betekenis,
/bin: Essential user command binaries
/usr/bin: Most user commands
Het is dus niet zo dat alles onder /bin stond en naar /usr/bin gaat, maar dat wat onder /bin stond nu samengevoegd wordt bij /usr/bin.
En dit is bij Mac dus (nog) niet het geval.
http://www.pathname.com/fhs/pub/fhs-2.3.html
voor het verschil in betekenis,
/bin: Essential user command binaries
/usr/bin: Most user commands
Het is dus niet zo dat alles onder /bin stond en naar /usr/bin gaat, maar dat wat onder /bin stond nu samengevoegd wordt bij /usr/bin.
En dit is bij Mac dus (nog) niet het geval.
Eh.. zo kan je natuurlijk niet zien wat symlinks zijn he.
MacBook-Pro:/ genicus$ ls -la
total 31501
drwxr-xr-x 37 root wheel 1326 Jan 26 16:28 .
drwxr-xr-x 37 root wheel 1326 Jan 26 16:28 ..
-rw-rw-r--@ 1 root admin 15364 Jan 20 22:51 .DS_Store
d--x--x--x 7 root wheel 238 Jan 24 11:57 .DocumentRevisions-V100
drwx------ 5 root admin 170 Jul 3 2011 .Spotlight-V100
d-wx-wx-wt 2 root staff 68 Jul 3 2011 .Trashes
srwxrwxrwx 1 root wheel 0 Jan 26 16:28 .dbfseventsd
-rwxrwxrwx 1 root admin 0 May 9 2011 .error
---------- 1 root admin 0 Jun 18 2011 .file
drwx------ 4481 root admin 152354 Jan 29 20:09 .fseventsd
-rw------- 1 root wheel 524288 Dec 18 03:13 .hotfiles.btree
drwxr-xr-x@ 2 root wheel 68 Jun 21 2011 .vol
drwxrwxr-x@ 92 root admin 3128 Jan 26 19:16 Applications
-rw-r--r-- 1 root wheel 0 Apr 16 2010 Archive.pax
drwxrwxr-x 15 root admin 510 Aug 1 10:37 Developer
drwxr-xr-x@ 66 root wheel 2244 Jan 16 20:42 Library
drwxr-xr-x@ 2 root wheel 68 Jun 18 2011 Network
drwxr-xr-x@ 4 root wheel 136 Oct 12 21:28 System
drwxr-xr-x 6 root admin 204 Jul 6 2011 Users
drwxrwxrwt@ 7 root admin 238 Jan 29 14:06 Volumes
drwxr-xr-x@ 39 root wheel 1326 Oct 12 21:23 bin
drwxr-xr-x 3 leendert admin 102 Jan 13 2011 codeblocks
drwxrwxr-t@ 2 root admin 68 Jun 18 2011 cores
dr-xr-xr-x 3 root wheel 4221 Jan 28 10:15 dev
lrwxr-xr-x@ 1 root wheel 11 Jul 3 2011 etc -> private/etc
dr-xr-xr-x 2 root wheel 1 Jan 29 19:59 home
-rw-r--r--@ 1 root wheel 15565404 Aug 10 05:58 mach_kernel
dr-xr-xr-x 2 root wheel 1 Jan 29 19:59 net
drwxr-xr-x@ 3 root admin 102 Nov 7 2010 opt
drwxr-xr-x@ 6 root wheel 204 Jul 3 2011 private
drwxr-xr-x@ 62 root wheel 2108 Oct 12 21:23 sbin
drwxr-xr-x@ 2 root wheel 68 Jun 16 2011 sbin (from old Mac)
lrwxr-xr-x@ 1 root wheel 11 Jul 3 2011 tmp -> private/tmp
drwxr-xr-x@ 14 root wheel 476 Aug 1 10:40 usr
lrwxr-xr-x@ 1 root wheel 11 Jul 3 2011 var -> private/var
zo beter?
total 31501
drwxr-xr-x 37 root wheel 1326 Jan 26 16:28 .
drwxr-xr-x 37 root wheel 1326 Jan 26 16:28 ..
-rw-rw-r--@ 1 root admin 15364 Jan 20 22:51 .DS_Store
d--x--x--x 7 root wheel 238 Jan 24 11:57 .DocumentRevisions-V100
drwx------ 5 root admin 170 Jul 3 2011 .Spotlight-V100
d-wx-wx-wt 2 root staff 68 Jul 3 2011 .Trashes
srwxrwxrwx 1 root wheel 0 Jan 26 16:28 .dbfseventsd
-rwxrwxrwx 1 root admin 0 May 9 2011 .error
---------- 1 root admin 0 Jun 18 2011 .file
drwx------ 4481 root admin 152354 Jan 29 20:09 .fseventsd
-rw------- 1 root wheel 524288 Dec 18 03:13 .hotfiles.btree
drwxr-xr-x@ 2 root wheel 68 Jun 21 2011 .vol
drwxrwxr-x@ 92 root admin 3128 Jan 26 19:16 Applications
-rw-r--r-- 1 root wheel 0 Apr 16 2010 Archive.pax
drwxrwxr-x 15 root admin 510 Aug 1 10:37 Developer
drwxr-xr-x@ 66 root wheel 2244 Jan 16 20:42 Library
drwxr-xr-x@ 2 root wheel 68 Jun 18 2011 Network
drwxr-xr-x@ 4 root wheel 136 Oct 12 21:28 System
drwxr-xr-x 6 root admin 204 Jul 6 2011 Users
drwxrwxrwt@ 7 root admin 238 Jan 29 14:06 Volumes
drwxr-xr-x@ 39 root wheel 1326 Oct 12 21:23 bin
drwxr-xr-x 3 leendert admin 102 Jan 13 2011 codeblocks
drwxrwxr-t@ 2 root admin 68 Jun 18 2011 cores
dr-xr-xr-x 3 root wheel 4221 Jan 28 10:15 dev
lrwxr-xr-x@ 1 root wheel 11 Jul 3 2011 etc -> private/etc
dr-xr-xr-x 2 root wheel 1 Jan 29 19:59 home
-rw-r--r--@ 1 root wheel 15565404 Aug 10 05:58 mach_kernel
dr-xr-xr-x 2 root wheel 1 Jan 29 19:59 net
drwxr-xr-x@ 3 root admin 102 Nov 7 2010 opt
drwxr-xr-x@ 6 root wheel 204 Jul 3 2011 private
drwxr-xr-x@ 62 root wheel 2108 Oct 12 21:23 sbin
drwxr-xr-x@ 2 root wheel 68 Jun 16 2011 sbin (from old Mac)
lrwxr-xr-x@ 1 root wheel 11 Jul 3 2011 tmp -> private/tmp
drwxr-xr-x@ 14 root wheel 476 Aug 1 10:40 usr
lrwxr-xr-x@ 1 root wheel 11 Jul 3 2011 var -> private/var
zo beter?
En wanneer gaan ze die achterhaalde X11 map eens verwijderen? Lijkt me nuttiger voor de filesystem hierarchy dan /sbin/ naar /usr verplaatsen...
weer een afwijking 
opzich verschillen die linux distro's neit zo veel van elkaar, maar het blijft altijd zoeken naar de juiste files wanneer je achter een systeem kruipt met suse/gentoo/debian/fedora etc. allemaal net even iets andere structuur of locatie van configs 
jah jah ik weet, je bent vrij om te kiezen ...
[Reactie gewijzigd door himlims_ op 29 januari 2012 14:26]
Hoezo ? De locatie van configuratie bestanden (/etc) word toch niet verplaatst ?allemaal net even iets andere structuur of locatie van configs
Daarnaast maak je meestal een keuze voor een Linux distro en blijf je daar een tijdje bij. Ik heb nog wel andere systemen draaien naast Linux zoals OpenBSD en OpenIndiana omdat die beide zo hun sterke kanten hebben (OpenBSD met PF goed als router en gateway en OpenIndiana met ZFS goed voor storage). Echter het gebruik van verschillende linux distro's zie ik niet echt voordelen in. Als je bijvoorbeeld RHEL / CentOS gebruikt en je wil zelf iets compilen ga je niet opeens Gentoo gebruiken; Dan package je gewoon zelf een RPM (of pas je een SRPM aan) voor RHEL / CentOS.
Maar de locatie van b.v. /bin/bash wel.
Hoeveel scripts bevatten wel niet:
!# /bin/bash
# -script-
Hoeveel scripts bevatten wel niet:
!# /bin/bash
# -script-
Ja, daarom komt er ook een symlink denk ik. Dan kun je dat script gewoon blijven gebruiken. /bin/bash ---> /usr/bin/bash zeg maar.
En als straks de overgrote meerderheid van distro's dit doet dan kan de symlink weg omdat de scripts /usr/bin/bash bevatten. Dan moeten distro's die het nog gewoon in /bin hebben staan maar standaard voor een symlink zorgen.
En als straks de overgrote meerderheid van distro's dit doet dan kan de symlink weg omdat de scripts /usr/bin/bash bevatten. Dan moeten distro's die het nog gewoon in /bin hebben staan maar standaard voor een symlink zorgen.
Dit probleem kan je vaak oplossen met #!/usr/bin/env bash
De verdeling tussen lange termijn en ff snel wat nieuws proberen is welk belangrijk.Echter het gebruik van verschillende linux distro's zie ik niet echt voordelen in.
Fedora valt met zijn 18 maanden support cycli dan al gauw af, dan wordt het toch Debian. (tenzij het echt erg mission critical is, dan kan je een RHEL overwegen)
Fedora is verder ook niet bijzonder sterk op niet x86 hardware, vooral oudere.
De bedoeling is juist deze verschillen weg te werken! Fedora zal volledig compatibel worden met alle packages welke naar /bin verwijzen EN met alle die naar /usr/bin verwijzen. Beiden zijn namelijk synoniemen. M.a.w. zelfs al is fedora de enige die merged dan nog is het aantal verschillen niet toegenomen.
Op dit moment zijn er veel verschillen tussen distros want voor iedere file kan ieder distro kiezen in welke van de 2 opties (vb /bin en /usr/bin) hij de file plaatst. Je hebt dus effectief tientallen mogelijkheden. Met de /usr merge verdwijnen deze verschillen en zal iedere distro die er aan meedoet geen onderlinge verschillen meer hebben. resultaat: met elke distro die de merge invoegt zullen er afwijkingen verdwijnen.
Op dit moment zijn er veel verschillen tussen distros want voor iedere file kan ieder distro kiezen in welke van de 2 opties (vb /bin en /usr/bin) hij de file plaatst. Je hebt dus effectief tientallen mogelijkheden. Met de /usr merge verdwijnen deze verschillen en zal iedere distro die er aan meedoet geen onderlinge verschillen meer hebben. resultaat: met elke distro die de merge invoegt zullen er afwijkingen verdwijnen.
Misschien ben ik te pessimistisch, maar zijn die systeemfolders vervolgens ook als niet-root te wijzigen?
Dus wanneer je als 'gewone' gebruiker aangemeld bent op het systeem?
Zo ja, dan lijkt me dat toch een zeker (extra) beveiligingsrisico met zich meebrengen:
niet alleen door kwaadwillenden van buitenaf (malware dat makkelijker system files kan wijzigen/infecteren), maar ook door onkunde/onhandigheid van de betreffende user.
Er staat wel dat ze het 'read only' willen maken, maar met evt. updates moet zo'n systeemfolder toch beschreven kunnen worden?
Dus wanneer je als 'gewone' gebruiker aangemeld bent op het systeem?
Zo ja, dan lijkt me dat toch een zeker (extra) beveiligingsrisico met zich meebrengen:
niet alleen door kwaadwillenden van buitenaf (malware dat makkelijker system files kan wijzigen/infecteren), maar ook door onkunde/onhandigheid van de betreffende user.
Er staat wel dat ze het 'read only' willen maken, maar met evt. updates moet zo'n systeemfolder toch beschreven kunnen worden?
Er verandert er niets aan de permissies, alleen aan de locatie.
dit zijn systeemfolders en deze standaard niet aanpasbaar door de gebruiker. Als gebruiker kan je slechts werken in je /home/<gebruiker>/ folder en temporary folders zoals /tmp en /var/tmp
Nee. De meeste distro's hebben al een bin, lib en sbin directory onder /usr hangen. Er is echter een duidelijk verschil: de /usr/bin en /usr/lib mappen bevatten de niet-essentiele libraries en commando's terwijl /bin /sbin en /lib de systeem-tools (zoals ls, cat e.d.) en de kernel modules bevatten.
Dit onderscheid gaat verloren indien alles onder /usr wordt gehangen. Persoonlijk zie ik het voordeel niet. Als je alles op een andere partitie zou willen hebben kun je dat nu ook al eenvouding doen mbv symbolic links of (bind) mounts.
Maar geen enkele distro laat het toe dat gewone gebruikers schrijven buiten hun home-directory, met als enige uitzondering de /tmp directory waar ze hun tijdelijke bestanden in kwijt kunnen. Dat zal hier echt niet door veranderen.
Dit onderscheid gaat verloren indien alles onder /usr wordt gehangen. Persoonlijk zie ik het voordeel niet. Als je alles op een andere partitie zou willen hebben kun je dat nu ook al eenvouding doen mbv symbolic links of (bind) mounts.
Maar geen enkele distro laat het toe dat gewone gebruikers schrijven buiten hun home-directory, met als enige uitzondering de /tmp directory waar ze hun tijdelijke bestanden in kwijt kunnen. Dat zal hier echt niet door veranderen.
[Reactie gewijzigd door MadEgg op 29 januari 2012 13:50]
Die basistools waar je het over hebt zitten tegenwoordig in de initrd image, en niet op /bin. In het artikel wordt het onderscheid tussen /bin en /usr/bin ook van tafel geveegd als mythe. Het bestaat in de praktijk al lang niet meer:
http://www.freedesktop.or...emd/TheCaseForTheUsrMerge
Daarin staat ook het bekende voorbeeld van /usr als netwerkschijf uitgelegd.
Het wordt juist maar beter als alles in /usr komt te staan, omdat je dan het gehele OS als readonly image of netwerk disk kan mounten. Voor de rest, zie:The historical justification for a /bin, /sbin and /lib separate from /usr no longer applies today. (More on the historical justification for the split, by Rob Landley) They were split off to have selected tools on a faster hard disk (which was small, because it was more expensive) and to contain all the tools necessary to mount the slower /usr partition.
Today, a separate /usr partition already must be mounted by the initramfs during early boot, thus making the justification for a split-off moot. In addition a lot of tools in /bin and /sbin in the status quo already lost the ability to run without a pre-mounted /usr. There is no valid reason anymore to have the operating system spread over multiple hierarchies, it lost its purpose.
http://www.freedesktop.or...emd/TheCaseForTheUsrMerge
Daarin staat ook het bekende voorbeeld van /usr als netwerkschijf uitgelegd.
[Reactie gewijzigd door YaPP op 29 januari 2012 15:43]
Ik heb het niet over het 'rescue system' waar jij het over hebt. Als je 'which ls' intypt krijgt je toch echt nog steeds /bin/ls en niet /usr/bin/ls, het onderscheid is er dus wel degelijk.
Het verschil is niet functioneel maar semantisch van aard.
En wat ik dus al zei, je kunt zonder deze wijziging ook al het hele OS als readonly mounten. Maak een disk met daarop bv:
/usr/bin
/bin
en mount die als, bijvoorbeeld /mnt/system
Doe vervolgens:
mount -o bind /mnt/system/usr/bin /usr/bin
mount -o bind /mnt/system/bin /bin
et voila, je hebt de hele zooi op een disk, die je best readonly kan mounten. Nu het geheel nog in /etc/fstab zetten om het automatisch te laten gebeuren (of dit natuurlijk tijdens de installatie gewoon al zo instellen) en je bent klaar.
Het verschil is niet functioneel maar semantisch van aard.
En wat ik dus al zei, je kunt zonder deze wijziging ook al het hele OS als readonly mounten. Maak een disk met daarop bv:
/usr/bin
/bin
en mount die als, bijvoorbeeld /mnt/system
Doe vervolgens:
mount -o bind /mnt/system/usr/bin /usr/bin
mount -o bind /mnt/system/bin /bin
et voila, je hebt de hele zooi op een disk, die je best readonly kan mounten. Nu het geheel nog in /etc/fstab zetten om het automatisch te laten gebeuren (of dit natuurlijk tijdens de installatie gewoon al zo instellen) en je bent klaar.
Net even in het cursus boek voor linux gekeken:
/bin folder: voor OS systeem folders en bestanden.
/usr/bin foder: voor aanvullende programma's folders en bestanden.
Op xubuntu 10.4 lijkt dit nog aardig in tact te zijn, volgens het bovenstaande.
Dus vermoed ik dat er in de linux wereld weer wat verschillen aan het ontstaan zijn ...
Lijkt me dat je je met het bij elkaar plaatsen van de libraries van het OS / syteem en de programma's wel sneller een "windows dll-hell" op de hals haalt.
Ik vraag me dan ook af of dit wel handig is voor de niet-cloud gebruiker.
En hoeveel linux gebruiker willen naar de cloud? Ik zeker niet.
/bin folder: voor OS systeem folders en bestanden.
/usr/bin foder: voor aanvullende programma's folders en bestanden.
Op xubuntu 10.4 lijkt dit nog aardig in tact te zijn, volgens het bovenstaande.
Dus vermoed ik dat er in de linux wereld weer wat verschillen aan het ontstaan zijn ...
Lijkt me dat je je met het bij elkaar plaatsen van de libraries van het OS / syteem en de programma's wel sneller een "windows dll-hell" op de hals haalt.
Ik vraag me dan ook af of dit wel handig is voor de niet-cloud gebruiker.
En hoeveel linux gebruiker willen naar de cloud? Ik zeker niet.
[Reactie gewijzigd door Xubby op 29 januari 2012 15:37]
De grens tussen systeem en applicaties is onder Linux altijd een beetje onduidelijk geweest. De nieuwe verdeling is:
initrd: essentiele OS-onderdelen
/usr: al het andere
initrd: essentiele OS-onderdelen
/usr: al het andere
Dit heeft weinig met DLL-hell te maken. De DLL-hell heeft betrekking op verschillende versies van dezelfde library die elkaar in de weg zitten.
Op Linux komt dit veel minder voor omdat er al sinds jaar en dag versienummers in de filename van elke library zitten. Ik heb bijvoorbeeld libtdl.so.7.3.0 en libtdl.so.3.1.6 geinstalleerd staan. Aangezien de minor versies over het algemeen niet boeien zijn deze gelinkt naar libltdl.so.3 en libtdl.so.7, welke door de programma's gebruikt worden die ze nodig hebben. Doordat elk programma naar de juiste versie linkt kunnen ze niet met elkaar in de knoop komen. De enige problemen die je wel tegen kan komen is dat de juiste versie van een library mist wat meestal opgelost kan worden door een andere versie van je distributie te installeren.
Wat dit artikel betreft: in /lib en /usr/lib staan verschillende libraries, niet verschillende versie van dezelfde library, dus dit zal hier zeker geen invloed op hebben.
Voor de gebruiker zal het inderdaad zeker niet uit maken, deze wijziging. Dankzij de symlinks zal het voor developers ook weinig uitmaken. De grote vraag blijft nog steeds het waarom. Uit het artikel wordt mij niet voldoende duidelijk waarom ze samen gevoegd zouden worden, anders dan 'meer overeenkomst met Solaris'.
Op Linux komt dit veel minder voor omdat er al sinds jaar en dag versienummers in de filename van elke library zitten. Ik heb bijvoorbeeld libtdl.so.7.3.0 en libtdl.so.3.1.6 geinstalleerd staan. Aangezien de minor versies over het algemeen niet boeien zijn deze gelinkt naar libltdl.so.3 en libtdl.so.7, welke door de programma's gebruikt worden die ze nodig hebben. Doordat elk programma naar de juiste versie linkt kunnen ze niet met elkaar in de knoop komen. De enige problemen die je wel tegen kan komen is dat de juiste versie van een library mist wat meestal opgelost kan worden door een andere versie van je distributie te installeren.
Wat dit artikel betreft: in /lib en /usr/lib staan verschillende libraries, niet verschillende versie van dezelfde library, dus dit zal hier zeker geen invloed op hebben.
Voor de gebruiker zal het inderdaad zeker niet uit maken, deze wijziging. Dankzij de symlinks zal het voor developers ook weinig uitmaken. De grote vraag blijft nog steeds het waarom. Uit het artikel wordt mij niet voldoende duidelijk waarom ze samen gevoegd zouden worden, anders dan 'meer overeenkomst met Solaris'.
* Als je gebruikmaakt van linux containers kun je nu /usr read only bind mounten in de guest wat je een compleet OS geeft
* Je kunt /usr snapshotten om je OS te snapshotten. Ik meende dat ze met een yum plugin bezig waren die een copy-on-write snapshot maakte van /usr zodat je altijd direct terug kan naar een versie van je OS voor de yum update. Dit CoR snapshots zijn met een FS als btrfs ook een stuk eenvoudiger te beheren.
Misschien zijn een boel technologien nog niet ver genoeg, maar je moet zo'n verandering op de lange termijn bekijken. Op korte termijn is er weinig winst te halen.
* Je kunt /usr snapshotten om je OS te snapshotten. Ik meende dat ze met een yum plugin bezig waren die een copy-on-write snapshot maakte van /usr zodat je altijd direct terug kan naar een versie van je OS voor de yum update. Dit CoR snapshots zijn met een FS als btrfs ook een stuk eenvoudiger te beheren.
Misschien zijn een boel technologien nog niet ver genoeg, maar je moet zo'n verandering op de lange termijn bekijken. Op korte termijn is er weinig winst te halen.
Nogmaals, zoals ik al drie keer gezegd heb, dat snapshotten en read only mounten kan in de huidige situatie net zo goed. Dus wat is het voordeel?
http://www.freedesktop.or...emd/TheCaseForTheUsrMerge
Samengevat : "Solaris doet het en Redhat heeft de compabiliteit nodig als verkoop argument, en de rest kan verrekken"
Ik heb er op zich niet zoveel op tegen, behalve dus dat het _WEER_ een verandering is. Zo komt Linux nooit in stabieler vaarwater, en blijft het bij de waan van de dag.
En dat alleen omdat het misschien nuttig is voor een paar RHEL enterprise klanten
Samengevat : "Solaris doet het en Redhat heeft de compabiliteit nodig als verkoop argument, en de rest kan verrekken"
Ik heb er op zich niet zoveel op tegen, behalve dus dat het _WEER_ een verandering is. Zo komt Linux nooit in stabieler vaarwater, en blijft het bij de waan van de dag.
En dat alleen omdat het misschien nuttig is voor een paar RHEL enterprise klanten
Als dat je samenvatting is, dan zou ik aanraden om het artikel nog een keer te lezen.
Ik zie niet eens in waarom ze weer wat moeten afwijken van de LSB. Dit bepaalt wat de directory structuur moet zijn zodat er meer standaardisatie komt maar Fedora heeft er blijkbaar geen interesse in terwijl zo goed als alle andere distributies zich hier wel aan houden.
[Reactie gewijzigd door Bunga op 29 januari 2012 14:55]
Aan de andere kant is het zo meer in lijn met unix. Overigens is dit een voor de eindgebruiker een weinig ingrijpende wijziging aangezien ze dmv symlinks volledige compatibiliteit kunnen garanderen. Ze worden hiermee dus eigenlijk meer compatible
Standaarden kunnen aangepast worden. Een van de schrijvers van de FHS vind het helemaal prima. Ik denk dat de meeste distributies uiteindelijk wel zullen volgen.
Lijkt me heel erg sterk dat ze de permissies vergeten zijn, denk je zelf ook niet?
Ja, dat leek mij ook wel
Maar het lijkt me (gevoelsmatig) ook veiliger/handiger om een gehele map "off limits" te maken én te houden dan een subfolder.
Ik ben bijv. ook geen fan van hoe Windows dat "af-fabriek" doet met de mappen voor je documenten, en met name de standaardopslagmappen van bijv. Outlook en Windows Live Mail: ergens 'diep' tussen de systeembestanden.
Niet alleen met het oog op veiligheid, maar ook voor het maken van backups en toegankelijkheid als het systeem crasht.
Maar het lijkt me (gevoelsmatig) ook veiliger/handiger om een gehele map "off limits" te maken én te houden dan een subfolder.
Ik ben bijv. ook geen fan van hoe Windows dat "af-fabriek" doet met de mappen voor je documenten, en met name de standaardopslagmappen van bijv. Outlook en Windows Live Mail: ergens 'diep' tussen de systeembestanden.
Niet alleen met het oog op veiligheid, maar ook voor het maken van backups en toegankelijkheid als het systeem crasht.
[Reactie gewijzigd door Iva_Bigone op 29 januari 2012 13:51]
Ik ben dan ook gecharmeerd van het feit dat onder mijn Linux-distributie alle persoonlijke bestanden (bestande, onfiguraties etc.) in /home/$username$ staan, dat maakt backuppen een stuk makkelijker (zeker omdat /home geen map maar een mountpoint is, en fysiek op een eigen partitie staat).
Ik zie op http://www.freedesktop.or...emd/TheCaseForTheUsrMerge geen woord over security.
Ik wel, da's het stukje over dat 'read only' wat ik aanhaalde:
Dat 'snapshotten' lijkt me dan wel weer een mooie als dat van systeem naar systeem kan: als je dan (behoorlijke) upgrade doet (ander mobo/cpu etc.) dat je niet al je persoonlijke instellingen én je extra software opnieuw hoeft te installeren.Myth #4: The /usr merge’s only purpose is to look pretty, and has no other benefits
Fact: The /usr merge makes sharing the vendor-supplied OS resources between a host and networked clients as well as a host and local light-weight containers easier and atomic.
Snapshotting the OS becomes a viable option.
The /usr merge also allows making the entire vendor-supplied OS resources read-only for increased security and robustness.
[Reactie gewijzigd door Iva_Bigone op 29 januari 2012 14:03]
Maar wat je aanhaalt is eigenlijk gewoon incorrect /usr/bin is niet alleen voor OS resources maar ook voor applicatie resources. Je essentiële " vendor-supplied OS resources" zouden in /bin moeten staan terwijl applicaties en niet essentiële resources in /usr/bin "horen" Veel applicaties die niets met het daadwerkelijke OS te maken hebben (denk bv MySQL maar je kan het zo gek niet bedenken) staan gewoon in /usr/bin
Je kan dus eigenlijk al snapshots maken van de daadwerkelijke systeem bestanden. (namelijk van /bin) Tenminste, dat zou moeten als vendors als Fedora er geen zooitje van hadden gemaakt.
Wat mij betreft is het:
1. We doen maar wat.
2. Verrek we willen eigenlijk toch alles in bin maar dat kan niet meer.
3. O, dan gooien we maar alles in /usr/bin
Ik kan me er niet heel druk over maken, maar dit argument grijpt terug op de reden waarom we een /bin hebben en is geen reden om alles maar in /usr/bin te proppen
Je kan dus eigenlijk al snapshots maken van de daadwerkelijke systeem bestanden. (namelijk van /bin) Tenminste, dat zou moeten als vendors als Fedora er geen zooitje van hadden gemaakt.
Wat mij betreft is het:
1. We doen maar wat.
2. Verrek we willen eigenlijk toch alles in bin maar dat kan niet meer.
3. O, dan gooien we maar alles in /usr/bin
Ik kan me er niet heel druk over maken, maar dit argument grijpt terug op de reden waarom we een /bin hebben en is geen reden om alles maar in /usr/bin te proppen
toevallig had ik net het artikel op Phoronix hierover gelezen. Ik ben het ook geheel eens met Fedora om deze merge uit te voeren. Er is geheel geen reden meer voor om deze scheiding te houden, de structuur wordt simpeler en uiteindelijk zal dit minder werk zijn voor de maintainers van de distributies. Ik hoop dan ook dat andere distributies (Debian!) in navolging treedt
gelukkig is ubuntu al bezig om de /var/run naar /run te brengen om het even duidelijk te houden
Wat ik me afvraag: voldoen ze dan nog wel aan de Linux Standard Base? Ook als je symlinks gebruikt?
Weet niet of deze actie invloed heeft, maar volgens mij voldoet Fedora met systemd daar al niet meer aan. systemd heeft aantal dependencies die vereisen dat /usr op de root partitie staat.
Ik denk zelf dat het tijd is voor een LSB 3.0 die hier rekening mee houdt. Ook /run mag wmb daarin. Gelukkig ligt de draft er al (http://www.linuxfoundatio...groups/lsb/fhs-30-draft-1).
edit:
edit:
doelde ik dus op.The following commands, or symbolic links to commands, are required in /bin
[Reactie gewijzigd door webkiller71 op 29 januari 2012 17:16]
Ik heb de verschillen tussen /bin, /usr/bin, /usr/local/bin en /opt onder Linux nooit begrepen. Kan iemand daar inzicht over verschaffen? FreeBSD maakt onderscheid tussen base en aanvullende ports, maar Linux kent geen echte base; dat is de kernel en de rest.
Origineel:
- alles in /is een minimaal single userl systeem voor rescue doeleinden (als /usr niet gemount is). Klassiek waren alle binaries hier dan ook statisch gelinked (soms zelfs tegen minimale versies van de libraries)
- /usr is de rest van het systeem, nodig voor het volle, multi-user systeem
/usr/local was origineel een BSD additie bedoeld voor "locale" addities aan het systeem. Linux en BSD hebben dat verschillend geinterpreteerd:
- Linux, als BSD-SysV hybride interpreteerde het origineel (SLS, en opvolger slackware) als "de distributie installeert zoveel mogelijk in /usr", en handmatige gecompileerde programma's gaan in /usr/local. DIt is door de jaren heen verwaterd, en /usr/local wordt niet veel gebruikt
- Op BSD is /usr het "base" systeem (het altijd geinstalleerde deel dus) en /usr/local de rest (optionele delen van de distributie). Dit wordt nog atlijd strak gehandhaafd. Omdat hierdoor de meeste software "prefix clean" is, is het op BSD vaak makkelijker software in een exotisch (b.v. eigen gedefinieerd) prefix te installeren.
- /opt is iets dergelijks als BSD's /usr/local, maar dan meer van de SysV kant van de familie en zonder prefix layout. Redhat wilde in het begin erg graag tegen SysV aanleunen en heeft dit geintroduceerd. SLS/Slackware als niet commercieel zat dichter tegen (de ook vrije) BSDs aan, en gebruikte /usr/local. Op BSD bestaat het niet.
Veel single user rescue wordt er echter niet meer gedaan. De meeste mensen booten toch via een CD in een voller rescue systeem. Ook hebben veel minder systemen echt /home, /var, /usr op een andere partitie staan. (om vollopen van het systeem door mortals te voorkomen)
- alles in /is een minimaal single userl systeem voor rescue doeleinden (als /usr niet gemount is). Klassiek waren alle binaries hier dan ook statisch gelinked (soms zelfs tegen minimale versies van de libraries)
- /usr is de rest van het systeem, nodig voor het volle, multi-user systeem
/usr/local was origineel een BSD additie bedoeld voor "locale" addities aan het systeem. Linux en BSD hebben dat verschillend geinterpreteerd:
- Linux, als BSD-SysV hybride interpreteerde het origineel (SLS, en opvolger slackware) als "de distributie installeert zoveel mogelijk in /usr", en handmatige gecompileerde programma's gaan in /usr/local. DIt is door de jaren heen verwaterd, en /usr/local wordt niet veel gebruikt
- Op BSD is /usr het "base" systeem (het altijd geinstalleerde deel dus) en /usr/local de rest (optionele delen van de distributie). Dit wordt nog atlijd strak gehandhaafd. Omdat hierdoor de meeste software "prefix clean" is, is het op BSD vaak makkelijker software in een exotisch (b.v. eigen gedefinieerd) prefix te installeren.
- /opt is iets dergelijks als BSD's /usr/local, maar dan meer van de SysV kant van de familie en zonder prefix layout. Redhat wilde in het begin erg graag tegen SysV aanleunen en heeft dit geintroduceerd. SLS/Slackware als niet commercieel zat dichter tegen (de ook vrije) BSDs aan, en gebruikte /usr/local. Op BSD bestaat het niet.
Veel single user rescue wordt er echter niet meer gedaan. De meeste mensen booten toch via een CD in een voller rescue systeem. Ook hebben veel minder systemen echt /home, /var, /usr op een andere partitie staan. (om vollopen van het systeem door mortals te voorkomen)
[Reactie gewijzigd door marcovtjetje op 29 januari 2012 14:39]
/bin, /sbin, /lib zijn voor de programma's die nodig zijn om het systeem kunnen op te starten(/nodig zijn tijdens het opstarten) etc.
/usr/bin, /usr/sbin, /usr/lib zijn voor alle extra software (die niet nodig is voor op te starten).
/usr/local/bin, /usr/local/sbin en /usr/local/lib voor als je software zelf installeert (middels zelf compileren)
/opt is voor software die niet aan de bin, sbin, lib standaard voldoet. Bv. Virtualbox, die plaatst alles onder een "virtualbox" hoofdmap en heeft daar een eigen directorystructuur in (vergelijkbaar met dat onder Win. elk prog. een eigen map onder C:/Program Files aanmaakt en daar een eigen invulling geeft aan waar de bestanden staan).
Dit staat ook zo beschreven in de Filesystem Hierarchy Standard
Bij mijn Arch install staan er ook maar iets minder dan 200 files in /bin en /sbin (/lib tel ik even niet mee omdat die bestanden nodig zijn voor de prog's in /bin en /sbin). Dat vind ik zeker niet slecht. (getest met find /bin /sbin/ -type f | wc -l)
/usr/bin, /usr/sbin, /usr/lib zijn voor alle extra software (die niet nodig is voor op te starten).
/usr/local/bin, /usr/local/sbin en /usr/local/lib voor als je software zelf installeert (middels zelf compileren)
/opt is voor software die niet aan de bin, sbin, lib standaard voldoet. Bv. Virtualbox, die plaatst alles onder een "virtualbox" hoofdmap en heeft daar een eigen directorystructuur in (vergelijkbaar met dat onder Win. elk prog. een eigen map onder C:/Program Files aanmaakt en daar een eigen invulling geeft aan waar de bestanden staan).
Dit staat ook zo beschreven in de Filesystem Hierarchy Standard
Bij mijn Arch install staan er ook maar iets minder dan 200 files in /bin en /sbin (/lib tel ik even niet mee omdat die bestanden nodig zijn voor de prog's in /bin en /sbin). Dat vind ik zeker niet slecht. (getest met find /bin /sbin/ -type f | wc -l)
De in de FHS (die overigens linux centrisch en redelijk nieuw is) gerefereerde BSD hierarchie is overigens op een BSD systeem makkelijk op te roepen met een "man hier"
Ter info: OS X mag je in deze ook tot de BSD's rekenen daar het veel van FreeBSD heeft over genomen (zoals een deel van de userland, je zult dan ook veelvuldig bsd manuals tegenkomen). In dit geval werkt "man hier" dan ook (de link die in de manual wordt genoemd bestaat echter niet meer).
Aanvullend. Het /usr file system stond nogal eens op een remote NFS server, en was bedoeld voor meerdere gebruikers. In /usr/local kwamen dan de spullen die alleen voor het lokale workstation bedoeld waren.
Dat /usr / en root worden samengevoegd snap ik, maar waarom zou je dan niet juist alles /bin, /lib, /sbin en /share zetten?
Dat /usr / en root worden samengevoegd snap ik, maar waarom zou je dan niet juist alles /bin, /lib, /sbin en /share zetten?
Mooi voor Fedora, maar ik vraag me af of er iemand op zit te wachten en of het de zaken effectief eenvoudiger maakt. Het zal eerder meer werk opleveren om alles weer met hun nieuwe 'standaard' compatibel te maken. Ik betwijfel of er veel distro's gaan volgen...
Vergeet niet dat er een grote KANS is dat dit in Redhat wordt opgenomen (RHEL 7 of 8)! Fedora is een early-adopter je zal straks zien (na 1 of 2 jaar) dat iedereen gaat volgen zie ook Pulse Audio, Systemd, nouveau drivers etc etc.
En dan bumblebee installeren op Fedora 17 
lmfao
Voor de geïnteresseerde tweaker: mooi stukje over /bin /sbin /usr/bin /usr/sbin: http://lists.busybox.net/...2010-December/074114.html
Op dit item kan niet meer gereageerd worden.
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
