Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 15 submissions in the queue.

GNU Hurd 0.6 Released, Still x86, Still 32-bit

posted by martyb on Friday April 17 2015, @05:11PM   Printer-friendly
from the whole-bunch-of-hairy-beasts dept.

Phoronix reports that version 0.6 of GNU Hurd has been released. Before getting too excited about GNU Hurd, it's still bound to x86 32-bit and doesn't offer any compelling new features.

GNU Hurd 0.6 has "numerous cleanups and stylistic fixes" to the code-base, the message dispatching code in Hurd servers is now better, there's support for protected payloads of GNU March 1.5+, libz/libz2 are used as the decompressors to replace gz/bz2, the native fakeroot has improved, the performance of the integer hashing library has improved, and the init server has been split into the start-up server and a SysVinit-style program. The procfs and random translators were also merged.

More details on the new GNU Hurd release can be found via the 0.6 release announcement issued by Thomas Schwinge.

 
This discussion has been archived. No new comments can be posted.
GNU Hurd 0.6 Released, Still x86, Still 32-bit | Log In/Create an Account | Top | 54 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 2) by FatPhil on Saturday April 18 2015, @10:15AM

    by FatPhil (863) <{pc-soylent} {at} {asdf.fi}> on Saturday April 18 2015, @10:15AM (#172342) Homepage
    Were that it was true. WE're not in the noise because software architectures have changed over time, and there's far more reliance on IPC. You're not just sitting in a tight processing loop until you need to pull some new data in or squirt some processed data out any more. You're constantly playing ping-pong with any number of different external resources. And of course, the processors process states are now *much* bigger and more complex, so that task/mode switches are more expensive than they were back in the 68030/486 days.

    Sometimes it might be the modern languages and language-architecture libraries that are partly to blame, rather than the actual software architecture itself. I once straced a modern piece of bloatware which appeared to have locked up, and noticed that it was basically doing nothing but mmap/munmap. In a pretty-much-pessimal scatter-gather pattern. System calls constantly, tens of thousands per second. Add that all together and alas it's not noise.
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2