Debian 12 had aimed to have a merged “/usr” file-system layout similar to other Linux distributions, but The Debian Technical Committee earlier this year decided to impose a merged-/usr file movement moratorium. But now with Debian 12 having been out for a few months, that moratorium has been repealed.
In hoping to have the merged /usr layout ready in time for Debian 13 “Trixie”, yesterday that moratorium was repealed.
I love Debian’s bureaucratic processes and procedures. I imagine all the Debian people working in a giant nondescript grey building with very few windows, somewhere along a generic highway at the edge of a boring suburb of a forgetable town.
“the committee decided to repeal the moratorium” – can’t get more exciting than that!
“people working in a giant nondescript grey building with very few windows, somewhere along a generic highway at the edge of a boring suburb of a forgetable town”
That brings me to Snowcrash by Neal Stephenson, which contains a similar description of software engineering.
It alluded that was to be reminiscence to the M$, but we all might have been wrong here!
Debian is a bunch of greybeards pretending to have a bunch bureaucratic processes but actually doing whatever they want.
Their bureaucracy make them do the same things as other distributions do, but 10 years later.
I was about to reply in support of all the virtues of that approach. Then I remembered that I use a distro that ships things about 15 minutes after they are released. Too hypocritical, even for me.
I use Debian on some systems, and often grumble about how outdated certain stuff is. It’s part of the experience. If you’re not doing the same, you’re not Debian’ing right.
friedchicken,
Indeed, debian updates are slow under their stable branch. That’s by design of course, but it can be problem when you need a recent update and this has affected me on a few occasions. Shifting to the testing branch does have newer dependencies (while still being fairly stable anyway). But for production I usually only want one package to be updated while keeping the rest of the system at “stable”. Unfortunately it doesn’t work this way, you generally get all or nothing and that’s my biggest issue with the repos. Sometimes I manage this by compiling the sources of a package myself. Whether or works well or not depends on just how incompatible the upstream source is with debian stable dependencies. Without the repos to manage them you can open up the gates of “DLL hell”.
@Alfman
I usually opt for the testing or sid/unstable with a lean towards unstable. For me, it’s been pretty solid, with problems usually fixed quickly by them or myself. The thing I hate most is when I need to compile a more recent version of something, that depends on a more recent version of something that won’t compile without more recent versions of other things. That’s maddening and makes me wonder if I’m at the point of diminished returns by doing all the work somebody else already did on another distro. Debian and I have history though. It’s hard to walk away. hah