Live data from Hacker News

Debian GNU/Hurd 2023

lists.gnu.org

121–130 of 132 posts

Re: Debian GNU/Hurd 2023

#121
post #5

This micro kernel vs. monolithic kernel still puzzles me. From a computer science perspective micro kernels make so much sense. But when I compiled the Linux kernel, I was always baking everything into one file. It seemed much more practical to do so.

A microkernel is has more processes, and those processes have their own state and their own MMU configuration.

They have to pass data between themselves to communicate by exposing data and mapping memory regions/structures across, which otherwise could be a function call with a pointer.

A monolithic kernel is either running or panicked, with either valid or invalid memory. The microkernel adds more failure modes - such as previously always present parts of the system going away, resetting their internal state, hanging, being upgraded on a live system, and so on.

The costs of the protections and of IPC recovery are what push towards monolithic designs. Modern microkernels have had a lot of focus on those two areas - often being little more than memory management and IPC at the core.

I'd say even though new microkernel systems haven't displaced the current ones, research on these newer "nano kernels" have borne fruit in various hypervisors.

Re: Debian GNU/Hurd 2023

#122

Earlier quoted context omitted.

> Generalising this to GNU and the FSF is daft I disagree - this isn't some isolated example, this pattern is seen across many other GUN, FSF and other free as in freedom projects. A lot of free as in freedom projects are completely out of touch with the modern world and waste their (already thin) resources on irrelevant, half-baked projects furthering some ideology rather than practical projects that would bring fre…

You're using "free as in freedom" very deliberately here... Probably to pretend you're not also talking about open source. But you are, because there's essentially no distinction in most cases. But hopefully you don't mean to say that most open source software is practically useless, because that would be pretty silly, right? So what exactly are you saying? That there are very niche open source projects around? Sure,…

I am using that expression to separate them from the broader Open Source movement. I do think there is a major difference between general open-source and GNU/FSF "free as in freedom" ideology.

I see the broader open source movement as "hey I made this thing to get stuff done, oh btw it's open source under a permissive license so feel free to take it/improve it".

GNU/FSF is more like "here's a list of reasons why the way you do your computing is wrong, the right way is to go back to the dark ages of computing, oh and we have some half-baked software to help with that - and don't you dare use that other open-source thing over there, it's not free enough".

> Name some examples

The hundreds of different Linux distributions, none of which can match the stability, consistency and user-experience of proprietary OSes even from a decade ago? Imagine the collective effort that has been wasted reinventing the wheel and bikeshedding.

The PinePhone, which despite there being a permissively-licensed, battle-tested mobile userspace (Android), would rather try to adapt a desktop-focused userspace to it (and the effort is obviously spread across multiple distros, because why wouldn't it?), and as a result you have a device for sale today that's less usable than a PocketPC from 2003.

The whole "Respects Your Freedom" list from the FSF (https://ryf.fsf.org/index.php/), which looks like a low-budget computer parts catalog from a decade ago, or their absurd position against CPU microcode updates (https://ariadne.space/2022/01/22/the-fsfs-relationship-with-...)? The RYF thing in practice just seems like a major blow to whatever credibility they have left (are they really not understanding that nobody in 2023 cares about mostly decades-old generic computer parts?), and they'd be better off scrubbing every mention of it and pretend it never happened.

I could go on and on. To recap, I think GNU/FSF is pushing some impractical and unrealistic ideology that is ultimately harmful as it wastes effort that could instead be directed to provide practical and pragmatic solutions that offer software freedom, even if partial (which is still better than no freedom at all).

Re: Debian GNU/Hurd 2023

#123
post #103

Earlier quoted context omitted.

Which is why in aerospace and safety critical systems, RTOSes are used and not fully fledged OSes. Also, redundant hardware is quite common (and mandatory by most standards), look up TMR, triple modular redundancy

>RTOSes are used and not fully fledged OSes. The idea that "RTOS" and "fully fledged OS" are incompatible with each other is outdated. seL4 advanced the state of the art with its formally-verified support for mixed criticality, years ago already.

The idea might be outdated, but as I have yet to seen a system running seL4, in practice it is very much true still.

Re: Debian GNU/Hurd 2023

#124
post #93

Earlier quoted context omitted.

Good luck stating that in any modern office. I dare you. Most gen-zers have no clue about how the real world works outside your smartphones. Hint: not as you think. At all.

I work in a modern office in a multi national company. I haven't seen actual document files sent around for years. It's all links now which enable collaboration and always show the latest version.

Not having offline backups with discrete data it's a recipe for a future disaster.

Re: Debian GNU/Hurd 2023

#126
post #99

Earlier quoted context omitted.

> x86 only And limited x86_64 :)

I'm not sure how far that support even goes. There's one page on the wiki which claims that "A 64-bit GNU/Hurd is also coming soon", but all of the downloadable images are 32-bit only, and Git history suggests that it's still a work in progress.

I don't think this release technically includes the 64 bit support, but there is an image here: https://lists.gnu.org/archive/html/bug-hurd/2023-05/msg00484... that can supposedly get you a minimal Debian 64 bit system running on Hurd after some configuration.

Also I just found that they have a directory for packages here: http://ftp.ports.debian.org/debian-ports/pool-hurd-amd64/ but none have been added yet.

Re: Debian GNU/Hurd 2023

#127
post #82
post #22

Earlier quoted context omitted.

Yes. But a Linux driver can crash the whole OS. In micro kernel land, most driver will not be able to do that. As I see it a micro kernel has simply a narrower definition of what should be in "kernel land" and what should be in "user land".

You're almost there. Yes, there's a narrower definition. Yes, that means that crashes are outwith the kernel. But no that only means that the circle around what bit is named "the kernel" is smaller. Importantly, it does not mean that it is impossible to "crash the whole operating system". Microkernels aren't a magic bullet against crashing an entire operating system, because a crash in a non-kernel component that the…

I think now we need to define what's the "whole OS". From a user's perspective: the whole OS crashed (became unresponsive). But from a developer's perspective the OS worked, as it was still logging, responding to network, etc.

Re: Debian GNU/Hurd 2023

#128
post #124

Earlier quoted context omitted.

I work in a modern office in a multi national company. I haven't seen actual document files sent around for years. It's all links now which enable collaboration and always show the latest version.

Not having offline backups with discrete data it's a recipe for a future disaster.

If you can do nothing without network connectivity, then it seems to be an acceptable disaster.

Or do companies generally have better backup policies than Google dRive?

Re: Debian GNU/Hurd 2023

#129
post #45
post #36

Earlier quoted context omitted.

Most people are generally more interested in functioning software running on existing hardware. Focusing on that might actually make Hurd actually relevant at some point in the future.

Quite a few RISC-V boards on the market now, no?

Maybe? I don't think there are many practical uses cases for it though..

I'l admit I'm not really sure what market segment Hurd is targeting. Presumably the goal is to replace in the GNU stack Linux at some point? If so only supporting niche/hobbyist CPUs (unless we're talking about really low power embedded applications) seems not like the best approach

Re: Debian GNU/Hurd 2023

#130
post #53

Earlier quoted context omitted.

Which come with well documented peripherals? The CPU is boring -- x86 instruction encoding is a bit ugly, but it works. It's all the stuff hanging off them that make the difference, and as far as I'm aware, risc-v hasn't done anything interesting here. It hasn't even enhanced discoverability (eg, by hanging internal peripherals off a virtual PCI bus).

Risc-v is interesting due to legal/licensing reasons rather than technological reasons. It certainly seems a good fit with ideological software

> It certainly seems a good fit with ideological software

I don't see how could it be more open that ARM longterm since there are no incentives to release high-end core designs for free. I mean I full see the potential for more competition between different companies designing proprietary cores which seems like an improvement over x86 from the consumer perspective but that's it..

Post reply on HN