Debian is at the heart of the most successful Linux distros
theregister.com
theregister.com
Over these 17 years, I have used Debian for frontend servers, backend servers, desktop computers, personal laptops, personal virtual machines, team virtual machines, etc. I run my static HTML websites, Common Lisp web applications, ZNC IRC network bouncer, Exim4 MTA, Matrix-IRC bridging clients, etc. all on Debian.
I also spin up fresh new Debian VMs to serve as clean rooms for testing my open source projects and technical guides. For example, when I published my "Lisp in Vim" article, Debian turned out to be a nice system to quickly install all the necessary packages and test out all the steps in my article thoroughly. When I write a shell script to be used across a variety of shells, I run my test suite for the script on bash, ksh, zsh, dash, posh, and yash, all of which can be easily installed on Debian.
Debian has served me very well for a wide variety of activities ranging from things like software development and testing to personal digital chores like writing documents, presentations, splitting and merging PDFs, editing audio/video files, document format conversions, editing photographs, etc. and even having fun, say by raytracing with POV-Ray, running vintage DOS games on DOSBox, or recording live music from my digital piano. No matter what the nature of the problem is, the solution often begins with a simple "apt-get install" command.
In all these years, I have never ever faced any problem with dependency management or package installation in the stable branch. Yes, the packages can sometimes begin to get old by a few years but the whole system remains outstandingly stable. It is a great distribution for long running servers. Debian is also quite good for a lean personal computing environment. In my opinion, the Debian stable version sets the gold standard for stability in the world of Linux distributions.
On arch this is all much less hassle.
That said, on my servers I just run stable and then compile anything I want that differs, and make sure it doesn’t clobber the system’s version. Like altinstall for newer Python versions. I’ve yet to have an issue this way.
Instead of doing this, create a Debian Stable (or Testing, if that's what you're running) repository on OBS¹. Fork the packages you want from Debian Unstable into your repo, and let them build against your preferred Debian release. If some of them need newer deps, pull in their deps, too. Add your repository to your system and upgrade that way.
Or if you're not that attached to only using DEBs, just use Nix or Guix to install newer software.
--
I can guarantee my distro will bring world peace, help you lose ten pounds and get 10% better gas mileage.
Unlike rolling release distros, Debian doesn't try to pretend that rolling releases are as reliable. It's exactly what it says on the tin. Both are probably equal in terms of reliability, but Debian is actually honest about what that reliability level is.
On the other hand, I remember Arch transition from readline 6 to 7 making the system unbootable (2016) if you did upgrade at the wrong moment. I don't know if package containing libraries are now versioned to avoid such issues.
I think the main difference you get by using Arch is AUR (we don't have that in Debian) and, I think, more fresh packages (mainly because it easier to package for Arch than for Debian).
While it's been serving me well, it still feels quirky and a lot of hardware stuff just didn't work out of the box so I've accumulated a fair few hacks and I dread having to butt my head against those again when this laptop inevitably craps out. Sometimes it's just finding the package you need but I also had to do a lot googling and changing speficic lines from specific config files for a bunch of things. Namely my volume buttons, mute button, Bluetooth, Bluetooth devices, recorder, brightness buttons and others I forget. My volume buttons still don't work if it's through a Bluetooth device but I'm just putting up with it cause I couldn't find an answer fast enough and on a new connect I have to explicitly go in pavucontrol (or whichever it was, "firefox no sound bluetooth debian" is seared in my search history). I never managed to get the Steam for Linux thing working and when I try again it seems to clash with the remnants of some old attempt.
Maybe I just don't have enough experience and it would be the same on any Debian or Linux distro but AFAIK Ubuntu does much better at handling drivers out of the box.
I like the simplicity of it at face value but I'm not sure why I wouldn't go with Ubuntu next time to avoid the hassles or if I'm not being stubborn by not going for Windows with WSL (assuming I don't buy another old horse). Worst is I still need to run a Windows VM in it when I'm compiling something to .exe or some specific Windows only software.
Work flawless on Debian 12
In such setups, the hardware driver quirks were most probably solved decades ago and as a bonus you don't have to babysit the server. Just install the OS, forget about it and focus on whatever is really bringing you value.
What drove you away from Arch Linux on your laptop?
Probably gonna try again some time but for now I try to think as little as possible about my OS as long as I can code on it.
Is Ubuntu still better at having every driver working out of the box and being kinda seemless or is that more a thing of the past?
> Yes, the packages can sometimes begin to get old by a few years but the whole system remains outstandingly stable.
I then compile from source. I do it for Emacs notably and at time I recompiled the kernel (for example at one point I had patched MagicSysRQ and was running a kernel with a modified MagicSysRQ).
Nowadays I like to use the stock, signed, Debian kernel: even if it's not a full UKI yet I like to see "SecureBoot on" (I know it's a touchy subject and I know it's not a panacea and I know I should really run a signed UKI but I haven't set that up... yet!).
I don't bother to "dist-upgrade", except to go from the "hard freeze" to the stable one. Typically I re-install from scratch when a new release comes out. YMMV.
Long live Debian! (and Debian shall outlive me)
It's been perfect in the few days I've had it, because I don't have to dodge Ubuntu's ads left and right, or worry about what the hell snaps are doing. Otherwise, it's basically the same as Ubuntu. I very much recommend it.
Is it Ubuntu that polluted with ads? Honest question as I haven't used it that much lately.
- I didn't type myself
- isn't a prompt of some sort
- isn't an all caps warning before a prompt
The kind of 'just works' that most refer to is that they turn their computer on and start working, rather than turning their computer on, being forced to login to a net account, being forced into a tutorial dialogue for a newly added feature, and then realizing that BigCo deprecated your file format support last forced update because they replaced it with TheNewWay.
> I simply can't stand anymore the incessant ritual of software updates
https://www.artnews.com/art-news/news/mona-lisa-smeared-cake...
Not sure your comment applies here.
My desktops often last over 10 years on a single install, upgrading from one release to the next, without a hitch.
Debian is the best! For me it's the highest quality operating system with a super impressive governance organization behind it.
Cheers to another 30 more years!
I mean, that's about one release upgrade
So that would be 6 stable releases in nine years.
Only semi-joking. Wish I could but the constantly declining quality of Microsoft software has made it an absolute.
In particular, Ubuntu snapd decided to fill my /tmp folder with gigabytes of data for no apparent reason and that made me 'snap' as well.
I also dislike the new Ubuntu auto-install installer[0], which is an absurdly complex kludge that doesn't provide me any benefit over the old and trusted Debian installer.
[0]: https://louwrentius.com/understanding-the-ubuntu-2004-lts-se...
Android is by far the most commercially successful piece of software to come out of the Linux kernel (granted, pretty far detached at this point).
If that’s not pure enough for you, I have to think that Valve’s Arch-based SteamOS drives more revenue than Canonical’s support contracts.
Estimates point to around 3 million Steam Deck sales and then the software revenue on top of it, which should amount to at least 10x Canonical’s revenue.
Then you look at the elephants in the room with enterprise Linux: I have to think that RHEL pulls in more support contracts than Canonical, Amazon Linux similarly has a place as a default option for Linux in AWS, and you’ve also got Oracle in the mix in terms of not-Debian enterprise distributions with widespread adoption.
And regarding the speed, which is what most people mention online when they compare the two, it's only faster because apt-get update is a separate step.
Around 2003, Yum was a Python tool which took ages just to build dependency graph to do basic things.
yum/dnf rollback is unreliable even today because the previously installed versions of packages might no longer be present in the repos.
I love Fedora, but DNF has atrocious UX.
I haven't run Linux on my local machines for a couple years though, so maybe things have changed a bit, but if we're talking about the years where Debian gained "market" (mind?) share, then these are the reasons IMHO.
Wikipedia says yum wasn’t even a thing until 2002.
It's a bit like the old Photoshop strategy, you let them pirate the software when young to hook them up, and then they would demand it professionally.
Ubuntu was always easier on the server with root user disabled by default and unattended-upgrades did its job without a hassle with newer packages. (It meant quite different if it was PHP 5 or 7.)
For some organizations there is benefit to continuously improving their platform engineering, but for many, technology is a tool that's required to do something else. They don't want to keep up with changes, and sometimes the changes aren't useful for them. On HackerNews most of the content and users are technology focused, but in the real world its the opposite. There is a reason why many enterprise organizations still run stuff on mainframes as an example. It's not because they want to, many have even spend hundreds of millions trying to exit, but the thing that's the most important is the stability to their core business. Now I don't want you to get the impression that I'm drawing a comparison between Debian and mainframes, my point is simply that to many organizations the ability to provide a stable support the core purpose of the organization is more important than anything else. Debian does that.
Compare Debian to Fedora. Fedora there are multiple releases per year. Debian you have the protection of being in the herd for a good 2 years. Each release is a much more known quality and it is easier to find bugs and documentation for whatever it is that got broken in Bookworm. Investing in workarounds makes more sense because it won't be fixed in 6 months. Etc.
Only software project I know where it seems likely that moving slow is a positive. But slow seems to work well for Debian.
As for Red Hat, it seems a bit dodgy to get involved with a company as an unpaid user. The incentives are never going to line up. Love their work, I just wouldn't use their system if I wasn't paying them.
EDIT Also, woah! Anticipating something like this sort of manoeuvre is a good reason to have avoided RHEL. Corporations. Not long term bastions of freedom.
"However, in 2023, Red Hat decided to stop making the source code of Red Hat Enterprise Linux available to the public. The code is still available to Red Hat customers, as well as developers using free accounts, though under conditions that forbid redistribution of the source code." - https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux
As a Fedora user, I like that someone pays for Fedora development, which (hopefully?) enforces standards in terms of code quality and QA, but also things like workplace policies etc. (e.g. I couldn't use software whose staff has been alleging sexual assault).
I think the only non-corporate distro I'd use is Arch (which I did for a while, but Fedora is just so easy to use!)
I should give Debian a try though for sure.
That's not actually true, it's just not being provided in such a way as to be trivially rebuildable. CentOS Stream is the upstream for RHEL and as such you can reconstruct RHEL from CentOS Stream [1], it just requires more effort to track the correct package versions.
[1] yes, I'm aware that has broken on occasion, almost exclusively for EL8 where the upstream / downstream process wasn't fully developed yet
* Red Hat Linux (previously the go-to desktop linux) was discontinued in favour of RHEL/Fedora in ~2003.
* Ubuntu was first released in 2004.
* Around 2000 a new release would come as a CD image and the normal way of upgrading was to wipe out everything except your home directory. This meant trying out a new distro was pretty much as easy as upgrading your existing one.
* As you say, although Yum was released in 2002, apt-get had been around since 1998, and so at that time was more mature.
* Wifi became increasingly common, and almost always needed proprietary binary blobs. Proprietary ATI and nvidia linux drivers became available. And of course MP3 was widespread.
Ubuntu arrived at an opportune moment - former Red Hat users looking for a new home, users used to wiping their system and installing a new distro, and clear benefits if wifi, graphics and MP3 all work out the box.
Consider a comparable quote:
> Taskrabbit is an ancient Swedish word meaning "I can't assemble IKEA furniture".
Years later, I figured out that you're supposed to use the spacebar to select/toggle UI elements, not the Enter key. Nobody told me that, and the text-mode installer certainly doesn't tell you!
Ubuntu 11.04, on the other hand, was no trouble to install.
> Ubuntu is an ancient african word, meaning "I can't configure Debian" https://www.urbandictionary.com/define.php?term=ubuntu
From the time I started to mess around with Linux, around 96-98, the biggest distros were certainly Slackware, Debian and Red Hat.
Slack you basically had to compile and config everything from scratch.
RH helped a bit with packaged software in RPM format but dependency management was missing. Basically a glorified tar ball.
apt solved the distribution and packaging of software.
I still prefer .deb packages so now I'm looking at jumping ship, probably to MX Linux as Ubuntu is using more and more snaps and so far they've just caused me problems; I also have philosophical objections (not necessarily well-founded in logic!) against monolithic packages.
Not sure why I started that reply, ... get off my lawn!
And any update would change the conflicts, to the point in that updating it simply wasn't a thing.
But technically, rpm was way more complete then dpkg. This changed with apt-get, as it took many years to the RPM distros to create yum.
It is a name full of misfortune if you think about it.
But as a distro, it is good.
As an organization, it has had controversial moments that many people don't know about. https://lists.debian.org/debian-vote/2007/03/msg00194.html
Essential anecdata : for the few computers in my household, the user experience and stability of certain mainstream Debian-based Linux distros cratered hard after, let's call it 20.x, and I doubt it would be possible to achieve the "I set up a 16.x machine for my parents in 2016, and to this day, It Just Runs, No Questions Asked, Ever" in the same way with today's equivalents - unless stepping back to a simpler incarnation of the Debian family. I'm thankful to be able to do that, and in my house, that thanks goes to the ever-present Debian.
"Debian was founded by Ian. First announced on August 16, 1993, by Ian Murdock, who initially called the system "the Debian Linux Release". The word "Debian" was formed as a portmanteau of the first name of his then-girlfriend (later ex-wife) Debra Lynn and his own first name.
In Australia at least, the journalistic standard [1] states that reports should avoid sensationalising suicide, and should not report on the methods. It’s also expected for support details to be added at the end of the story (this addendum is often the only indication that the persons’ death was the result of suicide).
https://www.presscouncil.org.au/wp-content/uploads/2021/11/S...
Many times I’ve add to add external/weird repositories to get some functionalities i rrallneeded (eg: appropriate codecs fir bluetooth audio and a version of bluez that supported by bluetooth headsets) and that kind of tainting really endangers the longevity of a debian-based system.
I understand that the fault is completely on the external repositories and on the user… however the choice then is to be able to use my hardware (or, in general, to the kind if computing i need) or not.
These days I’m using fedora btw, which has been really stable while providing fairly up-to-date packages.
That's not a problem with debian, that's just a mismatch in needs, you're probably better off with a "less" stable operating system.
I'll be honest, i haven't had any stability issues with Fedora either, and i've been upgrading as often as i would with Debian. And in both cases, i'm using fairly old and known hardware (years old thinkpads, the T440 and the X270).
Debian is for people who want to configure a server once and have it stay running and secure.
"Stability" in Debian's context means _version_ stability, not that it doesn't crash. I think most Linux distros aim to not crash.
Indeed, I moved to Fedora and I haven't looked back.
I was already using RHEL and CentOS (later Rocky Linux) on servers, I guess it's bye-bye time for Debian.
> Debian is for people who want to configure a server once and have it stay running and secure.
The same could be said for RHEL and most of its derivatives though.
Of course in theory they could also try to backport the changes, but I doubt anyone would bother for anything that’s not hugely popular. I’m tired of distro patches generating support load anyway.
Have the maintainer do stable/oldstable updates when backwards compatibility is broken.
Have the package removed from Debian stable/testing and have it only in unstable and the new fastrack.debian.net repo.
True. And yes, Debian stable packages do not work so well if a package needs to undergo frequent updates. As others have pointed out there are work arounds in place - like backports. Or if you want a Ubuntu / Arch like experience, you could try Debian testing. But they are kludges and for some packages the pain got so great Debian was forced to brake it's own rules and pushes new version into stable. But that's rare - Debian stable is so popular because it's stable.
The underlying reason for that focus seems to be Debian is a distribution put together by sysadmin's. A large chunk of the DD's (Debian Developers) are sysadmins pooling their resources to produce a distribution they can use in their day job. The two things that matters to them are security and stability. It's not an accident that Debian led the way on reproducible builds. This mob really cares about rock solid and secure.
To me Debian model of "sysadmin's pooling their resources" is remarkable. It's one of the few open source driver projects that combines open source and commercial objectives. At its heart is a whole pile of people teaming up in an open source project to create a tool (a server OS) they base their respective (and disparate) commercial products. The open nature of Debian - it's ethos, it's transparency, is critical to why this works so well. It allows the participants who might well be producing competing products to trust each other, and continue to work along side it other for decades now to produce a distribution. It also means it's always going to have a strong server focus.
That focus doesn't mean not to say Debian can't be used for a Desktop. A stable base like that is a very attractive thing to build a desktop on, and that's what happened. It's my daily driver, and I think it works wonderfully - but I also hand install some things from outside Debian (like youtube-dlp), and make liberal use of docker containers when I need to pin certain versions for development. It's a bit of work - but as a developer it's stuff I have to do anyway. It created an opportunity to create a derivative that caters to the desktop users who aren't like me and just want the latest shiny - and Ubuntu stepped into it.
If Debian shipped version n and the upstream fixes the vulnerability in version n+5 (not unusual, as debian stable is routinely out of date for 2-4 years depending on the length of the testing freeze and the point in time of the stable lifecycle), this can range from trivial to near impossible in a timely manner.
They also tend to be opinionated about the software they ship and do include many Debian-specific patches. Most of them are harmless or just small changes to make the software work better with the Debian way of configuring things; sometimes much more catastrophic: https://github.com/g0tmi1k/debian-ssh
If I want the latest version of a service app, I check for a Docker container and run that. If it's a CLI tool, I'll check for an apt repo, or build it from source then copy it to /usr/local/bin/.
I feel like I'm getting the best of both worlds: a rock-solid OS, and with a tiny bit of effort I can run the newest version of any tool I want. By not doing this systematically on every single package in the OS, there's little risk of breakage.
In which case was it an actual problem for you? What about switching to testing or unstable?
In my case I like to mix stable with a few packages from testing / unstable if needed. The current stable is relatively recent, so right now I just have golang from testing for instance.
I agree with the sibling comment that it's more of a feature: it's more efficient for me to work around the bugs / missing features of packages that won't be update for a while and stick to these workarounds, rather than constantly adapt to new bugs (even if old ones are fixed) or to changing features.
It's not just a modern thing. For no other platforms are application versions so tightly coupled with the OS version. Mac or Windows users would tell you to take a hike if you tell them they can't usually get new software without upgrading their OS. Similarly Android apps typically target somewhat older platform API versions to support users who have not yet upgraded to the latest base system.
Which is why it's so important that you have multiple choices. If you need the latest packages, use Arch. If you need stability over multiple years, use Debian.
For desktop use, distros like Fedora strike a decent balance in my opinion, being much more up to date without sitting on the bleeding edge and usually updating without issue.
I appreciate Debian for what it is, and I use it in VMs and containers. But for my own usage I prefer Arch (mostly Manjaro). Yes, even for servers. If you run a full system update at least once a week you will never stumble upon the possible problems of the rolling distro upgrades, by the way.