[Discuss] Debian 12 vs. WSL 1

[invalid at pizzashack.org (Derek Martin)]

On Fri, Jun 16, 2023 at 06:52:17PM -0400, Rich Pieri wrote:
> On Fri, 16 Jun 2023 16:41:21 -0500
> Derek Martin <invalid at pizzashack.org> wrote:
> 
> > I'm curious if this change is thought to have any genuine practical
> > benefit, or if it's just the usual, "I'm a bored developer, time to
> > break something completely arbitrarily, that's working perfectly fine,
> > that people have been used to for literally decades, that will likely
> > cause random obscure problems, simply because it does not uphold some
> > arbitrary idea I have of design perfection..."
> 
> Things haven't been working perfectly fine. Ever find NIS or LDAP login
> shells failing on some systems because BASH is /bin/bash on some of
> them while it's /usr/bin/bash on others?

No. A symlink solves that problem if it's a concern in your
environment--it never has been in any of mine, even with a mix of
SunOS, Solaris, HP-UX, and Linux machines.  And this is not actually
particularly different after the change, except that Debian is
providing those symlinks for you by default.  Most vendors provide a
means to automate both installs and post-install customizations; and
where and when they haven't, generally a shell script suffices, so for
the most part this doesn't need to be a concern. 

> Or have scripts fail to run properly because they can't find
> /usr/bin/df and /usr/bin/du because they're in /bin?

Personally?  No, never.  IMO well-written shell scripts that have to
live in such environments set their PATH to include the correct
locations to find things, and rely on the path to find the right ones.
I don't think I've ever written a shell script that used the full path
to a system utility, since I wrote my first one in 1994.  So long as
you ensure you don't have random, untrusted paths in PATH this is
fine.

Individual users I supported have, rarely, and the above was the
advice I gave when asked.  Couldn't have happened more than a handful
of times.  Never had anyone require a follow-up that I can recall...

Maybe there were issues when I was a college student, when the admins
were switching from Ultrix to OSF-1, and I was using Linux at home,
but... if so, nothing that wasn't more than a minor inconvenience that
was quickly and permanently dealt with.  Once I entered the
professional world (as a sysadmin) this problem has literally never
even been on my radar.  Perhaps maybe once every 5 years or so I had
to make a small modification to my PATH, but TBH only to add paths
that were environment-specific, i.e.  not any of the common well-known
ones.  Admittedly, it's been quite a while since I had sysadmin duties
for anyone other than myself...  But it's even less of an issue now,
since LSB and the general trend towards standardization.

> https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

Eh.  It's at best still only a partial solution to the problems you
described, because you still have things like /opt, /usr/local, or
whatever else local eccentric admins have dreamt up because they
could (is /usr/ucb still a thing? maybe that too).  You may not have
control over that, but if you live in such an environment you'd better
make sure your tools are robust enough to handle it.

> But what are the benefits of split usr?

The main benefit NOW is that it has been this way, so people expect
it to be this way, and by not changing it you avoid the risk of
arbitrarily breaking things that don't expect that, your WSL case for
example.  I'm fairly sure there won't be tons, but I'm about equally
sure that that one will not be unique.

There's also the problem that your link points out:

    [Not] implementing the /usr merge in your distribution will isolate
    it from upstream development. It will make porting of packages
    needlessly difficult, because packagers need to split up installed
    files into multiple directories and hard code different locations
    for tools; both will cause unnecessary incompatibilities. Several
    Linux distributions are agreeing with the benefits of the /usr
    merge and are already in the process to implement the /usr merge.
    This means that upstream projects will adapt quickly to the
    change, those making portability to your distribution harder.

Of course, if said development occurs on platforms that don't merge,
then it is those who have whom will have portability be "harder."

It basically requires everyone to get on board, causing a whole bunch
of arguably useless work, for what I still think is--not none at
all--but not a particularly compelling benefit.

I think the most interesting argument is sharing the OS, but I don't
find that particularly compelling either, and I can't even imagine why
I, as a user, would want that.  On my workstation the entirety of /bin
and /usr/bin is 540MB, which is insignificant compared to the 1TB SSD
it's on; and fast though networks have become, in the typical case my
SSD is still going to be faster.  Usually by a lot.


-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.