Interesting thread over at dyne.org

Originally Posted by thirdm At the risk of re-litigating past decisions, what I never understood was why the 32 bit libraries couldn't have been placed in a /lib32 directory with the native architecture getting the normal name.

Some distro's went with that scheme, and it's the one I've always preferred.

Originally Posted by GazL Some distro's went with that scheme, and it's the one I've always preferred.

That makes sense. Does anyone even use 32 bit hardware in 2024? I recycled my 32 bit Acer netbook years ago. I'm glad that we still have choices in the *nix world.

A separate /usr hierarchy is or was needed when /usr is a network share.

Does anyone here use such a configuration, or know of such a system still in use?

Originally Posted by commandlinegamer A separate /usr hierarchy is or was needed when /usr is a network share. Does anyone here use such a configuration, or know of such a system still in use?

I mount /usr as a separate partition (not a network share), but I have some systems which mount software directories from network shares. On such systems some other directory than /usr is used as amount point and some software resembling https://modules.readthedocs.io/en/latest/ is used to choose between different versions of different tools to put in your path.

As the /usr partition is rather big I prefer to have that directory on its own partition to avoid file system failures at something like an unclean shutdown. There are not much writings to directories below /usr so that makes that big partition rather unlikely to break.

regards Henrik

This falls into a recurring pattern of behavior on the part of newer developers and users, namely those that are huge fans of systemd. They never bothered to learn why the linux filesystem is structured the way that it is and decided that they can do it better.

While I could mention all the ways in which a dedicated /usr partition is useful, the MOTIVE behind this merge is to simplify the filesystem in order to create "easier" to deploy OS images. Instead of updating individual packages, they want to just roll out a new OS image. This is similar to the snap/flatpak idea, where the app includes whatever libs it needs (e.g. openssl) and manages its own updates.

The problem with this is that it actually has the opposite of the intended effect. Instead of updating openssl once, you update each snap package that has openssl. With immutable OS filesystems, you update the entire OS instead of just the library.

For me personally, I'm not a huge fan of learning this lesson in a production environment. But since my generation has no interest in learning the lessons of the past I guess we just have to wait for something big and important to come crashing down. The lesson will be learned one way or another...


I wonder if we could calculate the difference in power consumption for the different software delivery methods. Do immutable containers really scale as well as these people claim?

Originally Posted by rkelsen Surely you can see that Devuan's beef with systemd is not unjustified? They're proposing to remove support for sysvinit. That is a drastic change, and I'd say they're right to be mad about it.

I just saw this. I have to say while I do agree with much of your post, I don't think Devuan have any right to complain at all.

Devuan is a derivative project and like any derivative it exists only because 90% plus of the work in putting the distribution together is already done by the Debian project (who develop and maintain apt, dpkg, etc, etc). Devuan is not a fork, it is a small project focused on systemd removal from their own derivative of Debian, which is based on upstream Debian releases.

If Devuan don't like what Debian are doing, they really have the same choice as anyone else. From my point of view, basing their systemd-less distribution on one which is clearly going full systemd (the writing was on the wall from the start) was always a fool's errand. Devuan probably needs a new base for whatever it is they're doing. Other distributions have had to do that, for Devuan it's long overdue. Devuan are reluctant to do this, simply because they want the benefit of that upstream work and the huge array of pre-built binary packages, also supported by a dedicated security team - you can't have it both ways.

It would be like basing your OS on OpenBSD, then complaining on the mailing lists about some upstream change is making it harder for you - you know what the answer would be...

Originally Posted by _blackhole_ I just saw this. I have to say while I do agree with much of your post, I don't think Devuan have any right to complain at all.

Completely agree. I don't like many of Debian's choices, but if you ride the coattails of a parent distro then you don't get to complain about where they take you.

There are a lot of projects out there which fail to get off the ground. Devuan would be better off supporting, or pooling resources with, these rather than continuing as a bottom feeder, reliant on the Debian project, in turn mostly reliant in corporate sponsorship which is only invested in systemd et al. I believe systemd-less distributions should be mostly built that way from the ground up. If I'm going to start my own non systemd OS tomorrow I'm not going to choose a systemd Linux distribution as a base. They will claim Debian was about choice - exactly was - that hasn't been the case for years.

I gave up on Debian around 10 years ago and moved to Slackware when I realised in what direction it was heading and how toxic it had become (that was before the controversial systemd decision). Unfortunately I do have to use it at work (for now).

Devuan have opted for dependency on a hostile upstream and seem to expect accomodation and collaberation. Not going to happen. They only ever showed contempt to their users, Devuan don't have much hope of any better treatment.

Originally Posted by _blackhole_ I believe systemd-less distributions should be mostly built that way from the ground up. If I'm going to start my own non systemd OS tomorrow I'm not going to choose a systemd Linux distribution as a base.

My main OS is Void these days. I also manage my wife's Slackware Thinkpad. Void has been around since 2008. It is a robust, lean systemd-less distro which uses the runit init system. Void is not beholden to corporate donors, I like it a lot.

Originally Posted by USUARIONUEVO we can fight some time , like no pulse ..no pam ...

Those issues were fundamentally different, though.

PAM proposed to improve authentication and session management with an extensible framework, which was/is a very good idea, but it turns out that messing with the authentication subsystem where every component runs as root is likely to introduce security vulnerabilities. Which PAM then did, in spades. It made sense to wait at least until the dust had settled before embracing it. Today it pretty much works as advertised, and has been adopted by Slackware.

PulseAudio is an audio mixer built on the foundations of the Enlightened Sound Daemon, which made it possible for remote X applications to access a local sound server. Since the Linux kernel doesn't do sound mixing, it does make sense to have a separate sound daemon that all applications talk to, which in turn manages the actual sound hardware.

There's also the issue of modern PCs having multiple hot-pluggable inputs and outputs (which are all basically sound cards in their own right), and it would be nice if plugging in a USB or BlueTooth headset would somehow just work, like the 3.5mm jack plugs did in the old analogue days.

PulseAudio started out as a buggy, laggy (JACK exists for a reason) mess that didn't handle the above scenarios particularly well. It never really got fixed, and now we're being sold the idea that PipeWire will become what PulseAudio was supposed to be, and then some.

If we're lucky, we will have a fully functional, network-agnostic sound server by the time Wayland has killed the network-agnostic Window server.

Originally Posted by GazL Completely agree. I don't like many of Debian's choices, but if you ride the coattails of a parent distro then you don't get to complain about where they take you.

That is one way of looking at it.

Another perspective would be that the Debian project was hijacked by a group of individuals with an agenda that was fundamentally incompatible with the original vision of the project, and once they had successfully ousted their opponents, they kept doing their utmost to make life as difficult as possible for the new project started by their former colleagues.

But I agree that it was foolish to believe that Devuan could in any way use Debian as an upstream resource. Debian had already declared their hostile intentions.

It's a bit like the ongoing corporate takeover of the entire Linux project.

Devuan was not actually started by former Debian developers - that's a myth. Devuan was styled as a fork initiated by a group who referred to themselves as the "veteran unix admins" (VUAs). None of the developers who quit the project migrated to Devuan to my knowledge. As to the Debian project being "hijacked", that happened years before.

So admins, not developers and clearly unaware that "GNU's not UNIX" and that there are other OS about that are much closer to UNIX.

There are also Linux distributions like Slackware, but that might mean compiling some stuff from source...

The irony is that Devuan seemed to attract and cater to a lot of clueless people, especially those afraid of systemd, but not exactly sure why they're afraid of it and seemingly unable to cope with using a different package manager. These clueless people, dependent on this mysterious group, the VUA's, in turn dependent on the Debian project, seem to be the main following the distribution has.

Originally Posted by _blackhole_ There are also Linux distributions like Slackware, but that might mean compiling some stuff from source...

You certainly can compile stuff from source if you want; a full install of Slackware comes with a plethora of applications. Also the good people at SBo take the guess work out of compiling with their slackbuild scripts. I've used Slackware for 20 years and I don't have the need to compile a lot of stuff (I can if I wish though).

Originally Posted by _blackhole_ Devuan have opted for dependency on a hostile upstream and seem to expect accomodation and collaberation. Not going to happen. They only ever showed contempt to their users, Devuan don't have much hope of any better treatment.

Fair point.

Originally Posted by Ser Olmy PulseAudio started out as a buggy, laggy (JACK exists for a reason) mess that didn't handle the above scenarios particularly well. It never really got fixed, and now we're being sold the idea that PipeWire will become what PulseAudio was supposed to be, and then some.

Pulse is still a buggy, laggy mess, if you need realtime anything and audio. There's a reason why before pipewire people would just turn off pulse and run with jack. I've been using pipewire's implementation of jack for a good 6 months, and it does the job just fine.