Debian faces firmware furore from FOSS freedom fighters A painful issue for Linux distros that are built on free software is firmware. This especially affects Debian, as outlined by former project head Steve Mcintyre here, and it's getting worse with time. Firmware is only called that for historical reasons now, which we'll go into below. It's no longer "firm" at all, it's just …
You could suggest that firmware could be loaded into the devices via the UEFI.
Originally the BIOS would bring everything up and hand over to the BIOS' on cards etc. Well I don't see why we can not leverage the UEFI somehow to load the latest firmware into such devices, thus helping being those devices up and ready for the OS, which then can be allowed to ignore the firmware issue.
BUT this wont be the case with USB devices. I would imagine the OS having to load in that firmware, makes sense as they are removable. I'm speaking about the firmware for devices that are non-removable, such as the wifi or SATA cards/chips. Not something a user will pull out every day.
Doesn't solve all the issues
It has (a lot), and my own machine is a reasonably recent ThinkPad with Devuan (which did work out of the box).
Yes, this issue is... tricky. On the one hand, it saves a few cents in the BOM, on the other it means you have to trust and distribute foreign, closed-source, unfree (which is more of an issue for some) code. Then, it is now pretty simple to get some "firm"ware update for a device, which in turn again means that it is no longer reasonably immutable, and miscreants can just insert their stuff and let it run undetected - because it is not run under the dupervision of the OS. I am reasonably happy that some people invest their time and energy in this issue, but in the end I am getting too old for this shite, have very limited spare time and want my machine to just work.
(yes, I usually try to check if the hardware is supported by Linux distros)
"On the one hand, it saves a few cents in the BOM, on the other it means you have to trust and distribute foreign, closed-source, unfree (which is more of an issue for some) code."
Look at it in another way. Your alternative is a few more cents on the BOM and having to trust that the firmware that's now immutable is also immaculate.
Thank you!
(Actually, this time, the headline is more or less mine.)
If there's one thing that was as pleasant to read as your comment, it is the 90-odd-message slanging match about licences and their importance (or lack thereof) after the initial couple of comments saying "but we knew this, didn't we?"
Cheers, folks. :-)
"The problem is that these days, if you don't need that software present the moment the computer is powered on, you can save a few cents per unit by omitting the ROM chips, and having the OS load the devices' firmware when they're initialized. It's still firmware, but now the OS on a different processor reads it from a file and uploads it into the device's onboard RAM."
The more significant benefit to the H/W user, if not to the vendor, is that by loading the firmware into onboard RAM it can be upgraded without having to replace the ROM or go through the always slightly risky process of flashing an EPROM. The same applies to microcode.
Except for extremely simple peripherals* the choice isn't going to be between firmware and no firmware, it's going to be between firmware that can be upgraded in that fashion and firmware that can't, but even if you choose the latter you're still going to have to trust the vendor.
* If such things are still available you could choose a motherboard with just old-style serial and parallel interfaces. It would at least remove the dilemma because you're not going to have anything on which to load your OS.
Using my boxes without proprietary blobs would be nice. Reality gets in the way however and some things need the proprietary stuff to work properly.
Take the nvidia drivers in Linux. Nouveau works, not well, but it works. The trouble is if you want to do anything other than basic computing you really need the nvidia drivers.
I am having real problems with nouveau. For some reason my distro which used to install the nvidia driver for your card, if you wanted to use it, doesn't seem to work on my main machine and I'm stuck with nouveau. With that if I try and play a video I get stuttering, nasty artefacts and sometimes it will just slow to a crawl. I have been helped by my distro's forum and one of the suggestions was because my video card is getting old I should get a new one. That's not going to happen. Have you seen the price of new cards? That is if you can get one, and even second-hand ones are currently out of my reach.
My old card is perfectly capable of doing all that I need, all that's holding it back is the FOSS driver I am having to use. So while in theory having FOSS drivers to go along with my FOSS OS would be perfect, sometimes you have to compromise and use the tools that best meet your needs.
I would love to be able to ditch all the proprietary stuff on my machines, that's why I use Linux, but real life keeps me anchored to stuff I can neither examine or entirely trust.
> doesn't seem to work on my main machine and I'm stuck with nouveau
Same here. Fortunately I don't play graphics-intensive games, so while weak, nouveau is enough for me -- most of the time.
As for the option to change the video card, I'd be grateful if somebody could explain to me how to do that on a laptop...
Plan Stupid:
Step 1) Steal under wear Remove firmware.
Step 2) ???
Step 3) All firmware becomes libre.
Plan Sane:
Step 1) Create GPL firmware for devices with documentation.
Step 2) Offer to port firmware to new devices in return for documentation.
Step 3) Create list of hardware with GPL firmware so users can vote with their wallets.
Unfortunately the people creating the devices that need firmware aren't sufficiently incentivised to care. They don't really want a GPL firmware (GPL perhaps not being the best choice since then it's no good for BSD and such) and since the vast majority of Linux users will just install the proprietary firmware blob and get on with things there's very little demand from consumers even within the Linux community.
"GPL is only horrible if you want to take free (libre) code and make it not be free any more."
... but thats actually a useful thing to do, isnt it ? Nintendo take BSD, add a shed-load of bits to it, and now my kids have a Switch to play on. It's, no longer Libre, but you can't argue that Nintendo haven't added value doing that, which they can legitimately charge for.
and if I want to download and run BSD, well, I can still do that, so nothing has been taken away from me *shrug*
Wouldn't it have been better if the free licence had been retained? After all, it's not the code that they are asking to be paid for.
Oh yes, they want to shoehorn in DRM crap so that they can be a monopsony to the game devs. Without that you could afford more games for your kids.
> but you can't argue that Nintendo haven't added value doing that
Yes you can.
It is in the eye of the beholder.
DO your kids NEED that switch or is it YOU need them to have that switch?
Do I need a switch (yes, I have one). I don't need it. I need a front door, yes, but I don't need a switch. It merely fulfills a role which many things can do instead of the switch.
So it can be argued whether Nintendo added value or not, because that value is entirely arbitrary. You can get the same value from any computer. If you only look at it as a form of entertainment, you could replace the switch with anything from a board game to a cardbaord box.
Kids existed and played just fine before the switch. My C64 was perfectly fine, before that my books and a football worked fine.
“ GPL is only horrible if you want to take free (libre) code and make it not be free any more”
Well that’s just plain bollocks.
BSD (to name but one other license) is more “free” than GPL and yet the horrible viral nature of GPL makes it difficult to use GPL code in a BSD context.
As the line you quoted points out, your BSD isn't guaranteed to stay free. I care about that, seems you don't. We each make our own choice, knowing that there are costs either way. My cost is I don't get proprietary code, your cost is you don't get GPL code.
How the BSD licence help fix the problem with closed firmware blobs? All it does is allow the manufacturer to copy open-source BSD-licensed code and paste it in to the propriety code and then not distribute anything. How's that going to help the device work with an open-source OS (Linux, BSD, or anything else)?
If you just want a (mostly) working computer and aren't interested in why component manufacturers don't distribute code or drivers to OS developers except MS and Apple then just keep the default Windows 11 install and be happy. You're obviously not the target audience for an open source OS.
It's called choice, something that some open source advocated only support when it is in their favour. A shiny new world-beating graphics card from Nvidia does not have open source drivers? Use something else. Too many open source people are closed brains. They do not have some equal rights to something they did not create.
Drivers run on the OS side. Firmware runs on the hardware. The os interacts with the driver, the driver talks to the firmware on the device. Even if you had the source to the firmware there is didly squat you can do with it as you have no idea how the hardware works and you don't have the toolchain or compilers to build it anyway.
"Some people just don't get it."
You don't get it. The BSD license has enabled too many to bulk copy code into proprietary non-free software and sell it back to the user with very, very little in return. Worse, almost all that is returned back to the "FOSS" paradigm is poisoned and tailored for abuse, simply look at anything Google "gives".
The BSD license like the MIT license once had it's place and served as a needed bridge, but today these common licenses are simply fueling another CEO's yacht cruise.
FOSS is dead. Replace the 'F' with a 'C' for Corporate and you reveal the real beneficiaries.
-> The BSD license has enabled too many to bulk copy code into proprietary non-free software
And perhaps that is what the authors of that code wanted. The thing with GPL nutcases is they think they have the right to other people's code. GPL is a horrible licence. It is THE incompatible licence.
"GPL nutcases" - well that pretty well defines you're position.
The whole thing is that GPL is a choice - if you don't like it, then don't use any software released under it. Simples.
What GPL proponents want is not that "all code belongs to them", but that if they write and contribute code, then no-one can take that, build something from it, and not pass on the benefits of having built that system using other people's code.
Like I said up front, if you want to be able to take someone else's work and use it for your own benefits without passing on any of the benefits you got from taking it - then stay clear of GPL code. And let's be clear on this, if you are wanting to use GPL code, then that means you see value in using that instead of - for example - writing your own. So basically the anti-GPL argument comes down to "I want to steal code and use it to line my own pockets".
I don't need any lectures about GPL. If I want to and choose to I can write and release code under BSD.
Now how about the GPL headbangers acknowledging they frequently use code with other-than-GPL licences?
You have Xorg? MIT.
You use OpenSSH? BSD type.
You use LibreOffice? MPL.
etc. etc.
If GPL is so good, stick to it. And don't use these sub-par let's-sneer-down-our-noses-at-them non-GPL goodies.
Are, a good old non sequitur - lost argument so introduce something that sound vaguely plausible but is completely irrelevant.
Who said anything about only using code under one licence ? All I said was that if you don't like/want to abide by the terms under which you can use and adapt GPL code, just don't. I didn't suggest that there is only one valid licence.
And perhaps you might like to explain what is wrong with taking and using code within the specific rights/restrictions specified by the licence under which the code is released ?. What is wrong with including (e.g.) OpenSSH and complying with its licence ? Your statement seems intended to imply that doing so is somehow illegal or immoral.
> If it means I have a working computer, so what? Some people just don't get it. It's more important to me to have a functioning computer than an earful of pedantry about firmware which I will NEVER look at.
Ah, so you are the type who would sign away anything if it is convenient for you.
> GPL is a horrible licence. Pick the BSD licence instead
What is your problem with copyleft?
I have yet to hear anything that is convincing and not just about being the most free.
Society is full of freedom, plus rules that curb that freedom in certain circumstances. Those rules are there to cover exceptions. For example. I'm free to walk anywhere I like, but private property laws still exist, I can still be done for tresspass. In some countries you can own a gun, but you can not do certain things with it. Ok, a gun is an extreme example but it still is one, I don't have to shoot it but I'm still going to be in a worse off position if I were to wave an unloaded gun about during an argument.
Lets have another example, I have the freedom to own as many telescopes, binoculars and cameras as I like. I can take all sorts of photos ranging from the stars and moon, to the birds in the tree to people out on public property. But, I cant freely use such things to take covert photos of certain sensitive things like military bases. Nor can I take photos of someone on private property without the permission of the property owner. In fact if I do take a photo of someone on public property, which in most cases I would be free do do so, I still don't have the freedom to use such a photo commercially without a model release form (where the person can be identified). In fact France are even more strict, not allowing any public photography of anyone without permission.
So.
Why should a developer be free to remove freedom from users?
It's a curious distinction to make imo, if the user bought the hardware it seems reasonable to me to assume they trust the vendor. Even as the article states, you have to trust at least the firmware in the BIOS/UEFI for the motherboard.
All machines (PCs, laptops etc) have closed-source firmware running on them. If the device makers suddenly decided to use ROM/EEPROM chips to store firmware again, I can't imagine many users would suddenly just stop buying those devices just because the firmware was baked in.
So to summarise (and I think the article gets at this just in more words), in the case of Debian it's purist thinking whilst ignoring that short of rolling your own hardware (CPU and motherboard included) you can't avoid propriety closed-source firmware.
Actually it's worse than that
if I don't install the latest microcode update for my i7-3770, it'll run for about 2 hours before throwing a fault of some sort or the other.
I honestly thought I had a bad CPU before I knew I had to load the intel-microcode package.
> short of rolling your own hardware you can't avoid propriety closed-source firmware
That's the gist of the whole problem! Sorry you can't realistically expect Nvidia (or whoever) to bother open source their firmware just for you to feel better, especially if open source purists only make a vanishingly tiny 0.x% fraction of their clientele. They might start considering it if purists made up half their clientele, and there was an open source alternative for potential clients to chose from.
(For the record, I do use one closed source firmware blob on my laptop, because I don't have any uses for an oversized paperweight. Note I did buy this laptop before switching to Linux, and obviously changing hardware isn't an option.)
Also forking = duplication and wasted effort.
Let's go through the Mozilla code and remove all the Mozilla trademark stuff and call the result IceWeasel. The absolute pedantry of these people is pathetic. They haven't advanced their OS at all, they have instead diverted resources to doing this crap, and telling people they did this crap, and bragging they did this crap. Why not just tell people 'use Mozilla'? Don't answer, I already know why. I wonder if any of these nutjobs drives a car from the modern era that has embedded firmware in its parts. If they do, they should be banished from turning up to Debian meetings or told to ride a bicycle or drive an old car instead, lest they be tempted to the dark side of closed firmware.
What I see in this article is something I regularly complain about - the umpteen forks and derivatives in Linux as a whole. The fact that something can be forked does not mean that it should be forked. Rarely do any of these forks or derivatives stand out (Ubuntu is a successful one). The others have low use numbers and rumble along on one cylinder for a while and eventually conk out. It is wasted effort and distracts from what would be more stable and viable 'main' distributions.
No. They did it because that is what Mozilla chose to require.
Of course, in the the real world most people ignore licence agreements and "just get on with things". But don't blame Debian when it was Mozilla's choice to require Debian to use a different name.
The issue had a couple different sides to it, not just the one.
One part of the issue was that Debian was maintaining Firefox with patches and security fixes outside of what were officially available from Mozilla, largely because of different release cadences, different support philosophies, and perhaps most importantly, occasionally different versions of dependencies. Mozilla didn't want bug reports being submitted to upstream Firefox because of changes that Debian had introduced downstream.
Another part of the issue was that the branding included with Firefox was distributed under a license incompatible with the Debian Free Software Guidelines, so Debian had stripped out the logo and replaced it with a generic globe. In order to maintain their trademark, however, Mozilla required that Debian either use the source code and branding as they distributed or fork it.
There may be a bit more to it than just that, but it wasn't simply that Debian insisted on no trademarks.
At that time, Debian did not include the Firefox logo as it was not re-distributable (trademarked by Mozilla). Therefore they changed the logo for another one. Mozilla didn't like this and told them to distributing Firefox without its logo and to submit all changes made to the codebase to Mozilla for approval, so Debian changed the name of the browser as well.
But this issue has been resolved for several years now.
> duplication and wasted effort.
Indeed, the biggest problem of FOSS is that it is a huge billiard table of colliding egos.
FOSS (and Linux) unfortunately follows the second law of thermodynamics, most resources are wasted in petty fights...
Now don't get me wrong, I'm all about freedom of choice and all, but to my outsider eyes some of the forks sound unnecessary (if not downright conceited). I guess it's just the downside of freedom and thus unavoidable, but it does slow down the evolution of Linux, which could had been the most accomplished and thus dominant OS by now, especially seeing how Windows is going down the drain fast. *shrug*
"most resources are wasted in petty fights..."
Yes maybe they are, but unless the use of these resource are stopping you from doing something who cares?
People start projects, maintain programs and fork other peoples stuff because they want to. A lot of people are not in it for the money or as a job, they do it for the pleasure of building something that others may appreciate or find useful. Just stopping some of the forks does not mean that the devs will move onto something "more productive".
No one is forcing you to use any of the applications, utilities or OSs that are on offer so why worry about the time and effort other people are putting into their projects. They are not costing you anything in time, money or resources so why all the angst?
See choice is a two way street in FOSS. You have a choice to use or not programs and the devs have the choice in what they decide to work on.
Thank you for seeing the light. You perhaps express it a bit more politely than I usually do.
I am in favour of Linux and open source. I am not in favour of having thousands of distros with pointless differences which means duplication of effort. If you read the crap differences between them these people think they have invented a new wheel. One distro has Chromium instead of Firefox. Oh well, that makes all the difference. I had better drop what I am doing straight away and head on over there to this insignificant distro.
Let's all invent a new package manager, cos that's what the world is waiting for. Bob's package manager uses MongoDB which is useful for those people wanting billions of packages installed.
Of course, another viewpoint is that if some project manages to persuade a lot of people (and specifically distros) that their re-invention of multiple wheels (mostly in a manner that's incompatible and inferior to the original) then it's possible for a project to form with the specific intent of keeping the tried, tested, reliable, original wheels instead of being forced t use the all new, super duper, bug ridden "new shiny" from a team who have an Apple-esque attitude to bugs and incompatibilities they create.
And that's why I've not set up a new Debian install for some years now - all my new installs are Devuan.
Of course, when Microsoft or Apple decide that the world is changing to suit their whims, then users have little choice but to tag along - no matter how hair brained the changes. At least with FOSS there are options.
Far better in my opinion to have a friendly encouraging attitude and try to engage device manufacturers and explain why it would be nice if they open sourced the firmware. Then leave it up to them to make a choice whether they do or not, with hopefully enough praise having being given to those that do to make it seem attractive and even a positive selling point (and not piling in with criticism about open source license wars or nitpicking the moment something's discovered to be 0.00000001% non-compliant might help too).
Open souce is a bit of a red herring here. You may believe that having the source lets you have 100% awareness of what's happening inside the hardware. But unless you can inspect a full circuit diagram of all the chips inside it, work out how they work and check that each chip conforms, you have no guarantee that that code''s actually being executed, or doing what you think it does.
"engage device manufacturers and explain why it would be nice if they open sourced the firmware"
But then it would be obvious and visible to the world just how poor the hardware actually is and we'd all be able to see the badly written kludges in the driver software that has to work around those hardware failings.
> But then it would be obvious and visible to the world just how poor the hardware actually is and we'd all be able to see the badly written kludges in the driver software that has to work around those hardware failings.
And, I've heard it suggested, we'd also see exactly how many other patents and licences the manaufacturers are infringing.
Whether the firmware is already uploaded to the device or whether you (your driver) needs to upload it each boot makes this more of a philosophical decision which both have their advantages and disadvantages.
What I personally do however is only load firmware I need (likewise on Windows, I only install drivers that I need, leaving the Device Manager looking fairly unhappy!). It seems I am fairly alone in this in that the OCD(?) of others seems to lead them into installing loads of "stuff" even if they don't intend to use it. I find that odd personally. Things like Bluetooth drivers / firmware really don't need installing on a development workstation and actually wastes power when loaded but idle.
The only firmware that is tricky are ones that prevent damage / wear to the machine. Power management (CPU and GPU) mainly. I feel even if an OS chooses not to provide this by default, they really should notify the users that it is available. I feel OpenBSD does this really well on first boot. It also localizes the firmware into a separate "repo" so the correct one can be easily found and prepared for *offline* install.
> Some value purity over convenience
I wonder what the arguments: for / against "pure" O/S releases would look like if every user was given the same amount of publicity?
For example: each person who cared greatly about "purity" had as many tweets on the subject, articles published, opinions written as each person who frankly did not give a toss.
So for the FIIK how many million downloaders Debian or Ubuntu or whatever had, each person who objected to third-party blobs wrote the same number of opinion pieces as every other downloader did. Just what would the mass of user published feedback look like? Would there be a solid, identifiable, group of dissenters or would there be a small number of outliers whose presence simply got submerged in the overwhelming approval, or indifference?
This is just one aspect of global opinions being formed by a small number of outspoken activists. Individuals who speak loudly and frequently on a subject - disproportionately to their numbers. Thus giving the impression that there are a lot of people for, or against, any particular thing. Maybe even to the point where potential firmware developers think there is massive hostility against blobs, or no market for them, so they choose not to release them. Even though in reality it is nothing more than a small clique (or a horde of 'bots) making waves while everyone else gets on with not giving a damn about any higher principles or paranoia.
Rather a large assumption there - that the "purity" crowd aren't publishing to the same frequency.
They may well be doing so, but a) their views are less popular so they get read less and/or b) there's just not that many of them and therefore the numbers of such articles is low due to that.
Assuming there's some widespread bias about an issue that the majority of people neither know nor care about is rather odd.
Jenny List, writing at https://hackaday.com/2021/01/29/why-blobs-are-important-and-why-you-should-care/ , suggests that many controller ASIC contain bought-in IP which might include firmware provided under NDA, the source of which quite simply can't be made public.
As others have said, this is hardly a new problem. In addition, Debian does have various binary firmware collections in the "non-free" area of its main repository.
The real problem is when installation requires non-free firmware... and the target system has no supported removable medium from which it may be loaded (not to mention the virtually-undocumented naming conventions etc.). Or even (and I've seen this on SPARC systems... anybody remember SPARC?) when the installation CD contained a blob for the SCSI controller which it didn't actually install.
If Devuan and Debian were to merge, and then you get a choice of init during setup (and not after), wouldn;t THAT be AWESOME? But that might require double-sets of certain packages, one with systemd, one without, as too many key packages depend on systemd being there, or its features being implemented some other way (and the two may not be compatible).
Similarly Gnome and Mate, though I believe that by now it is FAR less likely with the latest GTK forcing ADWAITA. Just NO on that.
I'd say this is why forks exist.
"many key packages depend on systemd being there, or its features being implemented some other way (and the two may not be compatible)"
This is what keeps the Devuan guys working hard. They have an automated build system that fixes most things, the distro includes the odd "systemd is here, honest!" file for lying to the packages that refuse to instal without it but don't actually use it (how perverse can you get!), many tweaks get fed upstream so the packages can restore compatibility with multiple init choices, and yes a few have to be forked - but this may well be because the upstream developers are bloody-minded and/or lazy toerags who only support systemd, not for technical reasons.
If Debian accepted that they ought to offer init choice like they used to, in the same way they still offer a choice of desktops and various other whatnots, the community would very quickly shake itself down and recover its sanity.
AIUI Part of the "needs it but doesn't use it" is down to the way stuff needs to be linked to the libraries.
So for a programme to be able to run on a systemd system, it must be linked to the systemd core libraries. And once that's been done, then it can't be loaded if that core library isn't there.
In part, the fact that the systemd guys have gone out of their way to be incompatible with existing functions makes things worse. So there's an existing system call for (e.g.) logging stuff - so lets create a new and incompatible one meaning that programmers have to choose one or the other, or deal with both. From the systemd project PoV this is good - so many distros are now systemd only (in spite of having voted to support it as "will be a choice which init to use") that programs now need to support the new (many new just for the sake of being new) APIs.
And so, there's going to be a temptation to stop supporting the tried, tested, and reliable older versions - meaning more work for those trying to keep some choice going.
I'm not an expert here, but that's how it's been explained to me - perhaps it's just my terminology is wrong ?
If a binary isn't linked (and this typically means statically linked with at least the headers for the libraries, then it can't use any of those functions - so without being linked to libsystemd0 then it can't use any systemd functions , effectively it can't run on a system using systemd for "all the s**t systemd had decided needed replacing for often vague or invalid reasons".
And when it is statically linked to that - it won't load if it's not there. Hence why even Devuan still has libsystemd0 - because otherwise it would mean forking a gazzilion packages (and then having to maintain those forks) just to remove gratuitous dependencies to non-essential functions.
I'd much rather have all free code, end to end. Until I can afford the premium for Puri.sm I'll have to put up with the other thing, but I'll minimise it as far as I can.
Then there's the fact that I also prefer to buy used, so that I'm not responsible for more embodied energy or chemical pollution. So I'll still hesitate to buy from Puri.sm for that reason.
"Probably the only real ROM in your computer is the main one on the motherboard – formerly the BIOS, and more recently UEFI – because without it, your computer won't boot. All the other firmware is loaded when it's needed."
Far from it.
My laptop has the system UEFI as you describe, but the SSD has its own non-volatile, persistent firmware too. So does the touchpad. So does the LCD panel. So does the external mouse I use when I don't want to faff around with the touchpad. So does the external keyboard. So does the printer. And if it was my desktop that has a discrete GPU card, it would have one as well.
I've updated the onboard firmware in all of these things. The LCD panel was the one that was the biggest surprise, but yeah, Dell put out an update for that too to solve a flickering panel issue.
The updater for the LCD panel, as well as the ones for the touchpad and the SSD, are in .exe format and do not have Linux versions, so I have an external (USB 3.1 10GBPS) SSD with Winders on it that I use for those rare occasions. For the USB devices, my VM is sufficient, so no need for the external SSD there.
I would contend that there is almost no ROM in your computer. There is persistent storage - normally flash or sometimes EEPROM nowadays, yes, but most devices now are made with SoC micro-controllers with built in storage, even down to the mouse and external storage card readers.
The only real ROM there is will probably be a small amount embedded in the SoC that allows the real firmware to be loaded into persistent storage using something like the I2C or JTAG interfaces when a device is first manufactured
It's been many, many years since there have been ROM chips on devices like disk adapters.
I remember when I first realized that device adapters had their own processors. In theory, I knew, as mainframe channel attached devices had to have their own processing power, but it was when I spotted a Z80 sitting on a DEC DZ11 8 port serial adapter for a PDP11, and read that the local processor on the adapter would manage fifos in the device mapped memory space of the UNIBUS without the involvement of the main processor, and would only interrupt the CPU when 12-16 characters had been received, or the fifo transmitted. Prior to that with the DL11 serial cards, the CPU was involved with every individual character received or transmitted, and the interface just handled strobing the bits out to the line.
The code to manage the DZ11 was contained in real ROM chips, which needed to be physically swapped out if there was a firmware update. This is what firmware originally meant. It was software that was handled as it it were hardware. Software updatable firmware should really be called something else, like microcode, although even that is used to mean multiple things. And firmware that needs to be installed every time a system is initialized is something else again.
It's funny. I've just realized that implementing serial buses using pins on the GPIO bus of Raspberry Pis or Arduinos is much more like the old DL and KL11 adapters, and is hardware managed directly by the CPU. How things go around!
> I would contend that there is almost no ROM in your computer
EEPROM Is a type of ROM
Flash is a type of ROM.
We are not only considering mask ROM here, they are all ROM. Well, ok flash is much more writable than you would expect ROM to be so it may fall into your argument, but not EEPROM
I would disagree. I
In both of these cases, the memory can be altered without removing it from the system. This means that it is definitely NOT Read Only Memory.
EEPROM is probably a bit of an oxymoron, especially in the modern implementations, and I would say that it is probably best regarded as Read-Mostly Memory (can I coin RMM?). I admit that early EEPROMs needed to be taken out of the system to be re-programmed, but many systems for the last 30 years or so contain the mechanisms to alter the contents in situ.
Flash is decidedly RAM, albeit of the persistent variety, in the same way that Core memory was RAM, but persistent.
I read the source. OK, not all of it, but I do check the most important parts before putting anything public on my server. And yes I have found and reported security problems which have been patched. You lot should be grateful that crazy folks like me are around looking after you, and open source lets us do our thing :-)
>> -> I read the source. OK, not all of it,
< = You do not read the source.
How did you navigate that weird logic. Even if the poster read only 1 function or whatever, then that is reading the source. How can the poster, read the source of just 1 function, without reading the source?
Explain...
What I really like about this article are the penetrating observations that the problem with open source is that it goes unread, while the problem with proprietary code is that the source is necessarily unavailable. I have to wonder where this guy finds problem-free code.
Funnily enough, both observations are wrong. Open-source code gets audited, reported and patched with relentless frequency, while proprietors have been known to open their source to inspection by arrangement, when it suits their business to do so; you just have to make it worth their while.
You should be able to repair and modify the firmware. You should be able to upgraded this and have support from the community otherwise you end up with vendors that keep on pushing new hardware where there are only software changes that support newer standards for instance. Granted this will fuck the Broadcom Nvidia Intel business model but then again Standard Oil had to broken up and sold off.
So: if you head over to Debian mailing lists and see what the fuss is about. One of the maintainers of the Debian media has asked: Can we split off firmware into its own subset of non-free software - which stops you having to suggest the whole of non-free to users? If users want a fully working PC, can we then add the contents of the firmware repository to the install medium so that it works out of the box for most users?
This reflects most people's reality with installing Debian without firmware: it's really hard, stuff doesn't then work and people complain that Debian is at fault. Almost all the other distributions already accept firmware as absolutely necessary. The ones that don't - the FSF approved ones - are mostly three or more years old / unmaintained / are switching to a BSD base. Many - including myself - suggest installing with the firmware .iso file to save trouble you might have.
Our priorities are our users and free software: the discussion (and various options proposed) are as to how we best serve that. Both Steve McIntyre and Andy Simpkins have also written blogs on this subject syndicated to Planet Debian.
[Disclosure: I am a Debian developer: I work on the CD release team with both Steve and Andy].
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
