I’m not saying those guys don’t know what they’re doing, obviously they are experts. But I would prefer to trust but verify (not just trust).
Thats not a trivial matter, its a potential source of many issues
There are really no perfect option here. Upstream and distro developers have different goals, and it's up to you to decide what you should adopt.
Forced updates every 6 months is annoying to most people. Forced updates every day or so would be annoying to basically everyone.
In particularly it was a significant improvement over the annoyances of Ubuntu, and I am still angry when thinking about the brief period I was maintaining a bunch of servers running Debian. Really unnecessarily difficult - particularly updating/upgrading and trying to clear the mess their systemd approach caused, in particular missing unit files for popular services (I think it was the isc-dhcp-server).
This is of course even worse if you are not the end-user but are trying to ship an appliance to your customers. Why would you want to update the entire appliance OS in the field fo all of your customers just to ship a security patch, instead of sticking with the same base OS on already released appliances?
Upgrade schedule for Fedora is twice a year, yes. Goes by without any issues, stuff still works.
There is change and then there is change. Yes, I understand that some things don't need to change, and why do they always have to. Do I need my Desktop to still resemble 3.11 because "Why did it ever change"? - No.
Some things in life simply change and they always have. I try to keep up where change is necessary.
And if I would be shipping appliances to customers, why should I have "forced updates" of any kind outside of my control? I would never sell anything without my own repos, quality control, etc.
Do you seriously sell Debian devices to anyone and support them, if anything outside of your control breaks? I seriously don't understand the argument.
And if I ship software of any kind that relies on some libraries, I have to maintain it, of course. This includes going with the major releases.
If this is embedded hardware, where there simply are only two or three updates in its lifetime, everything is different of course, but how on earth would I then have forced updates from RedHat??
Why are you afraid of updates then?
You aren't forced to update on Fedora. Fedora always supports current release n and n-1. There's even a window when n-2 is still supported after a new n is released.
Even then you aren't forced to update. I work with a guy still running Fedora 29. I wouldn't recommend that personally but his machine still works fine and is rock solid stable. Probably not the most secure though :-P
If I wanted an endless stream of new vulnerabilities I can just use upstream software.
IME, they do keep things fairly vanilla, and I speak as someone who has run Debian since . . . I wanna say 2002? Plus I've done kernel dev work, and Debian's kernel patches ain't nothing compared to what RedHat used to do.
The various RPM flavors keep their kernels vanilla enough that I can mostly just rebase on top of linux-stable, and it's been that way since I started 7 years ago (according to github).
Arch is the winner. I've never had to make a custom patch for Arch.
Disclaimer: I work for Red Hat but opinions are my own
No, they radically change things to match their standards. E.g. look at their tomcat package which explodes it all over the filesystem.
Without the latter, all you have is a burlap sack full of software. Hardly a distribution. Fine if that's what you want, but it's not what Debian is.
> I also think Debian's approach has shown itself to produce something less reliable on the whole
I think the opposite. Is there something particular you'd like to point to? I accept the SSH disaster. But that's 12 years ago now, and it is a single example.
Debian's patches to cdrecord introduced so many bugs that they eventually ended up driving the original author away from open source.
I think I remember something about the python 2 -> 3 transition being harder on Debian because of changes they've made?
The packaged Tomcat on Debian is so different that every time I've seen someone running Tomcat they've installed it manually instead.
Debian has essentially given up on packaging Hadoop. Some of their criticisms of its build process are certainly valid, but others seem to be an unreasonable expectation that everything will build exactly the way Debian expects. E.g. if I'm understanding correctly, they essentially take the position that they won't package anything built with Maven, on frankly spurious grounds.
Debian tends to end up with very outdated versions of anything from an ecosystem that uses large numbers of small libraries, or, basically, anything that isn't written in C or Perl. E.g. Python libraries are typically a long way out of date (even compared to other distributions), and Debian's package management tends to be less compatible with Python's built-in tools like pip than other distributions (e.g. Debian is more likely to rename a Python library, in my experience, which then breaks reverse-dependencies on that library or leads to having two incompatible copies of it installed). So people running Python programs on Debian tend to end up with either a difficult-to-manage mix of system and non-system dependencies, or multiple parallel installs of Python.
You could say that Debian offers a reliable platform and it's the users' fault for installing these unreliable things on top of it. But an OS exists to run applications, not the other way around, and I find that in practice Debian's approach means users are forced to step outside the managed parts of it much more than with other distributions, and it handles it less well when they do, making for setups that are less reliable in practice. Put it this way: the "add-on repository" culture is a lot stronger in Debian/Ubuntu than in other distributions, and I think that's actually a weakness rather than a strength.
That's not how I remember it. I remember distros (Debian and others) patching cdrecord, which resulted in the upstream author getting furious and re-licensing cdrecord under a non-free license to stop them. Of course the software was then forked, and the author indeed ragequit free software development. People can read more of the story here: https://en.wikipedia.org/wiki/Cdrtools#License_compatibility...
There's a reason stuff like this is named after Schilling: https://mako.cc/copyrighteous/award
> I think I remember something about the python 2 -> 3 transition being harder on Debian because of changes they've made?
No? There was no transition. 2 and 3 coexisted, 2 was recently removed.
> The packaged Tomcat on Debian is so different that every time I've seen someone running Tomcat they've installed it manually instead.
Different as in file layout?
> Debian has essentially given up on packaging Hadoop. Some of their criticisms of its build process are certainly valid, but others seem to be an unreasonable expectation that everything will build exactly the way Debian expects. E.g. if I'm understanding correctly, they essentially take the position that they won't package anything built with Maven, on frankly spurious grounds.
Hadoop is not buildable with non-bundled dependencies, as far as I understand. This violates Policy. We were discussing reliability – am I missing something here?
> Debian tends to end up with very outdated versions of anything from an ecosystem that uses large numbers of small libraries, or, basically, anything that isn't written in C or Perl. E.g. Python libraries are typically a long way out of date (even compared to other distributions),
Can you show some examples?
> and Debian's package management tends to be less compatible with Python's built-in tools like pip
This is just not true.
> than other distributions (e.g. Debian is more likely to rename a Python library, in my experience, which then breaks reverse-dependencies on that library or leads to having two incompatible copies of it installed)
The package names are often renamed, but not the Python modules.
> You could say that Debian offers a reliable platform and it's the users' fault for installing these unreliable things on top of it. But an OS exists to run applications, not the other way around
Python libraries are hardly applications.
> Put it this way: the "add-on repository" culture is a lot stronger in Debian/Ubuntu than in other distributions, and I think that's actually a weakness rather than a strength.
Add-on repos are frowned upon in Debian.
Right, because he was getting blamed for bugs introduced by those patches.
> Hadoop is not buildable with non-bundled dependencies, as far as I understand. This violates Policy. We were discussing reliability – am I missing something here?
Well, if you can't install programs you want to use, that's not reliable. My point is that in practice you end up with an awkward mix of system-managed and non-managed programs installed, because there's a lot that Debian is unwilling to package, and such a system becomes unreliable, particularly when those system-managed packages diverge from their upstreams.
> Python libraries are hardly applications.
No, but in the Python ecosystem it's normal for new versions of an application to require relatively up-to-date versions of a large number of small libraries. So the applications end up out very out of date. I think there was a post here not so long ago from the Debian side about how it's increasingly unsustainable to try to include programs from ecosystems with a small-library mentality in Debian.
> Add-on repos are frowned upon in Debian.
And yet I've seen far more of them being made for Debian than for other distributions.
why would that definition make any sense ?
I have never heard that definition of an operating system, but it seems that every university & place has its own so we're all speaking different languages anyways when using that word :-)
Does Debian actually change upstream significantly? I thought they kept things fairly vanilla.
I know Fedora patched in VAAPI support on Firefox before it was merged into the Mozilla codebase. I can’t think of a worse piece of software to patch, the last thing I want to be running untested code on is my web browser.