Live data from Hacker News

Debian GNU/Hurd 2019 Released

lists.debian.org

11–20 of 99 posts

Re: Debian GNU/Hurd 2019 Released

#11
post #4

> Debian GNU/Hurd is currently available for the i386 architecture with about 80% of the Debian archive, and more to come! Does Hurd still not support amd64?!

From https://www.gnu.org/software/hurd/faq/64-bit.html > There are currently no plan for 64-bit userland, but there are plans for 64-bit kernelland with 32-bit userland, which will notably permit to efficiently make use of more than 2 GiB memory and provide 4 GiB userland addressing space. Work on this is currently in the master-x86_64 and port-amd64 branches for GNU Mach. > That being said, you can always run a 32-b…

Debian x32 has a pretty similar concept wrt more efficient memory usage: https://wiki.debian.org/X32Port

Re: Debian GNU/Hurd 2019 Released

#12
I think that it is exciting that people are still working on Hurd and there is a new release synced with Buster. I think there is latent potential in microkernels and that we may actually be at in position to exploit some of the benefits such as heightened security and stability. While at the same time the performance cost of context switching could be reduced due to the higher number of cores on modern chips (especially compared to the hardware available in the 90s). One of the biggest adoption challenge any new operating presents is hardware compatibility and well a reason to try it. 80% software compatibility with Debian is a big accomplishment, so this is probably worth spinning up a virtual machine to play around with.

Re: Debian GNU/Hurd 2019 Released

#13
post #4

Earlier quoted context omitted.

From https://www.gnu.org/software/hurd/faq/64-bit.html > There are currently no plan for 64-bit userland, but there are plans for 64-bit kernelland with 32-bit userland, which will notably permit to efficiently make use of more than 2 GiB memory and provide 4 GiB userland addressing space. Work on this is currently in the master-x86_64 and port-amd64 branches for GNU Mach. > That being said, you can always run a 32-b…

Debian x32 has a pretty similar concept wrt more efficient memory usage: https://wiki.debian.org/X32Port

You can also store pointers for more than 4 GB in a 32 bit address by compressing them.

Re: Debian GNU/Hurd 2019 Released

#15

I'm curious, but why are people still spending time and resources on Hurd? Is it curiosity or is there some use case for Hurd that I'm not aware of? Thanks.

I can't speak for the developer of Hurd.

But I think it's fun and something different.

It's one of the few OS up there that seems to be able to take advantage of multicores.

Other such as barrelfish and dragonflyBSD.

Re: Debian GNU/Hurd 2019 Released

#16

What does Hurd uniquely solve?

Well apart from actually building and researching how to build an OS. This stems from a very very deep seated itch. The answer is "because we can". It's volunteer engineering; because they can! Also it is not possible to know how the fruits of innovation might materialise. There might be achievments coming from this in a serendipitous way. The Hurd is a process.

After the news about pip being maintained by 5 people, I wonder how many are working on hurd. (As a grown adult, I also envy and more than a little humbled by their ability to devote time to it.)

Re: Debian GNU/Hurd 2019 Released

#17

Earlier quoted context omitted.

Debian x32 has a pretty similar concept wrt more efficient memory usage: https://wiki.debian.org/X32Port

You can also store pointers for more than 4 GB in a 32 bit address by compressing them.

But you are still using 32 bit registers so your load and save instructions can't really make use of compressed addresses

Re: Debian GNU/Hurd 2019 Released

#18

I think that it is exciting that people are still working on Hurd and there is a new release synced with Buster. I think there is latent potential in microkernels and that we may actually be at in position to exploit some of the benefits such as heightened security and stability. While at the same time the performance cost of context switching could be reduced due to the higher number of cores on modern chips (especi…

Well I've been hearing about those benefits for at least 20 years. None yet actually sighted in the wild. Any attempted explanations from the microkernel religious zealots has been thoroughly unconvincing (because mach is slow, so?). Maybe you're right, I'd love to see it if you are. But while prior performance is no guarantee of the future, as they say in the funds management adverts, a pattern of repeated failure is something maybe not to completely ignore. Is there a reason for it that is being overlooked or glossed over. (In mutual funds it was and is M.E.R.) Stallman talks about hurd being really hard to debug, is that a thing? Or is there some kind of combinational explosion using multiple servers a message passing that isn't there with a monothlithic kernel? Something else entirely?

Anyway I'll go back to the american monolithic kernel conspiracy to destroy OS research and keep the Europeans out and ask the brothers if they can think of anything. (That's a joke, right? Yet I've heard it said in the absence of irony...)

Re: Debian GNU/Hurd 2019 Released

#19

What does Hurd uniquely solve?

"Remember when men were men and wrote their own device drivers." --Linus Torvalds

"Come and join the fun!" --Alan Cox

Linux wasn't going to big and professional, like Hurd, but better fun. Perhaps those roles have switched?

Post reply on HN