On 6/21/19 7:36 AM, John Paul Adrian Glaubitz wrote: > On 6/21/19 1:55 AM, user...@yahoo.com wrote: >> It's neither right nor wrong for people to make assumptions based on >> their prior experience. The link that Adrian sent on a different thread >> regarding a separate /usr was instructive: >> >> https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ > > It's surely not wrong to make your own assumptions. But at least you should > give me a chance to explain the situation a bit. There are certain design > decisions that we cannot influence and there are certain issues that are > bugs that can be bugs. > > If you give me some time to look at the issue you are experiencing, I can > tell you whether this is "as expected" or you actually stumbled into a bug.
ok, thanks > >> I now understand that the latest trend is that a separate /usr is not >> recommended. And it's clear that most major Linux distributions have >> become dependent on systemd. That's neither good nor bad; the GPL will >> allow people to do whatever they want. I have to say that I was a >> little troubled by the supremely smug attitude in the above link. > > Well, is there actually a valid reason to have a separate /usr? I don't > see any. Yes, I think there are valid reasons, so we can disagree. On a production system, it makes sense to separate user files from system files, including system logs. So if user directories are in, for example, /usr/people, but there's only a single filesystem for everything, then users can fill up the filesystem, and then if there's a crash it can be difficult to figure out what happened because the filesystem filled up. In the old days, it was common in a security attack for a local non-privileged user to fill up the root filesystem and then proceed with escalation attacks, which then would not be logged (which is why /tmp should also not be on the root filesystem). This case can be addressed by having a separate filesystem for home directories, such as /home. A second case I can think of is if an administrator wants slightly different executables with the same names that behave differently whether called by a non-privileged user or root. In that case, these different executables can exist, for example, in /sbin and /usr/sbin, where /sbin is not readable by users but exists before /usr/sbin in root's path. A third case involves corrupted filesystems. If root is 2 GB and usr is 500 GB, and root becomes hopelessly corrupted, then only 2 GB needs to be restored instead of 502 GB. If usr becomes corrupted, then (ideally) single user mode with critical files such as dump and restore in /sbin can be used to restore usr without resorting to booting from an alternate partition or installation media. > >> But it's all good. There's an active community (and Linux >> distributions) that are still working to maintain sysvinit. > > This is not related to systemd vs. sysvinit. Of course it is. Entire distributions have forked over the disagreement in philosophy between systemd and sysvinit. > >> I won't rehash the systemd / sysvinit arguments here; it's clear the >> direction that most distributions are taking. People who want the >> older, simpler way, especially for older systems, or who like to >> maintain some compatibility with the BSD universe, will be able to find >> a way. > Forking hundreds of shell instances for doing simple things like string > substitution isn't efficient. It's a brain-dead design. Anyone who thinks > that sysvinit is the original Unix design has never used an original > Unix. sysvinit has always been a hack. > > And, FWIW, I recommend reading the "Unix Hater's Handbook" [1] for > anyone who is still convinced the "old traditional Unix way" (TM) > is the way to go. It isn't. Original Unix sucks. I have used HP-UX, > OSF/1 and old versions of Solaris and they are all horrible to use. Well, I've used IRIX, SunOS (Solaris) 4-7, ConvexOS and others, and they all had something similar to sysvinit (startup scripts based on run levels). All operating systems have their pros and cons. Regardless of how inefficient the startup scripts are, they don't run very often, so efficiency isn't that important. When I see systemd taking several minutes to do something relatively simple like adding swap, that doesn't strike me as particularly efficient, especially on older, slower systems. > > Adrian >
