Debian 12 “Bookworm”
debian.org
debian.org
An important change appears to be the inclusion of non-free firmware by default in the official install image for the first time, as a result of this vote: https://www.debian.org/vote/2022/vote_003
Intriguing. I feel a little torn on this. One the one hand, I appreciate being able to install Debian from an official image onto a bothersome device. On the other, I can't help but feel we're losing something when even a purist distribution like Debian is forced to concede in the fight against proprietary blobs.
Edit: dropped the word 'kernel' from 'proprietary blobs', as rightly picked up by kind commenters below.
On the other hand, firmware is a convoluted issue. It was always present, but became increasingly visible over the years. While I'm a strong Free Software supporter, firmware is one of the hardest parts to convert, because of the IP it entails and trade secrets it embodies.
At the same time, you have a good point, these decisions are difficult and need to be very carefully weighted. Debian and RedHat are the two distributions that everybody else always ends up following so a major departure from established policy there has potentially huge impact downstream.
How is that different from the "if you want to run linux don't buy a winmodem" that we said convincingly twenty years ago ? Would you have approved that linux 2.0 added binary blobs to the kernel in order to correctly work with the hardware that you had invested in (some random winmodem) ?
But they don't have to choose Debian.
If Debian had maintained a strict "Free" stance, people could still use their troublesome hardware out-of-the-box simply by picking another distro that did include non-Free firmware in the installer. There are plenty of them. Like, 99% of all other distros.
Not all distros have to be everything to everyone. It's OK to have a niche.
This isn’t Debian’s niche though. Like many distros, Debian came with the free repos configured by default, but its had non-free packages available forever and they already had a non-free installation iso hidden away. The line had been crossed forever ago. Now it’s just a friendlier experience.
This is a good thing.
Point 1 of the Social Contract[0] is literally "Debian will remain 100% Free"
Please explain how championing Software Freedom would not be Debian's niche.
Because you wouldn't be pushing those users to an alternative linux distro, you'd be pushing them to Apple and Windows and that's far more damaging to FOSS than to include some firmware blobs. The issue was debated at considerable length, I've followed the debate (because I use Debian and Debian derived distros on all of my machines, including laptops, servers and desktops) and I'm happy to see this outcome because it shows a certain level of maturity. The world isn't easily defined in terms of black and white. Debian is doing a great job and this minor concession is only going to strengthen its position as the FOSS distro of choice because more people will end up being able to use it successfully.
Note that far more people care about whether or not a distro works on their machine than whatever narrow reading of 'The Word' causes it to malfunction. Builders are few, consumers are many and I'd much rather see Debian succeed in the long term than die on the hill of FOSS purism.
When thought with a clear and unbiased mind, Debian did the absolute best they can do.
Add firmware, be open about it, install only when necessary, allow people to opt out when they know what they are doing.
The Linux-libre people even removed the warning that the CPU is vulnerable to spectre/meltdown if you don't update the microcode. But ... your CPU already comes with that microcode out of the factory, just a different version of it. How is running an older known to be buggy microcode better?
As far as I know, Debian does not distribute proprietary EEPROM firmware updates at all, as these are generally not required to use the hardware (and, depending on the device and update in question, may or may not be recommended for most users).
In other words, the difference is practical, not ideological.
My point was that the entire position just doesn't make any sense: either you reject all non-free software no matter how it's loaded (which means there are very few computers you can actually use), or you just use your hardware with "non-free firmware" that would be baked in anyway and stop worrying about the entire thing.
The plan is to have it ready for Debian 13: https://lists.debian.org/debian-devel-announce/2023/06/msg00...
If you want the maintain the status quo you support the hardware that has the most users, if you want to change it you also support the hardware you want them to use.
The relevant documentation is here: https://wiki.debian.org/PortsDocs/New
Also, the rules for becoming an official port is here: https://ftp-master.debian.org/archive-criteria.html
When RISC-V satisfies the relevant criteria, they can become official.
Also, maintaining a port is tremendous amount of work. Debian users only see the tip of the iceberg. There's so much beneath that.
Is RISC-V the be-all, end-all? No, but it could help them get a lot closer than they're likely to get with any of the proprietary ISAs.
This is just like Debian generally does not write new useful software to put into Debian, and instead depend on outside, “upstream” authors to write software. Some other organizations, like FSF and its GNU project, will have advocacy roles, and do have the incentives to write new software and to help porting to new architectures. It is there that the motivations for this work must be found. Of course, individual people can be involved in more than one organization, and many Debian people happen to be enthusiastic advocates, and will in fact often do this work. But the reason for them doing this work is not, mostly, rooted in them being a part of Debian.
Therefore, and this is my point, if you want this work to be done, you can’t exhort Debian to do it. It will not work. Ask instead why someone else, whom you think should be motivated to do the work, does not do it.
Yes, but my point is, they weren’t doing that work just because they were Debian contributors; they had their own additional reason for doing it. They were not assigned the work by Debian central command. Therefore, asking Debian why Debian does not do some work or other is usually the wrong way to get something done.
That said, the community of contributors are what makes up the Debian project, so in a sense it is Debian deciding to do things when Debian does things :)
If they conflict with RISC-V's own space, the chip can't use RISC-V trademarks.
And, of course, the RISC-V Consortium will never adopt proprietary extensions, as that goes against its core values.
Everything else matters as much as FSF point of view on something being free or not.
So that we do not have to rely on anybody's goodwill.
Just like many open core products that really need the full deal for being usable in a proper way.
Expecting otherwise is whishful thinking, or academia/maker community focus.
Including but making it optional was an excellent decision. Those who need will get what they want, those who don't will have the same result as with Bullseye.
The sad truth is that the Linux distributions recommended by the FSF have approximately zero users.
it makes it easy to get working
...and it also carefully attempts to lock you in using packages that can't¹ be disabled.
just saying it is a slippery slope.
[1] well with effort you can
https://www.baeldung.com/linux/snap-remove-disable
https://gist.github.com/jfeilbach/f4d0b19df82e04bea8f10cdd59...
Eg I intentionally got an old ath9k PCI-E wifi card for my Debian 11 router because it works without proprietary firmware, unlike newer ath10k etc cards.
I agree, but I also think this depends heavily on who you ask. Stallman for example would rather have poorer functionality than compromise his personal (extremist) ethical principles.
There are a lot of folks who use laptops without wifi because the blobs are non free, so they're using ancient ThinkPads plugged into Ethernet.
Much depends on your personal computing needs.
Stallman is open to pragmatism now and again. For example, on this very topic:
https://www.gnu.org/philosophy/free-hardware-designs.en.html
> We can envision a future in which our personal fabricators can make chips, and our robots can assemble and solder them together with transformers, switches, keys, displays, fans and so on. In that future we will all make our own computers (and fabricators and robots), and we will all be able to take advantage of modified designs made by those who know hardware. The arguments for rejecting nonfree software will then apply to nonfree hardware designs too.
> That future is years away, at least. In the meantime, there is no need to reject hardware with nonfree designs on principle.
Not a single thing I've ever read about him has indicated this to be even remotely true. We're talking about the guy who used a Lemote Loongson-based laptop in text mode for years and isn't capable of uploading HTML to his own website (he has to rely on volunteers to do this for him, per his own website).
All that in the pursuit of ideological purity.
If you have firmware/software/whatever in a device, which is updateable (as opposed to mask-rom or hard logic), I'd much rather have it transparently managed by an OS I can control, than some EEPROM with often proprietary, inscrutable, I-ask-you-nicely-please-update-your-firmware update mechanism.
IMO, the difference is:
- with OS provided firmware (and preferably no writable storage), I can be sure my device is running the same SW as the rest of the world
- with dozens of EEPROMs in my device, I can never be sure what is running on it.
Firmware that is legally not redistributable is a non-trivial, though perhaps less bothersome issue. Firmware that requires manufaturer's signature is bothersome but I would still prefer it over inscrutable hidden firmware.
The software needs hardware to run, and the whole point of the software is to make the hardware useful. If you can't use the hardware, what's the point of the software?
In my book, freedom is a function of usefulness. No amount of redistributable source code has any value to me if I can't run it.
Enabling the use of hardware I already own is not a compromise, it's a solution. It's what operating systems exist for. Debian is fulfilling its primary function. I'm glad that this necessity was finally recognised.
By being forced to install non-free BLOBs to be able to use "our" devices we actually admit that we're not the ones who actually control "our" computers. That's admitting full defeat! You're not the owner of "your" devices.
Given that computers are now kind of "brain extensions" this means you're not in control of a substantial part of yourself.
This has quite some implications! And I'm not even thinking about such things like future computer devices connected directly to human brains…
I had more than once, back when I first installed Debian in the late 1900s and early 2000s, and I believe my experience wasn't unique.
Back then, not requiring any loadable firmware was common; the hardware either didn't require firmware, or came with the full firmware in a ROM chip in the device itself. And that explains the issue: Debian is an old distribution, coming from these times when not having non-free firmware (or even any firmware at all) in the distribution was viable, and often fully usable.
And if I'm not mistaken, this isn't about kernel blobs (which run on the CPU as kernel code), only code that gets loaded on devices (including CPU microcode).
If it can go wrong it will, and if software isn't free then its owners will do things that the users really do not like. In this case, if they can fix bugs they can reduce functionality post-hoc. That is consequential. It is better to have freedom or certainty as to what a device does.
As a practical example, I have never heard anyone considering the freedomness of firmware in eMMC flash memory chips. But the talk "eMMC hacking, or: how I fixed long-dead Galaxy S3 phones" from CCC reveals that actually, Samsung eMMC chips have an undocumented debug interface to read/write the RAM of the firmware running on the ARM core inside the eMMC chip.
The legal system sometimes has definitions of copying that aren't that straightforward. I've seen in a copyright context judges talk about a computer loading software into RAM being copying.
Intel microcode comes with a license: https://bugs.gentoo.org/664134
IANAL, but this is a general concept of exhaustion of IP rights when the IP is sold as a part of physical medium, see (28) and article 4 of EU copyright directive 2001/29.
> The legal system sometimes has definitions of copying that aren't that straightforward. I've seen in a copyright context judges talk about a computer loading software into RAM being copying
This is handled in (33) of the directive:
"The exclusive right of reproduction should be subject to an exception to allow certain acts of temporary reproduction, which are transient or incidental reproductions, forming an integral and essential part of a technological process and carried out for the sole purpose of enabling either efficient transmission in a network between third parties by an intermediary, or a lawful use of a work or other subject-matter to be made."
As far as I'm aware, nothing has recently changed in this regard. It's more of a reflection on the mentality of young members, those who tend to treat software as if it's in a vacuum, separate from all the social and moral concerns of the meatspace.
It's not exciting, but a fair amount of the time, this is what people expect from their operating system. Support my hardware, give me the software I need, and stay out of my way otherwise. And that is what Debian does very well.
If I had dozens of desktops and/or servers to take care, I would probably take the time and upgrade a few non-critical machines to see how it goes, provided I have the resources for that.
If in doubt, there's nothing wrong with waiting a month or so to see if others run into trouble. It's what I did when I worked as a Windows admin, and it saved me from major headaches more than once. (Admittedly, updates causing trouble is more common on Windows than on Linux in general and Debian specifically.)
That's good feedback and I've heard it from other people. Personally I've never been able to dist-upgrade Rapbian or Ubuntu without breaking the OS.
Raspbian has been problematic for me. I tried upgrading from Buster to Bullseye, and it went so badly I ended up reinstalling from scratch. (To be fair, the docs were clear that was a likely outcome.)
OTOH, my ThinkPad x220 has been running Debian since 2016, I installed Jessie back then and upgraded as new stable versions were released. The upgrade to bookworm has finished by now, and it's been entirely unexciting. :-)
Actually searching turns up https://access.redhat.com/documentation/en-us/red_hat_enterp... , which... appears to use a totally different tool? I don't really know what's going on there, but it does looks like they have some sort of support for in-place upgrades now.
> An in-place upgrade is the recommended and supported way to upgrade your system to the next major version of RHEL.
As for RHEL-clones, your only choice is to use ELEvate(1), by almalinux, which supports other distros too.
But overall the process isn't as simple as Debian/Ubuntu, and on clones other than alma, you need to resort to third party tools, with some clones like Rocky saying that in-place upgrades should be avoided.
Much gratitude from a Slink-and-a-half user, back in the day.
If you go also by how much those distris are used it's even like 9x% of the stuff running out there is Debian based.
There are almost no independent distris. You have Arch, you have SUSE, you have RedHat and a few clones, you have Gentoo. But more or less everything else is Debian based.
But I'm not sure Slackware is still at this point relevant enough to be named in a row with the others I've mentioned.
Of course the sampling was subjective, and I didn't intended to marginalize any not mentioned distris. I just thought the others are too niche to be included in such kind of pick.
Here a list of almost all the OS distris I've left out:
https://distrowatch.com/search.php?ostype=All&category=All&o...
Besides mentioning Slackware for historical reasons I should have also mentioned NixOS, which I forgot.
The former was the first Linux distri, the later gained some respectable user-base in the last years, I think.
Ah, and there is also Alpine which you can see sometimes here and there. (People using it in containers for reasons I've never understood as that's imho a recipe for trouble.)
But if you look at the rest of the list most of the stuff is really obscure. (I've tried some Solaris derivatives and Exherbo in the past but didn't even heard of all the other names.)
Musl is still a kind of experiment. I would not recommend running experiments in production…
Just a few random links:
https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine...
https://news.ycombinator.com/item?id=28312433
https://www.linkedin.com/pulse/musl-libc-alpines-greatest-we...
https://martinheinz.dev/blog/92
https://www.linuxquestions.org/questions/linux-software-2/mu...
https://unix.stackexchange.com/questions/729342/performance-...
https://github.com/rust-lang/rust/issues/70108
https://news.ycombinator.com/item?id=23080290
https://vector.dev/highlights/2020-07-09-add-musl-and-glibc-...
There are more. Much more of those!
Musl exist in large parts just for ideological reasons. It still rides some hype in industry as industry hates GPL software…
marpstar was correct.
I am a Debian fanboi since Slink. Since it was drilled into me by rvdm, ssmeenk, miquels, jdassen and dth.
And have seen Debian survive and thrive a lot of critisism. "Too slow release cycle, not Free(Dom) enough, Too free, systemd, too much politics, too many architectures, etc....etc....etc.."
Yes, any large community will be flawed and deliver flawed solutions. And I for one celebrate those flaws and features, and appreciate the sheer magnitude and accomplishment of this enormous, complex, great project.
Ubuntu 22.04
Kernel 5.19 (new installs only, existing installs 5.15)
systemd 249
KDE Plasma 5.24
Gnome 42
Debian 12
Kernel 6.1
systemd 252
KDE Plasma 5.27
Gnome 43For most purposes, though, I find that I increasingly don't care about 1 or 2 years of difference in the base OS. Most of the toolchain is stable and well established. There are only a small handful of things I want to pin to a specific version (like node.js or Python), but these can usually be installed side by side with default packages. If not, I can always install it in a container. :)
Ubuntu probably do the HWE kernel better than stable backports kernel, the HWE kernel has a release schedule.
There's been more community support for Ubuntu in the form of PPAs but Flatpak has mostly solved that problem for the things I care about.
As such, I've already switched all my laptops to Debian, and will switch my desktop and work computer when I can be bothered.
For a while the Debian kernel packages had -ckt suffix (Canonical Kernel Team), although it doesn't seem to be the case any more.
Also, an estimated 96.3% of packages are built reproducibly for amd64.
https://tests.reproducible-builds.org/debian/bookworm/index_...
- Some day 22.04 randomly started without GUI and I couldn't get it back either with ubuntu-desktop and startx
- I installed a Python package without a virtual environment and it somehow interfered with system Python, bootloader broke
It's possible that those errors were recoverable but I'm not a linux expert and I couldn't repair it after ~2h of stackoverflow
Shouldn't the OS python be protected by root?
Coincidentally, doing this is now disabled in Debian Bookworm.
I always had trouble booting proxmox the first time, because even though it is a server os with no graphics, the installer is graphical. I would get black screen at boot.
I would just interrupt hte boot use 'e' to edit the command line, add 'nomodeset' and it would boot.
Perhaps this is a good opportunity to try a combination of Debian, for general system stability, and Nix, for specific tools where I need newer releases? Has anyone tried this combination before? If so, how did you find it?
It is Ubuntu-based but without the bad parts like snap. So you get to keep access to all the Ubuntu packages but also your sanity.
She went from needing tech support every time I was at her house to never overnight.
I highly recommend Mint for this scenario.
[1] every couple of years in my experience... typically as they're getting closer to a new release and package breaking changes are needed/slip through.
Pinning some security sensitive packages to stable or unstable might be worth considering. E.g., if running testing on a client, pin firefox and extensions to stable + stable-security (note, globbing works too):
/etc/apt/preferences.d/firefox:
Package: firefox-esr
Pin: release a=stable
Pin-Priority: 999
Package: firefox-esr
Pin: release a=stable-security
Pin-Priority: 999
Package: webext-ublock-origin-firefox
Pin: release a=stable
Pin-Priority: 999
Package: webext-ublock-origin-firefox
Pin: release a=stable-security
Pin-Priority: 999
If there are only a couple things you want to update to newer versions that are not in backports, you can just run stable, and pin those packages to versions in testing or unstable (but only if those packages pull in no / only a few dependencies not used by other packages). If you add e.g., testing/unstable sources to a stable system, add a catchall pin to force those packages to a low priority by default to prevent accidentally updating your entire system e.g., for sid:
/etc/apt/preferences.d/sid:
Package: *
Pin: release a=unstable
Pin-Priority: 10
https://wiki.debian.org/DebianTesting#Best_practices_for_Tes...
Otherwise this is good advice.
Debian is fine right up until you have to build something and find that the dep you need is too old so you have to build that from source, and that dep has a dep that's too old so you have to... basically build hell.
Arch seems to not have these problems but is a hair buggier on occasion.
Ubuntu 22.04
Kernel 5.19 (new installs only, existing installs 5.15)
systemd 249
KDE Plasma 5.24
Gnome 42
Debian 12
Kernel 6.1
systemd 252
KDE Plasma 5.27
Gnome 43for them: Whatever you download is going to be "Debian Stable." Debian Stable is as fresh and up-to-date as it's ever going to be at this moment, but it will not change significantly in the future, because its goal is stability. You throw it on something you want to run for years and not crash.
If you don't mind your system crashing every once an a while because you like new stuff, you use "Debian Testing." There is no place to download this directly from Debian, although some third-parties (like Canonical with Ubuntu) distribute customized versions of it. The way you get a non-customized version is by installing Debian Stable, changing sources.list to point at Testing (which you can do as "testing" or by its nickname), then dist-upgrading. Debian Testing is being tested to be the next Stable.
"Debian Unstable" afaict is where individual pieces of software are being tested to go into Testing. Nobody should be running it unless they are contributing to Debian, although there are apt-get masters who know exactly what they're doing who will pull bleeding edge packages from unstable individually.
About the nicknames: Stable, Testing, and Unstable aren't releases, they're an indication of the current status of a release. Each release has its own goofy name. "Bookworm" has just moved from Testing to Stable. "Bullseye," which until just now was Stable, has now become "Oldstable."
Also important is the "[yourrelease]-backports" repo, which Stable users can add to take newer packages from Testing that are 99% certain not to mess with the stability of Stable. Stable + backports is a compromise between Stable and Testing for people who want new stuff that doesn't break things.
I'm sure most people know all of that, but 1) when it comes to things like this people are often afraid to ask because they're afraid they'll look stupid, and 2) the Debian website is very utilitarian and not marketing oriented, so there's no clear entry point for people who don't already know what they're looking for.
Trying to run a mix of stable and testing packages can be a pain as occasionally a package you want to bring in from testing will try to bring with it new system libraries, which in turn often conflict with the "stable" versions of packages (so you are forced to move a lot more of your system to "testing" packages than you originally wanted to fix this).
The key advantage (at least for me) of using the "backports" repositories is that it avoids this - packages are compiled against the "[yourrelease]" system libraries.
Ubuntu is based on Sid (Debian Unstable).
You can download Debian installers for Testing.
Usually nothing on Testing crashes, as such severe bugs are considered blockers to move a package form Unstable to Testing. (Of course once in a few years something slips through the testing period in Unstable. But it's than usually repaired within a few hours.)
People are running Sid. (Even I personally wouldn't recommend it.)
But one point of the parent I strongly support:
Debian's web page is a mess. I'm using this system for decades but still don't find anything on the Debian page without the help of some search engine. Also, when I need Linux related documentation I go to the Arch Wiki (and sometimes to the Gentoo docs), even as a Debian user. OTOH, you only seldom need docu, because Debian "just works" for the most part.
A lot of end users of different distros do not even know that Debian is the foundation. I will as go as far as to say Debian had solved a lot of the hard issues and then other sprinkle it. (Probably not a popular view)
Anyways thanks to all the Debian team members. Your work ought to be better known.
will installing over the internet work without DNS resolution?
> You are running Debian stable, because you prefer the Debian stable tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. This is where backports come in.
> Backports are packages taken from the next Debian release (called "testing"), adjusted and recompiled for usage on Debian stable. Because the package is also present in the next Debian release, you can easily upgrade your stable+backports system once the next Debian release comes out. (In a few cases, usually for security updates, backports are also created from the Debian unstable distribution.)
I have some gripes about the installer's partitioning tool but I suspect that it would have been fine if I was willing to reboot a couple more times. The laptop was locked down and I needed someone to type the BIOS password every time I wanted to boot off the USB stick.
I wanted 4k blocks all the way down but got stuck with 512b sectors.
It feels like the blog post was written before images were created, but they forgot to add a comment saying when it'll be available for download and published anyway.
I understand by the comments that the apt repos were already updated, so you could install bullseye 11.7 and upgrade to 12 in the OS, but seems a convoluted way to do it. I guess I won't be trying out 12 this weekend.
This HN post jumped the gun a little with the Debian Wiki page: the final official release happens when https://debian.org/ gets updated to point to the new installation media.
Time to flex new SSD drive and install ALL the packages. Of course, I'll do it a bit later, when downloads will get back to normal levels.
https://www.debian.org/releases/stable/i386/release-notes/ch...
Read the documentation, follow it.
https://www.debian.org/releases/bookworm/amd64/release-notes...
> Just apt upgrade?
Mostly (please do RTFM):
# update to latest point release of current system:
sudo apt update
sudo apt upgrade
sudo apt full-upgrade
sudo apt --purge autoremove
# Update sources list
sudo sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list
# upgrade to bookworm:
sudo apt update
sudo apt upgrade --without-new-pkgs
sudo apt full-upgrade
sudo apt --purge autoremove
Generally no, unless you've specified/use third party (or to a lesser extent "back port") software sources.
What had kept me on Ubuntu so far has been their out of box laptop support (I.e. WiFi drivers).
What I did not like was Firefox taking 20s to start.
Not a heavy user though - maximum 15-20 VEs (virtual enforcements) per server.
Yeeei My favorite Fast Linux distro keep going !!!
Congratulations
https://www.reddit.com/r/debian/comments/12gyjpg/debian_mate...
https://www.reddit.com/r/debian/comments/13ueaub/debian_12_m...
https://tracker.debian.org/pkg/dnscrypt-proxy https://tracker.debian.org/news/1366204/dnscrypt-proxy-remov... https://bugs.debian.org/1017302
Do I miss something?
https://wiki.debian.org/Init#Changing_the_init_system_-_at_i...
But it seems the efforts to actually restore the compatibility of some components with sysvinit is from devuan, not debian. May be wrong again.
Those are steps in the right direction. But I stay alert: I know that sysvinit experience could be actually desastrous on debian compared to devuan. Not to mention the debian "default" is systemd: we all know how critical is the choice of the "default" on the long run, that's why I may still go to devuan.
Don't blame Debian if the Debuan contributors fail to send their patches upstream.
Well, it seems it did not last.
Maybe I'm asking too much, but for me "official" support would mean that I can do it from the installer directly, no terminals and chroots required.
[1] https://www.goodreads.com/quotes/40705-but-the-plans-were-on...
But one is grotesquely and absurdely bigger and kludgier than the other one, so this is more about choosing the lesser evil...
Systemd seems to be propelled by distro packagers and developers, but for admins/users, it's not that great.