After 1 year, 9 months, and 28 days of development, the Debian project is proud to present its new stable version 12 (code name
bookworm).
The biggest change conceptually is that Debian now includes a non-free-firmware package area, and the Debian project from here on out will allow non-free firmware to be included on installation media. For the rest, a new Debian release is exactly as you’d expect – all the latest versions of packages, and it will serve as the base for an immense number of popular Linux distributions, either directly (such as Ubuntu) or indirectly (such as Linux Mint).
And it even comes with the very latest version of KDE Plasma (5.27.5)… nice
Yup, it slipped in right before the freeze.
People always point out hiw old the software in Debian is… but how many of these people actually A) use Debian enough to even know…
B) Actually require the bleeding edge version of the software they use?!
leech,
I primarily use Debian, and I have to admit there have been multiple occasions when the software in stable was missing critical features for me. For example, PHP and nginx in stable have been outdated. Those who want the latest software may be better off with the debian “testing” repo, Naturally with testing, there’s less of a buffer between you and upstream.
I wonder if there eventually be a ‘stream’ like what Red Hat have come up with, where they will create repos for newer things like php.
But as I have always said, testing or even sid is better for Desktop use. Stable is great for servers. But upon a new release, Debian has throughout the decades gotten MUCH better at being current upon a stable release.
I like a stable base system (including the desktop environment such as KDE), but I want the latest and greatest of most applications I activelly use. When I read an announcement about a new major version of an application I use, I get inspired and I want to install it immediately. Things like Digikam, Darktable, Gimp, Reaper, RetroArch, Firefox, and so on. It’s not about what I “require”, it’s about what I want. The older I get, the more I care about applications and less about the OS, and I want to have access to those same new versions of my applications as the Windows and Mac people have.
You can just use Flatpak / Snap / Nix for that. They’re all supported on Debian.
Yes, and I do. And I use Homebrew for up-to-date important command line tools such as ffmpeg and neovim.
Actually most cases when I needed more recent desktop software was because it included bug fixes that were disrupting my workflow, so in that case stable == buggy.
It seems like desktop software usually follows different release philosophy and release buggy / fix fast seems to be a preferred mode of operation.
The same approach would usually be quite catastrophic for mission critical server software. That’s why there’s not exactly one distribution that works equally well for a daily driver as well as server driver.
In this case it’s perfect timing because 5.27 is also a long-term release that will be supported indefinitely (until the unscheduled KDE 6 release and then some time).
But imagine the timings weren’t so aligned and Debian would ship with some random version like Plasma 5.26 and you know they’re fixing all these bugs and adding all these features upstream but not for you because you’re going to be stuck on 5.26 for another 2 years…
Devuan 5 should be released shortly then.
Although if there is something keeping you on init.d, start planning your migration to systemd already. In this era of EC2 VMs and microservices (containters), RedHat and Canonical will not abandon the advantages of faster boot times and container integration that systemd offers to please some people who obsess about memory usage or have religious aversions against using systemd.
Sooner or later, more and more packages will drop support for systemd-less distros and Devuan will have to do more and more work, until they inevitably quit.
If there is a technical reason for staying on init.d, fine, but keep in mind you are on leased time. Also, systemd will run your old init.d scripts, so I don’t see what those technical reasons could be.
kurkosdr,
Clearly you wouldn’t want to load things sequentially, but modern init systems aren’t the bottleneck. The main reason boot times are slow after hardware initialization is because of bloat plain and simple. My distro uses my own init system and it boots inside of a VM almost instantaneously, much faster than my headless systemd based computers and VMs do. Sometimes I use my distro to chainload other operating systems because it’s fast & compact and gives me a convenient way to perform administration (although “secure boot” has broken this configuration on some windows machines, grr).
RedHat and Canonical won’t remove “bloat” from their distros either just to please some people who like running minimal distros outside containers.
kurkosdr,
Ok, but if you really want to boot computers and VMs quickly then bloat needs to go. In practice though we generally tolerate slow bootup times on servers because it’s relatively rare.
I’m unhappy whenever the boot process blocks/hangs on an fsck or network drives, especially when we’re talking remote machines!! While it’s understandable that some FS/network operations are slow, I think distros should aim to bring up network services and remote consoles without delay. Similarly, my desktop would occasionally experience long shutdown/reboot delays (on the order of 5-10 minutes) because I had many shares open and shutdown the server before disconnecting the client. The OS was shutting them down sequentially in a loop rather than creating a separate task to shut down each share in parallel such that the timeouts overlap. The lesson for distros here should be that it’s not enough for different subsystems to run in parallel, their tasks should also be running in parallel even for something is innocuous looking as an “umount”..
People want that “bloat”, that’s the issue. Also, systemd itself has lots of features that make managing a VM easily like not having to write init.d scripts and being able to quickly see logs and service status.
kurkosdr,
I don’t think people actually “want bloat”, they just end up with it.
Which is not unique to systemd. Also systemd’s binary logs can be a con for some admins.
It was a matter of time before a “mainstream” distro like Debian backed out of their decision to not include proprietary firmware (I am using “mainstream” in the context of “mainstream with the 2% of Dekstop Linux users”).
When the main way to get your OS to users’ hands is by having people install the OS on a repurposed Windows box, it makes sense to include as many drivers as possible in order to make your OS compatible with as many PCs as possible. For 2% of the 2% the people who care about proprietary firmwares and have handpicked their hardware accordingly, there are more obscure distros that cater to them.
kurkosdr,
Debian already had non-free, but it wasn’t available by default. I think now they’re isolating non-free firmware into a new category and distributing it on installation media. I agree this could make installation easier for some users.
Which is the point here: forcing people to jump through hoops to get their proprietary firmwares is a usability hurdle that people who don’t care about proprietary firmwares didn’t ask nor want. And that 2% of the 2% that cares is served by more obscure distros. Glad Debian is getting rid of that usability hurdle.
kurkosdr,
I don’t remember if previously the debian installer prompted to setup non-free for the user, but ultimately I can agree with what you are saying
Good release; seems faster than Debian 11 was. Also it didn’t break anything during the upgrade process. The desktop is definitely more snappy. I kinda wish kernel 6.2 made it in, for the sake of Intel Arc graphics, but given the graphics card market now, where AMD and NVidia are dumping garbage at the mainstream (8GB in 2023 and now with a narrower bus width than two years ago!), I think I will punish the GPU market by not upgrading and using what I’ve currently got for as long as possible. If enough people do this, GPU prices will eventually be in free-fall, like they currently are with solid state drives and memory.
I’ve updated my system to Trixie now that Bookworm is stable. Debian is awesome. Already updated my machines to it. Can’t wait to see what Trixie brings, Super pumped for MATE 1.28. Hopefully we’ll get a full Wayland release sometime soon.