[troad]

Congratulations to the Debian team!

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.

[bayindirh]

I was involved in the discussion, and I'm also torn on that issue, but at least you can disable installation of non-free firmware and install Debian without any non-free software.

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.

[jacquesm]

That and the simple fact that without it the hardware you've invested in won't work. So this is very much an individual choice, if you don't have such hardware you are fine but shouldn't be voting on whether or not someone who does have hardware that won't work without proprietary blobs has to go out to buy new gear. There are all kinds of considerations that go in to this decision (for instance: environmental impact) and I'm all for compromise when it helps out others.

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.

[enriquto]

> the simple fact that without it the hardware you've invested in won't work

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

[jacquesm]

Winmodems had plenty of alternatives, for PCs the choice is usually limited to 'what you were given' or 'what you recycled from a dumpster'. Linux is typically not the first OS to be installed on any given piece of hardware (even if brand new plenty of people pay either the MS or the Apple tax). And because those are exactly the people that benefit from having a working PC I'm all for maximizing their chances. Choice is a luxury.

[Karellen]

> Linux is typically not the first OS to be installed on any given piece of hardware. And because those are exactly the people that benefit from having a working PC I'm all for maximizing their chances. Choice is a luxury.

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.

[realitythreek]

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

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.

[jacquesm]

Fortunately Debian recognized that being a 'niche' would sooner or later spell the end of Debian and that would be a loss.

[bayindirh]

When you are one of the biggest “root” distributions, and the template of countless big and small time derivatives, you don’t have the luxury to have niche.

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.

[nunesvn]

We’re on the laptop age, most people can’t pick and choose the components of their computers.

[boricj]

Usually, people first buy a computer and then hear about Linux later, not the other way around.

[5e92cb50239222b]

It's also close to impossible to choose fully Linux-compatible hardware for some of us. Whatever decent Thinkpads there are left are practically unavailable in my country, unless you're willing to buy from foreign sellers without any warranty and pay hundreds of dollars for shipping. Things like Framework are completely unavailable and probably will be for the foreseeable future. I use desktops exclusively so I can pick and choose, but I am in the minority of a minority.

[arp242]

As I understand it "firmware" is essentially just the same as an EEPROM, except that using volatile memory is cheaper and easier to upgrade. No one seems to have great issues with EEPROMs (FSF doesn't anyway), but uploading that same code to the device when it starts is a huge problem? I never understood this, and especially given the huge practical trade-offs the entire thing seems fighting windmills.

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?

[jasomill]

Debian distributes firmware stored in volatile RAM because it is either required to use the hardware, or, as is the case for CPU microcode updates, highly recommended for most users.

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.

[pabs3]

Debian distributes fwupd, which accesses the Linux Vendor Firmware Service, which distributes updates for proprietary firmware stored on devices:

https://fwupd.org/ https://wiki.debian.org/Firmware/Updates

[arp242]

Organisations like the FSF recommend that you don't use devices that require "non-free firmware" at all. They don't recommend anything like this for devices with "non-free EEPROMs at all". Stallman himself has stated he has no problem with such devices (I can't find a direct quote on this right now, but I'm 100% sure I've seen Stallman write or say this at time point).

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.

[blihp]

While I'm glad to see proprietary firmware both included and segregated in its own repo, I'm wondering why RISC-V wasn't added as a supported architecture in Debian 12? It seems like that supporting at least an open ISA would move closer to the possibility of what Debian wants to see happen... so why isn't it as a distro helping to make it happen?

[seba_dos1]

It's simple - because the port is not ready yet.

The plan is to have it ready for Debian 13: https://lists.debian.org/debian-devel-announce/2023/06/msg00...

[pabs3]

At the end of the day, this was because the hardware ecosystem (and the hardware support in Linux/bootloaders/etc) isn't really "ready" yet, and also there was slow and unclear communications between the porting team, the core Debian teams and one of the hosting providers. Eventually the teams provisionally approved the port, but after that the needed actions weren't done in time for the archive-wide rebuild that happens during the process of an unofficial port becoming official. I'm not on the porting team, but am on the Debian sysadmin team, and tried to speed up the process and make it more transparent. Debian contributors are mostly volunteers, so things take time.

[blihp]

Sorry for the lag in my reply (I just noticed your response)... I very much appreciate the info as I found the lack of official RISC-V support in 12 surprising. I hadn't read about the blockers to being ready for the release which makes perfect sense. Looking forward to seeing in in 13!

[teddyh]

https://wiki.debian.org/RISC-V

[blihp]

That doesn't answer the question. It's still 'unofficial' per https://wiki.debian.org/SupportedArchitectures

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.

[bayindirh]

In Debian, there's no single entity which decides on things. There are rules, and processes.

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.

[teddyh]

Who is the actor in this scenario who wants to change the status quo and therefore support the RISC-V platform in Debian? I.e. who are the people with the motivation to do that?

[blihp]

The Debian project has been historically a vocal proponent for open hardware/firmware/drivers etc. and here we are in 2023 having Debian somewhat controversially acknowledging that proprietary firmware may be required at least by some users, to some degree. So I am suggesting that if they really want to get there that they might need to help facilitate the change they would like to see.

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.

[mikae1]

> you can disable installation of non-free firmware and install Debian without any non-free software.

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.

[yrro]

Debian was never a purist distribution. If it was then there wouldn't have been a non-free section in the archive in the first place.

The sad truth is that the Linux distributions recommended by the FSF have approximately zero users.

[Kwpolska]

Is it sad? Actually working Linux on real hardware is far more important than purity IMO.

[m463]

Ubuntu is based on debian and is pretty pragmatic in that respect.

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

[Arnavion]

It's sad for the people who don't share YO.

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.

[nvy]

>Actually working Linux on real hardware is far more important than purity IMO.

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.

[amiga386]

> Stallman for example would rather have poorer functionality than compromise his personal (extremist) ethical principles.

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.

[nvy]

>Stallman is open to pragmatism now and again.

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.

[teo_zero]

Please note that in the paragraphs that you quoted Stallman is talking about hardware, not firmware. He tolerates firmware blobs only if they are loaded once to the device and never changed (yes, I know it's more complex than this, read the whole essay for more precise information).

[josephcsible]

I think this would be a better summary: it's okay for hardware to have code that's baked in at manufacture time and can never be changed thereafter. It's not okay if, after you buy hardware, the manufacturer can modify the code but you can't.

[yrro]

Sad in that I'd love to purge all non-free software from my life, but that has proven to be impossible and increasingly more so as the years go by.

[mistrial9]

at those great (FSF) heights, the light is bright but the air is thin!

[labawi]

While I don't like proprietary firmware, I'm not sure if the line is drawn at a useful place.

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.

[rollcat]

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

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.

[still_grokking]

I disagree. I'm very disappointed that this "necessity" came into existence in the first place.

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…

[arp242]

You don't control the hardware in the first place. Can you modify the microchips on your hardware? Can you modify the printed circuits? Can you modify a ROM in hardware? In all those cases the answer is "not really", short of some spectacular reverse engineering effort and specialized hardware and skills that even most technical users don't have (you can modify anything with enough effort). All this focus on firmware seems rather misplaced.

[5e92cb50239222b]

Let's not conflate hardware with software. The first one is practically impossible to modify for a completely different reason than the second one (physical limitations and the need for specialized hardware that costs serious money vs artificial limitations imposed by developers). You can at least repair it (unless you bought into the Apple ecosystem — you knew what you were getting into then), and a relative of mine makes good living doing just that.

[arp242]

Firmware is inextricable tied to hardware; you could pretty much say it is hardware. Hardware has had "software" in it for decades and no one complains about it either, except when this software is loaded in a particular fashion.

[rollcat]

Then don't buy hardware that requires non-free firmware.

[GrumpySloth]

I've never had a computer which would work with the official ideologically-pure installer. Always had to use the non-free one. I'm glad this vote turned out the way it did.

[cesarb]

> I've never had a computer which would work with the official ideologically-pure installer.

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.

[NikkiA]

Same, and I used to keep a little cache of 'known working without firmware issues' wlan cards (pcmcia), I probably still have some somewhere; though I don't think I have any pcmcia capable laptops anymore

[progval]

For devices which have firmware, does it matter whether the firmware is loaded by the OS rather than hardcoded inside the device? The former at least gives an opportunity to fix bugs.

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

[roenxi]

There is a little ritual we do here from time to time where someone writes a comment that starts something like "Well, I didn't expect Stallman would be right about [issue now being reported on] but he predicted this years ago".

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.

[dezgeg]

How can you ever really be sure that there is no way to change the code running on the hardware, either unintentionally via some exploit, or intentionally via a deliberate backdoor or a debugging interface enabled in production?

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.

[zajio1am]

There is a difference from legal point. If the firmware is hardcoded in device, you do not need to accept any license contract with IP holder. You do not need to copy it, and your right to run it is implied from ownership of the device. If the firmware is independent part bundled with OS, then anyone who wants to run it or even just distribute the OS must accept the license.

[iudqnolq]

Are you guessing what sounds logical to you or do you actually know the answer here?

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

[zajio1am]

> Are you guessing what sounds logical to you or do you actually know the answer here?

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

[ThePowerOfFuet]

The term you're looking for regarding the numbers you have in parentheses is _recital_.

[vbezhenar]

Firmware is not kernel blob. It's executed on separate device and has nothing to do with Linux. It's about open hardware, not open software. I don't think that it's worth to pursue this direction for Debian.

[hahhahanananana]

> when even a purist distribution like Debian is forced to concede in the fight against proprietary blobs.

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.