I'm really looking forward to bookworm. Not for any particular reason, but just to have another fresh base (and see even more up-to-date packages start showing up in bookworm-backports).
I'm a recent refugee from ubuntu LTS's, after having run them for a decade or so. Previously, I just never really had a reason to move away from the community support and google-ability around ubuntu, plus many guides having example commands for ubuntu installs etc.
Snaps are what made me switch. It's insane that they're making apt packages pull in snaps. If snaps were an additional thing similar in spirit to `/usr/local` where system admins could install weird stuff they needed that didn't fit, that's one thing. Forcing them onto me is another, especially when you can literally feel the difference between a program living in a snap vs one installed normally.
This is nitpicky but I also don't like that it messes with my mount and df outputs with a bunch of mounts I don't care about and 100%-full filesystems.
Now, debian - I don't know why I didn't make this switch ages ago! It's everything I wanted from ubuntu without any of ubuntu's opinions. My new default linux distro for servers. (I still run Arch on my laptop).
Similar story for me. I used Debian for servers for many years, then a few years ago I thought, "well I like Ubuntu's LTS support timespans and release cadence, I think I'll start using that for new server deployments." Then snap happened, now I'm back to Debian. Typing "apt-get install" and ending up with a snap is a really jarring experience.
> Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years
But to be honest I find the LTS schedule a bit confusing when comparing to Ubuntu, because it's separate from the initial stable period, e.g Debian 11 Bullseye (the current stable release) transitioned into stable in 2021, and on above page it's LTS support date is in set between 2024 and 2026. I wonder if this difference in presentation has previously put people off.
We moved our servers from Centos (then 6) to Debian. Holy shit so many stuff that we had to fix or change "just worked". And upgrades works! Maybe less important in container era but still.
Debian is the vanilla of distros - just enough glue to make stuff work well together.
And upgrades work the smoothest of any distros I tried. My desktop install is from 2007 and I think it survived replacement of every component of my machine including the case.
We even had one of admins accidentally update one of legacy servers "2 versions up" and it just worked!
> Debian is the vanilla of distros - just enough glue to make stuff work well together.
Just enough glue and tons of patches. I used to love Debian, these days I much prefer the "upstream is king, do not patch it unless it's broken" approach of Arch Linux, and to a lesser extent, Fedora.
I always say that when you learn to use Apache 2 on Debian, you only learn how to use Apache 2 on Debian. There was a moment of confusion the first time I configured it on Arch and there was no /etc/apache2/sites-enabled directory. Upstream will always know better, and have better testing facilities than a random maintainer adding their custom solution on top of the vanilla code.
(Since I'm here complaining, I might as well add I dislike deb/apt more than I dislike dnf/rpm, and they are both quite unergonomic)
Just my 2 cents. I respect Debian and its place in the Linux world. I've just fallen out of love with it and that's OK. I wish non-Debian distros were more popular though.
Same here. Got my start on Ubuntu, always loved Ubuntu, but they lost me to Debian because of snaps.
My reasons are different from yours: I can tolerate UI issues, polluting the mount list is far worse, but the dealbreaker is that the user is not allowed to disable automatic updates on snaps, the option merely delays updates for a maximum of 30 days. I simply cannot accept someone patching my OS against my will, what is this, Windows? And since Ubuntu went all in on snap, more and more system apps are snaps, so it's not as simple as removing snapd, I see what's coming on the horizon.
The snap developers arrogantly tell you you're wrong for wanting to disable automatic updates, and they will not make it optional like it is for apt. This is despite the snap store being a far less tested/reviewed repo than the apt repo. So any rando can upload a snap package, you can install it after approving it, then said rando can push a malicious update, and it will be immediately deployed to my PC against my will.
"Use another distro if you don't like it?" OK, that's what I did. But I would still be a Ubuntu user if the snap devs weren't so smug and antagonistic.
Yep, I moved from Ubuntu 20.04 to Debian 11 for the same reasons during the Christmas holidays. I'll live boot Debian 12 and check how it copes with my 2014 laptop.
The main hurdle is the NVIDIA graphic card. Sooner or later the proprietary driver for X11 will stop supporting it by and who knows if the one for Wayland will work. I remember I had problems with Wayland so I went back to X11. The card is a Quadro K1100M.
A lot of laptops with NVIDIA graphics still had integrated graphics on the CPU, and the Intel drivers are much better if all you need is to drive the display. (And if you're trying to put a load on the GPU with something so old then you're screwed anyway.) See if the BIOS has a setting to disable it.
I agree with your reasons. But on the flip side, I've installed Debian a few times in the past, and I always end up wanting packages or versions of packages that aren't available. Over time my package source lists end up changing to Ubuntu anyway, and after some upgrading, I'm essentially running Ubuntu, upgraded in place from the Debian base install.
My Ubuntu desktop was very customized to make it look as much as possible as the old Gnome 2 and drop any animation and special effect. I installed all the Gnome shell extensions I had on Ubuntu, removed some and added others to cope with the new version of the shell. I have an almost pixel perfect copy of my Ubuntu desktop now.
I switched for similar reasons, but went from Ubuntu to Fedora a couple years ago. I like Debian as well, but its a bit slower to release at every 2 years unless you stay on testing or backports. Fedora releases are every 6 months, and the kernel seems to update faster than that. I've been using docker and toolbx for things where I need vendor tools that are somewhat distro specific. Even if you use Debian I'd recommend toolbx for developers.
I was wondering more about support of drivers and codecs etc. Is Debian after adding the non-free drivers exactly the same as Ubuntu or are there some things that are only specially available in Ubuntu? Especially also regarding things like audio/video codecs, hdmi etc.
I went from Ubuntu to Debian on a desktop machine. I have an nVidia 1080Ti with default drivers, running 3 displays with no problems. Motherboard audio works, USB headphones also work well. I can watch videos no problem and re-encoding/recording with ffmpeg/OBS works without a hitch. Only thing I remember doing is replacing the firefox version from ESR to latest.
They're allegedly including the non-free stuff automatically now, but the better solution is to avoid that hardware whenever possible. Proprietary drivers tend to have more bugs because the public can't fix them, and even if they're supported now, you're at the vendor's mercy for when it stops working regardless of what Debian or Ubuntu includes.
How do you deploy anything that depends on bleeding-edge programming-language runtimes? Half the stuff I end up installing on servers are Ubuntu PPAs maintained by the third party software vendor; which in turn depend on Ubuntu-specific base packages that don't exist on Debian.
If your answer is "I use containers", then that's just a regress — as for most complex software (i.e. not just a static binary), due to library package requirements, the base OS-image inside the container almost always ends up being Ubuntu. So now you have to ask, how does the person creating the container-image switch to using Debian for that?
> Ubuntu PPAs maintained by the third party software vendor;
If it's proprietary closed binaries distributed over a PPA, I'd prefer run those in independent VMs (first trying the PPA on Debian - they're really just apt repos and can be added as suc), falling back to Ubuntu if its not worth resources fixing some particular one
> as for most complex software (i.e. not just a static binary), due to library package requirements, the base OS-image inside the container almost always ends up being Ubuntu.
I don't share this experience at all. The only situations I had where Ubuntu PPAs was the only nontrivial solution would be kernel drivers - precisely what does not go into containers.
> your answer is "I use containers", then that's just a regress — as for most complex software (i.e. not just a static binary), due to library package requirements, the base OS-image inside the container almost always ends up being Ubuntu
The reasons to move away from Ubuntu as base distro often don't apply to container images. Ubuntu images don't run any daemons like snap and are actually quite optimized for size (smaller than Debian, surprise surprise)
> So now you have to ask, how does the person creating the container-image switch to using Debian for that?
Compile outstanding libraries from source in the image build; injecting integrity-checked static assets as necessary.
I made a similar comment above. I find myself needing so many packages that aren't in the Debian repositories, over time the system just morphs into Ubuntu anyway.
You are not alone. I will likely be migrating from Ubuntu to Debian on my next major upgrade cycle because of snap packages being forced upon me in places they should never exist (headless servers, substitutes for debs, etc).
For what it's worth, Debian and Ubuntu are similar enough that a lot of the troubleshooting people post online for Ubuntu tends to work with Debian, too.
Add me to the list I suppose. I used Ubuntu as a desktop for basically all of the 2010's and so it seemed pretty natural to use it as a server too. Now I like Pop!_OS for desktop and plain Debian for server.
If you're having to screw with defaults right out-of-the-box, with Ubuntu, you may as well just use Debian. Basically its whole value-prop was originally "Debian, but with obviously-correct defaults for most desktop users".
Even after you add the Firefox repository, installing Firefox from APT is not as simple as "sudo apt install firefox". That command would still install the Snap version of Firefox. You have to figure out how to force APT to pick the "firefox" package from the new repository rather than from the default Ubuntu repositories.
I wish they didn't track Python and Go packages in their repositories--especially with Python. These languages already have their own package managers, and this creates so many different problems when user calls to pip/go-install have collisions with whatever root installed via apt-get.
It's still possible, you just need to provide the additional command line switch "--break-system-packages". When trying to install packages without, pip will even tell you that.
It's to create a stable target for the OS. You can target "Debian [version]" and know there's some stability & consistency to the versions of various packages.
There's:
1) System packages. Any OS with discrete releases should aim for stability, here, to create a useful deployment/support target.
2) User packages that the user plans to use directly. Your web browser, a spreadsheet program, maybe something like ripgrep. You don't need multiple versions, and the version you want is almost always "whatever's latest". This could also, potentially, include your main daemons on a server—SQL servers, web servers, that kind of thing.
3) Development packages. It's common to need multiple versions and to need to switch between them frequently (due to having multiple projects with the same deps at different versions, or needing to "git-bisect" or debug a branch with older deps, that kind of thing). Some overlap with 2 (especially on servers, if only because it's convenient to manage your servers' packages with the same tool you use to manage development dependencies) but they remain distinct categories.
MacOS with Homebrew gives you 1 (macOS itself) and 2 (Homebrew). Some people try to use homebrew for 3, which tends to make them unhappy and leads to them making angry posts about Homebrew because doing that is a bad idea... but it's also a bad idea on most linux distros, which will be mixing together 1-3 if you try to use the system package manager for everything. You should be using something else for #3, at least. You shouldn't be using the system Go or Python packages unless you're targeting that specific distro at that specific major version as a deployment target.
Linux distros tend to have difficulty separating 1 & 2, in large part, I think, because of how the graphics and multimedia stacks work. This is really annoying if you're used to having nice, clean separation between those, as on macOS + Homebrew.
How does that affect you ? You're supposed to use venvs for Python (and Ruby) anyway, and for Go whatever you compile will download its own deps anyway.
The libraries in distro are for distro packages. Using them is fine but by no means required.
Not me directly, but a common issue on all of the Debian (& derivatives) support forums is where people bust their Python install by doing a `sudo pip install...`. I know what that does, you know what that does, but I can assure you that the average user doesn't.
I mention Go because I think it's heading in the same direction on Debian-based distros.
Seems like there would be a better way to keep things straight...
For some reason it makes me think of the "very hungry caterpillar" children's book - not because it's about a worm - but because it has little holes cut out of the pages you can stick your fingers through :P
How are the efforts going to add LTS to Debian? I've always felt like the support cycle was one of the weaker points of the distribution from an enterprise standpoint.
Debian releases generally have a 5 year support cycle, at least the last several have, which is the same as Ununtu LTS. It also seems pretty standard for most distros now.
EDIT: I forgot that Freexian also provides a few more years, but I've never used that. I find that I need to upgrade more frequently to keep up with increasing security requirements anyway.
Recently jumped from Fedora (after a decade?) to Mint, which is free of Ubuntu's nonsense as far as I can tell. But that puts me on kernel 5.15 which is unfortunate as I'm interested in using btrfs. So I've contemplated making this jump - but in the meantime I've come to appreciate Mint's niceties.
And so... maybe I'll just wait for Mint to update.
By default the upgrade can ask a lot of questions, but you can kinda skip it by just telling it to keep old config files then merge them with the new ones at the end:
If you are more happy-go-lucky, you can just do 4, 6-8 and 10, like I did for years (closer to a decade, actually, I think 1997 til 2006, when I switched mostly to Ubuntu).
However, I've always installed apt-listchanges and configured it to prompt me before installing anything, which (mostly?) removes need for 1 and 2, a bit like backing up removes need for 3.
(we use that because our configs are managed by CM Puppet anyway)
That will:
if you have not changed system config in a given package, update config file to latest
* if you have changed it, it will preserve it but put new one into .dpkg-dist file.
If you did not add any non-debian repos that would collide it pretty much always succeeds.
Now:
* find any file ending with .dpkg-dist
* inspect both this and config to see whether you want to put some of new config into your current config
That looks longer than it is. Near-every upgrade I did is just those 3 commands and some waiting.
fwiw in server environments I have (knock on wood) always had very pleasant experiences upgrading debian. for a desktop env with lots more config and packages, ymmv.
The most common case for failures is frankendebian [0] and just putting some badly designed packages that mess stuff up. I had never had, even on desktop, problems with vanilla Debian install, they all stewed from some 3rd party repo not playing nice.
I'm a recent refugee from ubuntu LTS's, after having run them for a decade or so. Previously, I just never really had a reason to move away from the community support and google-ability around ubuntu, plus many guides having example commands for ubuntu installs etc.
Snaps are what made me switch. It's insane that they're making apt packages pull in snaps. If snaps were an additional thing similar in spirit to `/usr/local` where system admins could install weird stuff they needed that didn't fit, that's one thing. Forcing them onto me is another, especially when you can literally feel the difference between a program living in a snap vs one installed normally.
This is nitpicky but I also don't like that it messes with my mount and df outputs with a bunch of mounts I don't care about and 100%-full filesystems.
Now, debian - I don't know why I didn't make this switch ages ago! It's everything I wanted from ubuntu without any of ubuntu's opinions. My new default linux distro for servers. (I still run Arch on my laptop).