Yet it has functioned for 25 years (apt turned 25 this year). There has been mistakes, like the OpenSSL "fix", but not many. One issue that I, now that you mention Javascript, is stuff like npm, but to me that more a sign of npm being badly broken by design, or at least designed for a different environment. Build Python projects on Debian, using apt as you dependency manager works pretty well for systems that you expect to be stable over time.
One think so seems to forget is that you can often pull in newer versions of libraries and other packages from Backports. That does mitigate some of the issues with packages being to old.
Up to a point. Even 15 years ago the issues were clear and people were having to work around them.
> There has been mistakes, like the OpenSSL "fix", but not many.
That was the single worst bug in a general-purpose computer system IMO, and a predictable result of the Debian way of building packages. But they never felt the need to change their policies.
> Build Python projects on Debian, using apt as you dependency manager works pretty well
Python has notoriously terrible dependency management. It's a pretty low bar.
> One think so seems to forget is that you can often pull in newer versions of libraries and other packages from Backports. That does mitigate some of the issues with packages being to old.
The fact that there is such a big ecosystem of workarounds for linux distro packaging should tell you there's something fundamentally wrong with the basic idea.
That's subjective. In my mind it's the only one that makes any sort of sense and isn't a freaking nightmare to use.
I remember looking in apt for nodejs one time and the version it had was about 5 years out of date, and it was missing all sorts of quality of life features that I had long since taken for granted (like promises). And of course, half of the packages in npm failed to run at all as a result. It was a complete non starter. Maybe I should have searched apt for ancient versions of common JavaScript libraries from a similar vintage? Then I could install them system wide. Yay. And what would all that extra hassle get me? A JavaScript program that would only work on one crusty Linux distribution. Which is strictly worse than what nodejs ships with out of the box: npm. Up to date packages. Modern JavaScript. And compatibility a mile wide.
And I could tell the same story with rust and cargo, and plenty of other languages.
Apt really makes no sense at all to use in this context. Maybe it’s fine to install X and gvim. But that’s about it.
If Debian really wants to mirror npm and cargo and other languages’ package managers, why don’t they just automate it, and add the hundreds of thousands of packages en masse?
Manually adding specific versions of packages from npm and cargo sounds like a massive waste of human effort. At best it will only ever produce a pale imitation of the real package repositories. I just don’t see the point.
If anything you usually have fewer problems with newer toolchains, because new features get used by your dependencies. The version of rustc or nodejs that Debian considers “stable” won’t be able to run a lot of software that I want to run.
And despite the name, “unstable” Debian is still usually 6 months behind the latest version of most packages. That’s an eternity for new things like Zig.
This is what Debian's Stable name means: that, once released, the operating system remains relatively unchanging over time.
> That’s an eternity for new things like Zig
So why isn't Zig making sure that their latest releases are available in Debian Sid? Anyone can be a Debian Maintainer, and if they don't want to invest their time in it, they just need an existing DM to sponsor their uploads.
As for why don’t the zig developers become official Debian maintainers, gentoo maintainers, redhat maintainers, FreeBSD maintainers, homebrew maintainers and so on - well, probably because they’re too busy making zig. There are way too many unix package managers to support without help. Especially if doing so requires joining mailing lists, manual testing and so on. I wish there was a way to automate making all those packages across different unix distributions, but I can see why that’s a hard problem.
Longer answer: In Debian's arrangement, the idea is that the distribution moves together, so it doesn't have a native idea of "fast moving packages on top of slow moving base packages". There are other systems where this isn't the case; AUIU you can run bleeding-edge packages on a stable FreeBSD base system (largely because the BSDs have a very strong separation of the base OS from everything on top), and NixOS is quite happy, especially with flakes but you could do it other ways, to go as far as "start with stable NixOS but then add packages X, Y, Z from unstable, and don't provide libFoo at all in a global context but provide libFoo 1.0 to package A, libFoo 2.1 to package B, and libFoo 3.0g straight from git for package C". But in Debian, the equivalent is probably running a newer version in a chroot or container, yes.
what is the constructive way forward? treat script language development and its packaging in a different way than OS base setup.
And rust is very much not a scripting language but it’s in exactly the same boat. Actually it’s probably worse because async and http support isn’t built in to rust’s standard library. A simple hello world web server with tokio and serde will probably have on the order of 40 dependencies in the dependency tree, not to mention rustc and cargo. How many of them do you think are in apt? Maybe none since, contra Debian’s policy, the final build result is statically linked anyway. The rust compiler doesn’t support dynamic linking of rust dependencies.
The reality is that apt simply doesn’t provide a stable, useful, modern software development ecosystem. The task of providing a “stable” version of rustc or nodejs is these days the responsibility of the rust and nodejs projects - which both have CI with incredible testing infrastructure. And the effect of that is that the latest stable versions are going to work more reliably to run real JavaScript and rust programs than whatever crusty version Debian ships.
And that disharmony between what Debian wants and what developers want causes real problems when shipping software to end users, and when deploying software to servers.
There's two problems with that: many tools no longer have multiple development lines, which means that Debian can't keep its stable releases secure without manual backporting effort, and upstream developers don't care about getting their software in Debian. This means that Debian unstable already lags behind, as you notice, but also that the freeze-before-release takes longer than necessary. But in my view, those are mainly ecosystem problems, not just Debian problems.
npm being "badly broken by design" is one opinion. But the fact is that almost all modern language tooling is moving in the direction of becoming more npm-like or has been created from the beginning with heavy npm inspiration. See for instance Rust's Cargo, Dart's Pub, Go's modules, Python's virtual env, Esy for Ocaml, and more. Developers love being able to easily manage and add dependencies, and this problem is only going to grow for Linux distributions across language ecosystems.
Something like npm og Rubys Gem, are confusing because I have no idea where the packages went. Apparently they like somewhere in the current directory, maybe? What if I want to use the same environment and package elsewhere? I'm sure you can do it, but it doesn't seem logical to me that you don't need to specify which environment you're using. It's the same with Go, it's rather confusing where packages go, or which version, it's all squirreled away in the go command. In one way it is really nice that it just goes into the same project directory, but it's also a little confusing that your environment changes when you move directories.
For production and containers... you normally just have that one thing running, so into the global environment it goes and here using apt to install the packages also ensures security updates, well not in the containers perhaps, unless you rebuild them.
Something that was lost when we moved to modules - the system is still the same, it's just that if you never used the old system (GOPATH) or read the manual, then you might be confused about where things have gone.
Also of note is that vendoring was for a time Go's answer to dependency management and can still easily be done, and is supported by the tooling.
If I can complain about something is that there are so many ways to do it that I can't remember their details when I'm away from my laptop, as I am now. I think that I have at least one occurrence of all those 4 methods on my laptop, for different customers. They decide and everybody makes a different decision.
Other languages: same problems with different tools.
I find the opposite - in theory the Python way might be more orthogonal, but in practice all that does is gives you more chance to shoot yourself in the foot. Realistically I never want to run project A's code in project B's environment or vice versa, and I certainly don't want to update project B's environment with project A's dependencies - combined with the fact that there's no way to undo a `pip install` command or recreate the previous state, you can permanently screw up your development environment by mixing up your terminals.
There's a wide range of package managers in the wild that exist to help build software using features that apt fundamentally does not support because of its broken model of the universe.
I build dwm and dmenu as well but they exist in the repos if I didn't like patching them. If I go outside the repositories that's a choice, and I think hard if I really need it on my system, or maybe a VM for isolation makes more sense if I don't trust the developer.
If one needs bleeding edge everything maybe Debian isn't the right choice. Why does everything always have to cater to the masses? Let Debian be boring for those of us who love it for what it is.
You're missing almost 1.5 years of bug fixes then (Bookworm+Unstable 0.7.2, Jun 26, 2022; Neovim stable 0.9.4, Oct 9, 2023). LSP support in particular has gotten much better in the meantime.
> If one needs bleeding edge everything maybe Debian isn't the right choice.
Stable versions are not bleeding edge.
No I'm not, I used vanilla vim without LSP until Bram (R.I.P) decided to write another vimscript, too much NIH for my taste. I'm fine with what I use and have my workflow. I'm considering trying out how Flatpaks work for me for the isolation though.
I do use Docker and even the occasional VM for complex environments and don't notice any difference in my use.
> Stable versions are not bleeding edge
Bleeding edge as in latest features.
I'd have run it anyway, because I want the latest software without of the disadvantages of keeping my entire distro rolling.
Also I make use of running software in docker a lot.
The way I see it Freecad - the thing that you're actually doing something with on the computer - is the point, the kernel and all the rest of it are just there to support that.
> Also I make use of running software in docker a lot.
Yeah, I didn't put it in my list but that's another one I see a lot.
Many people in corporate, because that removes a lot of noise in "compliance" audits - show them that you have the main and security repository enabled and do regular update checks and installs, and that's it.
For me, the exception is Docker and Kubernetes, but that's easily explainable to auditors as a business need.
Which I think proves my point.
Debian's stability is legendary and well deserved.
But I have a feeling for the vast majority of people this is why snap was invented, to not be stuck on old software for a few years.
> I don't know anyone who uses Debian and actually sticks with their packaged apps.
With various indications that they more or less actually do stick to the packaged apps.
Anyway, I for one don’t think that staying with for example nginx for two years on the same version is a good idea. Even if they fix security issues, you still miss out on features.
And this is for lots of other packages.
So you're saying you do install things outside their official repos, because their official repos don't package or maintain everything you want to use?
Besides our custom kernel modules and business applications, Debian has everything these systems need and more.
I find it way cooler to use Debian on embedded systems rather than some buildroot, because it's a widely available and reproducible environment and debugging and development tools are an "apt install" away.
The thing is that even in embedded, people are starting to see the value of using libraries when writing those business applications, and they end up being the same libraries that parts of the base system will use. So either you need to align how the OS approaches those libraries with how the developer wants to, or you need a user-friendly way to have OS-managed versions and developer-managed versions coexist. Current Debian does neither of those things.
For the stuff that you really _need_ to have the latest version, you have options to install it yourself. For the rest of the system, if you don't care about having the latest updates, you get a relatively stable system that doesn't potentially change every other week.
Of course some people do prefer having the whole system on the bleeding edge -- in which case Debian is obviously not for them, and there are many other distributions that cater to their needs. But the people who use Debian made a conscious choice to keep most of the system "stable" except for the important programs that they know well enough to "maintain" the latest versions themselves.
Those options exist, but Debian doesn't really support or steer people towards them. IMO their approach compares pretty poorly to e.g. FreeBSD where you have an explicit packages/ports split and support for using ports. (E.g. installing a newer version of an application on Debian is relatively easy, but if that application needs a library then it becomes quite hard, to the point that people resort to vendoring or static builds in one form or another)
There are very strong arguments for both approaches. Some people will tell you to use a version of a library in your distro's repo, because it's been vetted by a third party. It's nice to be able to choose an OS/distro that fits your needs.
CPAN was untested garbage by comparison. (In the same way that pip is today.)