Hyperbola GNU/Linux-libre operating system(hyperbola.info)
hyperbola.info
Hyperbola GNU/Linux-libre operating system
https://www.hyperbola.info/
36 comments
The FSF's stance is still a WIP. Per this update: https://www.fsf.org/news/fsf-is-working-on-freedom-in-machin...
> All software included in a free ML application has to offer every user the four freedoms that define free software. This applies to both the software that processes training data, and the software that interprets model parameters as context for prompts to produce human-usable output. This is necessary but not sufficient. Additionally, given our current understanding of ML applications, we believe that we cannot say a ML application is free unless all its training data and the related scripts for processing it respect all users, following the four freedoms.
> All software included in a free ML application has to offer every user the four freedoms that define free software. This applies to both the software that processes training data, and the software that interprets model parameters as context for prompts to produce human-usable output. This is necessary but not sufficient. Additionally, given our current understanding of ML applications, we believe that we cannot say a ML application is free unless all its training data and the related scripts for processing it respect all users, following the four freedoms.
> Even when people are before asked if their data could be used for further evaluation and training within such systems, it is never clear what will happen in the end with their data.
> Data should be only used occasion-related, nothing more and nothing less.
> Users should be always able to decide what happens with their data and information
I, the user, should be allowed to decide what happens with my information - but I'm not allowed to provide my data for things that aren't occasion-related.
That makes no sense to me.
> Data should be only used occasion-related, nothing more and nothing less.
> Users should be always able to decide what happens with their data and information
I, the user, should be allowed to decide what happens with my information - but I'm not allowed to provide my data for things that aren't occasion-related.
That makes no sense to me.
I think the occasion related part is meant to be explicit about the default relationship. That doesn’t in anyway preclude you the user from deciding the occasion to be all the time. The point is you have to opt in to that actively
> Our final goal is to provide a full new BSD descendant operating-system named HyperbolaBSD.
Where did the BSD come from? Surely the "GNU" aspect implies it doesn't use a BSD userland.
Where did the BSD come from? Surely the "GNU" aspect implies it doesn't use a BSD userland.
I found that confusing also.
Is it linux kernel or bsd ?
Is it linux kernel or bsd ?
Good system. No bullshit, and brave choices. Once you see how both OpenJDK and Mono need to be boostrapped under Guix, you'll understand a thing or two on the computing madness (and chains) we are, deeply sunk.
Also, I wish people improved Unicon as an alternative to Java/C# on small companies for RAD applications . With XFT support it would be one of the best alternatives here to the current bloat we are suffering everywhere.
Also, I wish people improved Unicon as an alternative to Java/C# on small companies for RAD applications . With XFT support it would be one of the best alternatives here to the current bloat we are suffering everywhere.
> Good system. No bullshit, and brave choices.
Maybe if by "brave choices" you mean "finding creative new reasons to remove things", e.g. (in no particular order):
- https://www.hyperbola.info/news/removal-of-php/ (no PHP)
- https://www.hyperbola.info/news/end-of-java-openjdk-support/ (no Java)
- https://www.hyperbola.info/news/end-of-d-bus-support/ (no DBus)
- https://www.hyperbola.info/news/no-support-for-sudo-and-orie... (no sudo)
- https://www.hyperbola.info/news/no-support-for-projects-with... (no rust, no Chromium)
Perhaps in a few years Hyperbola will reach its final, perfect state: a distribution which contains no packages at all, thereby providing users with a perfectly Free and perfectly secure system.
Maybe if by "brave choices" you mean "finding creative new reasons to remove things", e.g. (in no particular order):
- https://www.hyperbola.info/news/removal-of-php/ (no PHP)
- https://www.hyperbola.info/news/end-of-java-openjdk-support/ (no Java)
- https://www.hyperbola.info/news/end-of-d-bus-support/ (no DBus)
- https://www.hyperbola.info/news/no-support-for-sudo-and-orie... (no sudo)
- https://www.hyperbola.info/news/no-support-for-projects-with... (no rust, no Chromium)
Perhaps in a few years Hyperbola will reach its final, perfect state: a distribution which contains no packages at all, thereby providing users with a perfectly Free and perfectly secure system.
Well that's a bit snarky but there is an element of truth to it. I'm reminded of the first line of the old spec for the Scheme programming language.
"Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary."
https://people.csail.mit.edu/jaffer/r4rs_2.html#SEC2
"Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary."
https://people.csail.mit.edu/jaffer/r4rs_2.html#SEC2
> Perhaps in a few years Hyperbola will reach its final, perfect state
There's still a long way to go. The elephant in the room, prudently sidestepped by the hyperbola community, is the removal of dynamic linking. Now that would be a great, but difficult, brave choice. Most of the other removals (except the removal of dbus, which is mind-boggingly awesome) are fairly isolated stuff.
Fortunately, they are steadily taking steps in the right direction!
There's still a long way to go. The elephant in the room, prudently sidestepped by the hyperbola community, is the removal of dynamic linking. Now that would be a great, but difficult, brave choice. Most of the other removals (except the removal of dbus, which is mind-boggingly awesome) are fairly isolated stuff.
Fortunately, they are steadily taking steps in the right direction!
See https://github.com/oasislinux/oasis for a proof of concept.
No dynamic linking locks you out of Clang+LLVM (mostly: static clang isn't an officially supported configuration, but it can probably be forced to exist. I haven't properly looked into it yet.), Firefox, Chromium, QtWebEngine, (so no alt browsers, either), and probably a lot more. Statically linking every single package out there requires a lot of patches to build systems to get them to properly do it. Many build systems don't respect LDFLAGS and CFLAGS, or respect one or the other, or only partially respect them, causing a great deal of annoyance if you have a nonstandard desired result, such as fully static builds.
No dynamic linking locks you out of Clang+LLVM (mostly: static clang isn't an officially supported configuration, but it can probably be forced to exist. I haven't properly looked into it yet.), Firefox, Chromium, QtWebEngine, (so no alt browsers, either), and probably a lot more. Statically linking every single package out there requires a lot of patches to build systems to get them to properly do it. Many build systems don't respect LDFLAGS and CFLAGS, or respect one or the other, or only partially respect them, causing a great deal of annoyance if you have a nonstandard desired result, such as fully static builds.
> Many build systems don't respect LDFLAGS and CFLAGS, or respect one or the other, or only partially respect them, causing a great deal of annoyance
Sounds good, doesn't it? This means that efforts to produce a fully static distribution would imply a sweeping wave of fixes across a wide range of packages and build systems!
Sounds good, doesn't it? This means that efforts to produce a fully static distribution would imply a sweeping wave of fixes across a wide range of packages and build systems!
But your ideal UNIX has already come and gone.
"[Ultrix] never supported shared libraries or dynamically linked executables."
https://en.m.wikipedia.org/wiki/Ultrix
"[Ultrix] never supported shared libraries or dynamically linked executables."
https://en.m.wikipedia.org/wiki/Ultrix
9front/plan9. Unix 2.0.
The path of least resistance is to jam flags where they don't belong, sed patches, etc. Works well enough, so that's what ends up happening.
It's really weird that they target projects like PHP for their trademark policy, when the GPL itself contains no language allowing you to use an upstream project's trademark. In fact, the GPL explicitly grants you the ability to impose trademark restrictions on code you add to GPL code. For instance, Firefox is distributed under the similarly copyleft MPL, but Debian still had to distribute its version as Iceweasel until Mozilla gave its approval.
(Also, seriously? Policing users' email providers in their mailing list [0]? Write all the blog posts you want, but banning addresses is just silly.)
[0] https://www.hyperbola.info/news/hyperbola-rejects-all-email-...
(Also, seriously? Policing users' email providers in their mailing list [0]? Write all the blog posts you want, but banning addresses is just silly.)
[0] https://www.hyperbola.info/news/hyperbola-rejects-all-email-...
I use it daily. For java, I've just set the JDK by hand, as I'm learning it for a future job, but I plan to ditch it after I have no use for it at home.
No Sudo? Doas does it fine under OpenBSD. And so does Hyperbola. On Chromium... gven the future Google choices on extensions (hint: UBlock will either no work at all, or be severely limited) and current telemetry, that's a good riddance.
You can just use Luakit, or Iceweasel-UXP up to a limit.
No Sudo? Doas does it fine under OpenBSD. And so does Hyperbola. On Chromium... gven the future Google choices on extensions (hint: UBlock will either no work at all, or be severely limited) and current telemetry, that's a good riddance.
You can just use Luakit, or Iceweasel-UXP up to a limit.
Can you install chromium-derivatives like Brave?
Curious to see why "no Rust" I followed the link https://www.hyperbola.info/news/no-support-for-projects-with...
"...problematic trademarks". Say what? There is a link: https://wiki.hyperbola.info/doku.php?id=en:philosophy:rust_t...
Follow that...
"...problematic trademarks". Say what? There is a link: https://wiki.hyperbola.info/doku.php?id=en:philosophy:rust_t...
Follow that...
Permission Denied
Sorry, you don't have enough rights to continue.
I thought Rust's trademark-related controversy was pretty well-known. Here:
https://www.theregister.com/2023/04/17/rust_foundation_apolo...
Also, does this link from the wiki not work for you?
https://wiki.hyperbola.info/doku.php?id=en:philosophy:rust_i...
https://www.theregister.com/2023/04/17/rust_foundation_apolo...
Also, does this link from the wiki not work for you?
https://wiki.hyperbola.info/doku.php?id=en:philosophy:rust_i...
Try this page, called "Rust's problems and concerns": https://wiki.hyperbola.info/doku.php?id=en:philosophy:rust_i...
In short, the Rust Foundation does not permit users to redistribute modified versions of Rust/Cargo without their explicit approval.
In short, the Rust Foundation does not permit users to redistribute modified versions of Rust/Cargo without their explicit approval.
And, zooming out a bit: the reason Hyperbola wanted to modify Rust / Cargo was to prevent it from being used to compile non-free software ("[we wanted] to have Cargo removed as otherwise non-free packages could be used from projects being compiled").
This feels misguided. If you're in the position of adding limitations to software or stripping out features to keep the user from using it with nonfree software, you've lost track of why that software freedom mattered in the first place.
This feels misguided. If you're in the position of adding limitations to software or stripping out features to keep the user from using it with nonfree software, you've lost track of why that software freedom mattered in the first place.
No? The point is to keep the user's system free of non-free dependencies. As a user, I don't want to audit the several hundred packages that a single Rust application might decide to pull in; I'd prefer if such a thing were enforced instead. Otherwise, you might as well go use any of the hundreds of non-free distributions out there.
The Rust/Cargo license is also terrible grounds on which to build a free system anyway.
The Rust/Cargo license is also terrible grounds on which to build a free system anyway.
The user could use a web browser to download non-free software. Is that grounds for disabling the ability to download files?
(You should have no trouble thinking of a couple more reductio-ad-absurdum examples, like wget, gcc, or a text editor.)
(You should have no trouble thinking of a couple more reductio-ad-absurdum examples, like wget, gcc, or a text editor.)
Strawman, what is absurd is your own reduction. Hopefully you see the difference between running a build/install command that pulls 100+ dependencies from the network that may change any moment without notice versus downloading a standalone software package that is appropriately licensed.
(You should have no trouble peering at the depths of your own stupidity.)
(You should have no trouble peering at the depths of your own stupidity.)
... Not sure if such modification is not incompatible with GPL family of licenses, though, but I am not a lawyer (you're not allowed to combine GPL-licensed product, whether v2 or v3, in ways that create derivative works whose parts are licensed with more constraints than enforced by the GPL, with special carveouts for AGPL)
Whether one agrees with it or not, explicitly removing non-free software or the mere suggestion to install non-free software has consistently been a FSF litmus test for about twenty years in order for them to label an operating system as "truly free". Leading to exchanges such as the following in 2007 when Stallman remarked that he could not in good conscience recommend OpenBSD as their ports collection had wrappers that would allow the user to install non-free software more easily:
https://marc.info/?l=openbsd-misc&m=119730630513821&w=2
Key part: "Since I consider non-free software to be unethical and antisocial, I think it would be wrong for me to recommend it to others. Therefore, if a collection of software contains (or suggests installation of) some non-free program, I do not recommend it. The systems I recommend are therefore those that do not contain (or suggest installation of) non-free software."
https://marc.info/?l=openbsd-misc&m=119730630513821&w=2
Key part: "Since I consider non-free software to be unethical and antisocial, I think it would be wrong for me to recommend it to others. Therefore, if a collection of software contains (or suggests installation of) some non-free program, I do not recommend it. The systems I recommend are therefore those that do not contain (or suggest installation of) non-free software."
Guix does the same per every Rust crate AND with Golang. You can support them by importing them with 'guix import' and checking the manifest.scm of every package for licensing reasons.
So do Trisquel and Parabola, but in a more radical way. No PIP, no Cargo, no nothing. You are on your own.
So do Trisquel and Parabola, but in a more radical way. No PIP, no Cargo, no nothing. You are on your own.
Honestly, most of those seem like strong marks in favor of Hyperbola! :)
Now I'm wondering how easy it is to keep it automatically updated/maintained and how often config or packages break during upgrade.
Now I'm wondering how easy it is to keep it automatically updated/maintained and how often config or packages break during upgrade.
>...Once you see how both OpenJDK and Mono need to be boostrapped under Guix...
Where is GUIX covered on this site? I am interested reading about it. I dont see how guix needs OpenJDK or Mono as it is written in GNU GUILE -- but maybe there is something I am not aware of.
Where is GUIX covered on this site? I am interested reading about it. I dont see how guix needs OpenJDK or Mono as it is written in GNU GUILE -- but maybe there is something I am not aware of.
Searching for Unicon brings up multiple results. Which one do you mean?
The Unicon programming language, the new "Icon":
http://www.unicon.org/
http://www.unicon.org/
Very nice system! I fully support their endeavour, and may become my next daily driving OS.
[1] https://www.hyperbola.info/news/hyperbola-declines-fsf-stanc...