by ckastner on 3/31/2022, 6:50:18 AM
by EdwardDiego on 3/31/2022, 7:05:26 AM
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.
by kasabali on 3/31/2022, 9:57:11 AM
> 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
by imrejonk on 3/31/2022, 6:49:55 AM
> 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
by jitl on 3/31/2022, 4:25:09 AM
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.
by deknos on 3/31/2022, 6:40:58 AM
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.
by Koiwai on 3/31/2022, 8:16:52 AM
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.
by amtamt on 3/31/2022, 8:16:48 PM
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.
by athrowaway3z on 3/31/2022, 6:56:47 AM
> 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.
by notriddle on 3/31/2022, 5:39:23 PM
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?
by kosolam on 3/31/2022, 7:38:34 AM
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…
by eternityforest on 3/31/2022, 5:31:50 AM
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!
by georgewsinger on 3/31/2022, 5:37:17 AM
> 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.
by sobkas on 4/1/2022, 1:20:38 PM
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/
by cosmiccatnap on 3/31/2022, 12:34:08 PM
Another hot piece on systemd basically from someone who does this more as an evengelical hobby than a 9 to 5
by KronisLV on 3/31/2022, 7:55:11 AM
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?
by nuvious on 3/31/2022, 6:48:12 PM
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.
by incomingpain on 3/31/2022, 12:41:38 PM
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.
This 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