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

GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released

gnu.org

Post reply on HN
Print view View original

51–60 of 66 posts

Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released

#51

Post by qwertyuiop924 »

nickpsecurity wrote: post #39
qwertyuiop924 wrote: post #19

It's kind of unbelievable that HURD is still going. It's been the butt of many a joke in the Unix world: our equivalent of Duke Nukem Forever, or Mordeth. I can't admire their release schedule, but you're got to admire their persistance. One day, it might just be ready...

That's great. You make an excellent comparison between its promises vs success vs DNF's. disordinary inadvertently points out that, unlike Hurd, DNF eventually delivered and at least made some money selling 376,300 units. It's kind of a cutdown on DNF to compare it to Hurd which wasn't finished, had little adoption, and sold 0 units. Even MULTICS and SCOMP probably had more adoption in significant use cases despite t…

...Which is why Mordeth is a more apt comparison: over 18 years of "development" by a volunteer (I think it's only one), and still no release.

Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released

#52

Post by witty_username »

ChickeNES wrote: post #41
gravypod wrote: post #21

I know this is a bit off topic but is there anything to read about how to implement a microkernel? Like a real booting system for x86.

This is the best source of OS development info/tutorials: http://wiki.osdev.org/Main_Page

Creating a GRUB multiboot image is the easiest way and you can just directly boot from the kernel file stored on your normal filesystem.

Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released

#55

Post by nickpsecurity »

qwertyuiop924 wrote: post #51
nickpsecurity wrote: post #39

Earlier quoted context omitted.

That's great. You make an excellent comparison between its promises vs success vs DNF's. disordinary inadvertently points out that, unlike Hurd, DNF eventually delivered and at least made some money selling 376,300 units. It's kind of a cutdown on DNF to compare it to Hurd which wasn't finished, had little adoption, and sold 0 units. Even MULTICS and SCOMP probably had more adoption in significant use cases despite t…

...Which is why Mordeth is a more apt comparison: over 18 years of "development" by a volunteer (I think it's only one), and still no release.

Yeah that makes sense.

Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released

#56

Post by daveguy »

flukus wrote: post #38
lokedhs wrote: post #37

I remember installing Hurd on actual hardware back in 1996[1] and I as far as I can recall, it was quite interesting to use. Since then, on regular intervals[2] I've attempted to install the most recent version, but I have failed every single time[3]. I'm also noting that Hurd is still only 32-bit. Is there actually a plan to make this into a system that can actually be used? Exactly what is it about the Hurd project…

> I'm also noting that Hurd is still only 32-bit. I wonder if they'll make it to 64-bit before we start upgrading to 128-bit computers?

Probably. It's unlikely we will be upgrading to 128 bit computers any time soon. 64 bit words are enough to store a double precision floating point number and enough bits to directly address 18.4 exabytes of RAM. The jump from 32 to 64 is a huge leap and any issues we were having with a 32 bit word are solved for a much longer period than the jump from 16 to 32 bit.

2^8 => 2^16 : 256x increase

2^16 => 2^32 : 65,536x increase

2^32 => 2^64 : 4,294,967,296x increase

Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released

#57

Post by jheriko »

kobeya wrote: post #28
jheriko wrote: post #23

Earlier quoted context omitted.

lol. good joke there.

That's ... literally what the GP comment was about.

i don't understand.

i was trying to comment on the idea that something being open source doesn't change that it needs compiling for a particular platform, and that it should be expected to not be straightfowards. especially at the low level where you need to raise interrupts and fill particular registers...

Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released

#58

Post by brohee »

lokedhs wrote: post #37

I remember installing Hurd on actual hardware back in 1996[1] and I as far as I can recall, it was quite interesting to use. Since then, on regular intervals[2] I've attempted to install the most recent version, but I have failed every single time[3]. I'm also noting that Hurd is still only 32-bit. Is there actually a plan to make this into a system that can actually be used? Exactly what is it about the Hurd project…

They also still publish SHA1 sums, definitely stuck in the past.

Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released

#59

Post by kobeya »

jheriko wrote: post #57
kobeya wrote: post #28

Earlier quoted context omitted.

That's ... literally what the GP comment was about.

i don't understand. i was trying to comment on the idea that something being open source doesn't change that it needs compiling for a particular platform, and that it should be expected to not be straightfowards. especially at the low level where you need to raise interrupts and fill particular registers...

Oh that's actually reasonably cross platform these days. You can write drivers that are ISA independent and make use of kernel APIs for interacting with the hardware. There's no reason to drop into assembly. (Although yes sometimes the memory coherency model or details of the interrupt handler protocol bleed into a driver requiring tweaks to get it to work, but those are bugs a good driver author can avoid.)

Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released

#60

Post by flukus »

daveguy wrote: post #56
flukus wrote: post #38

Earlier quoted context omitted.

> I'm also noting that Hurd is still only 32-bit. I wonder if they'll make it to 64-bit before we start upgrading to 128-bit computers?

Probably. It's unlikely we will be upgrading to 128 bit computers any time soon. 64 bit words are enough to store a double precision floating point number and enough bits to directly address 18.4 exabytes of RAM. The jump from 32 to 64 is a huge leap and any issues we were having with a 32 bit word are solved for a much longer period than the jump from 16 to 32 bit. 2^8 => 2^16 : 256x increase 2^16 => 2^32 : 65,536x…

I know it doesn't seem likely, but these things have a way of creeping up on you. 25 years ago the prospect of everyone having 8 GB of ram was far fetched, computers still had 8MB and 8GB hard drives were years off. In 10 years we could have petabytes in our phones and from there exabytes aren't such a huge leap.
Post reply on HN