
HyperbolaBSD Roadmap: hard fork of the OpenBSD kernel and userspace - beefhash
https://www.hyperbola.info/news/announcing-hyperbolabsd-roadmap/
======
TazeTSchnitzel
> Reasons for this include:

> • Linux kernel forcing adaption of DRM, including HDCP.

This links to a Linux kernel patch which _allows but does not require_ turning
on HDCP in video output. Is that really so bad?

> • Linux kernel proposed usage of Rust (which contains freedom flaws

“freedom flaws” here means a Firefox-like trademark policy. This does not
really affect software freedom in the traditional sense?

~~~
Eikon
> This does not really affect software freedom in the traditional sense?

That’s not the point though. These kinds of people just consistently seek
conflict and are bending the reality to fit their narrow field of view.

And yet, they don’t see why no one use their projects.

Anyway, this article was probably written on a computer booted with a
proprietary bios, typed on a keyboard with a proprietary firmware, a
proprietary CPU microcode and what else.

There’s no code base to “hard fork” to sell as their own nor really something
to make outrage of so they don’t care though.

In reality, that’s more of a religious issue than anything else. Fingers are
pointed at those that are not extremist enough for their taste.

Real freedom is letting people do what they want with software. Most so-called
free software licenses are actually really restrictive and absolutely not
freedom inducing.

I guess it’s very important to create confusion not to say exclusion and throw
around licences so complex that you actually almost require a lawyer to
understand if you can use the software or not so organizations that produce
nothing of real importance can exist and preach the “real freedom”.

~~~
m-p-3
> Anyway, this article was probably written on a computer booted with a
> proprietary bios, typed on a keyboard with a proprietary firmware, a
> proprietary CPU microcode and what else.

Ah ok, let's give up then.

------
notaplumber
Unless it's not immediately obvious-- there are no OpenBSD developers
associated with this project, past or present. This isn't some splitting of
existing communities.

There was nothing "hard" about this fork, it's funny how a few GNU aficionados
think that deleting a few freely redistributeable firmware files constitutes
significant "new code" contributions.

It's in the same vein as projects like "libertybsd" or "libreboot"\--
misleading people into thinking they are anything but a agenda driven project,
onboarding like-minded and inexperienced new users, meanwhile offloading most
(if not all) the support/technical burden on other communities.

~~~
ramshorns
I take "hard fork" to mean they aren't going to rebase on future versions of
OpenBSD.

~~~
notaplumber
I'm sure they won't, if history tells us anything. It'll forever remain
"liberated".

~~~
zamadatix
So what do you take hard fork to mean then?

~~~
notaplumber
What it means. It's glib remark implying there was any difficulty.

------
geofft
In the US at least, you do not need to register a trademark to enforce it,
just like you do not need to register a copyright, and one of the specific
things trademark law lets you do is prevent people from misrepresenting the
origin of a product bearing that name.

Neither the BSD or GPL license families grant a trademark license.

Therefore, Hyperbola should immediately cease distributing _all_ software that
doesn't have an explicit "You may use the name of this software for whatever
you like" license and where the original authors might want to go into
business with that software, on the grounds that such software is non-free,
just the same as it would judge software with no copyright license as non-
free. That Rust and Firefox have trademark policies does not make them _less_
free than un-trademark-licensed names anymore than having a BSD license makes
code less free than unlicensed code.

~~~
throwaway348954
"In the US at least, you do not need to register a trademark to enforce it...
and one of the specific things trademark law lets you do is prevent people
from misrepresenting the origin of a product bearing that name."

Unless you register, you cannot sue for damages and you are limited to state
courts.

So how do you prevent people from using your mark?

You apply for an injunction. You would have to do this in every state where
you want to enforce the mark. If you target multiple states, you would likely
need multiple lawyers. How many of those free software authors will want to
pay for this legal expense?

Until you succeed in getting your injunctions, and there is no guarantee you
will succeed, there is no incentive for someone to stop using an unregistered
mark. Whatever damage they cause cannot be recovered under a claim based on
trademark law.

~~~
geofft
Sure, but free software projects typically do not work based on the principle
of "What's the worst they can do in court" or "Are they really going to sue
us," they work on the principle of "What are we actively and explicitly
allowed to do." Otherwise they'd have no worries about incorporating clearly
abandoned code, or incorporating code with an unclear license and not selling
it knowing that they can always reply to a lawyer letter with "Oops, sorry."
Otherwise Beerware and WTFPL and the JSON license would be free software
licenses.

It's quite clear that Mozilla isn't interested in suing Hyperbola or any other
free software distro for being a distro and doing distro things, and that in
the worst case, they'd send a nice message first and Hyperbola could choose to
discontinue distributing Firefox and Rust. Yet Hyperbola wants to take the
"explicit permission" principle to an extreme and discontinue distributing
them now, proactively. They should be consistent and cease distributing
everything else.

------
spamizbad
> Due to the Linux kernel rapidly proceeding down an unstable path....

I've been hearing this argument for 20 years now. What's different today?

~~~
MisterTea
> What's different today?

About 300 system calls.

------
quotemstr
It seems strange to fork the least advanced kernel in common use today.
OpenBSD still doesn't have a unified page cache (like literally every other
mainstream operating system does), and it still implements SMP using a "big
kernel lock" strategy from 20 years ago.

The opposition to Rust is also strange. Yes, the trademark restriction is
annoying, but it's not fatal: the existence of projects like Pale Moon and
Waterfox show that forking projects in the presence of trademark restrictions
is viable. (I still think Mozilla is really shitty for applying these
restrictions in the first place though.)

 _Technically_ , Rust is a good thing. A way to structurally prevent memory
safety defects is a major advance that occurs only rarely. Rust is the only
game in town for memory safety if you also want low-level control over the
machine. Giving that up over a trademark is just luddism.

> Grsec is no longer free software

I really hate how various corporate forces in the Linux world have made is
socially unacceptable to sue people out of existence for blatant GPL
violations.

~~~
yjftsjthsd-h
> OpenBSD still doesn't have a unified page cache

I doubt that they regard that as a flaw; no shared cache is an effective
mitigation against cache-based attacks (cache poisoning or information leaks).

~~~
markjdb
It means that there are two incoherent caches, not that they aren't shared.

------
rvz
> Future versions of Hyperbola will be using HyperbolaBSD which will have the
> new kernel, userspace and not be ABI compatible with previous versions.

I don't know why they waited so long to do this. While it's a good choice to
switch to the OpenBSD kernel, I'm not quite sure if doing it now makes sense.
This involves recompiling everything, probably a new toolchain, plus adapting
software to work with the new kernel, or even worse: A Linux compatibility
layer for existing software / drivers.

This doesn't seem like the right time to move to a new kernel for an existing
Linux distro. They might as well have created a new Hyperbola from scratch
from the side or started with OpenBSD from the start.

~~~
MBCook
So this is an existing Linux distro? Honestly there is basically no context at
the link so I thought this was a brand new project.

~~~
ramshorns
Yes, Hyperbola GNU/Linux-libre is based on Arch Linux and focused on user
freedom. So a lot like Parabola, but with maybe a stricter freedom definition
and slightly different goals. Looks like they found the goals of the project
are incompatible with the GNU/Linux operating system and had to find a new
operating system to base on.

------
saagarjha
> Future versions of Hyperbola will be using HyperbolaBSD which will have the
> new kernel, userspace and not be ABI compatible with previous versions.

A bit ironic for a project that claims it's more stable than Linux…

~~~
m463
Hyperbole BSD ?

------
yellowapple
What really irks me about this is the implicit intent to ensure that anything
Hyperbola adds to its OpenBSD fork can't be ported back to OpenBSD due to the
one-way street of license compatibility (BSD-licensed code can be included in
a GPL-licensed project, but not the other way around). Pretty
ironic/hypocritical given that in the same breath they mention the existence
of (and desire to replace) GPL-incompatibly-licensed OpenBSD code (where?
how?).

If they have any desire to be good free software citizens they'd release the
OpenBSD modifications under the ISC license or something else suitably
copyfree so that OpenBSD can use those modifications.

\----

Also, I fail to see how a copyfree-licensed binary blob is non-free. Sometimes
code only exists as binary code (i.e. if it's been written by hand). Whether
or not that's the case here is beyond my skillset/expertise, but it seems
silly to declare code to be inherently non-free if it's not human-readable,
actual license terms be damned. As long as you have the freedom to use it /
modify it / distribute it (verbatim or modified) / etc., then that's free.

Like, if someone wrote a device driver in Brainfuck, I probably wouldn't be
able to make sense of it, either, but that doesn't make that Brainfuck code
inherently non-free; it just means I don't know how to read Brainfuck code.

------
cryptonector
Eh, many OSes have been down this road, but the problem is that you end up
having to emulate the Linux ABO, but the Linux ABI is large and fast-evolving
and underdocumented, and you'll need to be compatible with it, and that's
ETOOHARD. Even Microsoft has given up on emulating the Linux ABI.

~~~
quotemstr
> Even Microsoft has given up on emulating the Linux ABI.

Then what's this Linux subsystem that Windows ships?

> Linux ABI is large and fast-evolving and underdocumented

You don't have to keep up with the latest ABI. You don't need to match tip-of-
tree. You only need to match some version of Linux that programs still target,
and that version can be pretty old, since enterprise customers scream bloody
murder when you force them up upgrade kernels to run new programs.

~~~
snuxoll
WSL2 operates in a Hyper-V environment, there's too many issues with trying to
do syscall emulation that WSL1 attempted - while both will remain supported
for a while the writing is already on the wall.

~~~
quotemstr
Ugh. I hadn't heard that. WSL2 being a VM is a huge disappointment. There's
the technically-cowardly Microsoft from the Ballmer era. Just when I thought
Microsoft had rediscovered how to do technically interesting things, they wave
the white flag and run away.

Using a VM for WSL means that it'll never be possible to write a program
that's simultaneously a good win32 GUI citizen and a Unix API user. WSL1
(AFAIK) didn't allow this use case, but there was a path to get there. There's
no path from a VM to a native USER32 process.

The bright side is that at least Cygwin won't die. Cygwin allows for precisely
this use case.

~~~
McGlockenshire
> Just when I thought Microsoft had rediscovered how to do technically
> interesting things, they wave the white flag and run away

You might want to look up all of the reasons why they made this choice,
including but not limited to the _amazing_ impedance mismatch between Linuxy
I/O operations and Windowsy I/O operations.

Running the Linux kernel in a VM and doing all sorts of integration tricks
ends up being a better end-user experience, even if it's not as cool and
clever as what WSL0 and WSL1 are.

~~~
snuxoll
> You might want to look up all of the reasons why they made this choice,
> including but not limited to the amazing impedance mismatch between Linuxy
> I/O operations and Windowsy I/O operations.

Yeah, this right here is the most problematic. It's fairly easy to implement
the proactor pattern of the Windows asynchronous IO APIs using reactor
implementations common on Linux, the opposite is not so true. Seeing as this
is a fundamental design choice of the NT kernel itself, and not just the Win32
subsystem it's rather difficult to properly emulate the Linux API's without a
similar amount of indirection that a hypervisor layer adds.

------
nickik
I like this kind of announcement, clearly talks about what they want and what
they think is important. It tells me that I will not be very interested it but
I wish them the best of luck in achieving their goals.

------
nerdponx
Diversity is a good thing, but BSD seems like it needs a lot more manpower as
it is. Why start a new project instead of contributing to OpenBSD?

~~~
saagarjha
The project seems to value being GPL-licensed.

~~~
snuxoll
There's some irony to be found in forking BSD-licensed code and putting it
under the GPL.

~~~
kick
They don't seem to be changing the license of the old code, but licensing
their new contributions under the GPL.

------
mikece
Uh, why is it necessary to change the license? BSD code can be compiled into a
GPL project without issue; by changing the license you guarantee the BSD crowd
won’t help you one iota.

~~~
dragonwriter
Hyperbola seems to be a project driven largely by GNUish licensing ideology.

~~~
mikece
But what does that gain anyone? If the Linux/GNU ecosystem were re-licensed to
MIT/BSD/Apache2, what would be lost?

~~~
geofft
In practice: there are many companies that built interesting networking
products on top of BSD kernels and had no compulsion to release the source,
and meanwhile the performance of Linux's networking stack slowly beat it,
because companies were working upstream.

~~~
mikece
"Have no compulsion to release the source" \-- reminds me of the interview on
the Bryan Lunduke show with a FreeBSD maintainer who talked about Juniper,
Comcast, EMC, and Netflix engineers who contribute back a lot of code to
FreeBSD, just not the code that specifically makes their work a competitive
advantage for their employer, a definition that changes over time. I might be
conflating the Lunduke interview with something else but I thought that the
Netflix engineers that build their ISP-level caching servers ultimately
decided that none of it constituted a proprietary advantage so they released
it all. Had the project been based on closed source this wouldn't be an option
-- and GPL was out the question all the way unless it was known up-front there
would be nothing that could give the makers a competitive advantage.

Programmers have to eat; permissive licensing is the best compromise between
openness and needing to make a living. History has shown that eventually the
code comes out rather than being socked away in proprietary hell.

~~~
mistrial9
although you make some good points, sadly, the permissive license structure is
arguably enabling a new Feudalism, at least in the West, with seasoned
programmers reduced to share-cropping, while finance rules the castle (and its
dining halls).

~~~
dragonwriter
Permissive license structure for computer programs (or, for that matter,
anything especially about computer programs) has nothing to do with that, it's
just the normal labor-capital relationship of capitalism. There is, literally,
no conceivable software licensing regime that avoids that effect, as long as
the broader economic system is predominantly capitalist.

------
mhd
This is/was Yet Another Arch Distro, right? So I highly doubt that they have
the personpower to continue with this project. Even Devuan (Debian w/o
Lennart-ware) had more people behind them, this would be closer to Mastodon,
the Linux distro that wouldn't switch to ELF.

Not that I'm entirely against the general idea, I think it's scary how common
corporate-ware is getting these days compared to early Linux. For example, I'd
much prefer a language that's not controlled by a commercial entity (and
without a "BDFL", while we're at it), preferably with several implementations
for example.

------
jimktrains2
Is this actually a GNU project? I don't fully understand who's behind this. I
also don't understand why the name would have been chosen, as it seems to not
have a good connotation?

I'm also a little confused about their problems with Rust
([https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...](https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws))
Firefox also has the same trademark issues, but there are multiple
forks/distributions of it with the trademarked material removed. It seems like
a petty thing to bring up on an "about" page.

Also, it feels weird that they complain that linux is including some things
they don't like (e.g. HDCP), but at the same time just gloss over that the
BSDs are they base of many proprietary products where you can't get the source
at all. I mean, I hate DRM and things like HDCP as much as anyone, but it just
feels like an _off_? argument?

~~~
ebiester
They have the same complaint about Firefox.
[https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...](https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws)

That said, I don't understand how that is in violation of freedom 3. It is
just saying, "if you want to redistribute it, don't call it rust so that
nobody gets confused and we don't get stuck supporting your fork." I think
that there is a higher barrier for something like firefox due to the graphics,
but Rust only has a simple copy and paste. And if your whole purpose is to
hard fork, why is that a problem?

I think that the requirement for internet access to build might be harder for
Hyperbola's goals, but _shrug_

~~~
steveklabnik
There is no requirement for internet access, they are mistaken.

------
3xblah
This seems like the first time I have ever seen a GNU/Linux distribution
switch to BSD.

Has this ever happened before

~~~
mikl
Gentoo added support for BSD kernels at some point, but it wasn’t a switch,
and didn’t see much use as far as I know.

~~~
IntelMiner
Gentoo and Debian both had (have?) support for what they call
"Debian/kFreeBSD" or "Gentoo/kFreeBSD"

The kernels are FreeBSD but userland is all GNU as far as I understand it?

I'm not sure how well supported they are, or if anyone ever used them beyond
proof of concept

~~~
boring_twenties
Debian/kFreeBSD has been discontinued for years.
[https://www.debian.org/ports/kfreebsd-
gnu/](https://www.debian.org/ports/kfreebsd-gnu/)

------
elagost
I love the concept of using OpenBSD on my personal machine as my primary OS,
but it's much slower and the drivers are less stable than Linux these days. I
wonder if this move will either shrink or grow the audience of this admittedly
small distribution.

------
mikl
All their complaints are about Linux. Why not just use OpenBSD instead of
forking it? GPL puritanism?

Seems like an enormous effort for very little benefit.

------
gdm85
I am a great supporter of open source diversity and ambitious projects, but
the rationale behind this one...leaves me skeptical.

------
razzmataz
Whatever happened to the other openbsd fork, bitrig?

~~~
otoburb
Bitrig doesn't seem like it is maintained any longer.[1][2]

[1]
[https://www.phoronix.com/scan.php?page=news_item&px=Bitrig-F...](https://www.phoronix.com/scan.php?page=news_item&px=Bitrig-
Fork-Dead)

[2] [https://github.com/bitrig/bitrig](https://github.com/bitrig/bitrig)

------
linusnext
Won't be a "distro"... What do they think the D in OpenBSD stands for?

