HyperbolaBSD Roadmap: hard fork of the OpenBSD kernel and userspace(hyperbola.info)
hyperbola.info
HyperbolaBSD Roadmap: hard fork of the OpenBSD kernel and userspace
https://www.hyperbola.info/news/announcing-hyperbolabsd-roadmap/
114 comments
Hello71(1)
> What's different today?
About 300 system calls.
About 300 system calls.
One person with an ignorant agenda it seems
[deleted]
[deleted]
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?
> 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…
A bit ironic for a project that claims it's more stable than Linux…
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...) 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?
I'm also a little confused about their problems with Rust (https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...) 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?
My interpretation of their plan is that the new OS will contain enough GPL code (on top of the BSD base) to effectively prohibit its use in proprietary closed-source products.
I was about to post with the same question about Rust. It looks like there's no issue with using anything other than the "Rust" or "Cargo" names and the logo, as per this:
> You are correct that we intended the trademark to apply when
> distributing a package or other binary called "Rust" -- and in
> particular that if modifications are made, then we would expect a
> trademark request outlining the sorts of changes being made (as the
> policy notes though, we are inclined to accept such a request).
> regards,
> Niko
https://github.com/rust-lang/rust/issues/53287
This thread in the project's (hyperbola) issue tracker seems silly and needlessly exclusive, given what seems to be a relatively minor restriction: https://issues.hyperbola.info/index.php?do=details&task_id=7...
> You are correct that we intended the trademark to apply when
> distributing a package or other binary called "Rust" -- and in
> particular that if modifications are made, then we would expect a
> trademark request outlining the sorts of changes being made (as the
> policy notes though, we are inclined to accept such a request).
> regards,
> Niko
https://github.com/rust-lang/rust/issues/53287
This thread in the project's (hyperbola) issue tracker seems silly and needlessly exclusive, given what seems to be a relatively minor restriction: https://issues.hyperbola.info/index.php?do=details&task_id=7...
They have the same complaint about Firefox. https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedo...
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
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
There is no requirement for internet access, they are mistaken.
It also seems like there's a similar trademark and policy for C++, unless I'm misunderstanding: https://isocpp.org/home/terms-of-use
The trademark policies you linked only seem to apply to the C++ logo and other content produced by the Standard C++ Foundation.
> 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?
It's strange, isn't it? The Sony PlayStation applies HDCP to some (all?) game content, and you can't disable it given its OS is based on FreeBSD, which isn't copyleft, so they don't have to release the source. Whereas, if it were hypothetically based on the copyleft kernel Linux, then you might stand a chance of disabling HDCP and recompiling it. Quite unlikely in practice though.
It's strange, isn't it? The Sony PlayStation applies HDCP to some (all?) game content, and you can't disable it given its OS is based on FreeBSD, which isn't copyleft, so they don't have to release the source. Whereas, if it were hypothetically based on the copyleft kernel Linux, then you might stand a chance of disabling HDCP and recompiling it. Quite unlikely in practice though.
> Is this actually a GNU project?
No. It's an endorsed distribution of Linux by the FSF. The BSD fork will need to be evaluated by the FSF too.
No. It's an endorsed distribution of Linux by the FSF. The BSD fork will need to be evaluated by the FSF too.
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.
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.
Hyperbola seems to be a project driven largely by GNUish licensing ideology.
GNU people will happy use and welcome contribution under both permissive and copyleft licenses.
BSD ideology will only accept permissive licenses. Anything less pure is unwelcome.
BSD ideology will only accept permissive licenses. Anything less pure is unwelcome.
But what does that gain anyone? If the Linux/GNU ecosystem were re-licensed to MIT/BSD/Apache2, what would be lost?
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.
"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.
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.
For the most part, I don't disagree with you, but it's also the case that Linux has gotten many contributions from companies that decided that they were okay with being required to give source to customizations they redistribute. Both models work, and both models have downsides.
It's also true that Linux has gotten contributions from companies like Facebook (and Netflix?) that are not redistributing Linux itself and so are not actually under any compulsion to release sources.
I've seen enough cases of private contributions to BSD code not getting released, even when they're clearly not a competitive advantage anymore, that I don't think waiting it out is reliable. There's a particular vendor product we used at my last company that was based on an extension to some FreeBSD kernel code. In the next version, they switched to a userspace app, it sucked, and I'm pretty sure they never released their old kernel implementation. (In fact there are plenty of well-known cases of license-violating private contributions to GPL'd code being a pain to compel through the legal process.)
It's also true that Linux has gotten contributions from companies like Facebook (and Netflix?) that are not redistributing Linux itself and so are not actually under any compulsion to release sources.
I've seen enough cases of private contributions to BSD code not getting released, even when they're clearly not a competitive advantage anymore, that I don't think waiting it out is reliable. There's a particular vendor product we used at my last company that was based on an extension to some FreeBSD kernel code. In the next version, they switched to a userspace app, it sucked, and I'm pretty sure they never released their old kernel implementation. (In fact there are plenty of well-known cases of license-violating private contributions to GPL'd code being a pain to compel through the legal process.)
> History has shown that eventually the code comes out rather than being socked away in properietary hell.
When people talk about reforming copyright there is usually a comment about GPL with a standard answer: copyright escrow. If we just have rules in places that guaranties that the code eventually comes out rather than being socked away in properietary hell then 99% of the purpose of copyleft has been served.
Last Friday in tech news there was an entry about a deal between a DRM company and a game company that expires, so "owners" of the game can no longer install the game. Proprietary code for games do not usually come out, so there is some real worry that the games are now closed down forever.
I wonder how supportive Juniper, Comcast, EMC, and Netflix would be to copyright escrow.
When people talk about reforming copyright there is usually a comment about GPL with a standard answer: copyright escrow. If we just have rules in places that guaranties that the code eventually comes out rather than being socked away in properietary hell then 99% of the purpose of copyleft has been served.
Last Friday in tech news there was an entry about a deal between a DRM company and a game company that expires, so "owners" of the game can no longer install the game. Proprietary code for games do not usually come out, so there is some real worry that the games are now closed down forever.
I wonder how supportive Juniper, Comcast, EMC, and Netflix would be to copyright escrow.
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).
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.
A number of proprietary extensions to the ecosystem that are never contributed back.
Right, just like Microsoft, Google, Apple, Sony, Netflix, Juniper and everyone else who uses BSD software never, ever gives their additions back.
Oh wait... they do!
Oh wait... they do!
Netflix kernel guy here... Off the top of my head, we (Netflix) have contributed the following over the last few years to FreeBSD:
- async sendfile
- rewrite of the pbuf system
- unmapped mbufs
- kernel TLS
- RACK TCP
- BBR TCP
- TCP high precision timer system (TCP pacer)
- various NUMA improvements, which allow us to stream in excess of 200Gb/s of TLS encrypted video traffic from a single server
- Metric tons of fixes
Contributing stuff back makes it easier to work with other folks, and makes our jobs easier. We merge from upstream FreeBSD-current every few weeks. The smaller the diff we carry forward, the easier our jobs are.
- async sendfile
- rewrite of the pbuf system
- unmapped mbufs
- kernel TLS
- RACK TCP
- BBR TCP
- TCP high precision timer system (TCP pacer)
- various NUMA improvements, which allow us to stream in excess of 200Gb/s of TLS encrypted video traffic from a single server
- Metric tons of fixes
Contributing stuff back makes it easier to work with other folks, and makes our jobs easier. We merge from upstream FreeBSD-current every few weeks. The smaller the diff we carry forward, the easier our jobs are.
If everyone contribute back everything then the distinction between BSD and GPL would be indistinguishable. A zero diff would be easier work, and would make your job easier than a small diff. but since that is not the case there is an evidential balance between contributing back and keeping changes proprietary.
It would be nice in this kind of threads if both sides were just honest in presenting how things work. Companies will decide on contributing back BSD code based on competitive advantages of doing so. It is a business decision. They can reducing costs by having the code maintained by upstream and reduce integration costs, or they can get advantage over their competitors by keeping the code proprietary.
I see similar discussing when companies talk about paying taxes. The press releases will talk about contributing back to society and being responsible citizen, while at the same time employing lawyers who do "tax management" in order to pay as little tax as possible. It is true that they do contribute back with numbers that looks impressive, and paying some taxes is easier than paying no taxes, but a honest description would call it a calculated business decision that balance benefits and drawbacks between compliance and tax avoidance.
It would be nice in this kind of threads if both sides were just honest in presenting how things work. Companies will decide on contributing back BSD code based on competitive advantages of doing so. It is a business decision. They can reducing costs by having the code maintained by upstream and reduce integration costs, or they can get advantage over their competitors by keeping the code proprietary.
I see similar discussing when companies talk about paying taxes. The press releases will talk about contributing back to society and being responsible citizen, while at the same time employing lawyers who do "tax management" in order to pay as little tax as possible. It is true that they do contribute back with numbers that looks impressive, and paying some taxes is easier than paying no taxes, but a honest description would call it a calculated business decision that balance benefits and drawbacks between compliance and tax avoidance.
I would say there's a massive difference between contributing back code and paying taxes. Public companies have a FIDUCIARY duty to provide maximum value to shareholders, and that's been the "legal justification" for the FAANGs to engage in the "reverse Irish, Dutch sandwich" scheme to pay zero taxes. Meanwhile, shareholders don't care about code licensing as long as the company isn't giving away the secret sauce under F/OSS terms. Netflix dude above mentioned how much they contribute back; the "enlightened self-interest" of the BSD world encourages these companies to contribute as much as possible back to the project so their diffs in pulling down updates are minimal. If they go asshole and keep everything private they are making their own headache worse when updating or locking themselves in the past.
> FIDUCIARY duty to provide maximum value to shareholders
i’m not sure that’s exactly true is it? [0] or at least it seems quite murky (case-by-case, state-by-state) [1]
[0] https://www.nytimes.com/roomfordebate/2015/04/16/what-are-co...
[1] https://www.lexology.com/library/detail.aspx?g=5dc3f206-0fcc...
i’m not sure that’s exactly true is it? [0] or at least it seems quite murky (case-by-case, state-by-state) [1]
[0] https://www.nytimes.com/roomfordebate/2015/04/16/what-are-co...
[1] https://www.lexology.com/library/detail.aspx?g=5dc3f206-0fcc...
>If everyone contribute back everything then the distinction between BSD and GPL would be indistinguishable.
The difference here is Netflix can choose which part to contribute back. In most cases the CDN work is not their core competitive advantage, their Quality Content are. Which means Netflix can contribute back everything they have done.
The difference here is Netflix can choose which part to contribute back. In most cases the CDN work is not their core competitive advantage, their Quality Content are. Which means Netflix can contribute back everything they have done.
Apple throws things over the wall after taking it and hiding it. They don't "give back" in any meaningful sense.
I'm still bitter at how they murdered KHTML.
(Before someone comments "But KHTML is LGPL!": I know. That's the point. The GPL doesn't have these problems. The LGPL is too weak to be meaningful.)
I'm still bitter at how they murdered KHTML.
(Before someone comments "But KHTML is LGPL!": I know. That's the point. The GPL doesn't have these problems. The LGPL is too weak to be meaningful.)
> I'm still bitter at how they murdered KHTML.
Murdered? Thanks in large part to the work Apple did to transform KHTML into WebKit, WebKit and its derivatives (like Blink) have utterly dominated the browser marketplace. I have a hard time reconciling your characterization of Apple's action with the facts.
Murdered? Thanks in large part to the work Apple did to transform KHTML into WebKit, WebKit and its derivatives (like Blink) have utterly dominated the browser marketplace. I have a hard time reconciling your characterization of Apple's action with the facts.
Murdered. They forked it in a way that couldn't be upstreamed (they waited a year and change before releasing source, when doing so releasing it as undocumented garbage), and made their contributions in a way that allowed it to be closed.
GPL doesn't forbid forking.
Safari would have been released as free software if KHTML was GPL.
Apple wouldn't have based a product around it if it were GPL.
Which is fine, too! What happened wasn't, though.
> Which is fine, too!
Yes, we know that a certain subset of Free Software zealots prefer preventing non-Free software to promoting Free software.
> What happened wasn't, though.
Why exactly is the creation of a set of F/OSS browser engine cores which have essentially completely extinguished the proprietary cores to dominate the space not “fine”?
Yes, we know that a certain subset of Free Software zealots prefer preventing non-Free software to promoting Free software.
> What happened wasn't, though.
Why exactly is the creation of a set of F/OSS browser engine cores which have essentially completely extinguished the proprietary cores to dominate the space not “fine”?
There were already multiple good libre browser engines: KHTML, Gecko, and (kind of) the Tcl one.
Apple forked one in a hostile fashion, and later used it to release proprietary software.
A substantial volume of web browsers, including the largest two (Chrome, Safari), are proprietary software, directly because of this.
It made the WWW less free, and hurt users.
Apple forked one in a hostile fashion, and later used it to release proprietary software.
A substantial volume of web browsers, including the largest two (Chrome, Safari), are proprietary software, directly because of this.
It made the WWW less free, and hurt users.
Only bits and pieces when they feel like it.
Tell me where I can download the source to nVidia's LLVM-based shader compiler.
Why is this being question being down-voted without explanation? I understand there are philosophical/religious implications to the question but it's still valid: what would you lose?
I didn't downvote, but my guess is that it's because there are well-known tradeoffs and no obvious answer, and asserting that there is no downside to one choice / making people re-argue well-understood benefits to one choice doesn't actually contribute to the conversation.
> 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.
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.
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.
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.
The Hyperbola Linux distribution already existed, as a fork of Arch Linux. HyperbolaBSD doesn't appear to exist yet.
> 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?
> • 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?
> 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”.
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”.
> 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.
Ah ok, let's give up then.
> This links to a Linux kernel patch which allows but does not require turning on HDCP in video output. Is that really so bad?
This seems especially silly in light of the fact that the patch doesn't even implement HDCP -- HDCP support is typically a hardware function, and the patch is providing a common interface for drivers to expose that functionality. HyperbolaBSD's description of the patch as "forcing adaptation of DRM" is a wild mischaracterization of the facts.
This seems especially silly in light of the fact that the patch doesn't even implement HDCP -- HDCP support is typically a hardware function, and the patch is providing a common interface for drivers to expose that functionality. HyperbolaBSD's description of the patch as "forcing adaptation of DRM" is a wild mischaracterization of the facts.
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.
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.
"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.
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.
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.
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.
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.
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.
Rust is the only game in town for memory safety if you also want low-level control over the machine.
https://news.ycombinator.com/item?id=21860713
https://news.ycombinator.com/item?id=21860713
Are you aware that Crystal uses GC? (https://github.com/crystal-lang/crystal/wiki/FAQ#language-x-...)
> 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).
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).
It means that there are two incoherent caches, not that they aren't shared.
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.
> 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.
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.
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.
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.
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.
Microsoft knows full well how to do technically interesting things, that's why WSL1 worked as well as it did. The problem is that, being a company and not a grad student, "works 100% of the time" is more worthwhile to them than "works 99% of the time and sounds really cool."
> 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.
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.
> 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.
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.
> 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.
Could you provide a link to this?
Could you provide a link to this?
Technically interesting isn't the same as the best technical choice
As far as I'm concerned, using a VM is a poor choice technical choice: a VM closes off lots of potential integration opportunities and creates all the system-resource-use coordination problems that all non-container system partitioning approaches have.
The point of WSL isn't to just run some Linux code on Windows. You've been able to do that for literally decades. The point is to create a tightly integrated environment that gives you Linux and Windows views onto the same workspace and that makes Linuxy and Windows processes peers.
Using a VM here feels like a "safe" and "sustainable" uninspired corporate choice that gives Windows a checkbox feature without expanding the bounds of what's possible. You can tell me all day that switching from innovation to crank-turning is right for the business, but I personally want nothing to do with crank-turners.
The point of WSL isn't to just run some Linux code on Windows. You've been able to do that for literally decades. The point is to create a tightly integrated environment that gives you Linux and Windows views onto the same workspace and that makes Linuxy and Windows processes peers.
Using a VM here feels like a "safe" and "sustainable" uninspired corporate choice that gives Windows a checkbox feature without expanding the bounds of what's possible. You can tell me all day that switching from innovation to crank-turning is right for the business, but I personally want nothing to do with crank-turners.
A light-weight solution would have been nice. Something like containers.
But again, the problem is that Microsoft wanted to have binary compatibility. That would mean containers w/ Linux ABI emulation, or a proper VM. Well, Linux ABI emulation has been tried by many people:
But again, the problem is that Microsoft wanted to have binary compatibility. That would mean containers w/ Linux ABI emulation, or a proper VM. Well, Linux ABI emulation has been tried by many people:
- Sun (twice)
- Joyent (once, based on earlier tech from Sun)
- FreeBSD
- Microsoft (WSL1)
- probably others
Could you give a specific example of what kind of integration you're looking for (that can only be addressed by WSL0/1)?
I'm not a Windows developer but I have a Windows laptop that I'd like to be able to run linux on and WSL2 scratches that itch, so your complaint doesn't register for me.
I'm not a Windows developer but I have a Windows laptop that I'd like to be able to run linux on and WSL2 scratches that itch, so your complaint doesn't register for me.
It was cool how WSL1 allowed named pipes to be shared between Windows and Linux apps, giving the possibility to have a shared SSH agent, efficient X11 support, etc. Does WSL2 support that? I'm not sure but I don't think so.
for NaNoGenMo [1] 2015, I wanted to run Racter [2] against Eliza, but 1) I run Linux and 2) I had an MS-DOS executable for Racter. I thought I would use DosBox to run Racter and pipe input/output to Eliza running under Linux natively, but DosBox didn't allow that. I ended up having to write enough of an MS-DOS emulator [3] to run Racter under Linux so I could pipe input/output. It barely functioned.
[1] National Novel Generation Month
[2] https://en.wikipedia.org/wiki/Racter
[3] https://github.com/spc476/NaNoGenMo-2015/blob/master/C/msdos...
[1] National Novel Generation Month
[2] https://en.wikipedia.org/wiki/Racter
[3] https://github.com/spc476/NaNoGenMo-2015/blob/master/C/msdos...
I think MSFT folk probably concluded that the Linux ABI being so difficult to emulate correctly was "a huge disappointment" :)
But yes, I was referring precisely to WSL2 being VM-based.
But yes, I was referring precisely to WSL2 being VM-based.
As someone who is using WSL2 and had used Cygwin in the past, WSL2 is awesome and way better than the original WSL. I highly recommend you give it a shot.
It may be a less pure design, but it solves my needs better than anything else out there.
It may be a less pure design, but it solves my needs better than anything else out there.
> Then what's this Linux subsystem that Windows ships?
It's now a full Linux kernel running in a hypervisor.
It's now a full Linux kernel running in a hypervisor.
A VM
This seems like the first time I have ever seen a GNU/Linux distribution switch to BSD.
Has this ever happened before
Has this ever happened before
Perhaps this explains the switch
Hyperbola was based on Arch but was trying to use Xenocara (https://en.wikipedia.org/wiki/Xenocara) as the X display server
Hyperbola was based on Arch but was trying to use Xenocara (https://en.wikipedia.org/wiki/Xenocara) as the X display server
Debian/kFreeBSD comes to mind. It kind of fizzled out and was dropped, though.
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.
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
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
Debian/kFreeBSD has been discontinued for years. https://www.debian.org/ports/kfreebsd-gnu/
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.
Seems like an enormous effort for very little benefit.
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.
Won't be a "distro"...
What do they think the D in OpenBSD stands for?
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.
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.
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.
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.
I take "hard fork" to mean they aren't going to rebase on future versions of OpenBSD.
I'm sure they won't, if history tells us anything. It'll forever remain "liberated".
So what do you take hard fork to mean then?
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.
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.
Whatever happened to the other openbsd fork, bitrig?
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...
[2] https://github.com/bitrig/bitrig
[1] https://www.phoronix.com/scan.php?page=news_item&px=Bitrig-F...
[2] https://github.com/bitrig/bitrig
I am a great supporter of open source diversity and ambitious projects, but the rationale behind this one...leaves me skeptical.
I've been hearing this argument for 20 years now. What's different today?