The Delusions of Debian
unixsheikh.comThis article is full of inaccuracies and errors.
> Due to the sheer size of the current Debian release it is infeasible for a small team to be able to audit all the packages, so there is a system of prioritizing packages which are more security sensitive.
This was, at best, poor communication. Of course nobody would ever audit all of 90,000 packages, easily billions of LOC. Especially not when the vast majority of these packages have a very small user base.
> The fact of the matter is that Debian has long been experiencing a decline in the amount of people willing to participate in the project.
The author is claiming an assertion of the fact. From a very recent thread "Is Debian sending people away" [1], there is no decline.
> Before that, Michael Larabel, the former leader had these ridicules points in focus for the future of Debian.
I don't know who they are, but they are not a former Debian Project Leader [2].
And so on.
[1] https://lists.debian.org/debian-project/2022/03/msg00037.htm...
[2] https://en.wikipedia.org/wiki/List_of_Debian_project_leaders
>> Before that, Michael Larabel, the former leader had these ridicules points in focus for the future of Debian.
>I don't know who they are, but they are not a former Debian Project Leader [2].
That one at least appears to be a brainfart by the author; they meant Sam Hartman. Michael Larabel is the author of the Phoronix article about Sam Hartman.
>> Due to the sheer size of the current Debian release it is infeasible for a small team to be able to audit all the packages, so there is a system of prioritizing packages which are more security sensitive.
> This was, at best, poor communication. Of course nobody would ever audit all of 90,000 packages, easily billions of LOC. Especially not when the vast majority of these packages have a very small user base.
How is that any different? It rather sounds like you've restated the same thing and then claimed the author's wrong.
I think OP is trying to suggest that you'd only audit the packages you actually use rather than all packages.
The author didn't state that. That's a direct quote from the Debian page, from the "Audit Scope" section.
That statement is entirely reasonable, yet the author frames this as the the point where "things begin to spin out of control!".
The author of this blog doesn't seem to like anything that happened in Linux after 2010.
Any time I see the domain, I know what I'm in for. But aside from "everything was fine the way it was", I've not seen the author ever present a better way forward when discussing how much they dislike systemd/Wayland/Gnome > some version, and now we can add Debian to the list.
I get it, having a rant is fun, but for your rant to be useful, especially when it's about FOSS projects, presenting a potential path forward is both an antidote to the incessant "bah humbug", and a way to maybe inspire the change you desire.
It is useful: it points out why one should stay away from Debian GNU/Linux. Sometimes, knowing what not to do is far more useful for making the correct choice.
Tearing down volunteer effort is fundamentally problematic. Yes, it’s important to not give anything flying under the banner of volunteer a free pass, but a huge project with decades of work and use like Debian is well beyond this. If you’re going to make criticism make it constructive or just move on with another distro.
Edit-The easiest way to make some points on the internet is just simple criticism. Doesn’t even have to be informed to come across as legitimate on the internet. Which is why internet blogs like this can do huge amounts of harm.
He was offering constructive criticism, the article concludes with specific recommendations for how they could improve and gives examples of projects that are doing a better job and could be emulated by debian.
> As of writing the Debian stable release has 96.729 packages in stable and 149.976 packages in unstable
That's a meaningless number because every distribution has different way of packaging things.
What should be counted is the number of source packages, because curl would still be counted as one package regardless of whether your distro split it into 8 (https://packages.debian.org/source/buster/curl) or 3 (https://archlinux.org/packages/core/x86_64/curl/)
Even when not doing a comparison between distributions (like when author complains about # of packages per # of LTS maintainers ) this is still the more meaningful count because package maintainers don't deal with every binary package separately, they deal with source packages.
As of today, Debian has 31306 source packages in stable and 34179 in unstable:
udd=> select count(source) from sources_uniq where release='sid';
count
-------
34179
udd=> select count(source) from sources_uniq where release='bullseye';
count
-------
31306> At the time when Debian 11 was about to be released, PHP 8.0 was 10 months old yet Debian's 11 was released with PHP 7.4. That makes PHP 7.4 the standard in Debian stable for at least 3 years after its release. But PHP 7.4 only gets upstream support until 28 Nov 2021 and security support is permanently ended at 28 Nov 2022, which is seven month from now. This means that unless Debian has some really good C developers, no one can provide any security fixes for PHP 7.4. Not only that, no one outside of Debian will be monitoring problems with PHP 7.4 because everyone else will long since have upgraded to PHP 8.
It’s a case of bad timing. Packages for PHP 8 were uploaded shortly before the bullseye freeze, which didn’t sit well with the release managers. See bug #976811 [1]. The maintainer also mentions in that bug thread that Microsoft will provide security fixes for PHP 7.4 after the EOL date.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976811
A common misconception is that just because an upstream released some time before a distribution release, the distribution ought to have had enough time to update, and a failure to update is a failure on the part of the distribution.
But it doesn't work like that. Packages have reverse dependencies. Just updating PHP to 8.0 would have broken all reverse dependencies that didn't already support PHP 8.0. So it isn't just a case of shipping the newer version of PHP; all upstreams of reverse dependencies need to have shipped updated versions, too, and all of those need to have had their packaging updated.
In practice distributions patch support in to laggard reverse dependencies or even remove them to speed things up. But still, the actual work involved is much more than the naivety in the statement "PHP 8.0 was 10 months old yet Debian's 11 was released with PHP 7.4."
A second common misconception is that just because an upstream declares some kind of support period, distributions have to follow them or it's somehow a problem if they do not. Upstreams even having a declared support period is the exception, not the norm. Distributions have been declaring a support period for their release as a whole long before some upstreams started doing this.
This is exactly why people pay for enterprise Linux distributions.
PHP 8.0 would only have been able if for example Zabbix would have been dropped as the version that comes with Debian 11 does not work with PHP 8.0 anyway
I worry about Debian’s future. The infrastructure of the project is slow moving and baroque. Not many people want to learn it to become maintainers. Michael Stapelberg’s blog post about leaving Debian describes the general issue of using tooling and process with 1994 leverage to tackle problems with 2022 scale, does not sound fun: https://michael.stapelberg.ch/posts/2019-03-10-debian-windin...
I tried to get into Debian package ownership while a student, but came to realize I would need a substantial financial incentive to interact with Debian’s machinery. I spent a while running FreeBSD after that.
Some of these issues are well known in Debian and being addressed; https://salsa.debian.org/debian/grow-your-ideas/-/issues
I spent a couple minutes poking around in here and saw mostly incremental ideas and not much momentum. Still I hope this effort is successful. The switch to Gitlab seems like a boon already.
Any idea what’s keeping it from doing a revamp?
I think there's a lot of naivety around understanding what a distribution does and why they do things the way they do. This article is full of that. And yet, most people in the ecosystem depend on the product.
In other words, I'm questioning whether a revamp is needed at all (as opposed to incremental improvements which are happening all the time). This article might be making some claims in that direction, but has had most of its points debunked in this HN thread already.
and in other news, some new opinions from the peanut gallery.
i am not involved in the debian project, but there seem to be quite a lot of people who know "what's best". Funnily most of them are not involved in building the stuff. and he shits on reddit comments but also does quite the same. i guess it's because they did not share his opinion.
Making OSes or browsers you are in a market share competition whether you like it or not because that dictates a lot about changes to how the environment deals with you in the future. One can ignore the least engaged/satisfied/likely-to-contribute users and their perceptions at one's peril.
At least I agree to some of his points, let's look at an example:
https://tracker.debian.org/pkg/samba
current stable at 4.13.13, accepted 2022-02-13
current testing/unstable at 4.13.14, accepted 2021-11-12
https://www.samba.org/samba/history/
current stable 4.16.0 released 21 March 2022
older stable 4.13.17 security release dated 31 January 2022
I don't want to point fingers at anyone but look at those version numbers and dates.
I'm pretty much an arch(and sometimes alpine) guy now, except some proxmox servers, which unfortunately is debian based.
Debian project has been a blessing to me personally.
For a daily driver always buy a ThinkPad, a year old model when new stable comes out, and use it as long as possible.
For servers, run the latest stable with minimal packages from main and occasionally few from backports.
Build from source/ download from upstream where Debian packages are available (specially browsers).
Reliable kernel, coreutils, vim and gcc from Debian stable, git + ooenssh from backports, tmux built from source, golang and "go get xyz" is mostly what I need. (I understand this can be too minimalist for many, but works for me).
I have a hobby website using fossil, running on 8year old SBC running bullseye.
At work, almost all bullseye docker images on minimal Bullseye running Dockerd. PostgreSQL, Redis, and few more central piece of software work fine with Debian.
Low maintenance, reliable systems that I seek, and Debian has never failed me.
Ahh and yes, when I need bleeding age, Arch is what I go to, but won't be running a daily driver machine or server on it. It's too fast for me to keep pace with.
I can safely say I have more peace of mind with free Debian than any paid OS I used (taken together with application ecosystem). All systems have their own pros and cons. I just picked what worked best for me, I am thankful for that and wish Debian project never runs out of great people.
> Yet Void is also suffering from a lack of maintainers, just like Debian, and as a result, many third party packages in Void Linux is hopelessly outdated.
On a tangent, i've been using Void for a couple of years now and i'm very happy with it. All the packages i want are up to date ( and i do not require LTS or backported security fixes ).
Things like runit and xbps-src are relatively simple. I can htop and know why every process was started.
Maybe I'd just reached the right level of skill to 'get' it once i switched, but i never had the feeling i was in control with other systems such as systemd and apt.
I'm happy with void for 7 years now, and used to contribute. You're right, xbps is much easier than other package managers (looking at you, dpkg!). The templates are even a tiny bit simpler than the equivalents of Arch.
If your marriage is ending over a toilet paper roll... it's not actually about the toilet paper roll.
It's the same deal with Debian and systemd. It's not the init system. It's the thing it represents. Having to either adopt systemd or run GNOME in an unsupported configuration seems like a clear-cut choice (which is why systemd is now the Debian default), but having a major upstream force you to significantly rearchitect the distribution seems like a pretty significant loss of control. This is at the same time as other upstreams have gradually ripped control out of the hands of Debian developers in other ways: Firefox, librsvg, and python-cryptography adopting Rust suddenly made it a lot harder to support a bunch of niche CPU architectures. Speaking of Rust, and also Go, they use static linking and have their own library package managers, which both makes it harder for Debian to package and simultaneously easier for users to install a binary directly provided by upstream. And languages that don't have static linking support can always use Docker.
Honesty, I wouldn't want to be a Debian developer right now. Red Hat has tried to reinvent themselves in a world of containers, but since Debian is a volunteer organization and not a corporation, it's a lot harder to pivot (attempting to pivot would probably cause all their existing volunteers to quit, while failing to attract new ones). What sort of future does Debian even have, if they have no decision-making power over the core OS, and all the applications route around them?
I would downvote you because:
1. "GNOME in unsupported configuration" is, with due respect, FUD.
2. There was no dichotomous choice to make. Debian could have let you decide whether or not to install systemd. Instead, the project decided to essentially force the use of systemd, necessitating a fork.
3. "suddenly made it a lot harder to support a bunch of niche CPU architectures" <- why is it difficult to offer a different selection of potential default browsers, on those niche platforms or in general?
4. Language-related package manager do make things difficult for an OS distribution, at least somewhat - but that's not particular to Debian.
However - I actually agree with your main point. I'm sure Debian maintainers/developers have it hard.
I really wish Debian would:
1. Admit the Devuan people were right and re-merge the distributions.
2. Recruit, offering a self-training track for aspiring package maintainers.
3. Modernize some of their tooling (as people seem to be complaining about that)
4. Fundraise effectively, to finance the above.
> 1. "GNOME in unsupported configuration" is, with due respect, FUD.
If GNOME doesn't work with Debian's systemd-shim, are they going to accept patches to fix it? Or will it be up to Debian to maintain those patches?
> 2. There was no dichotomous choice to make.
They didn't make a dichotomous choice. They made systemd the default, but maintained the ability to switch to another init system [1].
[1]: https://packages.debian.org/sid/init-system-helpers
> Debian could have let you decide whether or not to install systemd. Instead, the project decided to essentially force the use of systemd, necessitating a fork.
If this is "essentially forcing" the use of systemd, then what possible choice would have counted as not forcing it other than making sysv the default?
> 4. Language-related package manager do make things difficult for an OS distribution, at least somewhat - but that's not particular to Debian.
You're not wrong, but most Linux distributions either don't have "LTS" releases [2], or they have commercial backing.
[2]: Not having to backport security fixes saves them a lot of hassle.
> 1. Admit the Devuan people were right and re-merge the distributions.
Right about what? Devuan/Debian is hardly a comparable situation to LibreOffice/OpenOffice. It's more like the relationship between Librewolf and Firefox, where a bunch of loud fans are praising the fork to the sky, but most of the developers are still working on the original project and the "fork" is busy rebasing their patches onto each new upstream release.
> 2. Recruit, offering a self-training track for aspiring package maintainers.
That would be great, but are there volunteers lined out the door who want to join the program, and just can't? Or is it boring, frustrating work that few people are interested in?
> 3. Modernize some of their tooling (as people seem to be complaining about that)
I actually agree with this point, but I'm not sure if this is the primary problem, or if it's just a minor issue that distracts from the main problem.
> 4. Fundraise effectively, to finance the above.
There is no Debian Foundation. They would have to have somewhere to send the funds to, before they'd be able to collect it. Obviously, this is almost as contentious as systemd was [3].
> They made systemd the default, but maintained the ability to switch to another init system [1]
No, they didn't. You can't install debian without systemd. They _said_ they let you switch, but they don't. People did not fork an entire distro just because they didn't like to press "option B" instead of "option A".
> If this is "essentially forcing" the use of systemd, then what possible choice would have counted as not forcing it other than making sysv the default?
1. Not having packages depend on systemd.
2. Bringing up a prompt/dialog during installation to make a choice of whether or not to use it.
> most of the developers are still working on the original project
Because Devuan is just Debian with some tiny changes and a different choice of packages. And of course, the infrastructure of a project - website, forum, IRC, download servers, etc. So of course most developers aren't concerned with that, they just provide/maintain upstream packages.
> Obviously, this is almost as contentious as systemd was
I didn't know about this aspect, thank you.
> 1. Not having packages depend on systemd.
This implies either (a) refusing packages that depend on systemd, or (b) patching packages. Which brings us right back to the original problem: who's on the hook for making sure it works?
> 2. Bringing up a prompt/dialog during installation to make a choice of whether or not to use it.
https://www.joelonsoftware.com/2000/04/12/choices/
... okay, I admit I also need to offer a reason why it's okay for Debian to offer the install options that they do offer, while they also refuse to offer this option, and can't really come up with one. The way that Debian allows you to pick a desktop environment at install time, while not allowing you to pick an init system, is a bit of an arbitrary decision.
But the decision being arbitrary isn't a reason to offer every single theoretically possible option at install time. Debian never allowed you to pick an init system at install time before! Why start now?
> who's on the hook for making sure it works?
Well, Devuan people made it work, while also maintaining an entire distro fork. This could easily have been made to work on Debian. The alternative would have been to lean on GNOME, I think.
> every single theoretically possible option at install time
systemd-or-not is not "every single theoretically possible option". It is a highly contentious and political issue. If the systemd proponents would have accepted defaulting to no-systemd, then great, no need for the choice; but realistically, both sides are somewhat adamant, so making the user choose is a reasonable compromise IMHO.
> systemd-or-not is not "every single theoretically possible option"
Of course not. It's an arbitrary line, because the line has to be drawn somewhere.
> It is a highly contentious and political issue.
Most people don't care one way or the other.
> If the systemd proponents would have accepted defaulting to no-systemd, then great, no need for the choice; but realistically, both sides are somewhat adamant, so making the user choose is a reasonable compromise IMHO.
How is leaking internally-facing political issues into the out-of-the-box experience in any way acceptable?!
It's an almost perfect reflection of exactly the reason Joel On Software hates prompting people up-front with configuration options; by refusing to pick a reasonable default, the small number of people who actually care one way or the other are forcing everyone else to deal with their baggage. First-time Debian users completely lack the context to make such a choice, and anyone who does care knows where to look for information on how to switch over a system after it's installed.
> Of course not. It's an arbitrary line, because the line has to be drawn somewhere.
It's not a "line". Some choices are presented to the user, and some aren't.
> Most people don't care one way or the other.
If that were the case, then great - no-systemd by default.
No, the point is that the _people involved with the distribution_ care.
> How is leaking internally-facing political issues into the out-of-the-box experience in any way acceptable?!
Either people come to an agreement about a default; or they have a fight and split up; or they let the user decide.
... actually, there could be another option, which is a "mixed strategy", i.e. the installer flips a coin instead of asking the user. That could also be a compromise, which doesn't require bother the user. It has its own detriments though.
It’s a shame that after so many years and so many distributions the community could not come up with a good model for a low maintenance secure distro. IMHO the author of this post is surely the kind of people that eventually only care about their job security and just stir the water without making any progress…
"Low maintenance" and "Secure" are contradictory goals.
Maybe that’s the point of the author. But I completely disagree.
If programmers could write secure code from the start, then security updates wouldn't be needed.
Years of experience have shown that programmers can't write secure code from the start. Maybe some day we'll have languages & tools that allow for network-connected programs that never need security updates, but today is not that day.
Attackers often exploit vulnerabilities reasonably quickly, so updates have to happen soon after vulnerabilities are discovered.
So we need timely updates, and we keep needing updates. Unless we define "updating software" as not contributing to maintenance, I'd say my point stands.
The maintenance is made even harder for distributions like Debian that want to backport security fixes without backporting feature changes or other refactorings. That produces a lot of extra work for the maintainers, and those maintainers aren't usually as familiar with the code as the authors further increasing the maintenance burden.
I'm also worried about Debian's future.
Most of the big names who have left seem like it's a win all around, they seem to be anti-systemd hacker/tinkerer types who will be much happier over at Arch, and never really agreed with what Debian was trying to do.
But at a certain point, you just need more people for that many packages.
Perhaps they should try to transition away from the volunteer model. I wouldn't want to work at a distro if nobody was paying me, that seems like some of the very top unpleasant parts of tech work all it one job. And from what I hear, the Debian people are basically working a second full time job and some are not happy about the thankless drugery.
Either that, or the world should transition to Fedora. I'm sure they could get to Ubuntu's level of everything just works, if they had the whole Debian team helping!
> anti-systemd hacker/tinkerer types who will be much happier over at Arch
When you're anti-systemd, you won't be happier over at Arch, considering systemd is the only supported init system in Arch - in contrast to Debian, which supports alternatives.
I'm not exactly sure why Debian supports alternatives, that seems like a terrible idea when you're already stretched thin, but most everything else about it seems to be less tinkerer-friendly then Arch.
Seems like a lot more people can kind of grudgingly tolerate systemd, but they really seem to hate outdated packages, and anything "unnecessary"..
Some of them are pretty neutral on systemd itself, or have given up on fighting it.
They seem to mostly just want maximum ability to build their own system
> I'm not exactly sure why Debian supports alternatives
Debian has hurd and freebsd ports for which systemd is not available.
Supporting hurd and freebsd ports doesn't exactly seem like the best use of resouces for a smaller-than-google team either, but then again it might be important if losing those would also mean losing some key contributors.
> Either that, or the world should transition to Fedora.
So, instead of volunteering for Debian, volunteer for IBM?
I'm not sure anyone should volunteer for any of this at all, and most of these positions should be paid.
But that might be selection bias, maybe there's lots of happy distro maintainers that we just don't hear from.
> As of writing the Debian stable release has 96.729 packages in stable and 149.976 packages in unstable. That is a massive amount of software packages.
Does anyone know how this compares to other distros? In particular NixOS/nixpkgs is of interest.
The closest we have to a source of truth for that is the table on repology: https://repology.org/repositories/statistics
By that table, debian 12 has 32k packages, and nixpkgs stable has 67k
That said, repology doesn't track everything nixpkgs has nor everything debian has.
It's also difficult to compare debian and nixpkgs.
Debian has several packages for one thing where nixpkgs has only one, i.e. debian has "sqlite3, sqlite3-doc, libsqlite3-dev", while nixpkgs has the single "sqlite" package with the attributes "sqlite.bin, sqlite.dev" (and no docs split out I guess? They're probably in .out)
Because debian splits out dev packages from binary packages, that artificially inflates the number.
Another choice which makes the number very hard to compare is packaging style choices for certain dependencies.
For example, in debian, a go package's dependencies must all be packaged as their own packages (https://go-team.pages.debian.net/packaging.html#_dependencie...).
This leads to stuff like "golang-github-hashicorp-terraform-svchost-dev", a package that is only used as a library to build terraform. I'd argue it's not a user-facing package, just an implementation detail of the terraform package, but the count you mention above certainly includes it.
nixpkgs, on the other hand, is fine with not splitting out each dependency as a full package on its own right, so go and rust libraries are much more sparse in nixpkgs.
All of this is a lot of words to say "comparing numbers is hard, repology is the best we have right now"
Official repo [0] says more than 80,000.
Edit: it seems to be the largest software repo according to this (2020) [1].
[0] https://github.com/NixOS/nixpkgs [1] https://discourse.nixos.org/t/nixpkgs-has-been-the-largest-r...
I'm not on NixOS, but I do use Nix as a package manager on Debian and this is what I got:
Of course, it's important to note that Nix doesn't lag behind upstream as much as Debian. Actually, it's usually one of the first places where new versions of packages appear. So you don't have the problem such as the one Debian has with maintaining PHP 7.4.$ nix-env -qa | wc -l 39168Raw package count doesn't really compare, considering that Debian splits up packages a lot.
For example they have a lot of "-dbg", "-devel" and "-doc" packages that other distros might just choose to leave in the main package instead.
Debian have problems like this one: https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_...
Discussion on LWN: https://lwn.net/Articles/889026/
Another hot piece on systemd basically from someone who does this more as an evengelical hobby than a 9 to 5
To me, the tone of the article reads a bit dismissive and sometimes borders on a rant (e.g. i doubt that things related to inclusivity/social issues are to blame for the state of the OS), however it also feels like it concisely describes many important concerns.
> The fact of the matter is that Debian has long been experiencing a decline in the amount of people willing to participate in the project.
> Oh, I almost forgot. This is a list of the people assigned to the Debian LTS support team. 32 people who somehow must provide long term support for 90.000+ packages.
To me, these two feel like an unfortunate reality in the *nix world - there are more packages than anyone reasonably needs in the first place and hoping to get someone to maintain each of those packages is unrealistic. Many people might have written something that they needed to solve their particular problem at a certain point in time, used it for a while and eventually moved on, that is inevitable.
In my understanding, it's a bit like walking through a graveyard or at the very least some old library, where most of the books are largely irrelevant and won't be read by anyone in the following decade, short of very particular cases. For example, have a look at the Debian popularity context: https://popcon.debian.org/
Let's look at the install results for the main repository, open it up and scroll down a little: https://popcon.debian.org/main/by_inst
You'll see that only around 4'600 of the top packages have over 10'000 installs (by people who participate in the contest). Around 13'000 packages in total have over 1'000 installs. About 30'000 of the packages have over 100 installs.
That means that the majority of those packages aren't actually used by many people in the first place, thus don't present a juicy attack vector. That's not to say that they won't be exploited should any vulnerabilities remain, but surely the impact will be far lower and thus it's pretty reasonable to focus on the things that actually are popular.
Though one can and should definitely call this out and maybe consider what could even be done about this, since some people do need these packages for their niche use cases and perhaps are concerned with things working rather than being secure.
> Yet Void is also suffering from a lack of maintainers, just like Debian, and as a result, many third party packages in Void Linux is hopelessly outdated.
> Despite the fact that Red Hat is an enterprise Linux distribution, the problems goes even further there where you e.g. still can find a so-called LTS version of PHP 5 that long since should have been permanently terminated.
In my eyes, that just demonstrates the above - the people who need to use PHP 5 to support some legacy solution are probably aware that they should be using later versions, but it's just not in the cards for them. I once helped someone write new software in PHP 5 while PHP 7 was out at the time because even though i advised them against taking that approach, they didn't have other options, or at least viable ones. So, i wrote the software that they needed, left ample warnings and left to work on other things.
In practice, sadly LTS isn't always as much about remaining secure (even though it should be) as it is about keeping things vaguely working in slowly moving environments, which was one of the main reasons why people picked something like CentOS back in the day.
> On FreeBSD, the package manager informs you if you're installing a package that has been abandoned. It also informs you about important security issues. On the FreeBSD website the procedure is described in detail.
This is an excellent idea, as would be automated reminders about CVEs. Why should we only use external tools for scanning our servers, when they could do that themselves, at a package manager level?
> Keep a list of all the software you install.
Better yet: install less software. Nowadays my personal servers have a pretty minimal setup (sometimes with Ansible) with just the packages that i need to get containers up and running. Sure, some are against the idea of them at least in their current implementation, but they help me have a very clear distinction between what's a part of the system/infrastructure and what's the business software that i want to run - hence i should never install MySQL/MariaDB/PostgreSQL/PHP/Java/Ruby/Python/... on the system directly (okay, maybe Python for some scripts/CLI tools), but instead manage the attack surfaces with containers, which lets the old insecure stuff keep running, while updating the underlying system itself without worrying about breaking the software.
Of course, it's not perfect and virtualization still is useful for added isolation/security (multiple separate VMs/VPSes for different sets of containers) until rootless container runtimes will truly get there, but in my eyes it's streets ahead of pretending that we can somehow have our cake and eat it too - have software that is both up to date and works with limited resources.
I don't know about the circumstances that others are in, but in my homelab and even some professional projects i lean towards acknowledging out of date packages as an inevitable eventuality and thus thinking about how to limit the fallout until updates would eventually (hopefully) be done.
Back to the topic of Debian in general: it has always felt like one of the larger and more dependable distros out there, alongside Ubuntu and CentOS. With CentOS out of the picture and no popular replacements (both Rocky Linux and Alma Linux might take a few years until they're available in every regional VPS host), that choice now falls between Debian and Ubuntu: the former has a shorter life cycle (the LTS variety isn't entirely official) whereas the latter is pretty okay but has some weirdness going on (e.g. snaps and other curious decisions).
What is everyone else even using?
But OP is not blaming inclusivity or social issues for the state of the OS. They're simply questioning why inclusivity seems to get more space than e.g. efforts to try and bring more maintainers to Debian, or make the tooling and processes involved easier and less clunky.
> On FreeBSD, the package manager informs you if you're installing a package that has been abandoned. It also informs you about important security issues.
Debian has the package apt-listbugs
I may be naive, but don't we have automation handling a lot of the maintenance of packages and scanning for vulnerabilities these days? Of the 90k packages mentioned there's probably only a handful that have known CVE's and when they come up they probably just bump the version number in their CICD if a patch is available from the primary code maintainer and if not it's reasonable 32 people could manage that many packages depending on their CICD structure. Asking more than making an assertion btw.
Devuan is in rank 32 on distrowatch. What distros haven't moved to systemd at this point? I would appreciate a list so I never use them thanks.
How badass is Lennart Poettering? Dude just says alright I'm going to improve upon the craptacular init system. He follows through and the whole world starts using his software. That dude is a legend and he's only 41.
Devuan forked in 2015 and is basically a non-existent distro after 7 years. Systemd was never controversial as portrayed in this blog.
So what exactly is the delusion of Debian?
>But that's not all. The fact of the matter is that Debian has long been experiencing a decline in the amount of people willing to participate in the project.
There was another recent debian post on HN. No idea why Debian suddenly is so popular of a subject. People responded to me like as if Debian was doing fantastic.I just don't know how anyone can think Debian isn't in death spiral.
>Carter believes they need two to three times their current volunteer levels to accomplish all of their goals. He also feels Debian is too lacking in the area of diversity and not catching up fast enough. He blames Debian's diversity on large regions of the world not being represented enough, failing to put together a timely message regarding Black Lives Matter, and other concerns/ideas.
https://www.phoronix.net/image.php?id=2020&image=debian_prob...
Debian leadership thinks they don't have a strong position on black lives matter? That's why people are leaving the project?
So what have they done? They have built a diversity and inclusion plan.
They even enforce a anti-harassment team. https://wiki.debian.org/Teams/Community?action=show&redirect...
I encourage everyone to read that antiharassment page in depth.
As Debian leadership clearly indicated. They need significantly more people to contribute to the project, but they have an exodus/decline of developers. Clearly they are not doing enough with their antiharassment team.
People are harassing others at debian to such a huge degree the remaining volunteers are taking on ~3x the workload they should. Eventually they will quit as well.
I think what debian needs to urgently do... is figure out exactly who the harassers are. I very clearly can see exactly who is doing the harassment. If Debian makes a mistake and does not directly address this correctly. Debian is dead. Which is so sad to me.
>What distros haven't moved to systemd at this point?
The one that has the biggest impact on my life is Alpine, because I run postmarketOS on my phone which is an Alpine derivative. It has OpenRC instead, which doesn't have the ability to auto-restart crashed services (it doesn't do any action when a service crashes, by design), doesn't do socket activation, and doesn't support running as a user instance for a user session.
>The one that has the biggest impact on my life is Alpine, because I run postmarketOS on my phone which is an Alpine derivative.
Ok, that's a fair. My python projects refused to work on alpine so Ihavent tried it.