Live data from Hacker News

Debian GNU/Hurd Status Update [pdf]

people.debian.org

21–30 of 55 posts

Re: Debian GNU/Hurd Status Update [pdf]

#21

>Hardware support >● i686 >● start of 64bit support WTF? They started 30 years ago and still on an 32bit architecture nobody cares anymore? Beside that, I really don't get the point of all this, seriously. Not from a technological benefit, be warned, but from a user perspective the benefit is almost intangible. Why should the average sysadmin care? Linux is a rock solid kernel that does everything, what is the niche…

>>Beside that, I really don't get the point of all this, seriously. Not from a technological benefit, be warned, but from a user perspective the benefit is almost intangible. Why should the average sysadmin care? Linux is a rock solid kernel that does everything, what is the niche that Hurd is filling?

Well, that's debatable. Linux just crossed the 20 MLOCs bar. Granted, this is mostly driver code which you will only need a small subset of, but still: Linux is a huge complex blob. Linus himself said it's bloated years ago[1] and that it has a high entry barrier for new developers due to its complexity[can't find the link right now].

My guess would be that this is partly due to its classic monolithic architecture and partly due to their developement model[2].

After working with Plan9 for a while I can't help but take my hat off to the beauty and simplicity of the system. Especially as a sysadmin your life would be so much easier. No LDAP, no Kerberos, no NFS, no need to update or deploy software on/to terminals. But as it stands we're living in a land where every computer thinks it is a Mainframe.

Linux has done a great deal for OSS and will without question be around for quite some time but you have to wonder how computing would look like today, if history had taken a few diffenent turns.

FWIW: Is it just me, or is OS R&D gaining a little more traction lately after it almost stagnated in the 2000s ?

[1] http://www.cnet.com/news/linus-torvalds-linux-is-bloated/

[2] https://en.wikipedia.org/wiki/Criticism_of_Linux#Kernel_code...

Re: Debian GNU/Hurd Status Update [pdf]

#22

● Top dumb issues ● Not linux or BSD? #include can someone explain the above to me? the slides didn't make sense.

Poorly written preprocessor bits in C code that assume that anything anyone ever runs is either Linux, BSD (including OS X), or Windows. They basically write the following: #ifdef LINUX // include Linux headers #elif defined(BSD) // include BSD headers #else // include Windows headers. What else would it possibly be? #endif The "mach.h" one is similar: people make a bad assumption that OS X is the only Mach kernel pe…

I think it's wrong to call it poorly written because the programmer only accounted their C preprocessor code for ~99.99% of desktop and mobile operating systems. The diminishing return for avoiding this approach is so impalpable it hurts. Windows, OSX/iOS/BSD, and Linux/Android literally are everything anyone ever uses, within rounding error.

Re: Debian GNU/Hurd Status Update [pdf]

#23

>Hardware support >● i686 >● start of 64bit support WTF? They started 30 years ago and still on an 32bit architecture nobody cares anymore? Beside that, I really don't get the point of all this, seriously. Not from a technological benefit, be warned, but from a user perspective the benefit is almost intangible. Why should the average sysadmin care? Linux is a rock solid kernel that does everything, what is the niche…

You realize i686 is a catch-all term for 32-bit x86 processors, right? It's arguably the only 32-bit architecture anyone cares about.

Re: Debian GNU/Hurd Status Update [pdf]

#24
post #3

the last document linked to at the end is a really good read too - http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.37.... , Also I agree with him on the fdisk/mke2fs, I've often asked myself the exact same question. aparently, its not a so popular opinion though, since they're always tucked away in sbin...

Not all linux systems do that. Arch symlinks everything to /usr/bin, I believe.

Re: Debian GNU/Hurd Status Update [pdf]

#25

Earlier quoted context omitted.

Poorly written preprocessor bits in C code that assume that anything anyone ever runs is either Linux, BSD (including OS X), or Windows. They basically write the following: #ifdef LINUX // include Linux headers #elif defined(BSD) // include BSD headers #else // include Windows headers. What else would it possibly be? #endif The "mach.h" one is similar: people make a bad assumption that OS X is the only Mach kernel pe…

I think it's wrong to call it poorly written because the programmer only accounted their C preprocessor code for ~99.99% of desktop and mobile operating systems. The diminishing return for avoiding this approach is so impalpable it hurts. Windows, OSX/iOS/BSD, and Linux/Android literally are everything anyone ever uses, within rounding error.

The diminishing return approach is this:

     #ifdef LINUX
     // include Linux headers
     #elif defined(BSD)
     // include BSD headers
     #elif defined(WINDOWS)
     // include Windows headers.
     # else
     #error "unsupported system"
     #endif

Re: Debian GNU/Hurd Status Update [pdf]

#26

Earlier quoted context omitted.

Poorly written preprocessor bits in C code that assume that anything anyone ever runs is either Linux, BSD (including OS X), or Windows. They basically write the following: #ifdef LINUX // include Linux headers #elif defined(BSD) // include BSD headers #else // include Windows headers. What else would it possibly be? #endif The "mach.h" one is similar: people make a bad assumption that OS X is the only Mach kernel pe…

I think it's wrong to call it poorly written because the programmer only accounted their C preprocessor code for ~99.99% of desktop and mobile operating systems. The diminishing return for avoiding this approach is so impalpable it hurts. Windows, OSX/iOS/BSD, and Linux/Android literally are everything anyone ever uses, within rounding error.

If you develop for different platforms then it may actually make sense to do a "if linux / elif bsd / elif windows / else #error unsupported". At least it gives you a proper answer in case you forgot you have some wild crosscompiler in your path. But I understand it's not a popular concern...

Re: Debian GNU/Hurd Status Update [pdf]

#27
post #21

>Hardware support >● i686 >● start of 64bit support WTF? They started 30 years ago and still on an 32bit architecture nobody cares anymore? Beside that, I really don't get the point of all this, seriously. Not from a technological benefit, be warned, but from a user perspective the benefit is almost intangible. Why should the average sysadmin care? Linux is a rock solid kernel that does everything, what is the niche…

>>Beside that, I really don't get the point of all this, seriously. Not from a technological benefit, be warned, but from a user perspective the benefit is almost intangible. Why should the average sysadmin care? Linux is a rock solid kernel that does everything, what is the niche that Hurd is filling? Well, that's debatable. Linux just crossed the 20 MLOCs bar. Granted, this is mostly driver code which you will only…

I think there was some serious experimentation in 2000s, just not in the area of popular systems. Plan9 started to hit the news properly around then. A few OSes in managed languages were developed: MS Singularity, and smaller experiments like JNode and SharpOS.

Re: Debian GNU/Hurd Status Update [pdf]

#29

I was hoping they will mention something about crosshurd, but there was nothing, and crosshurd doesn't work on recent debian anymore. I'd love to see some way to install from an existing system.

You can either follow my guide [1] based on updated cross-gnu scripts, or try out gnuxc [2] for bootstrapping a full Hurd distribution, with the caveat that it requires your host to be Fedora.

[1] http://blog.darknedgy.net/technology/2015/07/25/0/

[2] https://github.com/dm0-/gnuxc

Re: Debian GNU/Hurd Status Update [pdf]

#30

I was hoping they will mention something about crosshurd, but there was nothing, and crosshurd doesn't work on recent debian anymore. I'd love to see some way to install from an existing system.

You can either follow my guide [1] based on updated cross-gnu scripts, or try out gnuxc [2] for bootstrapping a full Hurd distribution, with the caveat that it requires your host to be Fedora. [1] http://blog.darknedgy.net/technology/2015/07/25/0/ [2] https://github.com/dm0-/gnuxc

I found this bit in your post interesting: "kdbus (which was called “neutered Mach IPC” by Neal Walfield)" - does that mean mach ipc provides typed interface registration / binding between userland processes? I admit, I know very little about mach and thought it was for kernel/user-space communication only (both directions)
Post reply on HN