I think some compromises might be necessary but I think the insistence on open source drivers is otherwise pretty important. Yes, mobil OS are successful, but they still suck. The hardware and software situation restricts users massively. I wouldn't ever want that for a desktop computer.
The definition of what a "driver" is has been slowly changing, though.
Initially, hardware was just a bunch of transistors performing a fixed function. Then they got microcontrollers which were programmed once in the factory. Then the microcontrollers were user-programmable - which was a massive pain until we got fwupd. Now the microcontrollers don't have built-in firmware but require you to provide it on startup.
From the driver side, nothing really changed. A driver is still a piece of code you use to talk to your hardware: it translates between your OS and whatever weird protocols your devices are using.
Drivers have always had to perform magic incantations to get the hardware working, writing the right bytes to the right locations in the right order. The only thing that changed is that those incantations are now a few kilobytes long.
And yet, despite nothing really changing, your OS now technically contains proprietary firmware blobs...
True, that wasn't precisely stated. I honestly believe that these blobs wouldn't need to be proprietary.
I work on proprietary code for embedded systems too and we don't release the source either. But if it were leaked there is not really a threat to our intellectual property. Maybe the main benefit really is security through obscurity. We don't do general hardware though and it wouldn't be of much interest, but it would be nice to get manufacturers to open up here. Not even the source for the blobs, but some documentation to interface the firmware perhaps.
Sure, it is always some work if you release something to the public or maybe parts of your software need licences themselves, but if possible I would expect this to net secondary benefits for the manufacturers. If people know your hardware, they might use it in their applications as well...
Just getting manufacturers here to open up would still be nice and I believe they could benefit as well.
I don't think allowing "binary blobs" by default is a good idea. Allowing binaries built from "non-free" but publicly available source code is less of a problem, at least to me.
Most firmware is either a binary blob without source, or has public freely licensed source code. There is nothing with "non-free" but publicly available source code. The Intel Sound Open Firmware is a weird mix though, public freely licensed source code but most of the hardware can only run Intel signed firmware binaries.
Some hardware firmware is a binary blob because THERE IS NO KNOWN WAY TO COMPILE IT.
Certain chips are manufactured with an initialization code sequence that is generated very similarly to how an FPGA floor planning works.
It should be made clear this Debian Vote is to include Proprietary Firmware in the installer so it is possible for new users to install and try Linux. If it's not in the installer, new users just perceive that free software / Linux just doesn't work at all. That doesn't help anyone.
The source code to the tooling that generates the initialization code sequence along with all the input and configuration files and anything else needed to run it constitutes the source code of such a binary blob.
True enough, but Debian is trying to have a property - "this software is free!". If non-free stuff is included, it will no longer have that property.
I'm not going to second guess the Debian project, they are being reasonable. But guarantees that the software is free are important. New users are all very well, but the experienced users who make up the bulk of Debian's audience don't want to be drilling down into a bug and winding up running in to proprietary code.
The software is the way it is because it believes in freedom. Its successes are because it is free. If the point is to be cheap, go pirate windows or something.
...because one of the letters against Stallman stopped accepting signatures at three thousand people, but the "pro" Stallman letter never did. It included sixty open-source organizations were among those three thousand individuals. SUSE, Mozilla, GNOME, Creative Commons, X.org, etc. The point was made. A huge number of people and organizations wanted Stallman gone.
Stallman literally said a sex-trafficked child wasn't a "rape victim", and this isn't the first time he's espoused, on technical mailing lists, that golly, 'age is just a number' when it comes to children having sex with adults. He's an infamous serial sexual harasser - for decades. Threatening to kill himself if women won't date him, hosting barely-clothed "cuddle puddles" on the bare mattress in his office at MIT, and women in his office building stuffing their offices full of house plants because Stallman was known to hate them, and it was the only thing that would make him leave women alone.
When Redhat and others pulled funding, the board was clear they weren't interested in prudent governance of the organization, but solely about petulantly supporting their geek deity. His refusal to step down, and the board's refusal to remove him, irreparably harmed their reputation and finances.
> ...because one of the letters against Stallman stopped accepting signatures at three thousand people, but the "pro" Stallman letter never did.
It was always a hunch, but I suspected that part of the reason they stopped is that they reached a plateau, while the open letter was continuing to rise in popularity.
I have personally communicated with RMS, even privately, and see a discrepancy between the way he is portrayed and the way he behaves on a regular basis. Of course, I might have just caught his good and kind side, who knows? Either way, my impression remains that those who see him as bad want to see him as bad.
I am male, and I do get what you mean, which is why I wrote "Of course, I might have just caught his good and kind side, who knows?". As a person living in Germany, with a non-German accent, I also understand that not everyone perceives everything. Any person who feels excluded from participating in the Free Software movement is a loss. The more people with more perspectives, the stronger the movement is, which is in everyone's interest.
That being said: I do agree that some of the statements made in the past were tasteless, and I am disappointed that he did so. Yet when reading his own texts like https://stallman.org/articles/necessary-changes.html, I have to either conclude that he agrees but has made mistakes or is himself lying.
Another thing might be that I have only had contact with him via Email. Perhaps he is different in person, that I cannot say.
I often remind people that you are only ever duped by those you trust. I have no idea how you could think email exchanges with someone would lend credence one way or another in respect to this type of accusation. It is well-known that even serial murderers are often charming and everyone is surprised when they are caught. How kind, cordial, or charming someone is means nothing in this type of situation.
OK, but just because a serial murdered can be charming, doesn't mean that every charming person in a serial murderer. It is true, I can't deduce anything with certainty from my personal and public correspondence, or the messages I see him send to others. But as opposed to the serial murderer, the issue here is the way he communicates and behaves.
I guess you could try this out empirically, by creating a throwaway Email address and sending him a dry, technical question under a female name, and see how he responds.
That would be anecdotal, and after the fact when he is trying to be on his best behavior. Also, email and online communication in general is not a good way to judge somebody. for better and worse, People read non-existent tone into things I write endlessly, and you have to just stop caring about the disconnect it is so bad.
To be clear, I have no idea as to the truth of this situation, I am just saying the criteria to judge it must be different than that, especially because creeps do their best to hide their creepiness to the general world.
> Any person who feels excluded from participating in the Free Software movement is a loss.
Yes, but not every loss is equal, and in a changing world, growing groups will eventually reach a point where not everyone who wants to play will agree on the same ethics, which will lead to someone feeling unappreciated.
If I had the choice between losing a F/L/OSS contributor who has spend their life writing highly influential software and a F/L/OSS contributor who opened a 200-line-Python script once, half a year ago, I know who I would consider less of a loss.
I want to believe that this is not a necessary conflict, or rather is at best one that can be resolved. The choice still remains difficult, as you don't know the future, so it is preferable to have both on board.
Nobody would have guessed, also that you are male too. I really do believe that you have a problem with racism and sexism, but it won't be solved by accusing others.
> So as far as I know [...] quite some apparently have
You should not regurgitate these rumors without further evidence. I can imagine someone like Stallmann being awkward with women and maybe some of the accusations are true. That is certainly no reason to prosecute him like this. Not your job to do so, work on yourself instead. There is enough to do here and then you can lead by example.
> There is a reason, why the free software movement is largely dominated by men
Certainly not a fault of Stallman. Some women also do not like men trying to make their mark everywhere and these easy accusations of sexism or discrimination feel a bit like that. Pretty sure you won't find the "fault" for that in others.
Yes, RMS is a problematic person, but i'd prefer him over people who slander their opponents in public. I'm open to replacing RMS, but.. not like that.
>When Redhat and others pulled funding, the board was clear they weren't interested in prudent governance of the organization, but solely about petulantly supporting their geek deity. His refusal to step down, and the board's refusal to remove him, irreparably harmed their reputation and finances.
Alternatively, they decided they weren't going to be strong-armed into doing something that they saw no need to do.
>The Debian developer community has decided to say nothing about the new controversy surrounding Richard Stallman reelection to the board at the Free Software Foundation.
> The proprietary software to be included takes the form of Binary Large Objects, or BLOBs. In the language of free software, this means proprietary device drivers distributed without their source code, as pure binary.
But, in https://www.debian.org/vote/2022/vote_003 , I see no mention of closed drivers (i.e., code that runs on the Debian host machine) -- only of closed firmware (i.e., code that run on the component device itself).
(Of course, though closed firmware can seem reasonable right now, it can get more complicated over time, such as by encouraging complexity to be in closed device firmware that otherwise could've been in open kernel/userland in the host. And encouraging closed firmware over open firmware. But, for now, closed firmware seems not nearly as bad for libre/open software as closed drivers and other closed software on the host. And I'll admit that I've recently specified a company standard workstation built upon Debian Stable with closed firmware blobs, pragmatically, because we needed WiFi with popular off-the-shelf laptops.)
> We will include non-free firmware packages from the "non-free-firmware" section of the Debian archive on our official media (installer images and live images). The included firmware binaries will normally be enabled by default where the system determines that they are required, but where possible we will include ways for users to disable this at boot (boot menu option, kernel command line etc.).
"Debian Votes to Include Proprietary Firmware" in the headline is misleading. The Debian distribution already contained this firmware (in an isolated repository).
This vote seems to be about making it available by default on official media, making installation easier. This supersedes the previous approach, which as of this comment is still described here: https://wiki.debian.org/Firmware
Without extra explanation, "Debian" usually refers to the main section. If the headline is misleading in any way, it's because it implies inclusion into main.
But I think the discussion is old and well known enough for it to not confuse anybody interested on the subject.
There are indeed closed drivers. Nvidia recently released a blob with accompanying harness source code for embedding their proprietary drivers into novel operating systems or environments, assuming you can provide the harness with all of the facilities needed.
It's a way to get people to use the OEM drivers without having to explicitly support each distro/OS. They can just release the blob and assume that the harness takes care of the rest.
>closed firmware seems not nearly as bad for libre/open software as closed drivers
If I take my highly complex, proprietary driver, put it in a little ARM chip in my device, and provide a dumb and simple driver that interfaces with that chip instead, is anything won? Sure, the proprietary code is out of sight and out of mind, but it's still there and you still can't modify and improve it.
Yes, that's called a "peripheral" and there are many of them. From a software freedom and security perspective, a peripheral that gets its firmware loaded by a Free host is basically the same [0] as a peripheral that has its firmware stored in flash. The FSF chose an ultimately weird stance based on a copyright perspective [1], but it's time to move forward.
In an ideal world, all peripherals (all devices) would also be running Free software. But we're not in that world, so we've got to eek out the Free domains we can, and isolate the non-free parts through well defined interfaces ... and additionally in this world of assumed ubiquitous connectivity, by denying them unfettered Internet access.
[0] Flash is actually worse if you're sharing that peripheral with an untrustable host, since the firmware can be changed without your consent, or frozen against your desires. Whereas loading a stateless peripheral from the host chooses the specific firmware image every time.
[1] It's cool to be able to definitively say "this whole installation image is redistributable purely under Free licenses", but I'd say it's not the most important thing for user empowerment.
The reason to write an expansion like in the article is that it explains to the reader as we go. For example if I write "Universal Serial Bus or USB was developed..." then we've established what USB is during the text, for anybody who didn't know.
But the backronym adds nothing to blob, the reader learns nothing of value from this deliberately meaningless expansion. It's a blob.
I don't usually get involved in anything that smells of pedantry but I'm confused by your argument.
I understand from your earlier comment that Binary Large Object is a backronym for blob. This is news to me: I've always "known" that blob was an abbreviation for Binary Large OBject: for at least the last 20 years. Until your comment, I had no idea that the term "blob" had ever been used as a word in itself in the context of software.
All of which is to say that I think there's value in explaining what a blob is: without any context, it's not a meaningful term.
> I think there's value in explaining what a blob is: without any context, it's not a meaningful term.
The problem with the backronym for this is that it's plainly wrong. Which didn't matter in the context in which it was created, it reminds me of the R.V.Jones story about why H2S (a second world war radar system) was called that, you mustn't say it's because the big boss said "It stinks", and that reminded the chemists on the team of H2S, the formula for rotten egg smell -- that would make the boss look bad - so you pretend it stands for "Home Sweet Home" even though that makes no sense because it is for identifying bombing targets.
The blobs Debian cares about aren't necessarily "Binary", it's just as much a problem if we're obliged to send 4MB of inexplicable ARM assembler text to a remote device, or if the firmware is base 64 encoded (and thus ASCII text) for some daft reason. If Binary just means "Of course they are because it's a computer" see Object.
The blobs Debian cares about aren't necessarily "Large" either, what would constitute "large"? If I've got 64 bytes of firmware that are fed to an 8501 controller that's probably its entire program, but it's way smaller than this paragraph of text. Does large just mean "Non-zero size" ?
So that leaves us with "Object", which I mean, I guess? It's as vague a word as blob was.
I've been using computers since about 1993 and first installed Linux around 1999 and this is the first time I've ever heard that "blob" in this context is supposed to be any kind of acronym.
It's a dumb one, too. They don't have to be large.
Personally, I don't think expanding USB would add any meaning in any context. If somebody knows what USB means, they know the acronym, not the expansion.
But expanding blob adds meaning, even with it being a backronym. Maybe it would be better to define it instead of expanding, but it is better than nothing (differently from USB).
Blob appears before Modern English. I don't think Will Shakespeare uses the word in a play, but it would have been a word familiar to some audiences at least.
It's probably from an earlier English, before the vowel shift, back then you'd need to trace spoken language, which we can't do, very little is being written down and preserved. By the time Johnson makes a dictionary, centuries later, the origins of "blob" are already lost like many other words.
No. The main motivation behind Ubuntu (and its predecessors Knoppix, Mepis, UserLinux) was realizing that a knowledgeable person could get a nice, easy to use Debian desktop in a couple of hours and then let it in the hands of less knowledgeable persons. It was hard to install.
On the other hand, you could boot a perfectly workable system from a live CD (Knoppix) but it was hard to install.
So the motivation was: could we get the best of both worlds? Easy to launch/install and easy to use maintain once installed? This was also more or less coordinated with a huge shift in GNOME development where UX became the main goal and development switched to a 6 months based schedule.
Detecting hardware was part of what was hard with Debian but was not seen the most important part. Having a nice coherent desktop at first boot was the goal.
To be fair, Ubuntu had a hard time with lot of hardware too at the time ;-)
source : I ran Ubuntu Install Party at my local university and, for some laptops, I had to spend hours figuring out what to do. Situation is way better now for hardware (but Ubuntu became too full of bloat for my taste)
Ubuntu's killer feature early on, for me, was picking the obviously correct defaults. No, I don't want Gnome or KDE's stupid browser, I want(ed) Firefox. A whole bunch of little choices like that, that meant I could just hit "install" without modifying anything or choosing any packages and get a desktop set up about the same way I'd have set up Debian, after a bunch of faffing about.
As much as Debian's prior policy is laudable it's caused it to have one hand tied behind it's back for the last 20+ years. The result has been distros existing that wouldn't exist otherwise. It turns out as a user I do need those things to work regardless of the manufacturers closed source drivers/firmware, and I want it to JustWork™.
And yes, I know it was already available, but the default installation UX matters a lot.
Could this also not have been fixed by running some tool to detect non-free hardware and alerting the user of the need to install one of these packages later?
Ubuntu does more or less does this. But the crucial step is having a checkbox in the installer to install the non-free drivers (that are shipped in the installation media). Otherwise you might have a computer with linux but no easy way to get a driver for your wifi chip to it.
One issue with that strategy is accessibility; e.g. a case that was actually cited at the onset of the discussion that lead to the vote are blind users that need specific firmware to use their audio interface, without which they simply cannot use the installer
Yes, but I suspect that the vast majority of users would find this annoying.
Back in the day when I was playing with Slackware, it would have been interesting and I wouldn't have minded in the least.
But these days, if I'm installing a distro, it's because I'm being paid to do a job. And that job has nothing to do with the distro itself: that's just a hopefully minor step along the path. The fewer "just go do this one little thing" speedbumps I encounter, the better. Or I start to get frustrated and irritated and wonder if there isn't an easier way.
I remember 15 years ago having to plug a USB stick with network driver on it after installing Debian so the server would connect to the network in the datacenter...
Big fail for Debian to enable them by default. They could have kept the questions as before "We found this hardware that needs non-free, do you want to use it?" Otherwise this is catering for the new security chips like Microsoft Pluton or something...
It is sad that they prefer to go for easy instead of keep putting pressure for companies to improve their hardware
I will put a reminder to check Debian popularity in a year's time. My bet is it will go down, most desktop people used Debian for the schizophrenic thin line they toed with Freedom Software. Otherwise any other distribution is more up to date and usable for a modern desktop/laptop, this small change will do no difference
> The included firmware binaries will normally be enabled by default where the system determines that they are required, but where possible we will include ways for users to disable this at boot
If the project, or motivated users want to detail exactly how to run Debian without nonfree firmware, that would be great.
And just as the nonfree installer was available but kept slightly hidden (even though it's difficult to install on just about any laptop without it), I'm sure there will be Debian Developers motivated to continue providing a fully free installer for those who want it.
Clarification: I know there are instructions in the Debian documentation on how to put nonfree firmware on a USB drive and to use that drive with the free installer, but it's so much easier to just use the nonfree installer if you're going to be using nonfree firmware. Why make it hard if you're using the bits anyway?
That said, I'd love to see a lot more people writing about what hardware works with free firmware so we can decide if we want to go in that direction. I am all for that.
75 comments
[ 3.1 ms ] story [ 120 ms ] threadInitially, hardware was just a bunch of transistors performing a fixed function. Then they got microcontrollers which were programmed once in the factory. Then the microcontrollers were user-programmable - which was a massive pain until we got fwupd. Now the microcontrollers don't have built-in firmware but require you to provide it on startup.
From the driver side, nothing really changed. A driver is still a piece of code you use to talk to your hardware: it translates between your OS and whatever weird protocols your devices are using.
Drivers have always had to perform magic incantations to get the hardware working, writing the right bytes to the right locations in the right order. The only thing that changed is that those incantations are now a few kilobytes long.
And yet, despite nothing really changing, your OS now technically contains proprietary firmware blobs...
I work on proprietary code for embedded systems too and we don't release the source either. But if it were leaked there is not really a threat to our intellectual property. Maybe the main benefit really is security through obscurity. We don't do general hardware though and it wouldn't be of much interest, but it would be nice to get manufacturers to open up here. Not even the source for the blobs, but some documentation to interface the firmware perhaps.
Sure, it is always some work if you release something to the public or maybe parts of your software need licences themselves, but if possible I would expect this to net secondary benefits for the manufacturers. If people know your hardware, they might use it in their applications as well...
Just getting manufacturers here to open up would still be nice and I believe they could benefit as well.
https://github.com/thesofproject/sof/issues/5814
Certain chips are manufactured with an initialization code sequence that is generated very similarly to how an FPGA floor planning works.
It should be made clear this Debian Vote is to include Proprietary Firmware in the installer so it is possible for new users to install and try Linux. If it's not in the installer, new users just perceive that free software / Linux just doesn't work at all. That doesn't help anyone.
True enough, but Debian is trying to have a property - "this software is free!". If non-free stuff is included, it will no longer have that property.
I'm not going to second guess the Debian project, they are being reasonable. But guarantees that the software is free are important. New users are all very well, but the experienced users who make up the bulk of Debian's audience don't want to be drilling down into a bug and winding up running in to proprietary code.
The software is the way it is because it believes in freedom. Its successes are because it is free. If the point is to be cheap, go pirate windows or something.
Easy, run it through a disassembler, now you can compile it. ;)
https://www.theregister.com/2021/04/19/debian_stallman_vote/
Stallman literally said a sex-trafficked child wasn't a "rape victim", and this isn't the first time he's espoused, on technical mailing lists, that golly, 'age is just a number' when it comes to children having sex with adults. He's an infamous serial sexual harasser - for decades. Threatening to kill himself if women won't date him, hosting barely-clothed "cuddle puddles" on the bare mattress in his office at MIT, and women in his office building stuffing their offices full of house plants because Stallman was known to hate them, and it was the only thing that would make him leave women alone.
When Redhat and others pulled funding, the board was clear they weren't interested in prudent governance of the organization, but solely about petulantly supporting their geek deity. His refusal to step down, and the board's refusal to remove him, irreparably harmed their reputation and finances.
It was always a hunch, but I suspected that part of the reason they stopped is that they reached a plateau, while the open letter was continuing to rise in popularity.
https://linuxreviews.org/Grass-roots_Richard_Stallman_Suppor...
Regarding the other accusations, my understanding is that they are unfounded or intentional misrepresentations
https://stallmansupport.org/debunking-false-accusations-agai...
I have personally communicated with RMS, even privately, and see a discrepancy between the way he is portrayed and the way he behaves on a regular basis. Of course, I might have just caught his good and kind side, who knows? Either way, my impression remains that those who see him as bad want to see him as bad.
That being said: I do agree that some of the statements made in the past were tasteless, and I am disappointed that he did so. Yet when reading his own texts like https://stallman.org/articles/necessary-changes.html, I have to either conclude that he agrees but has made mistakes or is himself lying.
Another thing might be that I have only had contact with him via Email. Perhaps he is different in person, that I cannot say.
I guess you could try this out empirically, by creating a throwaway Email address and sending him a dry, technical question under a female name, and see how he responds.
To be clear, I have no idea as to the truth of this situation, I am just saying the criteria to judge it must be different than that, especially because creeps do their best to hide their creepiness to the general world.
Yes, but not every loss is equal, and in a changing world, growing groups will eventually reach a point where not everyone who wants to play will agree on the same ethics, which will lead to someone feeling unappreciated.
If I had the choice between losing a F/L/OSS contributor who has spend their life writing highly influential software and a F/L/OSS contributor who opened a 200-line-Python script once, half a year ago, I know who I would consider less of a loss.
Nobody would have guessed, also that you are male too. I really do believe that you have a problem with racism and sexism, but it won't be solved by accusing others.
> So as far as I know [...] quite some apparently have
You should not regurgitate these rumors without further evidence. I can imagine someone like Stallmann being awkward with women and maybe some of the accusations are true. That is certainly no reason to prosecute him like this. Not your job to do so, work on yourself instead. There is enough to do here and then you can lead by example.
> There is a reason, why the free software movement is largely dominated by men
Certainly not a fault of Stallman. Some women also do not like men trying to make their mark everywhere and these easy accusations of sexism or discrimination feel a bit like that. Pretty sure you won't find the "fault" for that in others.
> https://stallmansupport.org/debunking-false-accusations-agai...
Yes; also here: https://sterling-archermedes.github.io/
Toning down would have helped your cause.
the sinless one among you, throw the first stone
Alternatively, they decided they weren't going to be strong-armed into doing something that they saw no need to do.
>The Debian developer community has decided to say nothing about the new controversy surrounding Richard Stallman reelection to the board at the Free Software Foundation.
> The proprietary software to be included takes the form of Binary Large Objects, or BLOBs. In the language of free software, this means proprietary device drivers distributed without their source code, as pure binary.
But, in https://www.debian.org/vote/2022/vote_003 , I see no mention of closed drivers (i.e., code that runs on the Debian host machine) -- only of closed firmware (i.e., code that run on the component device itself).
(Of course, though closed firmware can seem reasonable right now, it can get more complicated over time, such as by encouraging complexity to be in closed device firmware that otherwise could've been in open kernel/userland in the host. And encouraging closed firmware over open firmware. But, for now, closed firmware seems not nearly as bad for libre/open software as closed drivers and other closed software on the host. And I'll admit that I've recently specified a company standard workstation built upon Debian Stable with closed firmware blobs, pragmatically, because we needed WiFi with popular off-the-shelf laptops.)
> We will include non-free firmware packages from the "non-free-firmware" section of the Debian archive on our official media (installer images and live images). The included firmware binaries will normally be enabled by default where the system determines that they are required, but where possible we will include ways for users to disable this at boot (boot menu option, kernel command line etc.).
"Debian Votes to Include Proprietary Firmware" in the headline is misleading. The Debian distribution already contained this firmware (in an isolated repository).
This vote seems to be about making it available by default on official media, making installation easier. This supersedes the previous approach, which as of this comment is still described here: https://wiki.debian.org/Firmware
But I think the discussion is old and well known enough for it to not confuse anybody interested on the subject.
It's a way to get people to use the OEM drivers without having to explicitly support each distro/OS. They can just release the blob and assume that the harness takes care of the rest.
If I take my highly complex, proprietary driver, put it in a little ARM chip in my device, and provide a dumb and simple driver that interfaces with that chip instead, is anything won? Sure, the proprietary code is out of sight and out of mind, but it's still there and you still can't modify and improve it.
https://www.pine64.org/2020/01/24/setting-the-record-straigh...
In an ideal world, all peripherals (all devices) would also be running Free software. But we're not in that world, so we've got to eek out the Free domains we can, and isolate the non-free parts through well defined interfaces ... and additionally in this world of assumed ubiquitous connectivity, by denying them unfettered Internet access.
[0] Flash is actually worse if you're sharing that peripheral with an untrustable host, since the firmware can be changed without your consent, or frozen against your desires. Whereas loading a stateless peripheral from the host chooses the specific firmware image every time.
[1] It's cool to be able to definitively say "this whole installation image is redistributable purely under Free licenses", but I'd say it's not the most important thing for user empowerment.
Yeah, no, that's a backronym. They're just blobs (see e.g. https://en.wikipedia.org/wiki/Binary_large_object).
But the backronym adds nothing to blob, the reader learns nothing of value from this deliberately meaningless expansion. It's a blob.
I understand from your earlier comment that Binary Large Object is a backronym for blob. This is news to me: I've always "known" that blob was an abbreviation for Binary Large OBject: for at least the last 20 years. Until your comment, I had no idea that the term "blob" had ever been used as a word in itself in the context of software.
All of which is to say that I think there's value in explaining what a blob is: without any context, it's not a meaningful term.
The problem with the backronym for this is that it's plainly wrong. Which didn't matter in the context in which it was created, it reminds me of the R.V.Jones story about why H2S (a second world war radar system) was called that, you mustn't say it's because the big boss said "It stinks", and that reminded the chemists on the team of H2S, the formula for rotten egg smell -- that would make the boss look bad - so you pretend it stands for "Home Sweet Home" even though that makes no sense because it is for identifying bombing targets.
The blobs Debian cares about aren't necessarily "Binary", it's just as much a problem if we're obliged to send 4MB of inexplicable ARM assembler text to a remote device, or if the firmware is base 64 encoded (and thus ASCII text) for some daft reason. If Binary just means "Of course they are because it's a computer" see Object.
The blobs Debian cares about aren't necessarily "Large" either, what would constitute "large"? If I've got 64 bytes of firmware that are fed to an 8501 controller that's probably its entire program, but it's way smaller than this paragraph of text. Does large just mean "Non-zero size" ?
So that leaves us with "Object", which I mean, I guess? It's as vague a word as blob was.
It's a dumb one, too. They don't have to be large.
But expanding blob adds meaning, even with it being a backronym. Maybe it would be better to define it instead of expanding, but it is better than nothing (differently from USB).
It's probably from an earlier English, before the vowel shift, back then you'd need to trace spoken language, which we can't do, very little is being written down and preserved. By the time Johnson makes a dictionary, centuries later, the origins of "blob" are already lost like many other words.
On the other hand, you could boot a perfectly workable system from a live CD (Knoppix) but it was hard to install.
So the motivation was: could we get the best of both worlds? Easy to launch/install and easy to use maintain once installed? This was also more or less coordinated with a huge shift in GNOME development where UX became the main goal and development switched to a 6 months based schedule.
Detecting hardware was part of what was hard with Debian but was not seen the most important part. Having a nice coherent desktop at first boot was the goal.
source : I was part of it.
On my side, I definitly kept ubuntu because that was the only distro that ran on my hardware on first try.
I should not have implied that ubuntu would not have been launched, but rather that the story would have went very differently IMO.
source : I ran Ubuntu Install Party at my local university and, for some laptops, I had to spend hours figuring out what to do. Situation is way better now for hardware (but Ubuntu became too full of bloat for my taste)
And what about the other 400 distributions based on Debian? There are many differences between them not just firmware
https://distrowatch.com/search-mobile.php?ostype=Linux&categ...
And yes, I know it was already available, but the default installation UX matters a lot.
Back in the day when I was playing with Slackware, it would have been interesting and I wouldn't have minded in the least.
But these days, if I'm installing a distro, it's because I'm being paid to do a job. And that job has nothing to do with the distro itself: that's just a hopefully minor step along the path. The fewer "just go do this one little thing" speedbumps I encounter, the better. Or I start to get frustrated and irritated and wonder if there isn't an easier way.
Also Debian really has zero focus on the desktop, in general.
It is sad that they prefer to go for easy instead of keep putting pressure for companies to improve their hardware
I will put a reminder to check Debian popularity in a year's time. My bet is it will go down, most desktop people used Debian for the schizophrenic thin line they toed with Freedom Software. Otherwise any other distribution is more up to date and usable for a modern desktop/laptop, this small change will do no difference
This is exactly what they are doing. It will be disableable in grub, too, if you want to prevent the firmware from being used entirely.
https://www.debian.org/vote/2022/vote_003
Lets hope so, but it doesn't look like to me, reading the proposal Maybe it is a matter of interpretation
If the project, or motivated users want to detail exactly how to run Debian without nonfree firmware, that would be great.
And just as the nonfree installer was available but kept slightly hidden (even though it's difficult to install on just about any laptop without it), I'm sure there will be Debian Developers motivated to continue providing a fully free installer for those who want it.
That said, I'd love to see a lot more people writing about what hardware works with free firmware so we can decide if we want to go in that direction. I am all for that.