"Self-contained" and "No bundled libraries" are two very important concepts that a subset of our ecosystem decided was too much work. Then they re-discovered all the problems that result, and have now coined terms like "software supply chain" to describe them.
Meanwhile Debian doesn't suffer from any of this because it's been doing things so as to avoid these issues all along.
If your goal is to consume software for which you need long term reliability, accepting software that bundles an unmaintainable (to you) set of dependencies does not make sense. Unless you have no better option [edit: or if you're paying to delegate your problems to someone else I suppose].
As a user, using software sources that make the same choices Debian makes is always preferable for you if that alternative is available.
> If your goal is to distribute software across multiple distros and operating systems, bundling dependencies makes sense.
Of course, an important "exception to the exception" is when you're making software that can easily be distributed by distributions, e.g. because it's end user software and open source.
I think the optimal cases for bundled dependencies are (a) large closed source binaries that never change, like games, and (b) self-deployed software, e.g. something like a server written in Go that is compiled and maintained in its running environment by a single developer or company.
Usually developer of application tests it only with a specific version of a library. If you use another version of library, you need to carefully test it and fix all found bugs and I am not sure if Debian has resources to do it. So we can assume that they simply use untested combinations of libraries and hope that everything will be ok (it won't).
As if this isn't an issue with fast-moving "let's bundle everything" upstream code drops either?
Distribution releases have the advantage that they have a large number of followers who share the same set of versions, and so can shake out the issues and fix the bugs together. In practice I think this beats what most upstreams that each pick their own sets of versions can achieve on their own.
It only takes one skilled engineer to fix any given issue in a given distribution release, even at today's scale. That's not a big burden, and is even available to those not skilled with a relatively inexpensive support contract.
Corporate upstreams additionally tend to focus on what matters to paying customers; other use cases can often receive a "not supported" answer. A community of followers operating on the same set of versions can address these use cases more easily, too.
The self-contained thing isn't always true either, for a long time the open firmware inherited from the linux-firmware repo wasn't built from source, we just shipped the binaries. I expect there are other cases in the archive too, Debian doesn't systematically strip generated files from all tarballs and regenerate them. Especially with more AI/ML stuff, where we probably can't even get the training data, let alone afford to train them.
Debian has a ton of embedded code copies, inherited from all our upstreams who bundle libraries for Windows/macOS/etc and also sometimes fork them etc.
Several open source software organizations are remarkable. Not little remarkable, big remarkable. As in they show us how alternative models to the typical corporate business model may well be far superior as a way for people to collaborate. For the most part these remarkable are unknown. I have used Debian for (ahem) a very long time without knowing much about the organization and this article was a very good introduction.
I have been aware of the IETF for quite a while. What is most amazing is that the internet today was built (more-or-less) by the IETF. See The Tao of IETF (https://www.ietf.org/about/participate/tao/). This is an organization with no members. It just works. Hardly anyone really knows about it.
Just as interesting is what happened when the corporate world decided to compete with the IETF for control of how the internet worked. Some people call this the protocol wars. (https://en.wikipedia.org/wiki/Protocol_Wars). For a while it seemed like each month the OSI would announce a project to replace parts of the internet, like TCP, with an X.protocol. Of these efforts very few survived and thrived - like X.509.
The question that comes to my mind is whether these kind of democratic type collaborative organizations are in fact superior (far superior?) to the traditional corporate model. I personally have watched many corporations act with obvious stupidity. Doing things that can only be described as severely fight-their-way-out-of-a-paper-bag challenged. To put it kindly.
Certainly these other-style organizations do not really stack up on an economic basis. The income of most corporations dwarfs that of both the IETF and Debian. And yet as a contributor and creator, I can ask Cuo Bono? Certainly not the contributors, they subsist.
And perhaps most interesting to me, and perhaps worth an experiment, is whether it is possible to use an IETF or Debian style model that competes with the corporate model. It did work once with the Protocol Wars, so maybe.
> Just as interesting is what happened when the corporate world decided to compete with the IETF for control of how the internet worked. Some people call this the protocol wars. (https://en.wikipedia.org/wiki/Protocol_Wars). For a while it seemed like each month the OSI would announce a project to replace parts of the internet, like TCP, with an X.protocol. Of these efforts very few survived and thrived - like X.509.
I would not describe it as 'corporate world decided to compete with IETF', than 'governments tried to enforce its power'. IETF working groups are often full of engineers from corporate vendors trying to collaborate to ensure interoperability, while ISO is traditional top-down governments-led organization.
You are correct. A better way to put it. And it is true that the IETF working groups are often from corporate vendors.
So perhaps that part of my argument is completely wrong. And distracts from the main question: could other fundamental models of collaboration be significantly more productive (efficient) than corporate models?
Yeah. I keep coming back to Debian after trying out another distro for a while.
There are some specific complaints I have about technical choices for Debian, like the way daemons autostart post install. But these complaints are outweighed by the benefits of using a distro with coherence across packages and upgrades.
Apt is also just such a phenomenal package manager. It is fast out of the box, and supports some relatively tricky scenarios—like using stable for your system, but a newer Nginx from backports. Feels like I can get the newer features for the one or two packages that I really care about, and then use something stable and boring for everything else.
I'm a Debian user since 1998 and have had it as my personal desktop since that time. I'd think that counts for something.
> Apt is also just such a phenomenal package manager. It is fast out of the box,
This wasn't always the case. There's a good reason almost all guides first written before 2015 specifically instructed everyone to use 'apt-get' directly. For quite some time the more uniform 'apt' frontend really wasn't intuitive or helpful. (Just to be clear: these days it is phenomenal in its simplicity and clarity.)
And as someone who has has to dive in to the package managers' code bases, the overall quality of libapt used to be .. questionable. Figuring out code and control flows back in 2010 was like trying to rub chili out of your eyes with an unsanded wooden spoon.
But the sheer bullheaded stubbornness Debian imposes on their package universe and its architecture means it's an absolute joy to work with if you're doing any kind of distro customisation work.
But it's a small issue compared to the mess I see in the rest of software these days ...
Alpine Linux seems interesting too, although right now Debian suits me well. I guess the problem is that I still don't make Debian packages myself, while Alpine's APKBUILD seems more approachable -- pure shell, while Debian has an array of tools and formats.
But Debian "lagging" a bit can be a feature, not necessarily a bug.
Same here, switched to Debian for my servers as OS from Ubuntu. Main reason: uses (boring & old) working technology. No more netplan, snapd, systemd-resolver.
What are you getting conflicts on? Unless you’re pulling from Sid, and did something fun like upgrading libc6, you shouldn’t see version conflicts if everything was installed via apt.
From the description, the Debian organization seems to be an anarchist one. A bunch of people, not coerced to be there, have created a diffuse rotating democracy for making decisions. Self-sufficiency is key to the organization, that emerges from thoughtful usage of resources.
> From the description, the Debian organization seems to be an anarchist one.
Then it mislead you. Anarchist organisations aren't typically characterised by large, long and complex sets of policies, constantly evolving, that are strongly policed. Often by bots.
I've been maintaining free software for 30 years so I've got a lot of experience with a lot of different tools, and I've rarely encountered anything that is as comprehensive and well-documented as all this stuff is.
This style of organisation is characteristic found in engineering organisations try to deliver high quality products, not anarchist organisations.
And while it's a flat(ish) style hierarchy, it has leaders (the DPL), a judiciary (the technical committee) and even behaviour police (whoever polices the conduct - it is policed).
Left out another major chunk: the conflict that arose over the eventual systemd adoption. To me that conflict altered the concept of ''What is Debian'' permanently, for better or worse (depending on who you listen to).
Regardless of whether one likes or dislikes systemd itself, I think that unfortunate debacle can only be seen as causing harm to the entire Debian project.
The politics of it certainly generated a lot of distrust and resentment among the users and contributors. The project's reputation was undoubtedly hurt.
Perhaps most importantly where the technological impacts. It's one thing when a user can generally ignore the politics surrounding a Linux distro, and the software still does what it needs to do. It's another matter when one routine update after another causes their computer(s) to no longer boot, among other serious problems, all thanks to systemd. Users definitely notice incidents like that, and it decreases, or even eliminates, their trust.
So much hard-earned and invaluable goodwill was unnecessarily lost during and after that period of time.
If any good did arise from that situation, it was that more people became aware of the BSDs, or tried them again if they'd used them in the past. FreeBSD and OpenBSD saved users who needed the reliability and trustworthiness that Debian used to offer, before systemd negatively affected the quality of Debian.
Yeah, it was annoying for a bit of time, but not anymore! I haven't had systemd installed in quite some time. sysvinit works without a hitch on bullseye and bookworm.
added:
Debian's (to me) about (among other things) technical superiority, a robust packaging system, as well as user freedom and choice. It's super easy to not use systemd these days, "what is debian" didn't change, there was just a slight delay in reality catching up to principles. :)
Your comment makes it sound like volunteers have a great degree of freedom and that's not the case because, obviously, in these organisations you will be shown the door if you don't do what others tell you to do.
Sometimes I daydream about getting a fuck-it amount of money.
During this thought process I always make a plan of what open source software project I should donate, and debian is always one of the first several candidates.
Now I just need the money! (meanwhile I donate to debian anyway)
Debian can't really directly pay contributors (there are some rare few cases like lawyers, etc....), so that would be one of the reasons for what the article is talking about.
The best thing someone could do in this scenario would to be hire someone to work on/improve Debian directly.
"We acknowledge that some of our users require the use of programs that don't conform to the Debian Free Software Guidelines. We have created "contrib" and "non-free" areas in our FTP archive for this software."
I had it running on a couple of my machines about 1 or 2 years ago and an update came in for WiFi that bricked them. I started looking into rolling back or whatever and just decided to switch those to Ubuntu (or Kubuntu actually) and they work great and have has no issues.
How are they "only tacitly" acknowledging it? Looks like they have put in very tangible solutions in place already.
Debian 12 even made a dedicated non-free-firmware repo for free software purists who would like to concede having non-free drivers just so they can use their hardware.
They've now relaxed their (stupid) policy so at least the default ISO includes non-free drivers.
When it comes to an already installed system, enabling the non-free repos and installing linux-firmware (or more specific firmware-* package for your hardware) should fix it.
If the default ISO already included non-free drivers, why would you have to separately enable the non-free repos to get firmware?
My Debian 12 install didn't come with proprietary Nvidia drivers, nor did it ask me if I wanted them during installation. I had to enable the non-free-firmware repo to get them.
I worked with Ian Murdock at Purdue in the days of the very first release. He was a sysadmin and devloper while I was a web designer for the libraries.
The guy truly believed in the GNU/Linux 'way' and 'free as in speech' software. His initial drive was from the difficulty of packaging and package management and that is probably his biggest contribution. Network-of-Workstations (NOW... think peer-to-peer infratsructure) was his passion that he really never quite got going.
Bruce Perens, the guy he handed control over to, is the authoritarian leader being refered to. I like the guy. He's definitely in the old guard, aka Linus Torvalds, style of management. In big complex projects with volunteers that syle works.
Anyways, the old days of Linux and Debian were a blast. I never quite go tinto like all these other people, but I miss those old days.
There's way too much money people involved today. So it goes.
Perens was fairly dictatorial. He also viewed the open source thing as more of a marketing tool than an ethos. That rubbed a lot of people in the groups the wrong way. He also was an effective project manager. Little column a, little column b.
I’m also interested by any source about that. I’m reading a lot about open source history and can’t find anything about that story (which seems quite important for those who want to understand Debian history)
He started his own company in Indiana called Progeny (https://en.wikipedia.org/wiki/Progeny_Linux_Systems). My old roomate ended up working there. That's were they tried to get network-of-workstations (NOW) going but it never really took off. That company sort of just ran out of steam (many linux companies did at that time)
After that, I heard he was CTO of Sun. At that point his marriage had fallen apart and his drinking had become a problem (I got all this second hand through mutual friends).
Everyone was shocked by the suicide and the events leading up. Seemed like he spiraled at the end.
With many other non-copyleft alternatives shaping up, and systems like ChromeOS and Android, with the Linux kernel and completely unrelated userspace, I firmly believe when our generation is gone, Linux won't stay around on its present form for much longer.
But neither Android nor ChromeOS are self hosting, in the sense that you can't use Android to build Android nor ChromeOS to build ChromeOS (well for the later maybe you could with a Debian container...)
So I think traditional Linux distributions will remain, at least as development tools.
Of course it is true that many end users these days get by with just a phone or a tablet but this is a general thing and also results in less Windows users too.
I wonder if the end-game is a BSD, or some sort of hard fork of the Linux ecosystem.
Ubuntu and RedHat basically don’t work by any of my definitions of “work”.
They’re both enterprisey and bloated and flaky in all the ways Windows was in the 90’s, except they add flatpack/snap, letting each program be its own flaky OS install, compounding the problem. Want to save a file to ~? Read this 1000 page tome on the 21 successors to SEL first.
Anyway, my current heuristic is that if it defaults to systemd or wayland, then I don’t want to use it.
Debian was never the default for big sprawling corporations, so it’s not clear to me that just staying on the “suckless ethos” side of such an ecosystem fork would be that bad vs. Linux in its previous heyday.
I still have fond memories of flame wars on alt.devil.bunnies and alt.pave.the.earth
It was a different world. Full of hope and wonder at this new thing. Remember the first major browser wasn't out until '94. We were all playing with Mosaic from the NCSA (which us Purdue kids got to have a small hand in).
Readit News
Meanwhile Debian doesn't suffer from any of this because it's been doing things so as to avoid these issues all along.
If your goal is to distribute software across multiple distros and operating systems, bundling dependencies makes sense.
If your goal is to maintain a distro, shared libraries that you can apply a security patch to exactly once is obviously better.
But these are two different people with either goal.
If your goal is to consume software for which you need long term reliability, accepting software that bundles an unmaintainable (to you) set of dependencies does not make sense. Unless you have no better option [edit: or if you're paying to delegate your problems to someone else I suppose].
As a user, using software sources that make the same choices Debian makes is always preferable for you if that alternative is available.
Of course, an important "exception to the exception" is when you're making software that can easily be distributed by distributions, e.g. because it's end user software and open source.
I think the optimal cases for bundled dependencies are (a) large closed source binaries that never change, like games, and (b) self-deployed software, e.g. something like a server written in Go that is compiled and maintained in its running environment by a single developer or company.
Except that it's clear that Debian is suffering from a manpower problem and has run into fundamental scaling limits with its current architecture.
Thus, we're seeing things like Nix and Silverblue at the OS level with Snaps and Flatpak at the application level.
I don't know what the solution is, but it seems to me like Debian is going to need to do something shortly.
Distribution releases have the advantage that they have a large number of followers who share the same set of versions, and so can shake out the issues and fix the bugs together. In practice I think this beats what most upstreams that each pick their own sets of versions can achieve on their own.
It only takes one skilled engineer to fix any given issue in a given distribution release, even at today's scale. That's not a big burden, and is even available to those not skilled with a relatively inexpensive support contract.
Corporate upstreams additionally tend to focus on what matters to paying customers; other use cases can often receive a "not supported" answer. A community of followers operating on the same set of versions can address these use cases more easily, too.
https://wiki.debian.org/EmbeddedCopies
I have been aware of the IETF for quite a while. What is most amazing is that the internet today was built (more-or-less) by the IETF. See The Tao of IETF (https://www.ietf.org/about/participate/tao/). This is an organization with no members. It just works. Hardly anyone really knows about it.
Just as interesting is what happened when the corporate world decided to compete with the IETF for control of how the internet worked. Some people call this the protocol wars. (https://en.wikipedia.org/wiki/Protocol_Wars). For a while it seemed like each month the OSI would announce a project to replace parts of the internet, like TCP, with an X.protocol. Of these efforts very few survived and thrived - like X.509.
The question that comes to my mind is whether these kind of democratic type collaborative organizations are in fact superior (far superior?) to the traditional corporate model. I personally have watched many corporations act with obvious stupidity. Doing things that can only be described as severely fight-their-way-out-of-a-paper-bag challenged. To put it kindly.
Certainly these other-style organizations do not really stack up on an economic basis. The income of most corporations dwarfs that of both the IETF and Debian. And yet as a contributor and creator, I can ask Cuo Bono? Certainly not the contributors, they subsist.
And perhaps most interesting to me, and perhaps worth an experiment, is whether it is possible to use an IETF or Debian style model that competes with the corporate model. It did work once with the Protocol Wars, so maybe.
(edit to remove markdown syntax, sigh)
I would not describe it as 'corporate world decided to compete with IETF', than 'governments tried to enforce its power'. IETF working groups are often full of engineers from corporate vendors trying to collaborate to ensure interoperability, while ISO is traditional top-down governments-led organization.
So perhaps that part of my argument is completely wrong. And distracts from the main question: could other fundamental models of collaboration be significantly more productive (efficient) than corporate models?
It grew on me after a long time. I always thought it was not the most "technically sound" way of doing things
i.e. I don't really like the packaging model of global updates where you don't know what's going on, and sometimes there are version conflicts
But I have come to appreciate the stability and good intentions of the Debian project
Sometimes it's not technical excellence that matters the most, but the purpose and goals of the project
There are some specific complaints I have about technical choices for Debian, like the way daemons autostart post install. But these complaints are outweighed by the benefits of using a distro with coherence across packages and upgrades.
Apt is also just such a phenomenal package manager. It is fast out of the box, and supports some relatively tricky scenarios—like using stable for your system, but a newer Nginx from backports. Feels like I can get the newer features for the one or two packages that I really care about, and then use something stable and boring for everything else.
> Apt is also just such a phenomenal package manager. It is fast out of the box,
This wasn't always the case. There's a good reason almost all guides first written before 2015 specifically instructed everyone to use 'apt-get' directly. For quite some time the more uniform 'apt' frontend really wasn't intuitive or helpful. (Just to be clear: these days it is phenomenal in its simplicity and clarity.)
And as someone who has has to dive in to the package managers' code bases, the overall quality of libapt used to be .. questionable. Figuring out code and control flows back in 2010 was like trying to rub chili out of your eyes with an unsanded wooden spoon.
But the sheer bullheaded stubbornness Debian imposes on their package universe and its architecture means it's an absolute joy to work with if you're doing any kind of distro customisation work.
But it's a small issue compared to the mess I see in the rest of software these days ...
Alpine Linux seems interesting too, although right now Debian suits me well. I guess the problem is that I still don't make Debian packages myself, while Alpine's APKBUILD seems more approachable -- pure shell, while Debian has an array of tools and formats.
But Debian "lagging" a bit can be a feature, not necessarily a bug.
This can be configured with service-policy.d(5), see https://packages.debian.org/bookworm/policy-rcd-declarative-... for example.
What are you getting conflicts on? Unless you’re pulling from Sid, and did something fun like upgrading libc6, you shouldn’t see version conflicts if everything was installed via apt.
Debian does have Conflicts package metadata - https://www.debian.org/doc/debian-policy/ch-relationships.ht...
So in theory I don't like it, but I now better understand the possible reasons for it, and I haven't run into it recently
I think there is room for other systems that don't have this problem, but Debian is good at what it does, and you can build other things on top of it
Then it mislead you. Anarchist organisations aren't typically characterised by large, long and complex sets of policies, constantly evolving, that are strongly policed. Often by bots.
This is the reaction from one software engineer that stumbled into Debian infrastructure: https://lists.debian.org/debian-devel/2023/09/msg00334.html
To quote one part of that email:
This style of organisation is characteristic found in engineering organisations try to deliver high quality products, not anarchist organisations.And while it's a flat(ish) style hierarchy, it has leaders (the DPL), a judiciary (the technical committee) and even behaviour police (whoever polices the conduct - it is policed).
The politics of it certainly generated a lot of distrust and resentment among the users and contributors. The project's reputation was undoubtedly hurt.
Perhaps most importantly where the technological impacts. It's one thing when a user can generally ignore the politics surrounding a Linux distro, and the software still does what it needs to do. It's another matter when one routine update after another causes their computer(s) to no longer boot, among other serious problems, all thanks to systemd. Users definitely notice incidents like that, and it decreases, or even eliminates, their trust.
So much hard-earned and invaluable goodwill was unnecessarily lost during and after that period of time.
If any good did arise from that situation, it was that more people became aware of the BSDs, or tried them again if they'd used them in the past. FreeBSD and OpenBSD saved users who needed the reliability and trustworthiness that Debian used to offer, before systemd negatively affected the quality of Debian.
added: Debian's (to me) about (among other things) technical superiority, a robust packaging system, as well as user freedom and choice. It's super easy to not use systemd these days, "what is debian" didn't change, there was just a slight delay in reality catching up to principles. :)
During this thought process I always make a plan of what open source software project I should donate, and debian is always one of the first several candidates.
Now I just need the money! (meanwhile I donate to debian anyway)
The best thing someone could do in this scenario would to be hire someone to work on/improve Debian directly.
https://www.reddit.com/r/debian/comments/paxj85/why_debian_w...
"We acknowledge that some of our users require the use of programs that don't conform to the Debian Free Software Guidelines. We have created "contrib" and "non-free" areas in our FTP archive for this software."
I had it running on a couple of my machines about 1 or 2 years ago and an update came in for WiFi that bricked them. I started looking into rolling back or whatever and just decided to switch those to Ubuntu (or Kubuntu actually) and they work great and have has no issues.
Debian 12 even made a dedicated non-free-firmware repo for free software purists who would like to concede having non-free drivers just so they can use their hardware.
When it comes to an already installed system, enabling the non-free repos and installing linux-firmware (or more specific firmware-* package for your hardware) should fix it.
My Debian 12 install didn't come with proprietary Nvidia drivers, nor did it ask me if I wanted them during installation. I had to enable the non-free-firmware repo to get them.
The guy truly believed in the GNU/Linux 'way' and 'free as in speech' software. His initial drive was from the difficulty of packaging and package management and that is probably his biggest contribution. Network-of-Workstations (NOW... think peer-to-peer infratsructure) was his passion that he really never quite got going.
Bruce Perens, the guy he handed control over to, is the authoritarian leader being refered to. I like the guy. He's definitely in the old guard, aka Linus Torvalds, style of management. In big complex projects with volunteers that syle works.
Anyways, the old days of Linux and Debian were a blast. I never quite go tinto like all these other people, but I miss those old days.
There's way too much money people involved today. So it goes.
Ian's manifesto explains it all, anyways.
https://www.debian.org/doc/manuals/project-history/manifesto...
After that, I heard he was CTO of Sun. At that point his marriage had fallen apart and his drinking had become a problem (I got all this second hand through mutual friends).
Everyone was shocked by the suicide and the events leading up. Seemed like he spiraled at the end.
So I think traditional Linux distributions will remain, at least as development tools.
Of course it is true that many end users these days get by with just a phone or a tablet but this is a general thing and also results in less Windows users too.
Ubuntu and RedHat basically don’t work by any of my definitions of “work”.
They’re both enterprisey and bloated and flaky in all the ways Windows was in the 90’s, except they add flatpack/snap, letting each program be its own flaky OS install, compounding the problem. Want to save a file to ~? Read this 1000 page tome on the 21 successors to SEL first.
Anyway, my current heuristic is that if it defaults to systemd or wayland, then I don’t want to use it.
Debian was never the default for big sprawling corporations, so it’s not clear to me that just staying on the “suckless ethos” side of such an ecosystem fork would be that bad vs. Linux in its previous heyday.
It was a different world. Full of hope and wonder at this new thing. Remember the first major browser wasn't out until '94. We were all playing with Mosaic from the NCSA (which us Purdue kids got to have a small hand in).
Deleted Comment