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.
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?
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.
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 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.
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.
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
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.
[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.
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 43A 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?
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.