Earlier quoted context omitted.
Hopefully it will run Project Xanadu https://en.wikipedia.org/wiki/Project_Xanadu (check the start date and first working version)
Huh...now I get the reference when playing Kentucky Route Zero
GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
61–66 of 66 posts
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#62Earlier quoted context omitted.
Basically Linux and then BSD took all the wind out of Hurds sails. A lot of that was timing, and also because those projects were much more attractive to big business who put a tremendous amount of development resources behind them. As far as I know QNX is the only usable OS based on a microkernel.
Quite a few embedded OSes are microkernels, L4 being one of them.
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#63Earlier quoted context omitted.
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.
8MB => 8GB : 1,000x increase
8GB => 8EB : 1,000,000,000x increase
The leap to 8 exabytes is 6 orders of magnitude greater than the last 25 years.
That would be 30 Moore's doublings (applied to storage) and would take 60 years. Oh, and we would still be able to address all of the ram with a 64 bit address.
In 10 years we will be closer to 256 GB in the phone, not petabytes or even terabytes (but terabytes would be close).
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#64It'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...
Unlike DNF it's not a commercial product, it relies on volunteers and corporate benefactors. For multiple reasons Linux got the brunt of OSS development resources behind it which wouldn't have helped Hurds schedule.
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#65Earlier quoted context omitted.
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.)
some hardware can be a nightmare for this stuff though...
i still contend that it can be much more complicated than simply recompiling for your target... and even when its not, that is still one more step than doing nothing, which was the impression i got from the "its open source you can do nothing" comment.
Re: GNU Hurd 0.9, GNU Mach 1.8, GNU MIG 1.8 Released
#66I hope they port Rust to it in order to take advantage of drivers ported in Rust which will become commonplace I foresee.