Debian 12 [1]should appear some time in the middle of 2023 (but beware of the typo in that post).

You could have pointed to the [2]corrected announcement...

[1] https://lists.debian.org/debian-devel-announce/2022/03/msg00006.html

[2] https://lists.debian.org/debian-devel-announce/2022/03/msg00008.html

This is just including non-free in the temporary installer which runs in RAM and vanishes when its job is done. It makes extreme sense for the installer to "just work" on the widest possible range of hardware.

It makes no sense to push dishonour onto a hard drive when the user does not wish it to be there. Despite the impression given in the article, such users are still honoured. Last time I installed Debian, the installer offered me the explicit choice; did I want to accept non-free stuff in the main build or not? As far as I am aware, that has not changed.

Strictly speaking if you're going the pure free route, once the non-free code has had its chance to hit your CPU the game is over no matter what gets saved on the hard drive for later.

However firmware never actually hits the CPU as code so the question is moot and this winds up being a move in the right direction.

Question: How is a user's honour affected when the same firmware is loaded into the co-processor from a ROM baked into the hardware rather than from temporary or removable storage?

-> If your internet connection is via Wi-Fi, for instance, there is a strong probability that the default Debian ISO will not be able to bring up Wi-Fi

I have been in this position with Debian. While I knew how to solve it, I can easily imagine how utterly arcane this would look to a person new to Debian or to Linux in general.

I applaud Debian's puritan attitude towards FOSS, but it has cost them dearly over the years. It is a lost argument to talk about FOSS firmware when somebody just wants to get on line.

Exactly. If there are wizards who know how to get wifi working without a non-free blob, more power to them. I have done the firmware both ways. If I need to download the drivers separately, it's just one more item on a pre-installation checklist. Even then, it only works for me because I have *another*, already connected computer. I pity the one who takes the plunge with Linux on their only PC, to find out afterwards they missed a step ... and in order to get connected to the internet they need to go online and download some firmware. Oh wait.

Arcane even for a Linux veteran.

Back in 2016 I replaced/upgraded from my old Toshiba Tecra A11 which ran Linux Mint 17, to a Lenovo P50(using it right now still), which I also put Linux Mint 17 on, everything seemed fine. Wifi didn't work but I didn't know that (yet) because I had no need for wifi at home my laptop stays wired.

Fast forward 2-3 months..

I moved out of my home, put my stuff in storage. Was going on a 3 month trip(and moving to another city when I got back). Checked into a hotel near the airport and tried to get my laptop on Wifi. It did not work. I was confused.

After some research on my phone I determined that the default kernel in Mint 17 was too old, and that the Intel wifi drivers for my chipset only worked on the newer kernel. That just seemed absolutely insane to me, as someone who has run with Linux on their desktop since 1998. I was running a still fully supported distro (at the time), with what was in my opinion, a very conservative hardware configuration (chosen in large part due to Linux support).

I have no problem compiling or installing a 3rd party driver, but the Intel website that had the code made it clear the driver would not work on any kernel less than version X (I don't recall the version number exactly). After maybe an hour or so I managed to get all the software I needed downloaded to my phone and then transferred to my laptop over USB to get wifi working.

But even then it had issues, so I made a "wireless-fix" shell script which from what I see just ran "rmmod iwlmvm; rmmod iwlwifi; modprobe iwlwifi", which got wireless working again in a few seconds when it crapped out.

Since re-installing with Mint 20 a few months after it was released (wanted a fully fresh/clean install, Mint 17 is still configured as another boot item in grub) haven't had to use that script though my wireless usage has been pretty minimal since.

I've never advised anyone to use Debian as their laptop/desktop if they are a newbie, unless they are prepared for some extra work to get stuff going. As per the article myself I stopped using original Debian on my desktops/laptops probably around the time Ubuntu 7 or 8 came out I don't remember, switched to Mint(for MATE) after Ubuntu 10.04LTS went EOL. I continued to use Debian on all of my personal servers up until Devuan came out and switched to it. At work my servers have been Ubuntu for the past 12 years now (originally didn't like it as before I was always RHEL/CentOS on work servers, even though I was Debian/Ubuntu at home).

Excited to see what Pipewire can offer us.

Long had a lot of problems with Pulse Audio and the fact that we have to go to a separate system, Jack, for audio production makes audio unnecessarily convoluted in Linux.

Be careful what you wish for.

Pipewire is a long way from competing with Jack. Apparently it doesn't like rt kernels, and in a pure audio creation setup it's difficult to direct audio from exactly where you want, to exactly where you want without anything else coming along for the ride. Oh, and you won't get anywhere near the low latencies possible with Jack.

... it might make life a little easier.

On hardware that I'm confident will work out of the box, I prefer to install Debian. So that's most laptops ruled out. Or anything else that I want to connect over WiFi. (Give me an RJ45 any day, unless the device regrettably hasn't got one of those, obviously, or I need to use it nowhere near a wall, such as right now perched on the dining room table.)

If not, then something more pragmatic. Mint, in fact.

I've nothing personal against the Ubuntu guys, nor those that turned it into Mint. In fact I'm very grateful to all of them. But I'd rather eliminate as many layers as possible, so this could be a turning point for me. On my next machine... perhaps.

-A.

good move imho. just provide a "no BLOBs" checkbox if someone really doesn't want them? Really, though, for me there's a distinction between closed source software (not portable to other cpu architectures, could have dependency problems down the road if they don't update it, etc.) and binary blobs (they have some stuff that would have been in a rom on the device 25 years ago load into ram instead, it's running on the wifi card or whatever, not on the main cpu.)

I'm not entirely sure the whole premise is correct. What firmware is needed during the installer?

GPU firmware? Really a text installer should be used until you have enough of the environment installed and set up to tackle X11 / Wayland config properly. Just loading up a GUI installer and "hoping" everything is working is a little bit flippant. I think even Windows keeps to the basic VGA drivers until installed.

Network firmware? I don't even recommend installing an OS whilst online. Again a completed install along with correct firewall and verification of listening ports should be done before you put the machine anywhere near a network.

Bluetooth firmware? Bluetooth isn't supported by the GUI or cli installer anyway.

Audio firmware? I don't believe there is a text to speech reader (Knoppix Adriane is pretty good for those interested)

The only firmware I can see as useful is for specific SATA / NAS / disks but much of this stuff is needing to use the CLI installer / manual setup that the guys with this kind of hardware probably know how to add the firmware files for their hardware.

So personally I don't think firmware is a problem (and platform agnostic firmware blobs don't particularly annoy me compared to unportable driver blobs) but I think people are possibly installing the OS in a sloppy error prone way.