Comment by neilv | Hacker News Reader

Comment by neilv | Hacker News Reader

Parent Full thread

The tomshardware.com article says:

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

Also,

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

It's an accurate headline. The firmware under quesiton was NOT included before.

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

Depending on the design of the hardware, you can limit its capabilities and e.g. prevent it from doing arbitrary read/write on RAM.

https://www.pine64.org/2020/01/24/setting-the-record-straigh...

> The proprietary software to be included takes the form of Binary Large Objects, or BLOBs

Yeah, no, that's a backronym. They're just blobs (see e.g. https://en.wikipedia.org/wiki/Binary_large_object).

"No"? Are backronyms somehow illegitimate? A term can be a backronym and also, over forty years later, be considered generally accepted parlance.

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

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

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

That backronym already exists longer now than the non-acronym BLOB term existed before, though.

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.

I meant the term being used for binary data.

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.

Reply on news.ycombinator.com