Insane effort. This sounded like a pipe dream just a couple of years ago. Congrats to everyone involved, especially to those who drove the effort.
replies(1):
I’ve said it many times and I’ll repeat it here - Debian will be one of the few Linux distros we have right now, that will still exist 100 years from now.
Yea, it’s not as modern in terms of versioning and risk compared to the likes of Arch, but that’s also a feature!
It'd certainly be nice, but if you've ever seen an organisation unravel it can happen with startling speed. I think the naive estimate is if you pick something at random it is half-way through its lifespan; so there isn't much call yet to say Debian will make it to 100.
I don't think traditional von Neumann architecture will even be around in 100 years, as energy demands drive more efficient designs for different classes of problems. =3
Then that's a good reason not to use Debian indeed. Whatever the distro you choose, you give your trust to its maintainers.
But that's also a feature: instead of trusting random code from the Internet, you can trust random code from the Internet that has been vetted by a group of maintainers you chose to trust. Which is a bit less random, I think?
This doesn't strike me as a strong argument. That naive estimate (in whatever form[0]) is typically based on not knowing anything else about the process you're looking at. We have lots of information about Debian and similar projects, and you can update your estimate (in a Bayesian fashion) when you know this. Given that Ian Murdock started Debian 31 years ago I think more than 100 years is a very reasonable guess.
[0] see e.g. https://en.wikipedia.org/wiki/Lindy_effect
If you ever want a laugh, one should read what Canonical puts the kids though for the role. One could get a job flying a plane with less paperwork...
Authenticated signed packaging is often a slow process, and some people do prefer rapid out-of-band pip/npm/cargo/go until something goes sideways... and no one knows who was responsible (or which machine/user is compromised.)
Not really random, but understandably slow given the task of reaching "stable" OS release involves hundreds of projects... =3
In a way, Flatpak/Snap/Docker was mitigations to support old programs on new systems, and old systems with updated software no longer compatible with the OS. Not an ideal solution, but a necessary one if folks also wanted to address the win/exe dominant long-term supported program versions.
If working with unpopular oddball stuff one notices the packages cycle out of the repositories rather regularly. =3
Best they can do is to follow developer's instructions to build a binary artefact and upload it somewhere. May be codify those instructions into a (hopefully) repeatable script like PKGBUILD.
The Lindy effect says nothing about popularity, which is how I translate your use of 'dethrone' here. It observes that something's duration of existence correlates with its chances for existence in the future.
I don't understand; isn't this exactly what maintainers do? They write a recipe (be it a PKGBUILD or something else) that builds (maybe after applying a few patches) a package that they then distribute.
Whether you use Arch or Debian, you trust that the maintainers don't inject malware into the binaries they ship. And you trust that the maintainers trust the packages they distribute. Most likely you don't personally check the PKGBUILD and the upstream project.
Yet, it's lasted 31 years, which is a pretty insane amount of time in tech. This on top of being kept up to date, good structure, really good contributions and advancements.
On the other hand, you look at centos, redhat, and oracle and their debacle. How much did they fragment that area.
And then we have Debian just chugging along.
Here's one of the recent examples: https://www.reddit.com/r/debian/comments/1cv30gu/debian_keep...
And that's applied to a lot of packages. Sometimes it leads to frustrated users who directly come to frustrated developers who have no idea what they're talking about, because developers did not intend software to be patched and built this way. Sometimes this leads straight to vulnerabilities. Sometimes this leads to unstable software, for example when maintainer "knows better" which libraries the software should link to.
They used an official build option to not ship a feature by default, and have another package that does enable all features. If that's your best example of
> Debian adds so much of their patches on top of original software, that the result is hardly resembles the original.
then I'm inclined to conclude that Debian is way more vanilla than I thought.
If an application requires a 3 page BS explanation about how to use a footgun without self-inflicted pwning... it seems like bad design for a posix environment.
People that attempt an escalation of coercion with admins usually get a ban at minimum. Deception, threats, and abuse will not help in most cases if the maintainer is properly trained.
https://www.youtube.com/watch?v=lITBGjNEp08
Have a nice day, =3
Worth noting lest I give the wrong impression, I don't think security is a reason to avoid Debian. For me the hacked up kernels and old packages have been much more the pain points, though I mostly stopped doing that work a few years ago. As a regular user (unless you're compiling lots of software yourself) it's a non-issue
Well yeah, but you choose the maintainers that do it the way you prefer. In your care you say you like Arch better, because they "patch less" (if I understand your feeling).
Still they do exactly what you describe they should do: write a recipe, build it and ship a binary. You can even go with Gentoo if you want to build (and possibly patch) yourself, which I personally like.
> Here's one of the recent examples: [...]
Doesn't seem like it supports your point: the very first comment on that Reddit threads explains what they did: they split one package into two packages. Again, if you're not happy with the way the Debian maintainers do it, you can go with another distro. Doesn't change the fact that if you use a distro (as opposed to building your own from scratch), then you rely on maintainers.
Once an OS is no longer actively supported, it will begin to accumulate known problems if the attack surface is large.
Thus, a legacy complex-monolith or Desktop host often rots quicker than a bag of avocados. =3