[Discuss] Debian 12 vs. WSL 1

[Derek Martin]

On Fri, Jun 16, 2023 at 09:52:56PM -0400, Rich Pieri wrote:
> On Fri, 16 Jun 2023 19:07:19 -0500
> Derek Martin <invalid at pizzashack.org> wrote:
> 
> > 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
> 
> Adding custom symlinks to areas owned by the operating system is not a
> solution. 

Sure it is--when the point is to make things play nice in
heterogeneous environments that do things differently.  In homogenous
environments none of this would ever be necessary.  However it's also
been decreasingly necessary as time passed due to various standards
compliance already leading vendors to do things the same way.
 
> > particularly different after the change, except that Debian is
> > providing those symlinks for you by default.  Most vendors provide a
> 
> Kind of the opposite, really: most Linux distributions have either
> enforced merged usr (like Fedora and SuSE) or defaulted to it (like
> Ubuntu) for years.

But there was obviously a time when that wasn't true, and that's when
most of the cost was paid.  So not at all the opposite.  Just the past.

> Any thing provided by the OS vendors which removes the need for me and
> other sysadmins to maintain custom work is a worth-while improvement.

Obviously I disagree, particularly when the customizations are
basically trivial, one-time work.

> > > 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.
> 
> Well-written programs (not just scripts) use absolute paths to ensure
> that trojan binaries and libraries are not invoked by privileged
> processes.

I call BS.  I'll make it simple:

-----8K------
#!/bin/sh
PATH=/bin:/usr/bin
export PATH
du -sh /usr > /var/log/du_report
-----8K------

Demonstrate how you can subvert this as a non-root user (assume your
sysadmin/vendor/developer is not a moron), and we'll talk again.  Just
because you found a vendor who got it wrong doesn't mean it's a
problem.

For (for example) third-party commercial vendors who are providing
their own stuff, which needs to invoke their own stuff, and doesn't
know where you will install it, sure...  it makes some sense to use an
install process to hard-code paths to the ones relevant for their
stuff.  Otherwise, do the above.

> First is that "we've always done it this way so we must continue doing
> it this way". 'nuff said there.

That's not what I said--I've already corrected your previous similar
mischaracterization once, I'll do it again:  What I said was, only
change it if you can justify the work it causes everyone else.  I
don't think this does (well, did).

> Second is that the UsrMerge changes are entirely transparent to users
> and usually are transparent to sysadmins as well.

I noticed it when Ubuntu did it (it's been some years now, I don't
remember why I noticed), and you obviously did with WSL.  So not so
transparent, apparently.

> My Debian on bare metal and virtual machines all upgraded without
> problems. It's only the odd cases like how WSL1 locks the filesystem
> that need special handling.

ODD CASES MATTER.  They're usually the hardest to fix, and there are
always more of them than you expect.

FWIW it's not even this specific case that I have an issue with, it's
just one more in a class of things that got changed that caused people
pain for (IMO) very little actual practical benefit.  It's too common
a problem, not just with Linux/OSS, but especially so.

-- 
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.