If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

GNU/Hurd Plans For A Future With USB, SATA, 64-Bit

02-10-2013, 01:20 AM

Phoronix: GNU/Hurd Plans For A Future With USB, SATA, 64-Bit

While GNU/Hurd isn't on par yet with GNU/Linux in terms of kernel functionality and hardware support, the developers do have plans for the future and a surprising number of user-space packages are now building on a GNU/Hurd platform...

While GNU/Hurd isn't on par yet with GNU/Linux in terms of kernel functionality and hardware support, the developers do have plans for the future and a surprising number of user-space packages are now building on a GNU/Hurd platform...

Comment

Even Stallman has abondon hurd as we now have Linux which is much simpler and more powerful. Working on hurd will a hold back open source.

It's best to concerntrate on Linux. Make it stronger and as the symbol of freedom and open source. Even stallman agrees with that.

Eh... Development doesn't work like that. If it was corporations working on it you might have a point but the people working on it are hobbyist developers, which means that they'll work on whatever they want to work on rather than what you think they should work on, unless you have money to pay them of course or some other incentive.

On Topic though, I must say for microkernel systems I'm far more interested in seeing how GENODE, HelenOS, and MINIX3 are going to develop here than HURD honestly. Particularly with Hurd still relying upon a gen 1 microkernel (i.e. Mach), and the others are using Gen 2 designs which are a vast improvement.

Comment

Eh... Development doesn't work like that. If it was corporations working on it you might have a point but the people working on it are hobbyist developers, which means that they'll work on whatever they want to work on rather than what you think they should work on, unless you have money to pay them of course or some other incentive.

On Topic though, I must say for microkernel systems I'm far more interested in seeing how GENODE, HelenOS, and MINIX3 are going to develop here than HURD honestly. Particularly with Hurd still relying upon a gen 1 microkernel (i.e. Mach), and the others are using Gen 2 designs which are a vast improvement.

I am also interested in MINIX3, dragonfly bsd has been peaking my interest a lot also. Though It is not exactly in the same boat.

Comment

Eh... Development doesn't work like that. If it was corporations working on it you might have a point but the people working on it are hobbyist developers, which means that they'll work on whatever they want to work on rather than what you think they should work on, unless you have money to pay them of course or some other incentive.

On Topic though, I must say for microkernel systems I'm far more interested in seeing how GENODE, HelenOS, and MINIX3 are going to develop here than HURD honestly. Particularly with Hurd still relying upon a gen 1 microkernel (i.e. Mach), and the others are using Gen 2 designs which are a vast improvement.

And on top of using the archaic Mach, HURD's an hybrid system, not a pure microkernel system. They're running their drivers in kernelspace.

The three systems you suggest are actual pure microkernel and multiserver systems and they're worth following.

Comment

On Topic though, I must say for microkernel systems I'm far more interested in seeing how GENODE, HelenOS, and MINIX3 are going to develop here than HURD honestly. Particularly with Hurd still relying upon a gen 1 microkernel (i.e. Mach), and the others are using Gen 2 designs which are a vast improvement.

Comment

Even Stallman has abondon hurd as we now have Linux which is much simpler and more powerful. Working on hurd will a hold back open source.

It's best to concerntrate on Linux.

It is hard for me to nail down every false aspect you stated in your comment, as the mass of it seems unbearable.

--

Richard Stallman did not *abandon* the Hurd, as he was never involved into active development in the first place. He is the founder of the GNU operating-system, but that does not mean he is involved in every sub-project.

--

Talking about the Hurd, it seems like most people don't even know the benefits of using a microkernel. Moreover, features like translators literally kick Linux's ass. You don't need FUSE or other tools to access remote filesystems, you just "cd" to them.

Not to forget the fact that Hurd is free software unlike the Linux-Kernel, which is full of BLOBS.

--

I have no idea why active development on Hurd would hold back free-software-development (not open-source-software, which is another deal). The opposite will be the case: It will turn the GNU-operating-system more flexible, supporting a multitude of Kernels (Hurd, Linux, FreeBSD) and not including hacks just for one of them.

Make it stronger and as the symbol of freedom and open source. Even stallman agrees with that.

First off: Richard Stallman execrates the term "Open Source", because it does not comply to the ideals of the Free Software Movement. The inclusion of proprietary BLOBs into the Kernel is not something that would qualify for a Kernel to be a symbol of freedom or even, in disregard, of open source.

--

Please, just RTFM and get your facts straight, because I have the impression to have just put in words what has already been written cleanly in many manuals.

Comment

Not to forget the fact that Hurd is free software unlike the Linux-Kernel, which is full of BLOBS.

Mostly agree with you, but don't go overboard on blobs. If you have the right hardware or just don't need support for certain features you can use Linux without blobs. If Hurd or whatever else wants to support the same hardware, it will be in exactly the same boat: use blobs or don't provide support, at least until some alternative becomes available.

Oh, and maintaining several versions of the same drivers (for Linux, *BSD, and Hurd/other micro kernels) doesn't make sense unless there's really an excess of people wanting to work on them, which I seriously doubt, which means some common interfaces for code sharing are needed to make driver sharing and thus choose-your-own-kernel feasible, which means more work and pain and overhead, which is why we don't see anything like driver equality across free software kernels, so if you're planning on doing some work on kernel drivers and your plans include making GNU/free OSs better, you should seriously consider which kernel project to spend time on.

Put another way, redesiging lots of wheels to work on your railtracks is not very useful unless your railtracks are widely used and similarly making adapters to use existing wheels on your tracks is often a lot of work, so choose your railtracks carefully.

Edit: yes, MINIX does sound interesting, though considering what I know about it is restricted to about five minutes reading a website I'm not going to say more than that.

Comment

Mostly agree with you, but don't go overboard on blobs. If you have the right hardware or just don't need support for certain features you can use Linux without blobs. If Hurd or whatever else wants to support the same hardware, it will be in exactly the same boat: use blobs or don't provide support, at least until some alternative becomes available.

Agreed; I personally also use the deblobbed Kernel source.
What wondered me the most is that obviously BLOB-dependent drivers like the BCM-TG3-Ethernet-driver still work in a deblobbed state (Luckily, my Ethernet-adapter has NVRAM), so everyone should attempt to get the most out of it.
For me personally not providing support is still a better alternative than having to rely on those binary-drivers; It's actually rather sad to see binary-arrays in the sources, not be able to understand or modify them to a certain degree.
With Linux turning more and more popular, it could definitely use its power someday to force the manufacturers into releasing free drivers (we shouldn't do this too early or else we would risk patch-forks).