
“Blob-free OpenBSD kernel needed” - lawl
https://marc.info/?l=openbsd-misc&m=143355112811564&w=2
======
Gracana
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.

~~~
grubles
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]

[0][http://shop.gluglug.org.uk/](http://shop.gluglug.org.uk/)

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

~~~
cypher543
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?

~~~
vezzy-fnord
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).

------
raverbashing
I'm happy Theo dealt with this in a swift manner

"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

~~~
microcolonel
For what it's worth, Stallman thinks that firmware is an integral part of
hardware, and doesn't seem to think of it in the same way as other software.

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

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

[1]
[http://www.bunniestudios.com/blog/?p=3554](http://www.bunniestudios.com/blog/?p=3554)

[2] [http://neo900.org/](http://neo900.org/)

[3] [http://bb.osmocom.org/](http://bb.osmocom.org/)

~~~
raverbashing
Good point

And today, chances are the firmware _is_ updatable, even if it's not
documented/supported.

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

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

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

~~~
vezzy-fnord
_Suggested AI class project: write a generator for Theo rants_

Or just use theo(1) from 9front:
[https://plan9front.googlecode.com/hg/lib/theo](https://plan9front.googlecode.com/hg/lib/theo)

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

~~~
seba_dos1
See, even you are confused.

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.

~~~
ergethaxsd
(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.

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

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

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

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

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

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

~~~
chubot
What about hard disk controllers and the like? I think that's what Theo is
talking about here.

I'm not an expert, but I won't be surprised if it's completely unrealistic.

~~~
duskwuff
Hell, what about _hard disks_? Those have firmware too; it's often updatable
from the host, and can be modified to add surprising new behavior:

[http://www.malwaretech.com/2015/05/hard-disk-firmware-
hackin...](http://www.malwaretech.com/2015/05/hard-disk-firmware-hacking-
final-part.html)

But, oddly enough, I have yet to hear anyone calling for open-source hard
drives...

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

[http://en.wikipedia.org/wiki/Disk_controller](http://en.wikipedia.org/wiki/Disk_controller)

[http://en.wikipedia.org/wiki/Controller_(computing)](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.

~~~
duskwuff
Oh, when you said "hard disk controller" I thought at first you meant the SATA
bus master.

------
exDM69
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 :)

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

~~~
cypher543
Then please explain Linux's extreme level of notoriety despite Linus Torvalds'
equally combative attitude.

~~~
icebraining
Linus' rants are usually (if ever?) not targeted at newcomers, but at people
who know him well (and vice-versa).

~~~
vezzy-fnord
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.

A funny example is here:
[http://comments.gmane.org/gmane.os.openbsd.misc/212565](http://comments.gmane.org/gmane.os.openbsd.misc/212565)

------
sudioStudio64
There are some great talks by Theo on different subsystems of OpenBSD on
youtube. I would post a link but I'm on a mobile.

------
vog
How does this relate to the anti-BLOB sentiment which they expressed very
clearly in the OpenBSD 3.9 release song?

[http://www.openbsd.org/lyrics.html#39](http://www.openbsd.org/lyrics.html#39)

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

~~~
wolfgke
> they can be hand-crafted for particular piece of hardware (so there's no
> source code)

The property of being handcrafted for a particular piece of hardware does not
imply that there is no source code.

------
nailer
Parent poster means free as in speech. Theo chooses to take it as free as in
beer. Love OpenBSD but Theo should have thought before getting angry.

~~~
icebraining
I'm pretty sure Theo understood what the parent poster meant.

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

