Hacker News Reader

Comment by anthk | Hacker News Reader

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.

View on HN

> 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.

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.

Can you install chromium-derivatives like Brave?

> 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!

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.

> 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!

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

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.

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.

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-...

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...

  Permission Denied

  Sorry, you don't have enough rights to continue.

Really? Yougottabekiddingme....

https://wiki.hyperbola.info/doku.php?id=en:philosophy:rust_i...

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...

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.

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.

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.

... 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)

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.)

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.)

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."

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.

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

>...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.

Guix in order to bootstrap OpenJDK and Mono from sources it needs to create a centipede-like toolchain building. WIth Rust it's even worse. One build per release since the first C++ compilable compiler.

Thank you. I misread your original comment but.. yeah.. very interesting to know.

Searching for Unicon brings up multiple results. Which one do you mean?

The Unicon programming language, the new "Icon":

http://www.unicon.org/

Reply on news.ycombinator.com