about debian, a warning

zapper · 2024-10-30 15:45:50

I am curious to know, what will devuan do about this?

https://systemd.io/THE_CASE_FOR_THE_USR_MERGE/

I hear debian is doing this in the near future and this will cut off 32 bit support as well as other not so good things.

I learned about it from an unexpected place, but it seems to be true.

Thoughts for any of you?

Also here's something else:

https://wiki.debian.org/UsrMerge

golinux · 2024-10-30 16:08:46

What rock have you been hiding under, zapper? Devuan Excalibur will be merged and needs to be upgraded to "merged" in Daedalus before moving to Excalibur.

UsrMerge Status: Testing/Excalibur and more

blackhole · 2024-10-30 16:33:06

Old news maybe...

https://dev1galaxy.org/viewtopic.php?id=6435

Devuan are facing the scenarios pushed in the agenda driven systemd article above - i.e. they are forced to implement usrmerge, because Debian are on that route anyway and to not implement it would mean people, time and resources that the project doesn't have.

i386 arch removal is a separate thing, as far as I know.

https://lists.debian.org/debian-devel-a … 00003.html

It's most likely corporate driven though, at least partially. In the past, maintainers had no problem supporting obsolete architectures until they eventually ran out of steam - nowadays there is a corporate driven roadmap of planned obsolescence at play in the background. The corporations fund the Linux Foundation and the major distributions and set the goals and the general vision, as well as steering developers on what to / not to work on. Saying that, i386 can't last forever. AMD/Intel released their first amd64 arch CPUs in 2003/2004. If you have an x86 computer older than that (a roughly 20 year old machine), then it's likely you would have that computer for a specific purpose and would need to run an older release of whichever OS anyway.

Some of the arguments in systemd's usrmerge advocacy blog are valid, some are just laying it on too thick. If something is good, it should be adopted, if it isn't it should be avoided. No one started using Linux because its developers sat down and wrote long winded advocacy pieces, with myth and facts sections. This is yet another push for "standardisation" by the systemd project, an effort to draw lines between systemd/Linux and the alternatives, coerce distributions and other projects to follow suit, and leave those alternatives behind / playing catch up / struggling due to lack of developers and corporate funding.

EDX-0 · 2024-10-30 16:53:31

usrmerge is not the end of the world tho there are valid critiscisms on the way it is implemented, mainly that the decision was taken to just symlink the directories without consulting with the author of dpkg and how that impacted dpkg, as it may lead to some issues (big may, so far i have not experienced any but could) not to mention taking that decision the way it was taken put a lot more pressure on the dpkg author to figure a way to support the usrmerge scheme fast and without potentially impacting packages, tho a situation arose where packages built for usrmerge systems would not work on non usrmerge systems due to autotools resolving the destination paths in a different manner, personally i do see the benefit of the usrmerge as there is no longer a good reason to make the separation of the directories and it is more compatible with very legacy stuff that had binaries in the "wrong" directory for one reason or another.

Camtaf · 2024-10-30 18:00:43

I don't like it!

It isn't the 'unix way', those programs were kept separated for a reason, the root user only could access the system programs, which kept things safe.

Linux is becoming more & more like a proprietary system letting crackers/hackers easier access to damaging programs; maybe so that they can sell more antivirus software, who knows, but they are undermining a secure O/S by doing this...

So, the next edition of Devuan is to followi suit - thanks for the warning - I might have to start looking toward Slackware based distros.... that's a shame, because I have been an apt user nearly all my Linux time, it'll be awkward having to relearn a different package manager....or perhaps I'll just take the leap & go full time BSD.

Whatever I choose, I wish to thank the Devuan people for my time using it.

Ron · 2024-10-30 20:13:26

So I read/skimmed through the links, which really didn't tell me anything. Can somebody in layman's terms explain to me why usrmerge is bad?

stargate-sg1-cheyenne-mtn · 2024-10-30 22:43:09

sharing these commentaries so others can form their own opinions:

https://wiki.debian.org/UsrMerge
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#a-merged-usr-is-now-required
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://fedoraproject.org/wiki/Features/UsrMove

Understanding the bin, sbin, usr/bin , usr/sbin split - Rob Landley, 2010
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

golinux · 2024-10-31 01:18:15

@Camtaf . . . Another option to abandoning ship might be to roll up your sleeves and contribute to finding a way to turn things around. Just sayin' . . .

rolfie · 2024-10-31 07:57:49

Camtaf wrote:

It isn't the 'unix way', those programs were kept separated for a reason, the root user only could access the system programs, which kept things safe.

Have you read the post by Rob Landley? This split was done in the late seventies simply due to practical reasons namely space limitations of available storage media. There is nothing more behind it. It was a workaround and had nothing to do with what you call 'safety' or the Unix way.

This workaround finally is removed which I think makes sense nowadays with the size of media available today.

@Ron: is this summary something you can get?

blackhole · 2024-10-31 09:25:33

It isn't the 'unix way', those programs were kept separated for a reason, the root user only could access the system programs, which kept things safe.

I think you may confusing this with bin and sbin seperation.

This is about merging /lib, /lib64, /sbin and /bin into the directories of the same name under /usr

They would become symlinks and nothing more. It may do no harm, but I'm not sold on it being necessary. Historically those directories were in / because /usr may have been on a separate partition and therefore not available in certain circumstances. The rest of the maintenance related points are just "problem, reaction, solution" politics. The maintenance issue is one they have created by merging and are now proposing to solve in suggesting all others should do the same. And you can be sure it won't stop there...

systemd project are citing "compatibility" with other "Unixes" in particular Solaris, which they have absolutely never cared about before. Suddenly Solaris is the "primary Unix implimenation", the BSDs are never mentioned. Solaris has been in maintenance mode since the last release in 2018, it's future was in serious doubt since the aquisition by Oracle and when most of the developers were laid off in 2017. The references to Solaris is simply smoke and mirrors to coerce / convince the general Linux fans to spread the word, as they did with regard to systemd itself.

Last edited by blackhole (2024-10-31 13:11:38)

zapper · 2024-10-31 19:32:35

@golinux I saw no mention of this on this forum, so I thought I knew something most people here didn't.

I am glad someone is developing an alternative for x86 including 64 bit at least anyhow. Maybe other architectures will follow once they get stable support for their devices.

I am of course talking of HyperbolaBSD. (when its stable!)

If it gets up to snuff the way it should, perhaps Devuan will have another interface of interest if this corporate nonsense starts overtaking linux to the level of no return.

I doubt the point of no return has happened yet though, as devuan still exists.

steve_v · 2024-11-01 09:19:10

usrmerge is a filesystem layout change, not some kind of "corporate" conspiracy. It's not really necessary and it breaks a bunch of old assumptions, but it's far from the end of the world. It sure doesn't need a "warning" for anyone who hasn't been living in a cave for the past 5 years.
It also has nothing whatsoever to do with 32bit support or non-x86 architectures.

OTOH, the only thing not adopting merged /usr really breaks is systemd (and compatibility with systemd-based distros), largely because that sprawling behemoth of feature-creep apparently can't keep it's tentacles out of things traditionally found under /usr and not needed to bring the system up... But that's not exactly a surprising development.

Ron · 2024-11-01 21:54:15

rolfie wrote:

@Ron: is this summary something you can get?

The post by Rob Landley sums it up very nicely. So it seems like this change is no big deal.

stargate-sg1-cheyenne-mtn · 2024-11-02 06:59:07

while the change may ultimately be organizationally beneficial, it is still part and parcel of the "conformed_uniformity" drive by the microsoft/systemd/eee cheerleaders whose endgame is to consolidate and consume all the poor misguided *nix/*bsd/*etc stepchildren.

Embrace, extend, and extinguish. SystemD. Indeed.

embrace, extend, extinguish
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish

systemd
https://en.wikipedia.org/wiki/Systemd

indeed
https://www.youtube.com/watch?v=4alc7dIP8M8

zapper · 2024-11-02 17:57:01

@stargate-sg1-cheyenne-mtn

More like Embrace Extend Assimilate

EDX-0 · 2024-11-03 04:13:03

still the split to the /usr was something that happened due to technical limitations and turning the /usr sub directories into symlinks should have happened since the time that ext4 became a thing.

then again there are some interesting distros out there like gobo linux that don't even care about the "traditional" unix directory layout as gobo can install multiple concurrent versions of a program by having the program versions in their own directories and only symlink the latest libraries and program versions to the "canonical" file names and locations while the other versions may have their own library versions redirected inside their environment.

to explain it is similar to the mechanism that debian already uses with the linux kernel where you can have multiple kernel version and only the latest version installed is linked to the "canonical" location.

to give a more concrete example, gobo with multiple bash versions:

/Programs/bash/
/Programs/bash/5.2.32/usr/bin/bash
/Programs/bash/4.5.11/usr/bin/bash
/Programs/bash/4.0.2/usr/bin/bash

ls -l /usr/bin
/usr/bin -> /bin

ls -l /usr/bin/bash
/usr/bin/bash -> /Programs/bash/5.2.32/usr/bin/bash

which is not only a neat thing but may even be possible to do something similar with apt but that would probably require a fork of dpkg and a lot of scripting for the symlinks.

The officially official Devuan Forum!

#1 2024-10-30 15:45:50

about debian, a warning

#2 2024-10-30 16:08:46

Re: about debian, a warning

#3 2024-10-30 16:33:06

Re: about debian, a warning

#4 2024-10-30 16:53:31

Re: about debian, a warning

#5 2024-10-30 18:00:43

Re: about debian, a warning

#6 2024-10-30 20:13:26

Re: about debian, a warning

#7 2024-10-30 22:43:09

Re: about debian, a warning

#8 2024-10-31 01:18:15

Re: about debian, a warning

#9 2024-10-31 07:57:49

Re: about debian, a warning

#10 2024-10-31 09:25:33

Re: about debian, a warning

#11 2024-10-31 19:32:35

Re: about debian, a warning

#12 2024-11-01 09:19:10

Re: about debian, a warning

#13 2024-11-01 21:54:15

Re: about debian, a warning

#14 2024-11-02 06:59:07

Re: about debian, a warning

#15 2024-11-02 17:57:01

Re: about debian, a warning

#16 2024-11-03 04:13:03

Re: about debian, a warning

Board footer