Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian GNU/Hurd 2023

lists.gnu.org

Post reply on HN
Print view View original

91–100 of 132 posts

Re: Debian GNU/Hurd 2023

#91

Post by marcosdumay »

mo_42 wrote: 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.

Our current hardware doesn't support microkernels because there is no demand, and nobody is creating general purpose microkernels because all the important hardware doesn't support it. So, I'm not sure we will ever see that change.

A proper microkernel isn't like Linux with a bunch of modules. It's something that can your game direct access to the GPU, while restricting access to a pseudo-root on your disk, and to an edited raw RAM that pretends the spyware from the game's DRM is running on the main system while it's actually sandboxed.

You can do something like that in a microkernel because you can replace it piecewise for a single application. You can technically do something like that on Linux, but you will never manage to.

Re: Debian GNU/Hurd 2023

#92

Post by ndsipa_pomu »

ori_b wrote: post #53
pshirshov wrote: post #47

Earlier quoted context omitted.

RISC-V SBCs are on the market in abundance and they are affordable.

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

Re: Debian GNU/Hurd 2023

#93

Post by anthk »

Gigachad wrote: post #28
cies wrote: post #19

Earlier quoted context omitted.

> really shows how irrelevant the GNU foundation (and even the FSF) have become I've seen several posts here in the last month about proprietary software being used to basically exploit the users: steeply increase fees, hold files ransom (upgrade for money or loose access to files), spying on users. My conclusion is very different from yours: GNU Foundation and FSF are very relevant! They seem to lack in the PR dept,…

Open source and software freedom are relevant, the FSF is not. In an era of insane surveillance, AI technology, mass corporate insanity, the FSF is still arguing about firmware blobs on hardware vs loaded in by the OS, or advocating for switching from .docx to .odt when the world has moved on from even having document files.

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.

Re: Debian GNU/Hurd 2023

#94

Post by arp242 »

ptx wrote: post #54
arp242 wrote: post #41

Earlier quoted context omitted.

> text dump of what Microsoft did in binary than a standard meant for interoperability. Isn't it all XML based? > OpenOffice was already better at reading old doc files than Microsoft Word was well before OOXML was a thing. It's been a long time, but that was certainly not my experience from what I recall; I had a lot of trouble with this. And writing files and then expecting Word users to be able to read them well w…

> Isn't it all XML based? That doesn't help much when the XML format consists of elements like "footnoteLayoutLikeWW8" which "specifies that applications shall emulate the behavior of a previously existing word processing application (Microsoft Word 6.x/95/97)" [1]. I think this kind of thing is what the parent comment was referring to. [1] https://www.consortiuminfo.org/opendocument-and-ooxml/the-co...

Ah, I didn't know that! It seems like they're only there for compatibility and not in new documents(?)

Either way, it seems like fighting yesterday's battle.

Re: Debian GNU/Hurd 2023

#95

Post by ori_b »

ndsipa_pomu wrote: post #92
ori_b wrote: 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

And the peripherals are far more interesting from a license perspective.

Re: Debian GNU/Hurd 2023

#96

Post by ssrc »

4gotunameagain wrote: post #46
taylodl wrote: post #40

Earlier quoted context omitted.

> > The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore. You're making a lot of assumptions with regards to the operating environment. What about a probe being sent to Mars, the Moon or wherever? In fact let's just generalize to space-faring craft. That environment demands incredible resiliency and the ability to continue running e…

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

And yet at some complexity level you have things like ARINC 653 where the usual implementation is to have a classic RTOS running on each of the partitions provided by the "application executive", and today's serverland is hypervisors running VMs running containers. I believe we are too centered on the "Linux vs Minix" debate while in actual practice both tendencies are reflected in most systems.

Re: Debian GNU/Hurd 2023

#97

Post by mattl »

martin8412 wrote: post #69
dale_glass wrote: post #49

Earlier quoted context omitted.

> Microkernels are not obsolete (see seL4), but HURD unfortunately is. Why HURD specifically? But I didn't mean microkernels, but the debate. Basically my view is that nothing stays pure. If microkernels have significant upsides a monolithic kernel like Linux doesn't have, then the logical outcome is that Linux copies the required feature like eg, FUSE. Yeah, it's not a true microkernel, but who cares? It can do the…

Hurd is never going to be more than at best a research project, more likely a hobby project. All semi-modern hardware requires proprietary blobs to function properly. It would be great if all firmware and drivers was open source, but that's not going to happen anytime soon. FSF is largely a joke in the way they certify RYF hardware. Proprietary blobs are all good as long as they're loaded from a separate flash that c…

I thought proprietary blobs were only "okay" if they were burned into ROMs and thus presented as hardware and not software?

Re: Debian GNU/Hurd 2023

#98

Post by kramerger »

senko wrote: post #52
dale_glass wrote: post #49

Earlier quoted context omitted.

> Microkernels are not obsolete (see seL4), but HURD unfortunately is. Why HURD specifically? But I didn't mean microkernels, but the debate. Basically my view is that nothing stays pure. If microkernels have significant upsides a monolithic kernel like Linux doesn't have, then the logical outcome is that Linux copies the required feature like eg, FUSE. Yeah, it's not a true microkernel, but who cares? It can do the…

> Why HURD specifically? Because Hurd is (in my understanding) exactly the solution in search of a problem you're talking about. It's microkernel for the sake of being microkernel, but tied to the past (POSIX/UNIX model). Actually innovative microkernels can do things Linux or other mainstream monolithic OS can't just copy (and that's why they're interesting). Again using L4 as an example, have a look at discussion h…

Do you have any actual (and professional) experience with sel4 and qnx?

Because we have shipped products with those and boy I wish we had used Linux instead!

Limited, expensive, developer unfriendly and surprisingly, quite unstable under certain loads.

Re: Debian GNU/Hurd 2023

#99

Post by Zambyte »

duskwuff wrote: post #87
bluenose69 wrote: post #2

Having been quite interested in GNU/Hurd a long time ago (the years have become decades, I fear) and having lost track of the project, I wonder whether somebody can comment on where GNU/Hurd is being used nowadays.

> I wonder whether somebody can comment on where GNU/Hurd is being used nowadays. Simply put: nowhere. It's an experimental kernel with limited hardware support (x86 only, very few device drivers) and a bunch of critical features missing (e.g. no multiprocessor support, no power management).

> x86 only

And limited x86_64 :)

Re: Debian GNU/Hurd 2023

#100

Post by senko »

kramerger wrote: post #98
senko wrote: post #52

Earlier quoted context omitted.

> Why HURD specifically? Because Hurd is (in my understanding) exactly the solution in search of a problem you're talking about. It's microkernel for the sake of being microkernel, but tied to the past (POSIX/UNIX model). Actually innovative microkernels can do things Linux or other mainstream monolithic OS can't just copy (and that's why they're interesting). Again using L4 as an example, have a look at discussion h…

Do you have any actual (and professional) experience with sel4 and qnx? Because we have shipped products with those and boy I wish we had used Linux instead! Limited, expensive, developer unfriendly and surprisingly, quite unstable under certain loads.

Not professional experience (I wasn't paid to build stuff on it), no, just hobby use (of earlier version of L4, L4Ka::Pistachio, and QNX once they started opening up before selling to RIM).

I believe you the developer experience was years behind Linux. That doesn't invalidate my claim that microkernels are interesting (and that these two are innovative), unless your pain was explicitly due to the microkernel nature of things.

Post reply on HN