in resumen> boot/ but fail agter the initialization of the initscript (but almos the kernel not have problem managin this...good begin)
]]>in my opinion
/
/boot
/etc
/sys
/proc
/mnt --> /media #For compatibility...but if noone is break and all are rebuildable againt /mnt withing break or a Dificult tansisitio can ignore the symlinking
/dev
/srv
/home
/home/root
/home/users/{users} #for managin a separate /home...or a /home/users
/usr
/usr/bin --> /bin
/usr/sbin --> /sbin
/usr/libs32 --> /lib
/usr/libs64 --> /lib64
/usr/var
/usr/var/run
/usr
/usr/include
/usr/share
/opt
is most probable that FHS (the standarisation of fs-hierarchi...) merge the /{{s}bin,lib,lib64} into /usr
]]>Putting the /home inside of /usr won't break anything. Just mount things sequentially. /usr is mounted, and then /usr/home is mounted as a separate partition inside of /usr. In btrfs, this could be a subvolume, in lvm it could be a separate logical volume. GPT solves the partition limitations.
Therefore since /usr and /usr/home are separate partitions, /usr can still keep it's "read-only" status.
As for /proc, /sys, I need more information on how they are used and prepared, but it should be possible to move those two partitions into /kernel. Doesn't seem like something hard to do.
]]>/
/boot
/etc
/kernel
/kernel/proc
/kernel/sys
/mnt - All mountable drives (including /media stuff. So /mnt and /media are now merged)
/dev
/srv
/home
/home/root
/home/{user}
/usr
/usr/bin -- merge bin and sbin
/usr/libs
/usr/libs/32 -- Any architecture libraries go inside a subdirectory of libs named after it's arch.
/usr/libs/64 -- ~
/usr/var
/usr/var/run
/usr/opt
/usr/include (or /usr/inc)
/usr/share (or /usr/shr)
Then /home is were your user data are, so this should probably not be mingled with /usr. And /var, /var/run are specific to one computer/host. So that should not be under /usr either.
]]>After analyzing the file system structure at the FHS website, and looking at Arch's currently layout, I came up with an improve layout (At least I believe it is easier, simpler, smaller, and better than what we currently have). The layout is for next generation computers, or current machines that can afford to make the switch (but don't have to/ convenient to though) GPT.
I emphasize GPT because you can then be unrestricted from the 4 prim or 3 prim/ 1 extended partition that MBR has. This gives you the benefit of maintaining the "read-only" /usr dir, but still put all relevant files in that dir to clean up things.
Using an initramfs is pretty much a standard nowadays for more advanced setups. But an initramfs is definitely something good since we can simplify a lot of the infrastructure.
This is the current layout:
/
/boot
/etc
/kernel
/kernel/proc
/kernel/sys
/mnt - All mountable drives (including /media stuff. So /mnt and /media are now merged)
/dev
/srv
/usr
/usr/bin
/usr/sbin
/usr/libs
/usr/libs/32 -- Any architecture libraries go inside a subdirectory of libs named after it's arch.
/usr/libs/64 -- ~
/usr/var
/usr/var/run
/usr/opt
/usr/home
/usr/home/root
/usr/include (or /usr/inc)
/usr/share (or /usr/shr)
That's the base layout, any dirs not mentioned are either considered to be the default dirs that are normally there, or will be implemented in a future "pondering" session (aka one of my "sit down and think" moments).
]]>You know how Ken Thompson and Dennis Ritchie created Unix on a PDP-7 in 1969? Well around 1971 they upgraded to a PDP-11 with a pair of RK05 disk packs (1.5 megabytes each) for storage.
When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!).
Of course they made rules about "when the system first boots, it has to come up enough to be able to mount the second disk on /usr, so don't put things like the mount command /usr/bin or we'll have a chicken and egg problem bringing the system up." Fairly straightforward. Also fairly specific to v6 unix of 35 years ago.
The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question why they're doing things. It stopped making any sense before Linux was ever invented, for multiple reasons:
Early system bringup is the provice of initrd and initramfs, which deals with the "this file is needed before that file" issues. We've already got a temporary system that boots the main system.
shared libraries (introduced by the Berkeley guys) prevent you from independently upgrading the /lib and /usr/bin parts. They two partitions have to match or they won't work. This wasn't the case in 1974, back then they had a certain level of independence because everything was statically linked.
Cheap retail hard drives passed the 100 megabyte mark around 1990, and partition resizing software showed up somewhere around there (partition magic 3.0 shipped in 1997).
Of course once the split existed, some people made other rules to justify it. Root was for the OS stuff you got from upstream and /usr was for your site-local files. Then / was for the stuff you got from AT&T and /usr was for the stuff that your distro like IBM AIX or Dec Ultrix or SGI Irix added to it, and /usr/local was for your specific installation's files. Then somebody decided /usr/local wasn't a good place to install new packages, so let's add /opt! I'm still waiting for /opt/local to show up...
Of course given 30 years to fester, this split made some interesting distro-specific rules show up and go away again, such as "/tmp is cleared between reboots but /usr/tmp isn't". (Of course on Ubuntu /usr/tmp doesn't exist and on Gentoo /usr/tmp is a symlink to /var/tmp which now has the "not cleared between reboots" rule. Yes all this predated tmpfs. It has to do with read-only root filesystems, /usr is always going to be read only in that case and /var is where your writable space is, / is _mostly_ read only except for bits of /etc which they tried to move to /var but really symlinking /etc to /var/etc happens more often than not...)
Standards bureaucracies like the Linux Foundation (which consumed the Free Standards Group in its' ever-growing accretion disk years ago) happily document and add to this sort of complexity without ever trying to understand why it was there in the first place. 'Ken and Dennis leaked their OS into the
equivalent of home because an RK05 disk pack on the PDP-11 was too small" goes whoosh over their heads.I'm pretty sure the busybox install just puts binaries wherever other versions of those binaries have historically gone. There's no actual REASON for any of it anymore. Personally, I symlink /bin /sbin and /lib to their /usr equivalents on systems I put together. Embedded guys try to understand and
simplify...
Is pacman ok with /bin, /sbin /lib being symlinks at present (not talking about future)? In that case isn't it just a matter of moving all the files from these dirs to the respective /usr/* dirs and creating the symlinks. This can be done manually by the user without issues. But automating this task without user intervention is tricky.
Be careful. Somethings in /bin or /lib have symlinks in /usr/bin or /usr/lib so you could either end up with a library or a symlink pointing at itself...
As mentioned in ML thread, any new software or update PKGBUILD(s) should configure with --bindir=/usr/bin --sbindir=/usr/sbin --libdir=/usr/lib
So... --prefix=/usr
]]>It could work, but from what I understand would require user interaction beyond simply upgrading (as automatically adding something to run in the initramfs is not something we would do). But I would not do it via pacman. A shell script would be enough...
Is pacman ok with /bin, /sbin /lib being symlinks at present (not talking about future)? In that case isn't it just a matter of moving all the files from these dirs to the respective /usr/* dirs and creating the symlinks. This can be done manually by the user without issues. But automating this task without user intervention is tricky.
As mentioned in ML thread, any new software or update PKGBUILD(s) should configure with --bindir=/usr/bin --sbindir=/usr/sbin --libdir=/usr/lib .
]]>