LWN: Comments on "FSF offers "GNU Bucks" for finding nonfree works in free distributions"

FSF offers "GNU Bucks" for finding nonfree works in free distributions

dlang — Sat, 10 Oct 2009 21:41:43 +0000

it depends on the hardware.

sometimes (like your radeon video card) if you don't use the firmware blob you can use the hardware in a degraded mode.

however, most of the time if you don't use the firmware blob you just can't use that hardware at all.

FSF offers "GNU Bucks" for finding nonfree works in free distributions

anton — Sat, 10 Oct 2009 15:11:16 +0000

how practical is it not to have firmware blobs ?

For some reason we recently built a 2.6.30 kernel from the Squeeze Debian source package and installed it on several Lenny systems. After some time I noticed the following in the dmesg output:

[drm] Loading R500 Microcode
platform radeon_cp.0: firmware: requesting radeon/R520_cp.bin
radeon_cp: Failed to load firmware "radeon/R520_cp.bin"
[drm:radeon_do_init_cp] *ERROR* Failed to load firmware!

I had not noticed anything missing from any of the machines at the time. Later I noticed that I don't get 3D acceleration on that card, but I don't care.

So it's obviously practical not to have some firmware blobs. According to another comment here the separation is not yet finished, so I cannot comment on not having any firmware blobs.

Debian packages the firmware blobs in separate packages in the non-free section, so it's still there for the less virtuous among us.

FSF offers "GNU Bucks" for finding nonfree works in free distributions

mjg59 — Sat, 10 Oct 2009 14:59:30 +0000

Not only do they not include the non-free software, they also make it impossible to use the non-free software. However, they're entirely happy to let you use non-free software out of the box, as long as it's in an eeprom instead. They're even running non-free software by default in the kernel when they execute ACPI methods. I honestly just don't understand how these distributions do anything other than encourage vendors to move their non-free software to somewhere where it's more difficult for us to replace it.

Newspeak

anton — Sat, 10 Oct 2009 14:56:37 +0000

Free Software, because if you don't, users' initial interpretation of the term is going to be "software that has no cost." Because that's what the term freaking means in plain English without the vernacular.

Ah, Newspeak has taken over. From the appendix of 1984:

To give a single example, the word free still existed in Newspeak, but could only be used in such statements as "The dog is free from lice" or "This field is free from weeds." It could not be used in its old sense of "politically free" or "intellectually free," since political and intellectual freedom no longer existed even as concepts, and were therefore of necessity nameless.

The difference is that Newspeak is now called "plain English" and in our commercially dominated world "free" was redefined to mean "has no cost". Interesting that Orwell did not think of that.

FSF offers "GNU Bucks" for finding nonfree works in free distributions

dlang — Sat, 10 Oct 2009 06:26:52 +0000

lots of chips are available with ROM nowdays.

EPROMs are just about gone (the packaging costs for them make it such that flash is a batter deal)

FSF offers "GNU Bucks" for finding nonfree works in free distributions

epa — Fri, 09 Oct 2009 23:20:08 +0000

I think it's not the job of the distributions to decide not to support certain hardware. Rather, they just don't want to include non-free software on the distribution CD. Whether to purchase such hardware is up to you.

FSF offers "GNU Bucks" for finding nonfree works in free distributions

mjg59 — Fri, 09 Oct 2009 22:50:33 +0000

Yeah, I tend to agree, which is why I don't buy this "Loadable firmware is worse" argument - there's a power imbalance between the vendor and you with almost all hardware you can buy these days, so if that's the motivation then drawing the line at loadable firmware seems like it's doing it wrong.

FSF offers "GNU Bucks" for finding nonfree works in free distributions

nix — Fri, 09 Oct 2009 22:41:57 +0000

I suspect a tiny bit of practicality enters here. How much hardware uses
actual ROM these days? Does any?

(For that matter, how much uses EPROM? I haven't even seen the acronym for
years, and shining UV on a chip for half an hour to erase it seems
terribly archaic now.)

FSF offers "GNU Bucks" for finding nonfree works in free distributions

mjg59 — Fri, 09 Oct 2009 14:12:13 +0000

In that case, why do the firmware-free distributions support hardware that has eeprom-based firmware? Shouldn't they only support hardware that has it in ROM?

Free vs convenient

epa — Fri, 09 Oct 2009 14:10:38 +0000

I remember RMS saying he wasn't too concerned about the software running his microwave oven. OTOH, if microwaves came with a binary blob on a USB key that had to be loaded, we can be pretty sure RMS would refuse to use them ;-p.

FSF offers "GNU Bucks" for finding nonfree works in free distributions

epa — Fri, 09 Oct 2009 14:05:26 +0000

1) EEPROM on the device that you can only write to from windows with a special firmware upload tool, and which only accepts signed-by-the-manufacturer-blobs.

But that's not considered free-as-in-GNU either.

AFAIK, RMS and his pals would like either (a) firmware with source code, where the owner of the device can install his changed versions; or (b) firmware in ROM, not changeable by anybody.

If this sounds bloody-minded, it's just the same principle as copyleft has been intended to create all along, that of freedom-or-nothing; for example, RMS would rather emacs not be distributed at all rather than be distributed without giving the user freedom to change it, share it, and run the changed copy.

A brave GNU world

pboddie — Fri, 09 Oct 2009 11:10:34 +0000

The freedom not to install is more important than freedom of speech, so operating system distributors must be censored.

The FSF chooses to promote those distributions that best fits their ideology. Once again we see the perversion of basic terminology (something is apparently "censored" if another party is "unwilling to advocate" that thing) by people who think that ridiculing organisations like the FSF for expressing their views somehow furthers the agenda of their favourite flavour of Free Software licensing.

Accusing the FSF of "coercion" (which upon further investigation actually refers to someone "voicing an opinion" to which one need not listen) is the only thing missing here - although it is implied - despite Microsoft having its products bundled on almost all systems available through mainstream retail channels. But then I suppose some people believe it still to be fashionable to frame the FSF as antidemocratic (using Newspeak-style rhetoric - how creative!) while ignoring the more blatant injustices.

A brave GNU world

BenHutchings — Thu, 08 Oct 2009 14:05:18 +0000

The FSF's favoured distribution, gNewSense, not only removes sourceless firmware from the kernel (along with many initialisation tables that are arguably "preferred form for modification") but also prevents loading non-free firmware (see http://www.fsfla.org/svn/fsfla/software/linux-libre/scrip...).

Free vs convenient

dlang — Tue, 06 Oct 2009 17:54:38 +0000

in the long run I believe that open firmware would be best, but you do have to take into account industry norms.

right now the industry is just shifting from the firmware in flash/rom to the firmware in ram. the easiest political response to being attacked for firmware in ram is to move back to having the firmware in flash, not to have to convince lawyers and upper management to release the source.

I hope that this will eventually change, but right now it is still very hard to get the industry to release the source for things that they are clearly legally required to release. once complying with the GPL for derivative works and embedded code becomes normal the industry will start to loose it's fear and see some of the benefits. right now they are on the wrong side of things and so pushing them now moves them the wrong way

FSF offers "GNU Bucks" for finding nonfree works in free distributions

dlang — Tue, 06 Oct 2009 17:40:36 +0000

exactly, if they were decrying all non-free firmware I would agree with their goal (even if considering it a bit of tilting at windmills still), but with their emphasis being only to attack firmware in ram and directing people to buy devices with the firmware in flash/rom instead I see them as activly harmful to their stated goal

FSF offers "GNU Bucks" for finding nonfree works in free distributions

foom — Tue, 06 Oct 2009 15:45:26 +0000

> First, is that the FSF has always been thinking more long-term than most of its opponents.

For that to be true, in this case, I want to see them decrying the evils of non-free *embedded*
firmware. I mean that seriously, I want someone to take up that call! It is a problem that needs
solving, there is way too much mysterious software (ahem "firmware") in modern systems doing
who-knows-what. But they completely ignore this, instead focusing only on the non-free firmware
that has to be uploaded to the hardware. Which IMO is a seriously warped and fairly useless view of
"100% free".

FSF offers "GNU Bucks" for finding nonfree works in free distributions

nye — Tue, 06 Oct 2009 14:04:17 +0000

Your post was fairly unfocussed, but there are two points I'd like to pick up on.

First, is that the FSF has always been thinking more long-term than most of its opponents. There are constantly complaints made that the FSF's methods and ideals are impractical, where the implicit meaning is 'impractical *in the short term*'. The FSF's positions are entirely practical over terms more like a decade or two - in fact, they're far *more* practical over that length of time than the 'pragmatic' positions of today. Sure it wouldn't be reasonable for *everybody* to follow the FSF position, but we need *somebody* to take that line, in order to progress. Too many people forget that it's worth sacrificing a pawn today if that means taking the opponent's queen in five moves' time.

The second point is about the naming. You say that nobody uses the term 'Microsoft Windows Vista', and in a sense that's true - most reasonably savvy people are likely to say they're running 'Vista'; the others might just say they're running 'Microsoft', if you're lucky. But take a look at anywhere it's written down by an organisation - you'll almost always see 'Microsoft(R) Windows(R) Vista'. The point is that it's an unfair comparison to compare a colloquial name with a 'full' name. Also, the 'GNU/Linux' business has become a lot more meaningful recently, since we now have non-GNU Linuxes (notably Android), which kind of ties in with the first point because the FSF preëmpted that issue by quite some time.

Free vs convenient

paulj — Tue, 06 Oct 2009 10:33:48 +0000

when someone lists a bunch of products and labels the ones with ram firmware blobs unacceptable and says to buy the ones with the firmware blobs in flash (usually with windows-only update tools) or rom instead that is clearly preferring the ones with the firmware blobs in flash/rom.

So you're taking practical advice, based on the current condition of shifting markets, and then extrapolating the FSFs general principled position from it. I'm not sure that's useful. E.g. at present there's a dearth of hardware with open firmware (though, some wifi is getting there with reverse-engineered firmware). If there were such hardware, it's more than reasonable to think the FSF would recommend it - therefore your "FSF recommends ROM over flash" extrapolation is clearly insufficient.

it's a lot cheaper and easier to justify shutting up the FSF by adding flash (possibly by selecting a different cpu that includes flash on the chip for the next revision) than it is to go through all the business/legal hassle of releasing the source (and for companies that have never done this before, it is a hard thing to do)

So we're all agreed on the principle that open firmware would be best, but you disagree with the FSF on how to advance toward that, right? The practicalities seems like something reasonable people could have lots of different opinions on. That said, I disagree somewhat with your premise that adding flash is cheaper than opening the firmware. I don't think that follows at all. If you believe that free software adds economic value over the long-term for both the users and the vendors (if you don't believe that it ultimately adds value to the vendors as well, then you believe free software is not sustainable), then clearly opening the firmware would be cheaper than adding to the cost of your device's BoM. This is ignoring the matter of just how much clout the free-software/free-firmware crowd have.

we still haven't managed to convince the industry that the firmware blobs should be able to be distributed with the OS instead of having to be extracted from the windows drivers, getting that message through would be a lot easier than convincing the companies that they not only need to release control over the binary blobs, but also the source for them as well.

You may have a point here about the practicalities of advancing this agenda. I don't think though that it helps to try read the tea-leaves of the FSFs binary- blob-avoid hardware lists so as to, almost certainly (IMO), mischaracterise their position. That seems divisive and counter-productive to a longer-term goal that, very likely, nearly everyone here shares.

Free vs convenient

dlang — Tue, 06 Oct 2009 09:39:02 +0000

I would love it for vendors to make the source of the firmware available.

you claim that the FSF position will drive vendors to open the source for their firmware, however by telling people to buy the products with the firmware locked down to flash/rom instead of the ones with it in ram, I see the push moving vendors the wrong way. it's a lot cheaper and easier to justify shutting up the FSF by adding flash (possibly by selecting a different cpu that includes flash on the chip for the next revision) than it is to go through all the business/legal hassle of releasing the source (and for companies that have never done this before, it is a hard thing to do)

asking for the source of the firmware would be good, but the reality is that much of what is in the firmware of devices is third-party libraries that the companies do not have the rights to release.

Free vs convenient

paulj — Tue, 06 Oct 2009 08:27:28 +0000

but it has been stated many times (including in this discussion) that it's _acceptable_ to have the firmware blob in rom or flash, but not acceptable to have it in ram.

So how is that a *preference* for ROM? As for this discussion, it's not quite clear to me who is speaking for the FSF and who is putting words in their mouth. (NB: I've nothing to do with the FSF, though I might have given them money in the past).

as for the claim 'users given the same rights as the manufacturers/developers', that's a nice sound bite, but I would argue that firmware blobs in ram already give the user more rights than the manufacturers as the user can decide at boot time which firmware to use. I don't see any way that the manufacturer can dictate that the user must update to a newer firmware blob. I have seen devices where one firmware has a feature that is removed in later firmware updates and users choose to use the older firmware to maintain them.

Well, there tend to be major differences in development attitude towards and the spread of its cost over the lifetime of a device, between devices whose working is hard to field-modify and those which are easy to modify. A hard-to-change device (ROM/most flash) will, on average, have had more effort put into development and QA prior to shipping. With an easy-to-change device (RAM/low-risk-upgrade flash), the vendor can afford to ship earlier obviously, and it will have more bugs initially.

Basically the 2 cases are, given the economics, not quite as equal as you claim. The 2 cases may be poles of a spectrum, and there may not be a sharp dividing line between them, but clearly at one end the user is getting a reasonably unprogrammable "device" and at the other they're getting a programmable device whose development cycles the market is expected to experience, just like any other software.

Why should firmware in the latter class be different from any other software, which the FSF would say end-users should receive source for?

Now, I know, at present, it's not completely pragmatic to eschew soft- uploaded firmware, and I fully agree soft-uploaded for local-devices is much better. However, it would be nice to get a world where we all get the source to such firmware, surely? We can't all walk their path, but the FSFs' idealism surely helps achieve it? Pragmatically, the FSF do not object to *end-users* using closed, easy-uploaded firmware, rather they encourage users to *avoid* such hardware.

Free vs convenient

paulj — Tue, 06 Oct 2009 07:54:55 +0000

That doesn't say the FSF prefers ROM to uploaded firmware, afaict. Lets have
the rest of the discussion under dlang's reply to me.

Free vs convenient

foom — Tue, 06 Oct 2009 02:38:52 +0000

> built-in flash/eeprom/rom non-firmware

I meant to say:
built-in flash/eeprom/rom non-FREE firmware

Free vs convenient

foom — Tue, 06 Oct 2009 02:32:44 +0000

> Where does the FSF say they prefer ROM to uploaded firmware? I think a clear
> citation is important here.

http://www.fsf.org/resources /hw/net/wireless/cards.html

They list both cards that have built-in flash/eeprom/rom non-firmware and those for which free firmware has been developed, in the same list, without distinction. They tell you to avoid using the ones that require uploading non-free firmware, but don't mind listing a bunch that have non-free firmware hidden within the device.

Since wireless cards are one of the only kind of devices available for which you even have the OPTION of using Really Truly Free firmware (which is because these devices having uploadable firmware and are thus easily and safely hackable!), I would at least expect a recommendation to only use those. But no. Non-free firmware that you don't see is apparently just fine.

Free vs convenient

dlang — Tue, 06 Oct 2009 02:11:14 +0000

The FSF doesn't say that it's preferable to have the firmware blob in flash/rom instead of ram, but it has been stated many times (including in this discussion) that it's _acceptable_ to have the firmware blob in rom or flash, but not acceptable to have it in ram. This has been done both implicitly (by only attacking vendors that have the frimware blobs in ram) and explicitly when challenged on this behavior. To me if one is acceptable and the other isn't, then the one that's acceptable must be preferred.

the OS developer may require it by requiring features/APIs that are implemented in the new firmware that weren't in the old one, but in my opinion that is not a problem as long as the features/APIs are documented any more than it would be to require firmware version >X for a device that has the firmware in flash/rom.

Free vs convenient

paulj — Tue, 06 Oct 2009 01:49:00 +0000

There have been several comments now putting forth that the FSF prefer
ROMs to uploaded firmware. I'd really love to see a cite for this.

My own understanding is that the FSF would have users given the same rights
as the manufacturers/developers.

It seems like you (and possibly others) are taking that the FSF does not per se
require source to any baked-in code, as it doesn't violate this (the manufacturer
can no more change it than the user) and then bending it to some position
which, afaict, the FSF does not hold (least, I havn't found it and don't remember
it).

Where does the FSF say they prefer ROM to uploaded firmware? I think a clear
citation is important here.

Free vs convenient

dlang — Tue, 06 Oct 2009 01:28:38 +0000

the FSF position is that it's better to have a proprietary firmware blob in flash than to have it downloaded by the driver.

it's not that they say they approve of the proprietary firmware blob in flash explicitly, but they do so implicitly by attacking the vendors that download the blob from the driver and recommending that people use the devices that have the firmware blob in flash with the closed source update tool.

Reloadable without penalty vs. great big buggy hurdle

xoddam — Tue, 06 Oct 2009 01:03:14 +0000

+1 for sanity, and +2 for a real-world example.

When 'firmware' is obviously (from its implementation) loadable, replaceable software, and the procedure for loading it is well-specified and well-tested, that non-free firmware becomes a clear candidate for replacement by free firmware in the same way as compilers, editors and OS kernels were clear candidates for replacement by free software in the earliest days of the GNU project.

Ripping out the blobs is one way of pointing up the issue, but it isn't a solution to anything unless it is accompanied by efforts to obtain genuinely free firmware: by asking the people who already produce the firmware, or by encouraging development of free replacements.

If it's in flash or ROM, it won't occur even to most fairly brave hackers that it's a reasonable idea to tweak the blob, reverse-engineer it or rewrite it. Nor will it occur to anyone to ask for the source. But if it's in the Linux kernel as pages of hex constants, it's glaringly obvious that the source code is missing. The solution is to encourage reverse engineering and concurrently to ask nicely (and insistently, for years, with solid reasoning) for the complete corresponding source code. Surely?

It is to my mind far preferable in terms of end-user freedom to use RAM for firmware than any kind of ROM or rarely-exercised reflashing interface that risks bricking your hardware.

Free vs convenient

nix — Tue, 06 Oct 2009 00:29:06 +0000

Oh good, some vendors have thought of this then (though it sounds like
they still haven't thought of documenting it).

FSF offers "GNU Bucks" for finding nonfree works in free distributions

alankila — Mon, 05 Oct 2009 22:55:49 +0000

You are correct in observing that I'm not ideologically interested in free software.

Since the firmware code is interpreted by the CPU it is in practice fixable/workaroundable if there are problems. You just have to blacklist the pci-id, maybe checksum the methods, or whatever, to identify bad code and run something else instead (if you can discover what works). Something in this spirit is probably done with buggy ACPI code too.

Otherwise it's just an engineering tradeoff. Your goal is to make a stable hardware API that works the same regardless what GPU your board has, so that a new GPU can work with older version of drivers as well. The way ATI people went about to gain this goal was to have the GPU supply command stream for the CPU to interpret, rather than implement some region of memory that can be written to and is interpreted by the GPU to perform equivalent effect. To me, both solutions look pretty much identical. The AtomBIOS code should not be treated as non-free software, it's just instructions to drive the hardware supplied by the hardware to fill the contract of a stable hardware API.

Free vs convenient

paulj — Mon, 05 Oct 2009 15:35:14 +0000

I had a Yamaha SCSI 4416 CD-RW which I discovered had an emergency
firmware, after I made a mistake in my port of a firmware-writing utility. The
emergency firmware could only speak SCSI and upgrade the firmware, it couldn't
run the actual CDRW drive..

FSF offers "GNU Bucks" for finding nonfree works in free distributions

josh — Mon, 05 Oct 2009 00:37:03 +0000

Yes, your reaction sounds perfectly sensible from the perspective of someone who only sees freedom as a means to an end for obtaining better quality software. I acknowledge that that viewpoint leads to different tradeoffs. Others, including myself, value the freedom itself for reasons beyond simply believing it will produce better code.

In any case, even from a purely practical perspective, firmware interfaces have proven notoriously buggy in the past, and I have no reason to believe that this interface will prove any different. Having the ability to fix the firmware would provide a practical benefit.

As for your comment about always having some layer of proprietary bits underneath everything: valuing Free Software as a principle does not preclude having enough practicality to value something more Free over something less Free, without requiring immediate perfection.

Hardly convenient

nix — Sun, 04 Oct 2009 22:46:17 +0000

Both have updateable firmware. My Seagate drives require (ick) a Windows
program to update the firmware: my Areca RAID controllers can be updated
via their relatively icky (Linux statically linked closed-source 32-bit
x86 binary) web proxy, or I think via their BIOS-accessible interface
(higher-end controllers also have an Ethernet port but I bloody hope you
can't reflash the firmware over that). If the update goes awry you could
potentially reflash back to the earlier version --- *if* you have it
somewhere accessible with your disks behind a dead controller, and *if*
the updater still works in that situation, and *if* the firmware lets you
downgrade like that. (All these facts are, of course, undocumented.)

As you suggest, uploaded blobs are a lost cause in both cases, but
autodowngrading on failure is something both could implement. (Hell, for
all I know they do, but if they do they don't document it anywhere I can
find.)

FSF offers "GNU Bucks" for finding nonfree works in free distributions

alankila — Sun, 04 Oct 2009 22:31:28 +0000

Right, they have come into their senses. Well, no argument from me then. Can't care about the missing source, all that matters is that it's a documented interface. Until you have a PC made out of open chip schematics there'll always be a layer of closedness behind you anyway.

It just struck me as odd that there's a company trying to engineer a generic solution for getting hardware and software to cooperate without pushing a lot of complexity into every driver, and people would object to that rather than understand that the hardware was just trying to be helpful.

I mean, open source is nice and all, but it's a bit strange to treat the hardware-supplied code in ATI cards implementing some sort of defined interface as suspicious when you know that you can't get it right yourself without executing that code and tracing what it does, anyway. Which takes time & iterations with people who have each kind of hardware.

I was just thinking that maybe the interface was somehow inconvenient to use. If the sole reason is that it's closed-source, then that's pretty insane. You're picking a "guaranteed to fail" approach over "might even work".

Hardly convenient

man_ls — Sun, 04 Oct 2009 21:08:06 +0000

Scary, I didn't even know drives or controllers had updateable firmware. For these low-level components I am fairly sure it's as you say, a vanishingly small percentage of people ever reflash them. (And there isn't even the option to upload a binary blob from the OS to use them, since either the firmware is used before the OS or it would be needed to fetch the blob.)

FSF offers "GNU Bucks" for finding nonfree works in free distributions

nix — Sun, 04 Oct 2009 20:41:25 +0000

Who's fighting against it? Nobody that I can see. radeon and radeonhd both
use atombios stuff now. It's just somewhat disturbing 'cos we don't have
the source to this stuff.

Free vs convenient

nix — Sun, 04 Oct 2009 20:37:24 +0000

Network-connected devices, sure. What about your hard drive firmware? Your
BIOS? Your disk controller? All of those have upgradable flashable
firmware in my latest machine, and only one (the BIOS) provides any sort
of recovery if things go wrong --- and *that* requires me to dismantle the
computer, turn it on with the case off, and flip a jumper. Hardly
convenient.

FSF offers "GNU Bucks" for finding nonfree works in free distributions

alankila — Sun, 04 Oct 2009 16:35:41 +0000

To me, it seems like a nobrainer to just execute the atombios bytecode. Why are they fighting against it?

Free vs convenient

man_ls — Sun, 04 Oct 2009 13:32:06 +0000

From my very limited experience with these things, I think that vendors have improved a lot. I bricked my first ADSL router uploading the wrong file (which it did not check at all -- it was a .txt for goodness' sake!). The next one was cleverer. The current model has a recovery mode where pushing certain buttons upon startup it will load the provided file as a firmware image; that part (the "bootloader") cannot be overwritten so it is always available. IIRC the NSLU2 has that capability too, and I believe the iPhone has a similar panic mode.

Modern network-connected devices know how to upgrade themselves, generally require signed images, and the panic mode is there just in case something really bad happens. This auto-upgrading somehow negates dlang's argument about him deciding when to upgrade his firmware, and again tips the scales towards the vendor.

Free vs convenient

mjg59 — Sun, 04 Oct 2009 02:26:00 +0000

Except that's not the choice either. See the reverse-engineered open firmware for b43, for instance. The vendor's choice to provide runtime loadable firmware resulted in the development of a platform that allows people to perform research on 802.11 with a much lower investment than previously. While it would obviously be better if the vendor had provided open firmware in the first place, I'm pretty sure that this is preferable to people having to flash the firmware under Windows and risk bricking the card in the process.

Free vs convenient

nix — Sat, 03 Oct 2009 23:13:41 +0000

I suspect that people updating the firmware in their devices is
*vanishingly* rare, especially if those updates are persistent.

I never ever do it unless I encounter a bug that a new revision fixes,
because in almost all of these devices *there is no way back*: screw up
the upload (itself often done by software written for that purpose and
hardly ever run, thus horrendously buggy crap) and your device is toast.

Some BIOS vendors have fixed this by having a 'backup BIOS' in actual ROM
(or non-overwritten flash RAM, there's no real difference) and an easy
hit-one-key/flip-one-jumper way to flash that over the top of the BIOS
that actually gets run. But apart from those BIOS vendors, I've never seen
another piece of hardware that even tries to deal with this problem. (Oh,
your disk controller flashing failed? Hope you had backups, hope you
weren't planning on doing anything with that disk soon... your RAID
controller flashing failed? Send it back to the vendor, hope it's still in
its warranty window, and your disks? hope you didn't need them for a long
while.)

This has happened to me more than once, as a result of which I am now
fricking terrified of ever reflashing anything. So is anyone else with any
experience of these things. It's a one-way trapdoor with a possible tiger
beneath it. (The possible tiger being what happens if you lock a tiger in
a box with a radioactive atom and a phial of poison gas...)

Blobs that have to be uploaded every time have *none* of these problems.
I'd upload those on a whim. The absolute worst that happens there is you
need to pull the power and restart (if you had a bad CPU microcode upload
that locked up the CPU).