Debian 12 'Bookworm' New Features and Release Date | Hacker News Reader

Debian 12 'Bookworm' New Features and Release Date

news.itsfoss.com

102 pointsteleforce54 comments

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 LTS is also 5 years https://wiki.debian.org/LTS/

> 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.

You can also pay for extended support for a further 5 years from a 3rd party for a total of 10 years: https://wiki.debian.org/LTS/Extended

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.

I am planning the same and for exactly the same reasons, viz snap. Its encouraging to hear you have had success with it.

edit: Is there anyone who can share their experiences switching from Ubuntu to Debian on the desktop?

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.

It's the same. Ubuntu is based on Debian. The default GUI is different but they change that in every major release anyway.

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.

10/10, would recommend over snaps.

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.

Same switched to Debian. It is super stable without snaps and other Ubuntu craziness.

I use it as my desktop os.

At this point I assume anything ubuntu adds will either be janky or replaced within few years by something else

> My new default linux distro for servers.

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).

I also dislike ubuntu's automated and phone-home behavior.

For my installs, I rip out or neutralize the motd-news stuff, ubuntu-advantage-tools, ubuntu-report, whoopsie*, snapd, 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.

In many cases the Ubuntu package might work too, as long as you use Ubuntu that's older version than Debian

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.

I don't get, just remove snapd, mask it in apt and that's it. Oh, and add Firefox repo.

Now it's back to normal.

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.

Another upvote for debian as a great replacement for ubuntu. Base install is very lightweight and rock solid stable compare to ubuntu.

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.

Its no longer recommended on Debain to use pip to install system-wide python packages. Instead

* apt is used to install python packages that system packages depend on.

* Users are ---required--- strongly encouraged (see below) to use virtual environments or conda to install python packages for their own usage.

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...

Luckily python/debian recently decided to just tell you "No!" when you try that particular foot gun.

https://peps.python.org/pep-0668/

They have to, as end-user applications can depend on those packages. My advice would be to never depend on those packages for non-system applications.

I know it is all Toystory names, but everytime I hear the name I think of this wonderful story https://j-novel.club/series/ascendance-of-a-bookworm

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.

Info on LTS support (5 years): https://wiki.debian.org/LTS Then there is the extended LTS, ELTS (10 years): https://wiki.debian.org/LTS/Extended

Not all the Debian packages are covered by this security support, but there's a tool to check your installation (see the LTS wiki).

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.

What made you leave Fedora?

I just made the switch to Silverblue from Debian/Ubuntu and so far like it.

What about for web servers? What's the default nginx version installed?

What's the recommendation? Nuke the system and install fresh? Or upgrade?

This is Debian. Starting with 1.3, it has been possible and generally recommended to upgrade in place.

1. Read the install notes. Read the upgrade notes.

2. Note the things that the upgrade notes say will change and need human input.

3. Backup if, for some strange reason, you don't make backups automatically.

4. Change the sources.list and, if there are any, sources.list.d configs to point to the new stable release name.

5. If you set APT::Default-Release, set it to the new stable release name.

6. Update the package list: apt update

7. Upgrade the system: apt dist-upgrade

8. Reboot.

9. Fix items from the policy config list you made in step 2.

10. Check on anything left: apt upgrade

That should be it.

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:

    export DEBIAN_FRONTEND=noninteractive

    apt-get update
    apt-get  -o Dpkg::Options::='--force-confdef' -o Dpkg::Options::='--force-confold' dist-upgrade

upgrade done. All of configs you changed are not touched and the new version is in <name>. dpkg-dist file

    find /etc -name '*.dpkg-dist

to show "a config that package would use if you didn't change it". diff it with your config and add any required changes. Done.

> 10. Check on anything left: apt upgrade

11. apt autoremove

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.

add repos

    apt-get update
    apt-get dist-upgrade

answer the questions. Most will be "do you want old version of file, distro maintainer version of file, or do you want to diff or edit it".

If you don't want to answer the questions and just want to keep only config that you changed:

    export DEBIAN_FRONTEND=noninteractive
    apt-get update
    apt-get -o Dpkg::Options::='--force-confdef' -o Dpkg::Options::='--force-confold' dist-upgrade

(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.

* [0] https://wiki.debian.org/DontBreakDebian

Reply on news.ycombinator.com