| 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? |