> I think last time I had to go outside of the debian repo to get a binary or something.
Debian is certainly not the best option for those that depend on packages that change frequently. The fact that you got it to work 75% of the time is actually a positive surprise.
> In my opinion, most Debian's issues stem from a centralized imperative package manager where all packages need to be carefully kept in sync for things to work.
Hmm, in my opinion, this is good thing, not an issue needs to be solved.
> I understand that, but it means that debian inevitably distributes buggy software in a supposedly 'stable' distribution.
Bugs are a matter of perspective. If alleged bugfixes actually make you modify your currently working setup, then I don't consider that much of an actual bugfix, just something that makes me do work for no real benefit:
I like Debian stable. Two years is an entirely reasonable amount of time to be able to have most software in my OS immutable except for security fixes. For the tiny amount of software for which I may want the bleeding edge, there are language-specific "package" "managers" (lol npm) or I can just backport the software myself.
> but random strangers not being allowed to push updates to my operating system in 5.34 seconds doesn’t sound all bad. To me.
So that's what the frustrating to maintainers crumbling infrastructure and crappy tooling are for. Now it all makes sense!
Actually, I'd very much prefer quickly pushed updates in case of severe security issues. Debian had lots of really ancient packages with problems in "stable" last time I looked.
Ooooh! Awesome! Thank you for your great work, I'd have 2 big questions:
1. Do you have any visibility into when things should stabilize enough for a 1.0 release? 1 year? 5 years? Impossible to say?
2. And the be-all-end-all of Linux distro packaging, Debian. Any plans to include it into Debian? Usually when this happens the package propagates to many, many downstream distributions, such as Ubuntu & family.
> Developers can just publish their apps directly on their own schedule.
As a Debian user I do not see that as a feature, I see that as a risk.
One of the biggest reasons I use Debian is because package management is done the way it is, but a lot of people complain because the packages in Debian Stable are out of date. I think the disagreement here isn't on whether the software in Debian Stable is up to date, it's actually about what the definition of stable is. Many people prefer bleeding edge. For me, I prefer Debian's definition of stable, and I don't want the developers of the software being able to push it to my systems on a whim because on rare occasion developers have been known to use their users as their testers, and this is a risk I want to minimize.
Regarding your other points, could you expand a bit on decoupling the OS from the applications? Everything else sounds like it could be a feature request against apt, do you have a moment to file them? It sounds like you've got some good ideas.
> The main problem with Debian is outdated software.
I'm a Debian user. I see this a lot. Often in contrast with Ubuntu.
Yet Debian's cycle is roughly on par with Ubuntu's LTS - every ~2 years.[0]
Perhaps they mean there are interim releases in Ubuntu? It's hard to say for sure, as the phrase 'outdated software' can mean different things (more than 6 months old, more than 2 years old, in need of a security patch for > 1 week, etc).
> But for a regular desktop/workstation system I want more frequent software updates even if it comes at the cost of a little stability.
This sounds like you want Debian Testing (currently Trixie).
Much more frequent software updates, with an extremely small risk of less 'stability'.
> Switching to the Debian boxes always feels like stepping back 2yrs in a time machine, which has a high cost for a person who likes to keep up with progress in software development.
(emphasis mine)
It still feels like we're disagreeing because we have a different idea of what stable software is, yours is keeping up with progress in software development and mine is using software that's been tried and tested by many others first. If I may suggest, you may enjoy the Unstable or Testing Debian distributions the next time you're giving it a go, if you can get past the admittedly off-putting names.
But further, are you suggesting that you can't keep up with progress in software development from a Debian Stable box? With apt-pinning, backports, and having the ability compile from source into .deb files, I have to disagree with you on this.
> would you recommend that over a distribution focused on rolling releases, like Arch?
Everything about Debian except the `stable` repository is explicitly a rolling release.
> Debian strongly advises against mixing repositories
Certainly you wouldn't want to add in the other repositories if you're aiming for Debian Stable type guarantees.
This is the `sources.list` file that I've been using for nearly a decade:
deb http://deb.debian.org/debian/ testing main non-free contrib
deb http://deb.debian.org/debian/ unstable main non-free contrib
deb http://deb.debian.org/debian/ experimental main non-free contrib
And then I have a preferences file that prefers testing to unstable to experimental (actually three separate files in the preferences.d directory, but I'd think you could combine them.
It may not be advised, but it works pretty well. Sometimes you have to get a bit creative when you go to run `apt-get dist-upgrade` and it wants to delete half your system, but usually you can just manually install individual upgrades (`apt-get install <x>`) until it unwedges itself.
> What distributions have you been using? I rarely have a problem with Debian or Fedora in this manner.
Fedora and especially Arch are big offenders. Debian is so "stable" that I can't install newer software through the provided packages anyway, so that's trading off one failure over another.
> Get your package into Debian and Fedora...
If you stay inside the FOSS bubble, of course maybe some maintainer will eventually spend their precious time packaging some version of your application in some (sometimes broken) fashion. I don't think that's a good solution even for FOSS, but for non-FOSS it's not even on the table.
Debian stable is released roughly every 2 years. Once a release becomes oldstable, it gets LTS [0] support for at least 5 years, and Extended LTS [1] for another 5.
I think Debian is one of the easiest distros to plan ahead for.
> 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.
> But seriously, has anyone ever empirically verified that the Debian Stable/RHEL model of shipping a bunch of really old packages and then layering years of patches over top actually generates more stable, more secure code?
Debian has released a new stable version every 2 years for the last 14 years. RHEL/CentOS are the only ones on a 3-5 year cycle.
> Granted, I admit I mess around a bit with debian sources. I sometimes pin things, and often times pull packages from sid or unoffficial repos to get fresher versions.
> I can't say that's been my experience, once I figured out [dozens of moving parts]
That's the whole point. Nobody doubts that the Debian tooling works (it evidently does), but the learning curve to get to that point is massively steeper and longer.
Makepkg you can figure out in an hour, at most an afternoon for the finer details like custom patches; reliable Debian packaging takes days or weeks to understand set up.
Until it makes it into Debian stable repositories.
reply