Interesting thread over at dyne.org

Originally Posted by lostintime These kinds of debates often are like watching Bugs Bunny and the aborigine yelling, "Unga bunga bunga," at each other (Bushy Hare, 1950).

Haha, I loved that cartoon. Possibly more like this cartoon.

Back on topic. It'll be interesting to see where corporate Linux takes us.

It'll be interesting to see where corporate Linux takes us.

I think that has already been decided. Both /usr merge and systemd have been embraced by most corporate IT admins. There are pockets of resistance but with virtualization and containerization nowadays requiring scalable automation and configuration management, the proverbial handwriting is on the wall and now more or less etched in stone.

To me a remaining question is whether upstream project maintainers will accept patches to support operating systems that do not abide by these foundations.

Originally Posted by lostintime I think that has already been decided.

Unga bunga.

... and other sad caveman noises.

Hello, good evening to all the slackers in the world. I'm not a developer or anything like that. I just like Linux slackware and installing and uninstalling packages. That doesn't stop me from giving a less technical opinion on the subject.

So my view of the systemd thing is that it's a movie that has been repeated over the decades. These companies only carry out these dirty scams because they have users and companies on their side. So from day to night they focus on what they want to do differently, from creating an unnecessary problem to selling a solution that only they have.

Political or capitalist issues aside. I think systemd and x11 will continue to exist, because there has been a market out there for x11 for over 30 years, and I don't see it disappearing lightly.

Obviously the number of users is smaller and they try to push the minority to their game, but I personally thank God that Pat had the best vision in the world regarding slackware.

Obviously, parts of systemd have to be implemented in slackware because Pat also knows that packages evolve, so if parts of systemd are necessary for the packages to work, they are already implemented.

I think that the warriors of the slackware world, developers and packagers, should not give systemd a break and should continue with the work they have done so far.

Now I make an appeal to people who have just arrived at Linux, and if they don't want to be swallowed up by systemd, choose the best distros. For domestic users this choice can be made and unmade, whereas in the business world this change is more complicated.

At least until there is a possibility of using x11 or systemd I will continue to support Pat and his excellent work with slackware.

A side note, obviously everyone knows the question, but instead of creating systemd they could very well help to improve x11 but obviously that is not the intention of the capitalists who have already infiltrated the linux world, but life it is evolution so this war between good and evil is not over. Everyone chooses what suits them best, but I hope that both alternatives continue to exist. And that freedom of choice remains in Linux. I've already made my choice since 2004 Slackware forever. I hope I didn't bother you with my non-technical opinion. Thanks

Originally Posted by hitest Haha, I loved that cartoon. Possibly more like this cartoon. Back on topic. It'll be interesting to see where corporate Linux takes us.

Sad to say but this is so me...

Funny thing to me about this topic, is that slackware had to go through the migration to the FHS (then called FSSTND?) since it predated it. So there was some significant rework done for slackware 1.1.1 to the packages and the package manager.

Originally Posted by volkerdi README.1.1.1 This is Slackware Linux 1.1.1. This version is not compatible with earlier releases of Slackware Linux, due to changes in the filesystem structure and the uids of standard users and gids of standard groups. It should be compatible with future releases, but installing over existing systems is still not going to be 'recommended' until I can get all the bugs out of it. There still are some.

It took some time to acknowledge that something we take for granted like upgrading was worth the trouble. It wasn't a good idea to upgrade across versions as things really could break bad. If there is one person to have chased how to comply with every standard that has pushed, it would be Pat.

Debian did not have to go through a transition like this. (did anyone else really?) For one, I don't think the debian distro was really being used in late '93, but second, to their credit, they were a proponent to push for a standard to clean up the filesystem hierarchy. Since then the spec has generally been followed as you've seen. There have been minor tweaks here and there, primarily renaming stuff, some specific subsystems migrations, but nothing that really affected the core system all at once, like forwarding /bin to somewhere else.

Reading what could be problems in using dpkg, it doesn't seem like they were ready for the merge? It's alot different today where there are 10000's packages, and how do you know to test them, and warnings about breaking things. It can't be that bad, now can it? Maybe the other distros that have gone through the merge took a harder break, and debian is trying to cater to everyone, and their own package managers way of doing things.

I can dimly remember one of these big transitions which took place around the time I started to use Linux. Linux had had its own libc for a while because of some disagreement with GNU about the way glibc was going. Then they decided to go back to it again. There was a weird update, a sort of fix-up with libc-6 being actually glibc with a different version number.

Did Slackware change then when everyone else did?

I actually like the usr-merge concept. IMO, it's a sensible simplification given that the distinction between /bin and /usr/bin means little these days. Whether it is worth the disruption of a migration is another matter, but if I were starting a new distro I'd follow this scheme.

I noticed that Fedora are now talking about a sbin -> bin migration now: I'm not in favour of that one as the distinction still has meaning (even if some things are sometimes placed in the wrong location).

One thing I don't like about the FHS is how they filled /usr/lib with subdirs of junk instead of using /usr/libexec. The neat-freak in me would rather the 'lib' dirs just contained libraries.

Originally Posted by hitest Not to mention no support for DRM streaming content(like Netflix) on the BSDs.

There's a workaround for that and it's called BitTorrent.

Originally Posted by GazL I actually like the usr-merge concept. IMO, it's a sensible simplification given that the distinction between /bin and /usr/bin means little these days. Whether it is worth the disruption of a migration is another matter, but if I were starting a new distro I'd follow this scheme. I noticed that Fedora are now talking about a sbin -> bin migration now: I'm not in favour of that one as the distinction still has meaning (even if some things are sometimes placed in the wrong location). ...

I was concerned usr-merge would cause me headaches at work where I use a debian based system, but I have to admit I haven't seen much. Of course, I'm not trying to maintain dpkg.

The thing with all these little changes is they always leave behind a blemish, at least as they are done in Linux userland. It's always only half forward thinking...

1. 32 -> 64 bit it's made sense perhaps for backwards compatibility that the adorned directory would be for the newer architecture. But when multiarch no longer is wanted by most anyone we're left with lib64 when all there is is "64". A blemish compared to a system like OpenBSD, which simply chose not to do multiarch, having the one lib directory the same across architectures. Not a huge deal, but one extra thing a slackbuild has to have a variable for, and a bit worse a way someone building vanilla to install to /usr/local can be caught with libraries chaotically landing in two different lib* directories, unless he knows to do what the slackbuilds do.

2. user merge as I've seen it on debian, as I recall, symlinks from /bin to /usr/bin. We've gotten as far as acknowledging that /usr was an artifact that stuck in the tech. culture and decided to eliminate the two places but not eliminate /usr. If you don't need the two places then the natural directory, ought it not be /bin? Then eventually -- crossing fingers -- the symlinks will disappear and it will be clean again. But the way it's gone it will be "clean" at /usr/bin with no /bin. Unless they can flip the direction of the symlink at some point.
(how this goes when you have a new system, few users, more of a clean slate: https://www.gnu.org/software/hurd/fa...r_symlink.html)

3. Following the above precedents, I can only suppose that if we get bin and sbin merged the symlink will somehow end up being from bin to sbin, with all our programs living in /usr/sbin.

Generally speaking, Linux both benefits and suffers from its popularity. I'll agree with hitest that BSD (in my case lately, NetBSD) hasn't the performance, or really the drivers, particularly for display cards, at least on the computer I'm using, so I'll keep partly using Linux. However, Linux cannot do "It doesn't work unless it's right" vs. "If it works, it's right" as NetBSD holds out as a goal, so I'll keep using that too.

Originally Posted by thirdm 1. 32 -> 64 bit it's made sense perhaps for backwards compatibility that the adorned directory would be for the newer architecture. But when multiarch no longer is wanted by most anyone we're left with lib64 when all there is is "64".

It's not that simple. A lot of proprietary printer drivers use 32-bit drivers, so you need 32-bit glibc even if you don't need full multiarch. Yes, you can use driverless printing if your printer supports it but a lot of old printers don't, and a lot of linux users use old kit. And what about all those people who play games on steam?

Originally Posted by BenCollver There's a workaround for that and it's called BitTorrent.

I like and use torrent clients, but, I want to be able to directly stream Netflix on my PC, TV, and any other device without any fuss. That's not happening with the BSDs.

Originally Posted by hazel It's not that simple. A lot of proprietary printer drivers use 32-bit drivers, so you need 32-bit glibc even if you don't need full multiarch. Yes, you can use driverless printing if your printer supports it but a lot of old printers don't, and a lot of linux users use old kit. And what about all those people who play games on steam?

I don't doubt there were individual requirements behind it. I'm not supposing the people who did it were fools. But like a lot of things in Linux, the cost of satisfying everyone's odd requirement (and linux everyone is much bigger than BSD everyone and way way bigger than Hurd everyone, who probably could all have drafts at the same pub, so the problem is harder for linux) for those who don't use proprietary software or have such printers is another of these annoying nits.

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.

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.

Why do we have /media when /mnt existed for exactly the same purpose?

Why do we have /run when we already had /proc and /sys?

Why do we have /run/media when we already had /media?

I can't make sense of any of these. And I agree that /lib64 is (yet another) abomination.

Mark

---
SlackwareCN: The Slackware Linux CN Community
slackwareCN：https://github.com/slackwarecn
slackwareCN：http://www.slackwarecn.cn
slackwareloong doc ：https://github.com/slackwarecn/slackbook_cn_loongarch64
slackwareloong web doc : https://slackwarecn.gitbook.io/slackbook_cn_loongarch64