HyperBola Linux Ditches Linux, Goes All-In BSD
The Hyperbola GNU/Linux-libre operating system has, or had, strict guidelines for what software is allowed in its Arch Linux based distribution. Only stable versions of truly free software were allowed. The HyperBola Linux developers just announced that they are throwing the baby out with the bathwater and re-starting from scratch with OpenBSD as a basis for an entirely new operating system called HyperbolaBSD. The developers cite the Linux kernel's adoption of Digital Restrictions Management (DRM), use of the Rust programming language and forced adoption of features in common GNU/Linux components like PulseAudio and systemd as reasons for abandoning Linux and the ecosystem around it.
written by 윤채경 (Yoon Chae-kyung) 2012-12-24 - last edited 2019-12-26. © CC BY
What's a HyperBola anwyay?[edit]
This is what Hyperbola 0.3 "Milky Way"s live image looks like.
HyperBola's "Frequently Asked Questions" page describes the Arch Linux based free software only distribution as:
"a long-term support distribution based on Arch GNU/Linux plus stability and security from Debian GNU/Linux. It isn't a rolling release distribution like Arch because Hyperbola is using Arch snapshots for its versions and Parabola blacklist as base to keep it 100% libre. Also Hyperbola is using Debian patches, therefore all packages are being stabilized with improvements through its development."
HyperBola Linux is essentially Arch Linux without non-free user-violating packages and some Debian security patches on top. No proprietary software like unrar and the binary blob drivers for Nvidia graphics cards is allowed. Free software advocate Richard Stallman would likely approve of its existing Linux-based distribution.
It appears that the developers of HyperBola believe the direction Linux and its ecosystem is heading is increasingly conflicting with its strict "must respect your freedom policy" to the point where they have decided to give up on Linux and move to a OpenBSD base. The shocking announcement published on December 21st, 2019, list several perceived problems free software users should pay attention to.
The Problems With Linux[edit]
The HyperBola developers cite "Linux kernel forcing adaption of DRM, including HDCP" as one of the main reason they are turning their back on Linus Torvalds and his Linux kernel.
"High-bandwidth Digital Content Protection", developed by Intel, is a user-restricting defective by design system designed to prevent "protected" content from being used on "unauthorized devices". It is, by design, incompatible with the free software spirit.
The specific objection put forth by the The HyperBola developers refers to the work done by Google's Sean Paul and Intel's Ramalingam C on the kernel's "High-bandwidth Digital Content Protection" (HDCP) stack (drivers/gpu/drm/drm_hdcp.c) and the Intel iGPU support for it in kernel source file drivers/gpu/drm/i915/display/intel_hdcp.c as well as the AMD support for HDCP in the folder drivers/gpu/drm/amd/display/ which, interestingly, only lists AMD as Authors: of that code. A close-up inspection fo the kernel's git changelog for amd/display/modules/hdcp/hdcp.c reveals that Bhawanpreet Lakha authored the offensive code. AMDs Harry Wentland reviewed it and AMDs Alex Deucher committed it.
Linux Kernel 5.5 will have a new option called DRM_AMD_DC_HDCP for the AMD GPU display driver which is described as "Enable HDCP support in DC". Intel has had a kernel driver available under "Misc" called INTEL_MEI_HDCP for quite some time. It is described as "Enables the ME FW services required for HDCP2.2 support through 915 display driver of Intel." There's also HDCP support in the Qualcomm MSM display driver for ARM SOCs.
It is tempting to point out that it's quite possible to just say no to the kernel's HDCP-related options. Resistance is, for now, far from futile. End-users who compile their own kernel and distribution providers are free to choose if they want to enable the objectionable code.
The second objection HyperBolas developers point to is the Linux kernel's potential adoption of the Rust programming language. Second-in-charge of the Linux kernel, Greg Kroah-Hartman, has indicated to josh of LWN that:
"he'd be willing to accept a framework in the kernel for writing drivers in Rust, as long as 1) for now it wasn't enabled by default (even if you did "make allyesconfig") so that people don't *need* Rust to build the kernel, and 2) it shows real benefits beyond writing C, such as safe wrappers for kernel APIs."
Those statements do not automatically mean a) that such a Rust framework exists today - it doesn't or b) that Linus Torvalds would accept anything but C into the kernel driver regardless of his second-in-command's opinion.
The third objection against the Linux kernel is more general:
"Linux kernel being written without security and in mind."
In bullet summary, the objections are:
- The Linux Kernel has optional support for HDCP.
- There is a chance that a Rust framework for drivers, if one is written, could be accepted into the Linux kernel
- The "Linux kernel (is) being written without security and in mind"
You are free to do your own judgements on the validity of these claims/objections. It is a very personal choice.
The Problems With GNU's Userspace[edit]
"Many GNU userspace and core utils are all forcing adaption of features without build time options to disable them. E.g. (PulseAudio / systemd / Rust / Java as forced dependencies)"
Non-optional dependencies in PulseAudio and systemd are a concern. One solution would be to uses ALSA's dmix or something else instead of PulseAudio. For those who are unfamiliar with PulseAudio: It sits between the applications and the kernel's ALSA audio sub-system. It provides features like per-application volume control. It or something like it is required if you want to play audio on one machine using the outputs on another machine on the local network. It's absolutely not required to send audio from a music player on a machine to locally conneted speakers.
systemd is also not required to build a GNU/Linux distribution. OpenRC, used by Gentoo Linux and Alpine Linux, is one alternative and there are others. It's possible to avoid both systemd and pulseaudio without going full BSD.
It's Over, HyperBola Linux Is Dead[edit]
All future version of HyperBola will be based on OpenBSD's userspace. They are, in effect, abandoning everything they've built so far and re-starting from scratch with an OpenBSD fork.
It's a change choice. It is, of course, theirs to make.
The five people outside of its developers who are using HyperBola Linux will be pleased to learn that the current "Milky Way" relelase will be supported until 2022.
The Hyperbola GNU/Linux-libre operating system, soon to be named HyperBolaBSD, has a homepage at hyperbola.info and that's where you find their HyperbolaBSD Roadmap announcement.
Enable comment auto-refresher
Anonymous (22889ab142)
Permalink |