IIRC he thinks that if the code is updateable, it should be free and it should be possible to replace it with code of ones own creation, if so desired. Completely non-updatable firmware in ROMs he is OK with being non-free.
Except even firmware that comes with the hardware may be updatable somehow.
I believe that firmware should be free, but refusing to ship blobs for this reason, while still attempting to be compatible with hardware that buries them under the covers (even when the blobs not being shipped are updates for the very same hardware - e.g. all major x86 CPUs), is burying one's head in the sand. Would be more principled to avoid hardware with proprietary firmware entirely, and advocate for both documented hardware and 'free' (i.e. open HDL etc.) hardware.
That's the problem. I understand and respect Richard Stallman, but I can't agree with him on this subject.
How can you know that firmware is "completely non-updateable"? You trust the vendor with that, there's no way to know for sure. What's more - recently (~1.5y ago) somebody figured out how to update firmware of microSD cards [1]. Thanks to him, if we want to apply FSF's point of view, microSD cards suddenly became unacceptable, non-free hardware, while before that blog post they were just fine.
I'm involved in development of Neo900 [2] phone and already had fair share of discussions about freedom and openness of components with various people. I was a part of Openmoko community in the past and remember the TI Calypso modem used inside Neo1973 and Neo Freerunner. At first they were non-updateable (for consumer), so were acceptable to RMS. Some time later Openmoko Inc. got firmware fixes for pretty annoying bugs like SIM compatibility and started trying to figure out how to distribute the updates. They obtained a license to redistribute the updater tool, provided the instructions and the firmware image. Suddenly, Neo Freerunner became non-free hw.
Then, some time later, partially thanks to Openmoko who provided the updater and instructions, OsmocomBB [3] was born (Harald Welte, who initiated OsmocomBB, also worked earlier in Openmoko). Suddenly Neo Freerunner became free again because there's a free firmware available for Calypso now.
So my device I was carrying in my pocket, without any my intervention, went from free to non-free and to free back again. Fun!
Also, as a user who cares about his freedom, I prefer to have a hardware with updateable or even entirely user provided non-free firmware than a black-box with the same non-free firmware inside, but not updateable. Of course over that I'll prefer a hw with open firmware, but in the case of the black box, there is even no hope that such a firmware will be provided in the future. And when at the same time you cannot be 100% sure that it really is non-updateable, then what's the advantage? I can't see any.
In theory, I can agree with FSF and RMS. In practice, hardware doesn't really work that way.
As someone who knows approximately jack shit about hardware and firmware issues, I appreciate the time he did waste explaining why he says the original poster was full of shit.
It's about time a decent Theo de Raadt smackdown made it to the front page of HN. The scale of the condemnation directed toward Linus Torvalds is quite unfair when there's even more stern (and often correct) ranters than him.
I'm sure I wouldn't want to find myself at the other end of a Theo or Linus rant, but they sure are entertaining to read. Let's face it: a majority of people probably wish they could be so direct, especially when dealing with those who do effectively zero research before wasting everyone's time.
I'm not sure the majority of people really wish that. There are plenty of places where you can rant on mailing lists, but it's not really a great way to spend time. Better to just calmly correct things that are worth correcting, ignore things not worth responding to, and move on to other things. Imo this style of rant isn't even entertaining once you've seen more than a few of them, because they basically follow a template. (Suggested AI class project: write a generator for Theo rants.)
This email was a bit harsh. The first poster was a bit clueless but I'm sure it would have been possible to correct all the misconceptions without being rude. And I'm a bit surprised to see a high profile maintainer bother to reply to such a misguided post anyway.
Perhaps being a maintainer of a significant infrastructure project like an OS kernel wears on a person and builds a bit of a short-fuse temper :)
That's just Theo being himself (and the OpenBSD community by extension) alienating yet another user.
A reason IMHO that OpenBSD has never reached the level of notoriety of FreeBSD is Theo's childish behaviour. I can understand a 20-something insulting someone like that, but not Theo.
ps. I didn't quite understand the Linus reference, but anyway.
the OpenBSD community gladly alienates those types of users. for "us" (I speak only for myself as a decade+ user and supporter), it's a qualitative game, not quantitative.
Different project structure, I think. You'll likely get told off by subsystem maintainers or even kernel janitors before that. If it gets to Linus, it must have been something unnerving.
This can be interpreted both ways, however. Where Linus will be more elusive, Theo will have no qualms with just barging in and telling you to read the source code, ivory tower be damned. Almost as if he sort of respects even newbies enough to slap some quick advice to their face.
This email was an entirely appropriate response to one of the most commonly-seen selfish and rude mailing list posts in software development.
"Hi guys, I know you've been working for years on this! I haven't really bothered to look at your code, or understand the principles of operation, but I have strong opinions about How Things Should Be Done and I'm here to tell you how to run your project."
The reason Theo himself replies to this sort of thing, and in this sort of fashion, is to make it absolutely clear (both to this imbecile and anyone who seeks to emulate him) that the people who want this sort of thing are wrong and will be wasting their effort in asking for it.
I don't think an email like that is ever appropriate. It's immature and childish, regardless of how foolish the initial inquiry was. There are certainly people who can provoke that kind of reaction, but since I don't know any backstory I have to go on what I read at the link. Here's an interesting truth: as your software achieves greater levels of use and success you come into contact with more, not fewer, clueless people with strong opinions. You going to tell all of them they are idiots? I assume so. Think about the impression others get when they come upon stuff like this in the archive, before you go cheering on such behavior. I have nothing bad to say about OpenBSD or the people who run the project, but reading a reply like that makes me wince.
> I assume so. Think about the impression others get when they come upon stuff like this in the archive
I loved this mail, and it's actually making OpenBSD stand out as a human project, because it's not riddled with indecipherable political correctness. You can feel there are people involved, that they didn't copy-pasted a template but actually thought out their words, you can feel the involvement of the people. On the other end of the spectrum a smiley would also make the project more human, closer to the people. This mail also serves as a warning to future people who will want to engage a similar path of "I don't know anything, but I think things should be done This Way" to actually think about it. A net advantage.
Yes, the mail is harsh; that doesn't mean countrygeek should have a problem with it. The latter can (and should) absolutely go back to the research part, try to understand what he asks for, and then come back with a plan. That is what is really asked from the kind of people in the same position.
The problem for me isn't the lack of "political correctness", but the weirdness of being so angry about someone being wrong on the internet, and the tediousness of it happening often. Sometimes someone is good enough at other things that it's worth working with them anyway, but it's despite their tendency go to off on mailing lists, not because of it! And when more than one person does it regularly it gets really tedious, e.g. in the old comp.lang.lisp, Another Goddamn Flame From The Usual Suspects was not one of the group's strong points, even though some of those people were also smart.
I think the email that was sent was incredibly rude. This person clearly spent considerable time writing it, and yet it shows from start to finish they didn't bother to read, research, or even understand the current state of OpenBSD.
Why should fools be suffered? OpenBSD developers have an OS to develop.
I've gone down the road of setting up a "blob-free" system, just to see what it might take, and it turned out (unsurprisingly) that it requires an enormous amount of sacrifice and effort. In the end I had a fragile old thinkpad x60 that ran an OS that got in my way. I lacked the time/effort/enthusiasm/means to commit to the cause, and now it's sitting in the corner collecting dust.
To piggyback off of the above comment; There does exist a completely, as in 100%, free laptop for sale. "This is extremely rare in modern day computing."[0]
Is it just me or is there a conspiracy not to determinedly and aggressively seek alternatives to closed firmware in the so called open source world? Theo de Raadt's response makes me feel that some people who claim to be committed to open source are happy to violate the principles by giving hardware providers who are not committed to the principles an easy ride.
I mean how many leading Linux/Open Source developers are ready to say 'we don't really like it, but if you want to use their hardware you will have to use their blobs'
How hard is it for open source designers to design their own hardware and open the firmware for it? How difficult is it for hardware developers to release the specs for dated hardware to allow software improvements, and keep the firmware for new more performant hardware closed.
The complainer has a point. It is disingenious for Linux to claim commitment to open source and neglect be virtually silent on the threat closed firmware blobs pose in this era of security issues.
The OpenBSD developers are concerned with working on OpenBSD, not leading some crusade against closed-source firmware. If it bothers you that much, then do as Theo says and don't use hardware that requires the blobs. If there are no open alternatives, why is that OpenBSD's problem?
Not to mention the implication that the BSD and Linux communities don't care about software freedom is patently false. The two communities have very much been willing to fork or reimplement things from scratch because of licensing reasons all the time, even when the result ends up worse (e.g. Debian's cdrkit forked from cdrtools).
It comes down to how important freedom is in software development, and whether freedom is an opportunity for hardware developers to piggy back on the efforts of enthusiasts and volunteer developers or involves something more fundamental than that.
> How hard is it for open source designers to design their own hardware and open the firmware for it?
If you have to ask, you are not qualified to comment on the issue.
Modern devices are complex, and the firmware often comprises the majority of the functionality of the devices and implements the interfaces exposed to OS drivers. It would not be an exaggeration to suggest companies spend just as much or more on development of firmware, than on the hardware.
Who are you to make such demands of them, and the people working on creating open drivers for such devices?
Since I realized that money is the driving factor in this world - it's way more powerful than any other vote you have - I buy devices as open as possible, like the libreboots from http://shop.gluglug.org.uk/ . I don't mind if they are more expensive and slower than other devices. If enough people think like that, eventually the open products will become better because there'd be a commercial incentive for the manufacturers.
No, there is no conspiracy. It's just a battle few are willing and able to fight. All major systems will gladly support open hardware, there are distros that avoid shipping blobs, but right now most people simply aren't willing to accept the compromises necessary to run blob-free or purely open hardware.
If they didn't care, there wouldn't be open-source drivers for GPUs, projects like coreboot, ...
I think it's not that people don't care and there are some projects (most relevant is probably coreboot) that try to replace firmware with free alternatives.
It's just that this is a very hard problem. Basically everything these days can be its own computer, sd cards, hard discs, network controllers, ...
Their inner working is usually not documented and often two revisions of the same product are different internally.
And the lifetime of these devices is short. Projects that try to replace firmware on consumer hardware often have this problem that they spend a fair amount of work on something and once they have reasonable support the device is no longer sold (e.g. the rockbox project constantly strugles with this).
I think the only possibility to have widespread free firmwares would be if this could be made a selling point for vendors. However to do that you'd need a widespread demand for these things, much larger than the open source / free software / hacker community is able to create right now. If it'd be considered "cool" to release the code of your firmware that could change things.
It's also quite disingenious to rant about the rant without noticing that it has nothing to do with Linux (except for the last sentence where Theo points to That Other Community)
Principles are principles. If hardware designers have no competition for their hardware then there is no reason for them not to make the firmware source available. The only commercial reason for firmware to be secret is the fear that competitors will create alternative hardware designs based which may be compatible with the firmware or even improve on it, or that the firmware can be enhanced to extend the working life of the hardware.
As more and more functions are being baked into software this issue is going to become more critical, and all talk about tackling the planting of secret backdoors into software becomes moot, as it can all be done in firmware without detection. This does not even deal with the issue of unintended bugs which are just as exploitable.
> How hard is it for open source designers to design their own hardware and open the firmware for it?
Depending on the type of hardware we're talking about, it's either: already done, hard or very hard.
If you want to go open with hardware, you either:
- decide that you can go with some obsolete specs. Then you only reach the small niche really interested in freedom and openness and pretty much nobody else. The costs and prices skyrocket, because you cannot rely on economy of scale.
- device that you want to provide competitive hardware to what's already on the market, but free. In most of the fields, you will have a hard time to catch up to competitors, as you most likely won't be able to get any funding in the way they did. You'll have to resort to crowdfunding and probably fail anyway, as a very small fraction of projects like that manages to do anything at all - and they're usually the smaller and easier ones anyway.
Also, closed firmware blobs don't pose any threats - any additional ones that you already have even when not using them, that is. If you have a device that doesn't need a firmware to be loaded in order to run, then most likely it already has a non-free firmware integrated on board. For instance: HDD, SSD, SD cards, some cameras, most of controllers like USB or RAID... virtually anything.
By calling people like Theo de Raadt conspirators, you only hurt the cause you think you are fighting for. You won't change the world by that. You can only change it with small steps, by supporting niche projects like Neo900, even if they had to go for some compromises. What differentiates them from others is that their compromise lies far further than what's common in mainstream devices, and only if this iteration succeeds, a new one could in the future, moving that compromise even further towards the ideal state.
Having been involved in Openmoko and related communities for quite a long time exactly for the reasons of hardware freedoms and openness, I really don't see any other way.
Has the development of the Neo900 halted or run into serious issues? I wanted to decide whether I buy one when it is finished, but it is already taking quite long.
It hasn't halted and it didn't run into "serious issues" (blockers). It just needs its time. It's a small project, so when for instance it has to provide a webshop so people can make their orders, the R&D is pretty much halted from lack of resources as everyone is focused on that. We haven't taken all such non-technical issues properly into account when estimating needed time and it backfires. However, I think it's not that bad overall - there is slow, but steady progress all the time. See the last news from a week ago: http://neo900.org/news/the-neo900-shop-grand-opening-for-pre...
Also, just so you're aware: you cannot "wait to decide", as it's basically built to order and financed almost completely that way. The moment it goes to production you will have to find at least another 200-300 people interested in buying it, so the second production batch will be possible to happen.
I'm sure Theo understood too. But Theo didn't say 'I don't share your definition of free', he just said the parent was wrong and that it was free, which doesn't seem like a very adult way of conveying his disagreement.
Theo completely understands. The problem is that a certain contingent of people clutch their pearls at the mere thought that they may be tempted from the way of Free Software by having a file that tells how to get a file that may offend their sensibilities. Theo treats his users like adults, who can make decisions for themselves, unlike certain other parties.
Pretty sure there's a dig at the GPL in this very post:
A few other firmwares are slightly less free. Meaning they are free
for money, but they try to stipulate subtle rules we do not want to
impact the freedom of our source tree with. ... OpenBSD
has a tool built in which will download those, so that our base source
tree remains full of freedom.
If one knows what he is doing, it's possible to build such computers (PC, server). You can run PCs with just the generic drivers that come with Windows or ReactOS, and the same goes for Linux and *BSD. It's usually means a few sacrifice and more effort on your side. Some distributions (afaik Debian) come without any blobs by default, but can be added to apt list. And maybe one should learn the difference between GPL and BSD licensed software - both have their advantages and disadvantages.
Theo wrote about software that flash hardware firmware (both provided as blob package), as I understood. Though flashing firmware is rather uncommon, but using a specific device driver for the operating system is a lot more common - and then I can understand that there is a wish for more open source device drivers in the Unix/BSD world.
One usually rarely flashes the motherboard firmware (BIOS/EFI) or the graphic card firmware. A lot can go wrong, if the power goes down or the computer crash during a firmware flash-process, then the hardware is dead (except there is a backup-chip/logic like on more expensive motherboard e.g. Asus and Android devices).
> hard disk controllers
One usually never flash the HDD firmware. The same goes for the GSM/3G modem in your smartphone which is a separate real time OS on a separate ARM CPU. It's a blob and one buys it and cannot change it. It's also a black-box for Apple and Google and they cannot change them. There only less than a handful real completely open source smartphones with open source firmware ("open source hardware"), one example is OpenMoko (2011): http://en.wikipedia.org/wiki/Openmoko
The Linux/*BSD/Android world has a historical deficit in the availability of suitable drivers. Also the binary ABI isn't stable like on WindowsNT which means older drivers don't work with never kernels (e.g. Android upgrade means no camera). There are open source projects that could make a difference, if they get more donations like: ReactOS which aims to be binary compatible with Windows NT series hardware drivers. And NDISwrapper, that recreated a partial Windows NT kernel (using ReactOS code) inside a Linux kernel making it possible to execute modern Windows drivers in Linux. It consists of a NTOSKRNL API, a basic WDM controller, and a set of Windows call wrappers such as Wireless/NDIS/USB/PnP to Linux APIs.
There are no open source smartphones with open source firmware for their modems. The closest you can get is Openmoko Neo Freerunner with OsmocomBB installed, but you cannot legally use it to transmit anything on public networks before you obtain new certification for the modem, as replacing the firmware voids the one vendor got for you.
The best you can get regarding openness of devices that can be practically used is to completely separate the main CPU from baseband processor (sans some generic interface like USB or serial) and this is exactly what Openmoko, and now also Neo900 are doing. Neo900 project goes one step further - it assumes the modem is a rogue black box by default, so deploys systems that allow the user to monitor the modem.
Unfortunately, mainstream devices go further and further away from that separation and now most of the time use fully integrated designs, where the non-free firmware of the baseband has full access to user OS via shared RAM or even shared CPU.
I believe that's what I said. The hard disk controller is a chip packaged with the hard drive. The CPU talks to the hard disk controller to get data from the disk, with IDE commands or something like that.
I think controllers used to be dedicated circuitry, but now they are more like CPUs with firmware.
In a modern computer, there are dozens of these little chips, each having security implications. Nobody knows the provenance of all the code since they are mostly manufactured overseas.
> But, oddly enough, I have yet to hear anyone calling for open-source hard drives...
Fruitless debates about HDD firmware (and many more) are an undying hobby of some people in the wider coreboot community. These days the topic comes up every week or two.
On a more pragmatic note, how can a person who 'don't know jack shit' figure out what hardware on their system requires non-free blobs for operation? (either in BSD or Linux)
On OpenBSD you can check the man page for fw_update IIRC. That utility is responsible for downloading firmware that couldn't be included in the kernel tree due to legal stipulations.
I went down the road recently to try and build a binary firmware free desktop. I gave up. I did manage a no non-free firmware build, which runs OpenBSD spectacularly, but I couldn't get rid of all firmware blobs.
It seems like open hardware is very hard to come by in this respect. Even swapping out your bios for coreboot is not possible for many (most?) systems--never mind all the other umpteen specialty computers running in your computer. A computer isn't one computer these days, and you will have a hard time taking a principled stand on all your software being free.
While it is naive to imply closed blobs could ever fully or easily be replaced, it is also naive to blame the kernel user for having bought the hardware. For add-on cards, sure, but the line is not always that clear. Many are simply making do with the hardware they were gifted, or that is embedded, and so it's an all-or-nothing scenario. The closed blob in question may be getting loaded for something the user can't unplug or replace. Everything costs money, and not everyone can afford to throw away an imperfect choice and start again.
I can typically blacklist things, but I need to know they are there to begin with so, to me, the problem boils down to the kernel, and other software, potentially doing things that I don't want. Since closed kernel blobs are clearly controversial, something as simple as highlighting their loading and making it as easy as possible to prevent it from happening on future boots may be enough. If the process is in place, it can be a simple lack of orientation - but Theo's response certainly doesn't help with that.
As for running blob-free in general... It's not that hard, really. Often the only loss is fast 3D. Debian does a good job of separating free from non-free - and really, that is enough, since adding non-free items then becomes a conscious act (there can be other ways of making the distinction though).
If you give "loss of fast 3D" as an example of running blob-free, you didn't understand what Theo is talking about. 3D drivers run in user or kernel space, there is a clear policy about how to deal with stuff like that in basically any serious operating system that labels itself free and open.
This mail was about firmwares. The little blobs your OS has to upload into memory of your WiFi card, Bluetooth controller, sensors, camera... and that's all it has to do with it. The rest happens on completely different CPUs - the ones that live inside your WiFi card, Bluetooth controller, sensors, camera...
Even if your hardware seemingly doesn't require the blob to be loaded, it's most likely because it simply has a on board memory to store it. Some don't (obviously, that's cheaper way) and require user to load their firmware before they can operate.
And nowadays, basically anything has such a firmware. Even microSD cards.
From OS point of view, the only sensible approach to differentiate between free and non-free firmwares is to ask a question "is it freely redistributable?". If you go deeper than that, you enter the Open Hardware territory - which comes with its own set of principles and pandora boxes.
(I'm saddened that you can't imagine ever needing to load FPGA, NAND, or VRAM "firmware" to boot a GPU.)
> "the only sensible approach to differentiate between free and non-free firmwares is to ask a question 'is it freely redistributable?'"
Is it? That's the question. It may not be when not differentiating between licenses, as shown by the current conversation, is differently important to different people. I'm still convinced that it's just a disagreement over log verbosity. It is perfectly appropriate for a kernel to support loading non-free anything... It's even a feature. I just want to know what it's doing, and show me a line based on a license that I fully acknowledge the kernel doesn't need to differentiate between other than for clear logging. I am simply hoping, as a user, to get the information I need to make informed choices, including the ability to turn feature X on or off as I see fit. I can only know to buy different hardware when I am told about the blob, and I can only see the effects of my goals if I can progress towards them (by disabling binary loading). I shouldn't have to guess, the feedback and levers should simply be presented clearly.
I will stop tilting at this one, for lack of OpenBSD-specific examples, but I'm really just advocating for better information - not reducing hardware support or anything so nonsensical.
How can you be sure that the firmware blob you got for some chipset is really some software compiled from source code and not a hand made initialization structure for some registers needed for it to operate properly?
Or maybe you need some custom, proprietary solution to compile it that even the company that developed this hardware have no rights to redistribute?
Or maybe even the company you bought that hardware from has no idea about the source code or firmware, because they simply used some chipset available on the market?
Or...
It's really counterproductive to differentiate it in this way. It doesn't help the cause at all. The license of firmware blob is really not a kernels issue. It's a lower layer - you can go for that when you start requiring all your hardware to be open. Otherwise, it's like bashing Mozilla due to Firefox not providing an option to load only Creative Commons or similarly free content from the Web.
The kernel is here just to upload a bitstream to memory of some device. For kernel, it doesn't matter if it's open or not. It's just set of bits needed to be sent somewhere, nothing more, nothing less. It not like a typical software, as it's not even executed on your system.
I don't think it's counterproductive at all and we actually agree in a sense. In a sense, opaque blobs are the default license category. Moving past that, if we can acknowledge that unambiguously (positively-stated) non-proprietary licenses are worth favouring, it is worth differentiating as a means to an end of open hardware.
For example, I would appreciate a "noblob" kernel option. If my system doesn't boot, I may reverse that choice, but I can also (still) hope for, and request, useful information along the way so I can choose the closest to ideal (for me) from the options available.
At some point it becomes a "if you don't like it, submit a patch" scenario, which is fine. It is more likely to lead to that when the response isn't overwhelmingly dismissive or insulting.
You already have such option. On Linux, you simply don't install or remove stuff from /lib/firmware
However, ideologically it doesn't make any sense, since when your kernel is booted you're most likely already past the loading of lots of non-free blobs in lots of chips. Kernel deals only with the ones that don't have internal memory to store them.
> (I'm saddened that you can't imagine ever needing to load FPGA, NAND, or VRAM "firmware" to boot a GPU.)
That's clearly not what you were talking about. It's true that drivers usually also contain firmwares, or microcodes for GPU. However, removing them will most likely prevent you from using GPU at all, not just "fast 3D".
And even if it doesn't, because the most important parts of that non-free firmware are already sealed in memory on the card, it's no different from, let's take the easier example, any HDD out there. So either your blob-free system works almost perfectly, cause you only take the software running on main CPU into account, or your blob-free system doesn't work at all, cause you actually removed all firmware blobs and basically nothing works anymore, including HDD, CD drive and motherboard.
> "And even if it doesn't, because the most important parts of that non-free firmware are already sealed in memory on the card, it's no different from, let's take the easier example, any HDD out there."
On the contrary, the mere fact that it is a series of bits under user control - pure software for which there is a user-initiated loading mechanism - is precisely what makes it a the subject of peoples' libre software goals. Furthermore, it is because it is required that the user perform the initialization to use the main features that the user is constantly reminded about the proprietary dependency. Hard drives, for example, aren't a big focus for advocates because the drives generally don't forget they are hard drives between boots. It is true that they CAN be re-flashed, but it is not conventionally necessary to run, and that places them on a much more remote wish list. The main responsibility of the kernel in such cases is to prevent unauthorized firmware changes coming from userspace (ex, the NSA, over the network).
Boot-time firmware is qualitatively different from hardware that ships with working firmware, just as the latter is a different beast than ROM-based blobs.
You still cannot be sure that WiFi blob isn't being reflashed over the air.
Sure, it's harder to mess with reflashable firmware stored inside the device. However, it's only just like you said - a change on priority list, nothing else. Differentiating this in terms of freedom is a hypocrisy.
Anyway. Kernel just provides you an interface to load such firmware into your device. When the firmware is freely redistributable, it's also included in the kernel source tree. Nothing more, nothing less. It's up to you to decide what to do with it - you can easily look up all the needed info and remove unwanted firmware files.
For me there's no difference where it's stored. Closed firmware is closed firmware. We either have to accept it or not use PCs at all.
In the meantime, we should rather focus on producing stuff that increasingly stops requiring it, instead of aimlessly fighting with kernel developers.
> "When the firmware is freely redistributable, it's also included in the kernel source tree. Nothing more, nothing less. It's up to you to decide what to do with it - you can easily look up all the needed info and remove unwanted firmware files."
Only, this process could be made more clear and more readily configurable (as I suggest, for example, a libre verbosity level, and noblob params). It is also not hypocrisy to fight battles in order of proximity - rather, it is strategy.
Binary blobs running on your CPU under your OS is a completely different issue than binary blobs of firmware. If you have to provide the firmware blob to the device, it's most likely only because it was cheaper to not include any flash memory on it that could store it.
Also, they can be very different in their nature. Firmwares can contains fairly complex operating systems that run on some microcontroller inside your hard drive, they can be hand-crafted for particular piece of hardware (so there's no source code) or they may only consist of some data structures needed to properly initialize the registers or other stuff like that.
78 comments
[ 2.3 ms ] story [ 128 ms ] thread"You don't know jack shit about computers or electronics, that much is obvious."
You might be sensitive to profanity (I am not), but it seems is a waste of time and energy to try to explain them the obvious.
"Fact is, modern hardware simply "is what it is". Telling people that OpenBSD should not run on such hardware is a gigantic illusion."
A good, realistic view, as opposed to that by Richard Stallman
I believe that firmware should be free, but refusing to ship blobs for this reason, while still attempting to be compatible with hardware that buries them under the covers (even when the blobs not being shipped are updates for the very same hardware - e.g. all major x86 CPUs), is burying one's head in the sand. Would be more principled to avoid hardware with proprietary firmware entirely, and advocate for both documented hardware and 'free' (i.e. open HDL etc.) hardware.
How can you know that firmware is "completely non-updateable"? You trust the vendor with that, there's no way to know for sure. What's more - recently (~1.5y ago) somebody figured out how to update firmware of microSD cards [1]. Thanks to him, if we want to apply FSF's point of view, microSD cards suddenly became unacceptable, non-free hardware, while before that blog post they were just fine.
I'm involved in development of Neo900 [2] phone and already had fair share of discussions about freedom and openness of components with various people. I was a part of Openmoko community in the past and remember the TI Calypso modem used inside Neo1973 and Neo Freerunner. At first they were non-updateable (for consumer), so were acceptable to RMS. Some time later Openmoko Inc. got firmware fixes for pretty annoying bugs like SIM compatibility and started trying to figure out how to distribute the updates. They obtained a license to redistribute the updater tool, provided the instructions and the firmware image. Suddenly, Neo Freerunner became non-free hw.
Then, some time later, partially thanks to Openmoko who provided the updater and instructions, OsmocomBB [3] was born (Harald Welte, who initiated OsmocomBB, also worked earlier in Openmoko). Suddenly Neo Freerunner became free again because there's a free firmware available for Calypso now.
So my device I was carrying in my pocket, without any my intervention, went from free to non-free and to free back again. Fun!
Also, as a user who cares about his freedom, I prefer to have a hardware with updateable or even entirely user provided non-free firmware than a black-box with the same non-free firmware inside, but not updateable. Of course over that I'll prefer a hw with open firmware, but in the case of the black box, there is even no hope that such a firmware will be provided in the future. And when at the same time you cannot be 100% sure that it really is non-updateable, then what's the advantage? I can't see any.
In theory, I can agree with FSF and RMS. In practice, hardware doesn't really work that way.
[1] http://www.bunniestudios.com/blog/?p=3554
[2] http://neo900.org/
[3] http://bb.osmocom.org/
And today, chances are the firmware is updatable, even if it's not documented/supported.
Or just use theo(1) from 9front: https://plan9front.googlecode.com/hg/lib/theo
Perhaps being a maintainer of a significant infrastructure project like an OS kernel wears on a person and builds a bit of a short-fuse temper :)
A reason IMHO that OpenBSD has never reached the level of notoriety of FreeBSD is Theo's childish behaviour. I can understand a 20-something insulting someone like that, but not Theo.
ps. I didn't quite understand the Linus reference, but anyway.
This can be interpreted both ways, however. Where Linus will be more elusive, Theo will have no qualms with just barging in and telling you to read the source code, ivory tower be damned. Almost as if he sort of respects even newbies enough to slap some quick advice to their face.
A funny example is here: http://comments.gmane.org/gmane.os.openbsd.misc/212565
A minor reason, perhaps. There are other, more serious concerns.
"Hi guys, I know you've been working for years on this! I haven't really bothered to look at your code, or understand the principles of operation, but I have strong opinions about How Things Should Be Done and I'm here to tell you how to run your project."
The reason Theo himself replies to this sort of thing, and in this sort of fashion, is to make it absolutely clear (both to this imbecile and anyone who seeks to emulate him) that the people who want this sort of thing are wrong and will be wasting their effort in asking for it.
I loved this mail, and it's actually making OpenBSD stand out as a human project, because it's not riddled with indecipherable political correctness. You can feel there are people involved, that they didn't copy-pasted a template but actually thought out their words, you can feel the involvement of the people. On the other end of the spectrum a smiley would also make the project more human, closer to the people. This mail also serves as a warning to future people who will want to engage a similar path of "I don't know anything, but I think things should be done This Way" to actually think about it. A net advantage.
Yes, the mail is harsh; that doesn't mean countrygeek should have a problem with it. The latter can (and should) absolutely go back to the research part, try to understand what he asks for, and then come back with a plan. That is what is really asked from the kind of people in the same position.
Why should fools be suffered? OpenBSD developers have an OS to develop.
[0]http://shop.gluglug.org.uk/
I mean how many leading Linux/Open Source developers are ready to say 'we don't really like it, but if you want to use their hardware you will have to use their blobs'
How hard is it for open source designers to design their own hardware and open the firmware for it? How difficult is it for hardware developers to release the specs for dated hardware to allow software improvements, and keep the firmware for new more performant hardware closed.
The complainer has a point. It is disingenious for Linux to claim commitment to open source and neglect be virtually silent on the threat closed firmware blobs pose in this era of security issues.
If you have to ask, you are not qualified to comment on the issue.
Modern devices are complex, and the firmware often comprises the majority of the functionality of the devices and implements the interfaces exposed to OS drivers. It would not be an exaggeration to suggest companies spend just as much or more on development of firmware, than on the hardware.
Who are you to make such demands of them, and the people working on creating open drivers for such devices?
Since I realized that money is the driving factor in this world - it's way more powerful than any other vote you have - I buy devices as open as possible, like the libreboots from http://shop.gluglug.org.uk/ . I don't mind if they are more expensive and slower than other devices. If enough people think like that, eventually the open products will become better because there'd be a commercial incentive for the manufacturers.
If they didn't care, there wouldn't be open-source drivers for GPUs, projects like coreboot, ...
And the lifetime of these devices is short. Projects that try to replace firmware on consumer hardware often have this problem that they spend a fair amount of work on something and once they have reasonable support the device is no longer sold (e.g. the rockbox project constantly strugles with this).
I think the only possibility to have widespread free firmwares would be if this could be made a selling point for vendors. However to do that you'd need a widespread demand for these things, much larger than the open source / free software / hacker community is able to create right now. If it'd be considered "cool" to release the code of your firmware that could change things.
It's also quite disingenious to rant about the rant without noticing that it has nothing to do with Linux (except for the last sentence where Theo points to That Other Community)
As more and more functions are being baked into software this issue is going to become more critical, and all talk about tackling the planting of secret backdoors into software becomes moot, as it can all be done in firmware without detection. This does not even deal with the issue of unintended bugs which are just as exploitable.
Depending on the type of hardware we're talking about, it's either: already done, hard or very hard.
If you want to go open with hardware, you either:
- decide that you can go with some obsolete specs. Then you only reach the small niche really interested in freedom and openness and pretty much nobody else. The costs and prices skyrocket, because you cannot rely on economy of scale.
- device that you want to provide competitive hardware to what's already on the market, but free. In most of the fields, you will have a hard time to catch up to competitors, as you most likely won't be able to get any funding in the way they did. You'll have to resort to crowdfunding and probably fail anyway, as a very small fraction of projects like that manages to do anything at all - and they're usually the smaller and easier ones anyway.
Also, closed firmware blobs don't pose any threats - any additional ones that you already have even when not using them, that is. If you have a device that doesn't need a firmware to be loaded in order to run, then most likely it already has a non-free firmware integrated on board. For instance: HDD, SSD, SD cards, some cameras, most of controllers like USB or RAID... virtually anything.
By calling people like Theo de Raadt conspirators, you only hurt the cause you think you are fighting for. You won't change the world by that. You can only change it with small steps, by supporting niche projects like Neo900, even if they had to go for some compromises. What differentiates them from others is that their compromise lies far further than what's common in mainstream devices, and only if this iteration succeeds, a new one could in the future, moving that compromise even further towards the ideal state.
Having been involved in Openmoko and related communities for quite a long time exactly for the reasons of hardware freedoms and openness, I really don't see any other way.
Also, just so you're aware: you cannot "wait to decide", as it's basically built to order and financed almost completely that way. The moment it goes to production you will have to find at least another 200-300 people interested in buying it, so the second production batch will be possible to happen.
I'm not an expert, but I won't be surprised if it's completely unrealistic.
One usually rarely flashes the motherboard firmware (BIOS/EFI) or the graphic card firmware. A lot can go wrong, if the power goes down or the computer crash during a firmware flash-process, then the hardware is dead (except there is a backup-chip/logic like on more expensive motherboard e.g. Asus and Android devices).
> hard disk controllers
One usually never flash the HDD firmware. The same goes for the GSM/3G modem in your smartphone which is a separate real time OS on a separate ARM CPU. It's a blob and one buys it and cannot change it. It's also a black-box for Apple and Google and they cannot change them. There only less than a handful real completely open source smartphones with open source firmware ("open source hardware"), one example is OpenMoko (2011): http://en.wikipedia.org/wiki/Openmoko
The Linux/*BSD/Android world has a historical deficit in the availability of suitable drivers. Also the binary ABI isn't stable like on WindowsNT which means older drivers don't work with never kernels (e.g. Android upgrade means no camera). There are open source projects that could make a difference, if they get more donations like: ReactOS which aims to be binary compatible with Windows NT series hardware drivers. And NDISwrapper, that recreated a partial Windows NT kernel (using ReactOS code) inside a Linux kernel making it possible to execute modern Windows drivers in Linux. It consists of a NTOSKRNL API, a basic WDM controller, and a set of Windows call wrappers such as Wireless/NDIS/USB/PnP to Linux APIs.
The best you can get regarding openness of devices that can be practically used is to completely separate the main CPU from baseband processor (sans some generic interface like USB or serial) and this is exactly what Openmoko, and now also Neo900 are doing. Neo900 project goes one step further - it assumes the modem is a rogue black box by default, so deploys systems that allow the user to monitor the modem.
Unfortunately, mainstream devices go further and further away from that separation and now most of the time use fully integrated designs, where the non-free firmware of the baseband has full access to user OS via shared RAM or even shared CPU.
http://www.malwaretech.com/2015/05/hard-disk-firmware-hackin...
But, oddly enough, I have yet to hear anyone calling for open-source hard drives...
I think controllers used to be dedicated circuitry, but now they are more like CPUs with firmware.
http://en.wikipedia.org/wiki/Disk_controller
http://en.wikipedia.org/wiki/Controller_(computing)
In a modern computer, there are dozens of these little chips, each having security implications. Nobody knows the provenance of all the code since they are mostly manufactured overseas.
Fruitless debates about HDD firmware (and many more) are an undying hobby of some people in the wider coreboot community. These days the topic comes up every week or two.
I went down the road recently to try and build a binary firmware free desktop. I gave up. I did manage a no non-free firmware build, which runs OpenBSD spectacularly, but I couldn't get rid of all firmware blobs.
It seems like open hardware is very hard to come by in this respect. Even swapping out your bios for coreboot is not possible for many (most?) systems--never mind all the other umpteen specialty computers running in your computer. A computer isn't one computer these days, and you will have a hard time taking a principled stand on all your software being free.
I can typically blacklist things, but I need to know they are there to begin with so, to me, the problem boils down to the kernel, and other software, potentially doing things that I don't want. Since closed kernel blobs are clearly controversial, something as simple as highlighting their loading and making it as easy as possible to prevent it from happening on future boots may be enough. If the process is in place, it can be a simple lack of orientation - but Theo's response certainly doesn't help with that.
As for running blob-free in general... It's not that hard, really. Often the only loss is fast 3D. Debian does a good job of separating free from non-free - and really, that is enough, since adding non-free items then becomes a conscious act (there can be other ways of making the distinction though).
If you give "loss of fast 3D" as an example of running blob-free, you didn't understand what Theo is talking about. 3D drivers run in user or kernel space, there is a clear policy about how to deal with stuff like that in basically any serious operating system that labels itself free and open.
This mail was about firmwares. The little blobs your OS has to upload into memory of your WiFi card, Bluetooth controller, sensors, camera... and that's all it has to do with it. The rest happens on completely different CPUs - the ones that live inside your WiFi card, Bluetooth controller, sensors, camera...
Even if your hardware seemingly doesn't require the blob to be loaded, it's most likely because it simply has a on board memory to store it. Some don't (obviously, that's cheaper way) and require user to load their firmware before they can operate.
And nowadays, basically anything has such a firmware. Even microSD cards.
From OS point of view, the only sensible approach to differentiate between free and non-free firmwares is to ask a question "is it freely redistributable?". If you go deeper than that, you enter the Open Hardware territory - which comes with its own set of principles and pandora boxes.
> "the only sensible approach to differentiate between free and non-free firmwares is to ask a question 'is it freely redistributable?'"
Is it? That's the question. It may not be when not differentiating between licenses, as shown by the current conversation, is differently important to different people. I'm still convinced that it's just a disagreement over log verbosity. It is perfectly appropriate for a kernel to support loading non-free anything... It's even a feature. I just want to know what it's doing, and show me a line based on a license that I fully acknowledge the kernel doesn't need to differentiate between other than for clear logging. I am simply hoping, as a user, to get the information I need to make informed choices, including the ability to turn feature X on or off as I see fit. I can only know to buy different hardware when I am told about the blob, and I can only see the effects of my goals if I can progress towards them (by disabling binary loading). I shouldn't have to guess, the feedback and levers should simply be presented clearly.
I will stop tilting at this one, for lack of OpenBSD-specific examples, but I'm really just advocating for better information - not reducing hardware support or anything so nonsensical.
Or maybe you need some custom, proprietary solution to compile it that even the company that developed this hardware have no rights to redistribute?
Or maybe even the company you bought that hardware from has no idea about the source code or firmware, because they simply used some chipset available on the market?
Or...
It's really counterproductive to differentiate it in this way. It doesn't help the cause at all. The license of firmware blob is really not a kernels issue. It's a lower layer - you can go for that when you start requiring all your hardware to be open. Otherwise, it's like bashing Mozilla due to Firefox not providing an option to load only Creative Commons or similarly free content from the Web.
The kernel is here just to upload a bitstream to memory of some device. For kernel, it doesn't matter if it's open or not. It's just set of bits needed to be sent somewhere, nothing more, nothing less. It not like a typical software, as it's not even executed on your system.
For example, I would appreciate a "noblob" kernel option. If my system doesn't boot, I may reverse that choice, but I can also (still) hope for, and request, useful information along the way so I can choose the closest to ideal (for me) from the options available.
At some point it becomes a "if you don't like it, submit a patch" scenario, which is fine. It is more likely to lead to that when the response isn't overwhelmingly dismissive or insulting.
However, ideologically it doesn't make any sense, since when your kernel is booted you're most likely already past the loading of lots of non-free blobs in lots of chips. Kernel deals only with the ones that don't have internal memory to store them.
That's clearly not what you were talking about. It's true that drivers usually also contain firmwares, or microcodes for GPU. However, removing them will most likely prevent you from using GPU at all, not just "fast 3D".
And even if it doesn't, because the most important parts of that non-free firmware are already sealed in memory on the card, it's no different from, let's take the easier example, any HDD out there. So either your blob-free system works almost perfectly, cause you only take the software running on main CPU into account, or your blob-free system doesn't work at all, cause you actually removed all firmware blobs and basically nothing works anymore, including HDD, CD drive and motherboard.
On the contrary, the mere fact that it is a series of bits under user control - pure software for which there is a user-initiated loading mechanism - is precisely what makes it a the subject of peoples' libre software goals. Furthermore, it is because it is required that the user perform the initialization to use the main features that the user is constantly reminded about the proprietary dependency. Hard drives, for example, aren't a big focus for advocates because the drives generally don't forget they are hard drives between boots. It is true that they CAN be re-flashed, but it is not conventionally necessary to run, and that places them on a much more remote wish list. The main responsibility of the kernel in such cases is to prevent unauthorized firmware changes coming from userspace (ex, the NSA, over the network).
Boot-time firmware is qualitatively different from hardware that ships with working firmware, just as the latter is a different beast than ROM-based blobs.
Sure, it's harder to mess with reflashable firmware stored inside the device. However, it's only just like you said - a change on priority list, nothing else. Differentiating this in terms of freedom is a hypocrisy.
Anyway. Kernel just provides you an interface to load such firmware into your device. When the firmware is freely redistributable, it's also included in the kernel source tree. Nothing more, nothing less. It's up to you to decide what to do with it - you can easily look up all the needed info and remove unwanted firmware files.
For me there's no difference where it's stored. Closed firmware is closed firmware. We either have to accept it or not use PCs at all.
In the meantime, we should rather focus on producing stuff that increasingly stops requiring it, instead of aimlessly fighting with kernel developers.
Only, this process could be made more clear and more readily configurable (as I suggest, for example, a libre verbosity level, and noblob params). It is also not hypocrisy to fight battles in order of proximity - rather, it is strategy.
http://www.openbsd.org/lyrics.html#39
Also, they can be very different in their nature. Firmwares can contains fairly complex operating systems that run on some microcontroller inside your hard drive, they can be hand-crafted for particular piece of hardware (so there's no source code) or they may only consist of some data structures needed to properly initialize the registers or other stuff like that.
The property of being handcrafted for a particular piece of hardware does not imply that there is no source code.