Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Fedora 17 moving Linux system folders to /usr
#1

Fedora 17 moving Linux system folders to /usr

 

 

Developers are busy working on Fedora 17 and found out they are making a few changes. What changes? They are moving some system files to the /usr directory.

The Following directories will be moved there: /bin /sbin /lib and /lib64 including their sub directories. For now they will keep a symbolic link from the / directory to the

/usr directory, that is to prevent compatibility issues with older Linux software and scripts. This way making it only possible to have a few system files under root and letting

the system creating a seperate mount point for the system files under /usr . Why are they doing this? The simplified directory structure brings advantagesto virtualization

and cloud computing. And developers want to improve compability with other unix varients and GNU software. See more information here. What do you think of this?

change?

 

 

[Image: blue-fedora.jpg]

 

 

 

Sources: tweakers.net and linux.com

Reply
#2

I partly like this idea, and partly dislike this idea, for a number of reasons.

 

Firstly, I'll have to delve into some background Unix knowledge. Traditionally, a disk was partitoned up into a number of slices, each containing a specific filesystem, with the intention of keeping the root filesystem (first slice) small and light. Typical slices included:

 



Code:
/home - user stuff
/var - variable stuff
/tmp - temporary stuff
/ - root filesystem
/usr - Unix System Resources (yes, I didn't know it was called that until much later).




This was to try and split:
  • dynamic from static (/home and /var away from /usr)


  • public from private (/home from /tmp)


  • system from user (/home and /usr)




Under /usr were a number of sub-directories. Those of interest are:
  • /usr/bin - binaries that ordinary users use


  • /usr/sbin - binaries that priviledged users could run. Paths could then be separated out


  • /usr/lib - libraries, shared objects, modules, drivers


  • /usr/share - place for common stuff to be lumped, such shared images for wallpapers, etc.


  • /usr/local - contained bin and sbin, keeping it separate from the one up a level. These were for custom user & system scripts which - by their location - meant an admin could include this region into a backup and keep it separate from the application-installed files in /usr/bin and /usr/sbin.




(this model has been deprecated to the newer one of "lump all static stuff into the first and dynamic stuff into the second slice then use quotas to manage capacity in the second alone)

 

Under /, however, were three directories of note:
  • / itself, containing loads of blank directories as mount points


  • /etc - config files for the system


  • /sbin - minimium binaries needed to get the system up and running.




 

Now, /sbin and /usr/sbin are two different locations for a specific reason - /sbin should be kept small and contain only essential binaries required for bringing Unix online, small enough that the contents of / could be copied to a floppy disk - what they called a "boot and root floppies" for system recovery.

 

I didn't quite understand this concept of having /bin and /usr/bin in Linux, especially when many binaries seemed to be duplicated - it was as though they forgot the /usr part when Linux was first conceived, then moved stuff to /usr/bin but had to retain backwards compatibility with /bin in case older code relied upon that original location.

 

So.. I see these changes as being partly good, partly bad. I'm concerned at what they could break, worried that /sbin and /usr/sbin are going to become confused, but thinking about it - people don't use small media like floppies to perform system recovery these days, they use USB devices, SD cards or bootable CD/DVDs, so there's less pressure upon keeping /sbin light.

 

It also seems like Linux is finally embracing many of the Unix concepts and ideals, maturing in its outlook - I've always felt that Linux has been the impetuous youngster that didn't always fully listen to older brother Unix, arriving at some daft decisions as a result of inexperience and unwillingness to accept that maybe Unix did know better. Time will tell if this model finds its way into other distros, too.

Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)