Page 1 of 3 123 LastLast
Results 1 to 10 of 23

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

  1. #1
    Join Date
    Jan 2007
    Posts
    15,091

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

    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...

    http://www.phoronix.com/vr.php?view=MTI5ODM

  2. #2
    Join Date
    Jan 2013
    Posts
    83

    Default

    Quote Originally Posted by phoronix View Post
    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...

    http://www.phoronix.com/vr.php?view=MTI5ODM
    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.

  3. #3
    Join Date
    Jun 2011
    Posts
    1,028

    Default

    Quote Originally Posted by systemd rulez View Post
    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.

  4. #4
    Join Date
    Jun 2010
    Posts
    74

    Default

    Quote Originally Posted by Luke_Wolf View Post
    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.

  5. #5
    Join Date
    Mar 2012
    Posts
    43

    Default

    Quote Originally Posted by Luke_Wolf View Post
    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.

  6. #6
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    390

    Default

    Quote Originally Posted by Luke_Wolf View Post
    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 really wish QNX was open source.

  7. #7
    Join Date
    Mar 2012
    Posts
    43

    Default

    Quote Originally Posted by LightBit View Post
    I really wish QNX was open source.
    I wish it was Free Software... but it's not. So we're left with those promising three.

  8. #8
    Join Date
    Oct 2012
    Location
    Cologne, Germany
    Posts
    308

    Default

    Quote Originally Posted by systemd rulez View Post
    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.

    Quote Originally Posted by systemd rulez View Post
    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.

    Best Regards

    FRIGN

  9. #9
    Join Date
    Jul 2009
    Posts
    221

    Default

    Quote Originally Posted by frign View Post
    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.
    Last edited by Cyborg16; 02-10-2013 at 06:38 AM.

  10. #10
    Join Date
    Oct 2012
    Location
    Cologne, Germany
    Posts
    308

    Default

    Quote Originally Posted by Cyborg16 View Post
    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).

    It definitely is an interesting topic.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •