Problems With UNIX Standards

[Primis]

It's an interesting thing to note that in the BSD world, /home is actually a symlink back to /usr/home. because according to the heir, ALL user files exist in /usr.
It's really nice because you can make it a separate drive or slice and just move it from version to version.

[SoulofDeity]

It's an interesting thing to note that in the BSD world, /home is actually a symlink back to /usr/home. because according to the heir, ALL user files exist in /usr.
It's really nice because you can make it a separate drive or slice and just move it from version to version.

Yeah. The older implementation of /usr was more practical in a lot of ways. A lot of the problems we have are caused by Unix-like systems going off and doing their own thing. eg. There used to be just 1 mount point (/mnt). To use the mount command, the user has to be in the wheel group. It's unsafe though to give everyone that amount of control over the system. A practical solution would have been to create a new group for people allowed to call 'mount'; but rather than doing that, people decided to add a new /media directory for removable storage. Then people decided that it was a jeenus idea to create speshal canonicalized mount-points like /media/cdrom. Another group of people is like, ooh! Nice!. But we're too friggin lazy to type '/media', so lets just toss them in the root directory. Now, we have like 4+ different mount-points that are entirely inconsistent across distributions. The FHS's view on this is pretty much, 'not my problem, pick a card'.

EDIT:
To clarify, after tesing many flavors of Linux, I've seen setups like "/cdrom, /media/cdrom, and /media/<username>/<disklabel>". There is no consistency, sometimes there's even a mix of 2 of these like on my current Ubuntu setup. The FHS quite literally tells you it's your own choice.

[Brynet-Inc]

It's an interesting thing to note that in the BSD world, /home is actually a symlink back to /usr/home. because according to the heir, ALL user files exist in /usr.

This is absolutely not true for OpenBSD or NetBSD.

/home is a separate partition (..or directory) outside of /usr

[Brynet-Inc]

There used to be just 1 mount point (/mnt). To use the mount command, the user has to be in the wheel group. It's unsafe though to give everyone that amount of control over the system.

The /mnt location has always been temporary convention, not enforced. You've always been able to mount a filesystem at any point in the hierarchy. In the early days of Unix, you generally weren't mounting much all but your local disk. BSD is where a lot of improvements in the Unix VFS occurred, dealing with network filesystems like NFS, and large disks which had to be further partitioned for operator convenience.

I remember a lot of early x86 Unixes had absolutely no support for non-Unix filesystems, it was common to use utilities like mtools to interoperate with your DOS partition and floppies. The ISO9660 CD filesystem was probably the first example of a removable media that people wanted to be able to mount and interact with, and it had some extensions that allowed for Unix permissions.

There are still a lot of people that don't run automounters, and systems like OpenBSD do not allow non-root users to mount filesystems without explicitly enabling it with sysctl(8).

[SoulofDeity]

There used to be just 1 mount point (/mnt). To use the mount command, the user has to be in the wheel group. It's unsafe though to give everyone that amount of control over the system.

The /mnt location has always been temporary convention, not enforced. You've always been able to mount a filesystem at any point in the hierarchy.

Of course this is true, but generally speaking, /mnt was the 'official' directory for user-mounted devices. It just pisses me off that people made a mess of the filing system over something that could've been fixed with about 2-3 lines of code in some configuration files.

Another common thing I keep seeing is people adding things to the root directory for early mounting. Now, I've personally never been into GNU/Linux OS development so take this lightly, but if you really need to have an environment that isn't ready yet then maybe you're using the wrong tool for the job. Imo, the only reason anything should be in the root directory is if it can optionally be stored on a separate volume.

[iansjack]

the only reason anything should be in the root directory is if it can optionally be stored on a separate volume.

Really!? Have you thought about that statement? Are you saying that, for example, /bin and /sbin shouldn't be in the root directory as they can't optionally be stored on a separate volume?

[Combuster]

They actually can. In your ramdisk.

[iansjack]

But initrd is a root filesystem, so not a separate volume from the root filesystem.

[Combuster]

So? It's still a separate volume from everything else on the real root. Besides the only thing an initial ramdisk needs to have is one binary - not even folders - that remounts to realroot, mounts all the other volumes into bin, sbin, usr, and everything else before executing init on the new root.

Mounts are meant to be transparent.

And even then, the kernel doesn't care about whether you call a folder sbin/ or foobar/. Those are userspace semantics.

[iansjack]

There is no such thing as the "real root". At the time that initrd is used that "other" (rather than "real") root isn't mounted, so it has no reality to the system. Without certain files in the current root the system can't boot. These files can't be stored on a separate volume to the one that contains the current root filesystem. The statement that "the only reason anything should be in the root directory is if it can optionally be stored on a separate volume" is as ridiculous as stating that "the traditional hosts file is just a DNS ip cache for the www". Both statements are uninformed nonsense that don't warrant further consideration.

[HoTT]

Yeah it was

Okay, it was.

[SoulofDeity]

There is no such thing as the "real root". At the time that initrd is used that "other" (rather than "real") root isn't mounted, so it has no reality to the system. Without certain files in the current root the system can't boot. These files can't be stored on a separate volume to the one that contains the current root filesystem. The statement that "the only reason anything should be in the root directory is if it can optionally be stored on a separate volume" is as ridiculous as stating that "the traditional hosts file is just a DNS ip cache for the www". Both statements are uninformed nonsense that don't warrant further consideration.

Yes, the files need to be there when the system boots up. This is why mounting time matters, and why distributions keep moving stuff to the root directory. Also, just because they have to be there when the system starts up doesn't mean they can't be remounted. In fact, I used to boot Gentoo off disc all the time. To do that, I had to remount several things before doing a chroot.

Also, we're past the networking thing. I said before that networking has never been my forte and that more experienced people (perhaps like yourself) might find that idea flat out ignorant. Hopefully you just missed that and aren't trying to invalidate everything I say simply because I don't know everything...

[iansjack]

If the files have to be there at boot time then they can't be on a volume separate from the root directory. (You can't mount other columes without having some program present to do the mount.) So I don't understand your comment that the only files that need to be in the root directory are those that can be stored on a separate volume. I would say the exact opposite was true.

Yes, we're past the network thing. I just used that example to emphasize your habit of making strange statements about Unix with an obvious lack of knowledge on the subject. I think you are doing the same here.

[SoulofDeity]

If the files have to be there at boot time then they can'be on a volume separate from the root directory. So I don't understand your comment that the only files that need to be in the root directory are those that can be stored on a separate volume. I would say the exact opposite was true.

There is a configuration file in the /etc directory that lets you configure specifically which devices get mounted where when the system boots up. I had my /boot, /home, /var, and /usr directories all mounted on separate volumes. My comment was an opinion; I don't like the idea of making the root directory a mess for no logical reason.

Yes, we're past the network thing. I just used that example to emphasize your habit of making strange statements about Unix with an obvious lack of knowledge on the subject. I think you are doing the same here.

So, you were trying to defame me. Well then. Oh, and "habit"? Have you read the topic title or first post? This entire thing is about people discussing ways in which Unix could be improved if you didn't have to worry about breaking standards.

[iansjack]

I still don't understand. If you need the "mount" command to mount other volumes how can you store that command (or a library implementing it as a system call, or an initialization program calling that system call) on a separate volume? I still don't understand the statement that "the only reason anything should be in the root directory is if it can optionally be stored on a separate volume". I just can't make any sense of that statement. Perhaps you could expound on the logic behind it.

I'm sorry that you think that my quoting your statements is tantamount to defamation. The remedy is obvious. I'm not worried about discussions about breaking standards; I just prefer that they be made based on an understanding of those standards. So if there is an obvious lack of understanding then I'm afraid I'm going to pick up on it. That's why I picked up the obvious incorrect statement about the hosts file and I'm now picking up the, to me equally incorrect, statement about the root directory. That's not defamation - it's just questioning statements that you have made.