Linked by Thom Holwerda on Wed 2nd Nov 2011 23:17 UTC
Fedora Core Good news from the Linux world. Fedora has announced its intention to drastically alter the file system layout of its Linux distribution. The plan's been out for a while, but was brought to my attention by Brian Proffitt (still the best name ever) over at ITWorld. The gist is to move all binaries to /usr/bin, and all libraries to /usr/lib and /user/lib64.
Thread beginning with comment 495522
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Comment by Jason Bourne
by sorpigal on Thu 3rd Nov 2011 11:34 UTC in reply to "RE: Comment by Jason Bourne"
sorpigal
Member since:
2005-11-02

A discussion on building a better FHS would be valuable, if that's what you want to talk aout. That's pretty off topic, of course.

Any imagined new FHS would have to account for both "desktop" and "server" use. If you're moving things around you might as well stick /sys under your /system or /os directories; then there's no reason you can't say /sys for your new /system.

You have to look at how things go together. You want the same FHS to apply during initramfs as the final system (that's just easier) and you want booting to work when some parts of the filesystem are stored on NFS or otherwise available late. You need to have a plan for what the system looks like from single user mode and how recovery is performed. One nice thing about a read only / of a minimal size is that you can be pretty sure it's never going to be corrupt, even if your fancy btrfs /var or /home is. What are the recommended partitioning schemes in your Better FHS design?

Where does /home/ go? Where do packages which install to one big directory go if there's no /opt/? How do you distinguish between base-system components, optional components provided by the distribution, and locally-installed components provided by the sysadmin? What about programs installed by regular users? What are your replacements for /usr/share, /usr/include, /usr/share/doc, /var/cache/, /var/lib/ and /etc/init.d/? What do you do with /mnt and /media? What do you do with /lib/firmware/ and /lib/modules/? Remember that these things probably shouldn't be mounted from NFS.

If you're improving things, what about defining more structure for /var and /tmp? In fact, take a look at http://www.osnews.com/thread?327769 where I asked some questions like these before.

Here's a thought experiment I did a few years ago:

/ - contains:
/local/
/system/
/mount/
/cfg/
/home/
/tmp/

/system/ - contains
-- /boot/ - files required to boot the system
--- /exe/ - copies of the programs executed during boot (statically linked?) so that /system/exe/ can be absent
-- /exe/ - symlinks to (or otherwise a collection of) all executables that a user or another process might be expected to run (non-internal, think public methods)
-- /lib/
--- one directory per package
---- any non-portable (arch-specific) files not needing to be writable at runtime. These may be .so or may be executables, or anything. Think private methods.
--- /all/ - symlinks to (or otherwise a collection of) all system libraries. LD_LIBRARY_PATH points here.
--- /system/ - ld-linux.so, libc, etc. Libraries not provided by packages.
-- /share/
--- one directory per package
---- any portable (not arch specific) files not needing to be writable at runtime
-- /data/
--- one directory per package
---- any non-temp files that will need to be written to during a program's run time
--- /<package>/run/ - lock files and named pipes
--- /<package>/lib/ - ?
--- /<package>/spool/ - write queues
--- /log/ - log files
---- /user/<username>/ - user's log files? Perhaps symlink back to ~/.sys/log/?
---- /<package>/
---- /system/ - log files for things that are basic and not part of another package. Kernel and what else?
---- NO log files in /log/ itself.
-- /kernel/ - kernel virtual fs mounts
--- /sys/
--- /proc/
--- /dev/ - device files


/local/ - contains
-- /lib/
--- one directory per package
--- /all/ - symlinks to (or otherwise a collection of) all locally installed non-system libraries. LD_LIBRARY_PATH points here.
--- as with /system/lib/, so here.
-- /share/
--- one directory per package
--- as with /system/share/, so here.
-- does NOT contain /data/. Runtime data is runtime data, regardless.

/cfg/ - contains
--- /<package>/ - one directory per package
--- /system/ - configuration files for things that are basic and not part of another package
---- /paths/ - directory containing files describing paths by name. This will make sense.
----- home - contains the string "/home/" by default. This is used when computing a user's home directory.
----- mount - contains the string "/mount/" by default
----- dev - contains the string "/kernel/dev/" by default
----- basically, the local admin can change the base name of system directories by altering these files. Woe betide you if you make a typo.


/home/ - contains
-- one directory per user
-- /<user>/
--- /.sys/ - hidden directory containing all files and the only files in the users home directory which the user does not create himself
---- /cfg/ - all userland app config files go under here, dotfile or no, subdir or no
----- /<package>/ - programs SHOULD store their config data in a subdir named after themselves, even if it's only one file
----- investigate fd.o ~/.local/ and see if it's worth duplicating
---- /mount/ - user mounted filesystems (remote or local). Perhaps system policy can lock users out of mount privileges unless it is under this directory.
----- /net/ - mirrors /mount/net/ in structure. User-mounted network locations.
----- /disk/ - non-network mounts
----- instead of /local/ the user's naming policy is to have symlinks called whatever the user likes pointing back to net or disk directly. I think this is OK.
---- /exe/ - user's executables. This directory is in the front of the user's PATH
---- /log/ - log files for user's processes
----- /<app>/ - one directory per application, internal structure is up to the app


/mount/ - contains
-- Perhaps by policy nothing will be mounted outside of /mount/ and /home/$user/.sys/mount/. I think using symlinks is sufficient to make this OK.
-- /net/ - network hosts sorted by host name
--- /<hostname>/
---- /<some_export_name>/
-- /local/ - directories for mounts named however the local sysadmin likes. In reality anything can be mounted anywhere as needed, but this is the correct location for transiant mounts. might be symlinks to ../disk/*/*. NOTE: not just local devices! Local naming policy. Policy may be *described* in /cfg/system/ somewhere, but here is where those named links are created in fact.
-- /disk/ - local disks sorted by disk name (as found in /dev/). If something is mounted anywhere it is ALSO mounted here
--- /cdrom0/ - for example, the first cdrom device (device file: /system/kernel/dev/cdrom0)
--- /floppy/ - for example, the first floppy (device file: /system/kernel/dev/floppy)


I eventually gave up on this approach. Remember, please, that it's all about what problems you're trying to solve (and that with the FHS you have to solve ALL PROBLEMS).

Reply Parent Score: 2

JAlexoid Member since:
2009-05-19

I'd also add that all non-system software should be split off, so that it does not "pollute" the system directories.
I know that the best software package management tools have been created to deal with the mess, but they should be able to add a good option of cleaning up the scattered data that software packages tend to leave behind.

Reply Parent Score: 2