1. 8

  2. [Comment removed by author]

    1. 5

      Device firmware is not a blob, it’s a inextricable part of the hardware that often comprises the bulk of its functionality, being required by both free/open source and proprietary drivers alike. It just so happens to no longer be located on-device, like it always has been, and must now be explicitly loaded onto it first. OpenBSD requires that all firmware included be freely redistributable and includes those full terms alongside firmware in /etc/firmware.

      This is a good point - how many of these people can audit the fixed-function silicon? Or audit the very machine-specific DSP code that’d normally be on ROM? How many could replace the latter?

      1. 1

        I’m very much in favor of using audited hardware as well as software, and it’s part of the reason I’m so excited for libre Risc-V implementations. I don’t have the resources to audit everything on my own, which is why sharing audited hardware and software is so important.

        I don’t agree that rewritable firmware is equivalent to immutable ROM-based firmware. I think it depends on the vendor and the peripheral. I’m sure many devices are benign, but I like to know.

        I am extremely leery of anything that runs code, can be updated, and is connected to the internet.

      2. 5

        It’s not ignorance; it’s widely known that the BSD community has a different definition of “blob” from the GNU/Linux definition.

        FreeBSD, NetBSD, and OpenBSD all include instructions for obtaining nonfree programs in their ports system. In addition, their kernels include nonfree firmware blobs.

        Nonfree firmware programs used with Linux, the kernel, are called “blobs”, and that’s how we use the term. In BSD parlance, the term “blob” means something else: a nonfree driver. OpenBSD and perhaps other BSD distributions (called “projects” by BSD developers) have the policy of not including those. That is the right policy, as regards drivers; but when the developers say these distributions “contain no blobs”, it causes a misunderstanding. They are not talking about firmware blobs.

        No BSD distribution has policies against proprietary binary-only firmware that might be loaded even by free drivers.

        From https://www.gnu.org/distros/common-distros.en.html

        1. 3

          OpenBSD requires that all firmware included be freely redistributable

          OpenBSD requires that device firmware is gratis, but doesn’t require it to be libre. Granted, that’s a sane choice and I don’t think OpenBSD should change. It’s just not idealistic enough for some people.

          I’ll take the contrarian stance and say that LibertyBSD is a worthwhile project. Just as I think Libreboot and Trisquel are worthwhile projects. Yes, they are all derivative forks leveraging the technical achievements of others. And yet, it’s nice to use a distro with ideological gatekeepers. There’s a strong assurance against accidentally running non-free software, if that’s the sort of thing that’s important to you.

        2. [Comment removed by author]

          1. 4

            use of comic sans for the hat is a hilarious touch

            1. 1


              1. 3

                Because of the hat he’s wearing ;)

                1. 1

                  his hat makes him believe things?

            2. 7

              TBH, if it gets them to have BSD officially recommended by RMS and FSF, all power to them.

              Although, OTOH, it’s unclear who’d be that shallow to only use the OS if the proprietary firmware is hardcoded in ROM, but not via self-loading from /etc/firmware, as the distinction is very superficial.

              Another observation — if you’re actually using 100% free hardware, then it’s unclear why would the logic to load proprietary firmware be ever reached — the issue is only applicable if you’ve already made a compromise hardware-wise.

              1. 6

                Or they could do some development instead of deleting a bunch of files. Making ideas such as this one happen would actually make a difference:


                Needless to say, nobody has stepped up yet, so it’s just sitting there on my long todo list.

                (edit: better link)

              2. 5

                Little point. Those blobs would be in ROM, but the FSF only complains when a company cheaps out and gets the host system to load what was ROM into RAM.

                1. 2

                  RAM can change. If it can change, I want to be able to change it.

                2. 0

                  Another BSD spliter group expressing its cultural otherness. How quaint.

                  I think the OSS community benefits by multiple points of view and different ways of solving problems. There’s little doubt that OpenBSD and FreeBSD have made sizable contributions to the state of the art in operating system design, but I question whether this is what the world needs right now.

                  OTOH, it’s their time, so they get to spend it how they like.

                  1. 9

                    This is not a splitter group - to be one the persons must have been a part of the OpenBSD, or any other *BSD for that matter, project in the first place. This is not the case here.

                    Moreover, I’m not sure it is even a group - the whole thing started with emails (please search the misc@ mailing list archives if you’d like to know more) from a single individual who just doesn’t get it.

                    1. 5

                      Honestly I think this says more about FSF-devotees’ willingness to fork projects than it says anything about BSD culture.

                      1. 1


                        I don’t understand and won’t be told otherwise but will happily fork - this is stallmanism at its worst!

                        1. 3

                          I don’t understand and won’t be told otherwise

                          I wouldn’t chalk it up to ignorance. The FSF uses a different definition of blob than OpenBSD does. They care about device firmware being libre and not just gratis.

                          Bear in mind, the FSF has very strict criteria. They don’t endorse popular distros like Ubuntu or Arch, they endorse the deblobbed Trisquel and Parabola. As far as the FSF is concerned, OpenBSD’s lack of kernel blobs gives it a great head start over most Linux distros.

                      2. 3

                        The BSDs aren’t “splinter groups” of a separate operating system - they aren’t Linux distributions. They’re separate OSes with different focuses and directions that share a common heritage.

                        1. 1

                          Is it true that many of them share / are descended from large parts of the 4.X bsd codebase?

                          1. 1

                            Yes, but they broke off in the early to mid 90s. They sometimes get code imported into each other, but the scopes are different.

                            1. 1

                              Also isn’t there a huge amount of cross pollination between the BSDs and Linux?

                              Certainly reading the posts here and listening to the Garbage podcast one of the authors posted here would leave me to believe this is the case.

                              (I’m sincerely asking out of ignorance here - most of my life is lived in the cloud these days- Mac desktops, linux in the cloud. The BSDs are less of a thing there so I have no experience other than having built a FreeBSD system in 1991 :)

                              1. 2

                                The BSDs are less of a thing there so I have no experience other than having built a FreeBSD system in 1991 :)

                                That’s interesting considering FreeBSD did not exist yet - more like 1993, perhaps? ;^)