Re: Aranym installation, was Re: Centris 650 Debian 10 SID Installation
On 6/21/19 7:36 AM, John Paul Adrian Glaubitz wrote:
> On 6/21/19 1:55 AM, userm57@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
>
Reply to: