Thougths on HyperbolaBSD
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
Hard fork to https://trisquel.info/en/forum/canonical-and-microsoft-are-bed-other#comment-168103.
- andyprough insisted:
-
>"Rejecting it just because it comes from a company that mainly writes user-subjugating software makes no sense to me"
I'm pretty certain that the Hyperbola true-believers would look at a statement like that as complete anathema.
Well, one may or may not agree with them on that point. Do they also think Hyperbola should stay away from openBSD given its abhorrent past donors? I find the HyperbolaBSD project interesting anyway, so I tried to research the topic further and I found this:
I am under the impression that such a roadmap confirms that the Hyperbola devs do intend to maintain the whole HyperbolaBSD codebase themselves, ultimately [1]. I have no idea how realistic this is but I wish them success: diversity means even more freedom for users, not less. It also means new ideas, new implementations, and readily available proofs of concept for others to use. By merely seeding discussions it helps other projects stay alert instead of falling asleep at the helm, provided they are ready to consider external ideas. I don't see any reason why GNU/Linux distros, and hence Trisquel users, would not also benefit from such healthy stimulation. You mentioned kernel hardening and userspace sandboxing, there is probably room for improvement in other areas too.
As for their resources, I see no reference to companies releasing user-subjugating software in https://en.libreware.info/?Services. Whoever has been taking advantage of various BSDs in the past seems totally irrelevant here. To the contrary, it would be good news if BSD could be turned into a fully free distro instead of benefitting mostly the evil entities that be. In the meantime, I'll keep compromising with Freedo and stick to Trisquel.
[1] This is also what I had initially understood in: "For the first version we plan to keep in synchronization with OpenBSD where it is possible. In future versions we may adapt code from other BSDs and even the Linux kernel where needed to keep up with hardware support and features" from https://itsfoss.com/hyperbola-linux-bsd.
For future reference:
"OpenBSD has a much smaller code base, around 2.9 million lines of code, compared to FreeBSD's roughly 9 million, and NetBSD's 7.3 million."
"The Linux kernel has around 27.8 million lines of code in its Git repository, up from 26.1 million a year ago, while systemd now has nearly 1.3 million lines of code."
"There were nearly 75,000 code commits to the kernel during 2019 which is actually slightly down on 2018 (80,000 commits), and the lowest number since 2013. The top contributors by email domain were Intel and Red Hat (Google’s general gmail.com aside) and the top contributing individuals were Linus Torvalds, with 3.19 per cent of the commits, followed by David Miller (Red Hat) and Chris Wilson (Intel). There were 4,189 different contributors overall."
What we really need is a suckless kernel which is perpetually kept at under 4,000 lines of code. Like they do with their DWM window manager (which I am using at the moment, by the by).
Do that in Linux by deleting lots of the drivers. Yes you end up with less hardware support but what the numbers in this aren't counting is that a lot of Linux code is hardware drivers. OpenBSDs is smaller because they have less hardware support. From that point of view Linux is the better kernel from that point of view of supporting more hardware.
> Do that in Linux by deleting lots of the drivers.
Is anyone doing that yet? Is there any "Binux", Minux" or Dinux" that forked Linux to strip it of vast amounts of drivers?
The question I was trying to document is whether it sounds realistic for a smaller project like Hyperbola to maintain a kernel, that is why I tried to get numbers about codebase and contributors. Based on your input, it seems the answer may in fact depend on how much hardware support they are aiming for, and how fast. Starting with the lesser number of LoC to review still makes sense, though. They also state that they "may adapt code from [...] even the Linux kernel where needed to keep up with hardware support and features."
>"Is anyone doing that yet? Is there any "Binux", Minux" or Dinux" that forked Linux to strip it of vast amounts of drivers?”
Yes, my understanding is that there are tiny linux kernels for embedded devices.
Sure. I was thinking of a non-embedded generic kernel that anyone could just download and build to their liking, as with Linux-libre. But those tiny embedded kernels are probably good examples of kernels being maintained by a limited team.
When you compile the kernel there's a little program called 'menuconfig' that helps you decide on all the config options, and I think that you can simply disable most (or a lot) of the hardware support while using that little program at that point. Of course, you'll end up with a kernel that won't boot on any of your equipment unless you really really know what you are doing. And those hardware modules probably don't matter - they are taking up space, but probably not doing anything as long as you don't have that hardware.
There's lots of videos on choosing config options for compiling your kernel. I like the ones by "mental outlaw" (Kenny) when he's configuring gentoo kernels on yewtu.be, not because he's an expert (he's not), but more because he talks through it like he's one of us non-experts. Just search 'mental outlaw compile kernel' and you'll find them.
Of course, the Linux-libre kernel already strips out tons of stuff, and the hardware support that is left is probably so basic to just being able to boot and run a basic system that you might not want to go much further. But keep in mind, when you run Trisquel you are not using Linux-libre, you are using a de-blobbed Ubuntu kernel. I always prefer to replace the Trisquel kernel with jxself's Linux-libre kernels myself. I love that super streamlined feel of pure Linux-libre.
Edit: Another thing you can do is use the oldest possible still-supported kernel, which I believe is 4.9 at this point, and then you'll be using a kernel prior to the past few years worth of hardware support being added on. jxself should have up-to-date 4.9 kernels. I know that anticapitalista over at antiX loves to use those as the default, and I've found the 4.9 Linux-libre kernel to be very very good on old enough hardware.
> when you run Trisquel you are not using Linux-libre, you are using a de-blobbed Ubuntu kernel.
True, and I am aware that this is an awful lot of compromise. But what is it exactly Linux-libre is stripping, beyond (tons of) non-free blobs? Or do you mean Ubuntu is adding libre drivers?
Anyway, about kernel hardening:
https://trisquel.info/en/forum/how-come-hardened-kernel-isnt-more-popular
https://trisquel.info/en/forum/linux-libre-hardened
"True, and I am aware that this is an awful lot of compromise"
There's really no compromise; it's the same outcome. The Trisquel people deblob the Ubuntu kerel instead of upstream from kernel.org because they want the Ubuntu kernel modifications. But it's still equally free after being cleaned up.
That was a tongue-in-cheek reference to the original post that started it all in the previous thread. I forgot the irony flag, sorry.
I would need to do more research about these Ubuntu kernel modifications that make it into Trisquel. Is it mostly about hardware support? While trying gnuinos the other day, all was great but only after I installed the proper ath9k firmware. Could this be a typical example of what Ubuntu may add to the upstream kernel?
EDIT: never mind, I asked Ubuntu: https://askubuntu.com/questions/37147/what-are-the-differences-between-the-ubuntu-shipped-kernel-and-the-upstream-kern.
The ath9k_htc firmware isn't included in the kernel itself, it is loaded from an external file in /lib/firmware (like most firmware loaded by Linux kernel drivers). Trisquel has this file installed by default, and I guess gnuinos doesn't. It's not a difference between the two kernels.
Indeed, gnuinos doesn't, at least not in its currently available version.
Can we infer that this was an Ubuntu addition, albeit not concerning the kernel?
Actually, Trisquel (and perhaps other FSDG distros) was among the first to include the ath9k_htc firmware when it was first liberated. At the time Ubuntu and Debian only had the proprietary version.
Eventually, Debian packaged it as well, and this is the package that Trisquel uses nowadays. At first, Debian did not include this firmware in the default installation, but now it does.
I see. That probably explains why I was eventually able to switch seamlessly from Ubuntu to Trisquel 7, without any hardware change.
Anyway, thanks again, the whole picture has become much clearer in my fuzzy mind. All these "hardware support" lines that make Linux ten times larger than openBSD in terms of lines of code are indeed drivers, but the firmware is stored elsewhere.
The package concerned is firmware-ath9k-htc. I'll include it in future releases from now on.
Sorry I missed this when you posted it.
Thanks for the inclusion.
Most of what Linux-libre strips from upstream Linux is actually names of nonfree blobs (in these cases, the blob is loaded from an external file). Linux-libre also removes a few blobs (5 of them) and some documentation/scripts related to obtaining nonfree blobs.
I was indeed under the impression that the main difference between using the Trisquel libre kernel and Linux-libre was the upstream Linux version it is based on. After all, the first line in the Documentation here says: "Trisquel GNU/Linux is a distribution of the GNU operating system, with the kernel Linux-libre."
Some earlier post got me confused. Anyway, thanks for these precisions, it is all clearer now.
Hard to do, even for a microkernel. seL4 has 60 965, GNU Match has 311 716 and Minix 3 has 432 898. Even Minix 1 had 12 000 LOC.
- > it helps other projects stay alert
-
OpenBSD was right, he said. "A year ago they said disable hyper-threading, there's going to be lots of problems here. They chose security over performance at an earlier stage than anyone else. Disable hyper-threading. That's the only way you can solve some of these issues. We are slowing down your workloads. Sorry."
https://www.theregister.com/2019/10/29/intel_disable_hyper_threading_linux_kernel_maintainer
"I am under the impression that such a roadmap confirms that the Hyperbola devs do intend to maintain the whole HyperbolaBSD codebase themselves"
If your goal is just to have a fully free BSD, there's no need to do all that work. You could remove blobs from OpenBSD just like we remove blobs from Linux. I believe there was a deblobbed version of OpenBSD called LibertyBSD in the past, but it's not maintained.
The reason they're doing this is because they want to release HyperbolaBSD under the GPL, and it turns out that much of OpenBSD code is licensed under the 4-clause BSD license which is incompatible with the GPL.
> If your goal is just to have a fully free BSD
Clearly, their goal goes beyond having a fully free BSD, GLP'ed or else. I guess that is why they are planning such extensive work. Else they would just keep using GNU/Linux-libre as they have been doing until now. Again, I only wish them success, although I believe this is probably an overshot for the vast majority of users. I have a feeling it may be more realistic than I initially thought, given that they seem to be aiming a first stable release in 2024.
The main point, in my limited view, being that most of the reasons they state for rebasing can probably be addressed on a GNU/Linux base. That is why I am closely following Gnuinos: I am not convinced systemd is the "disease" that some of its critics claim it is, but keeping alternatives alive and running still sounds like a good idea. Again, I am quite happy with Trisquel/GNU/Linux(-libre).
Yeah. I guess I'm just skeptical of the possibility that a small team can maintain a BSD fork, with 20% of the code rewritten, on their own. Also, it's pretty hard to write secure code in C, and I doubt the resulting OS will be as secure as OpenBSD.
If I were in their position, I'd just work on deblobbing OpenBSD without trying to rewrite massive amounts of code and release it under the GPL. And I'm not really sure what the benefit of releasing a BSD variant under the GPL is, since a proprietary software company can just take code from an existing BSD variant.
And I'm with you on systemd. I think a lot of the criticism of systemd is overblown (and arguments that it's somehow "less free" are complete nonsense), but at the same time it's good to have alternatives.
>"I am not convinced systemd is the 'disease' that some of its critics claim it is"
That's because Cthulhu has his wet tentacle firmly implanted in your medula oblongata, and is partially blocking the "IBM/Microsoft questioning/suspecting portion" of your brain.
Nonsense. All the evil entities you mention have been neutralized long ago by our cunning infiltration plans, to the point that they have not even realized it.
- Vous devez vous identifier ou créer un compte pour écrire des commentaires