11 ms·

Debian GNU/Hurd 2023

197 points by jrepinc 3y ago

bluenose69 3y ago
Having been quite interested in GNU/Hurd a long time ago (the years have become decades, I fear) and having lost track of the project, I wonder whether somebody can comment on where GNU/Hurd is being used nowadays.
- ant6n 3y ago
  Obligatory xkcd: https://xkcd.com/1508/ https://xkcd.com/1508/
  - jbverschoor 3y ago
    The pre-iOS Android was a blackberry clone
    - b112 3y ago
      Did you just reply with random OS names? Android isn't iOS, the first release version looked and was nothing like Blackberry devices. (If you're making sense, clarity might help for me/others?)
      - orev 3y ago
        Google initially was working on Android as more of a Blackberry clone, and then when Apple announced iOS they realized that a full screen touch system was the future. So they scrapped the Blackberry clone OS and scrambled to get something more like iOS, which is what you’re now familiar with as the Android OS. This story has been floating around in various tech areas. Here’s a podcast about it: https://corecursive.com/android-with-chet-haase/ https://corecursive.com/android-with-chet-haase/
        jbverschoor 3y ago
        Exactly. I remember the alpha screenshots. Although not many seem to somehow
        deleted 3y ago
        [deleted]
      - chem83 3y ago
        OP is just saying that before iPhone/iOS was announced in 2007, there was an effort to build Android, but it was something that resembled Blackberries. After the iPhone was announced, there was a big project reset, which shifted Android to what eventually got launched in 2008. https://www.theatlantic.com/technology/archive/2013/12/the-day-google-had-to-start-over-on-android/282479/ https://www.theatlantic.com/technology/archive/2013/12/the-d...
        ant6n 3y ago
        And in the xkcd household Android was used starting in 2009, and some years later iOS. Seems consistent with history.
- inawarminister 3y ago
  I just read on info guix that they have a setting to use GNU/Hurd as kernel, maybe that could be fun virtualized.
- duskwuff 3y ago
  > I wonder whether somebody can comment on where GNU/Hurd is being used nowadays. Simply put: nowhere. It's an experimental kernel with limited hardware support (x86 only, very few device drivers) and a bunch of critical features missing (e.g. no multiprocessor support, no power management).
  - Zambyte 3y ago
    > x86 only And limited x86_64 :)
    - duskwuff 3y ago
      I'm not sure how far that support even goes. There's one page on the wiki which claims that "A 64-bit GNU/Hurd is also coming soon", but all of the downloadable images are 32-bit only, and Git history suggests that it's still a work in progress.
      - Zambyte 3y ago
        I don't think this release technically includes the 64 bit support, but there is an image here: https://lists.gnu.org/archive/html/bug-hurd/2023-05/msg00484.html https://lists.gnu.org/archive/html/bug-hurd/2023-05/msg00484... that can supposedly get you a minimal Debian 64 bit system running on Hurd after some configuration. Also I just found that they have a directory for packages here: http://ftp.ports.debian.org/debian-ports/pool-hurd-amd64/ http://ftp.ports.debian.org/debian-ports/pool-hurd-amd64/ but none have been added yet.
anthk 3y ago
Hurd should be able to load linux-libre drivers in the userland for a compatibility boost.
- pshirshov 3y ago
  If you only knew how bad things really are. That's, probably, not possible.
  - sandos 3y ago
    I assume that would require such an insane amount of "framework" around it as to be practically impossible, not literally impossible?
    - pshirshov 3y ago
      From my understanding - yes, the kernel APIs never meant to be portable.
mo_42 3y ago
This micro kernel vs. monolithic kernel still puzzles me. From a computer science perspective micro kernels make so much sense. But when I compiled the Linux kernel, I was always baking everything into one file. It seemed much more practical to do so.
- dijit 3y ago
  With Linux it makes sense to go with the one file approach because it's a monolith. The difference would be if there was a seperate "kernel" that handled disk devices. Imagine being able to upgrade it without swapping out anything to do with process control. I mean; we already do this with userland programs of course.. but I think we're not used to this in kernel land conceptually. The closest we have is kernel modules which are simply not in the same arena.. like comparing function calls to RESTFul RPC; they just operate too differently to compare mentally.
  - samus 3y ago
    We have something like this already on mobile phones. NFC chips and the radio are pretty much independent systems and the host system has to use message passing to talk to them. The OS as a micro kernel doesn't really yield benefits in this case. Graphics cards and other accelerators are trickier since they can also access main memory. Therefore, restarting its driver might not resolve the problem, and the whole system has to be rebooted anyways. Anyways, the system might not be that usable anymore if a critical driver keeps crashing and restarting...
- nequo 3y ago
  Linux is not a microkernel, whether you compile it with modules or as one file. In a microkernel, the various modules run as separate processes rather than as part of the kernel. For example, if your network driver crashes, your kernel keeps running. Whereas in a monolithic kernel, a driver crashing crashes the whole kernel.
  - arp242 3y ago
    It's not quite that black/white, because drivers in Linux can and do crash without bringing down the whole system. I don't really know the technical details on how this works exactly, but I've seen drivers crash while the system remained running.
_joel 3y ago
No arm or x86_64 love?
- rascul 3y ago
  I guess 64bit needs some more work still: > * APIC, SMP, and 64bit support was improved a lot: they now do boot a complete Debian system, but some bugs remain to be fixed. https://lists.gnu.org/archive/html/bug-hurd/2023-06/msg00038.html https://lists.gnu.org/archive/html/bug-hurd/2023-06/msg00038...
- jlpcsl 3y ago
  I'd be much more interested into RISC-V support.
  - wwtrv 3y ago
    Most people are generally more interested in functioning software running on existing hardware. Focusing on that might actually make Hurd actually relevant at some point in the future.
    - _joel 3y ago
      Quite a few RISC-V boards on the market now, no?
      - wwtrv 3y ago
        Maybe? I don't think there are many practical uses cases for it though.. I'l admit I'm not really sure what market segment Hurd is targeting. Presumably the goal is to replace in the GNU stack Linux at some point? If so only supporting niche/hobbyist CPUs (unless we're talking about really low power embedded applications) seems not like the best approach
    - pshirshov 3y ago
      RISC-V SBCs are on the market in abundance and they are affordable.
lincpa 3y ago
[dead]
Gigachad 3y ago
[flagged]
- petepete 3y ago
  Confusingly if you follow QEMU images there's a link to the LiveCDs: https://www.gnu.org/software/hurd/hurd/running/live_cd.html https://www.gnu.org/software/hurd/hurd/running/live_cd.html I love that they're referred to as CDs, I built my computer a couple of weeks ago and am running one with an optical drive for the first time in more than a decade. Might burn one for old times' sake.
- rascul 3y ago
  > I looked around and I couldn't find a way to even download the ISO to try it out. On the right side, under "Hurd", the "Running" link can get you there.
- cies 3y ago
  > really shows how irrelevant the GNU foundation (and even the FSF) have become I've seen several posts here in the last month about proprietary software being used to basically exploit the users: steeply increase fees, hold files ransom (upgrade for money or loose access to files), spying on users. My conclusion is very different from yours: GNU Foundation and FSF are very relevant! They seem to lack in the PR dept, which makes them look (by simply looking at the website) outdated and hence "possibly irrelevant". Looks can be deceiving though.
  - dale_glass 3y ago
    The cause they fight for is very relevant. Now whether the organizations are actually doing a good job on that front is more questionable.
  - arp242 3y ago
    We have Linux though, and mountains of non-GNU projects. It's not really about "proprietary vs. free software", it whether the FSF and GNU are still a driving force for Free Software. And to me this seems ... not really? They're still trying to create their anno-1985 Unix replacement. That's great and all, but also not really driving anything forward.
gattilorenz 3y ago
@dang this is maybe a better url, since it provides more info and download links: https://lists.gnu.org/archive/html/bug-hurd/2023-06/msg00038.html https://lists.gnu.org/archive/html/bug-hurd/2023-06/msg00038...
- dredmorbius 3y ago
  Please email suggestions to hn@ycombinator.com as mods don't monitor comments for such actions. I've done so in this case.
  - dang 3y ago
    Thanks to you both! Changed to that from https://www.gnu.org/software/hurd/news/2023-06-11-debian_gnu_hurd_2023.html https://www.gnu.org/software/hurd/news/2023-06-11-debian_gnu....
29athrowaway 3y ago
The Hurd website is a mess. Where is the code?
- yrro 3y ago
  Contributing -> Source Repositories lands you at https://www.gnu.org/software/hurd/source_repositories.html https://www.gnu.org/software/hurd/source_repositories.html
  - 29athrowaway 3y ago
    http://git.savannah.gnu.org/cgit/hurd/hurd.git/ http://git.savannah.gnu.org/cgit/hurd/hurd.git/ Here it is
xyproto 3y ago
It's the anti-Alpine, in terms of GNU-ness.

197 points by jrepinc 3y ago

Having been quite interested in GNU/Hurd a long time ago (the years have become decades, I fear) and having lost track of the project, I wonder whether somebody can comment on where GNU/Hurd is being used nowadays.

ant6n 3y ago
Obligatory xkcd: https://xkcd.com/1508/ https://xkcd.com/1508/
- jbverschoor 3y ago
  The pre-iOS Android was a blackberry clone
  - b112 3y ago
    Did you just reply with random OS names? Android isn't iOS, the first release version looked and was nothing like Blackberry devices. (If you're making sense, clarity might help for me/others?)
    - orev 3y ago
      Google initially was working on Android as more of a Blackberry clone, and then when Apple announced iOS they realized that a full screen touch system was the future. So they scrapped the Blackberry clone OS and scrambled to get something more like iOS, which is what you’re now familiar with as the Android OS. This story has been floating around in various tech areas. Here’s a podcast about it: https://corecursive.com/android-with-chet-haase/ https://corecursive.com/android-with-chet-haase/
      - jbverschoor 3y ago
        Exactly. I remember the alpha screenshots. Although not many seem to somehow
      - deleted 3y ago
        [deleted]
    - chem83 3y ago
      OP is just saying that before iPhone/iOS was announced in 2007, there was an effort to build Android, but it was something that resembled Blackberries. After the iPhone was announced, there was a big project reset, which shifted Android to what eventually got launched in 2008. https://www.theatlantic.com/technology/archive/2013/12/the-day-google-had-to-start-over-on-android/282479/ https://www.theatlantic.com/technology/archive/2013/12/the-d...
      - ant6n 3y ago
        And in the xkcd household Android was used starting in 2009, and some years later iOS. Seems consistent with history.
inawarminister 3y ago
I just read on info guix that they have a setting to use GNU/Hurd as kernel, maybe that could be fun virtualized.
duskwuff 3y ago
> I wonder whether somebody can comment on where GNU/Hurd is being used nowadays. Simply put: nowhere. It's an experimental kernel with limited hardware support (x86 only, very few device drivers) and a bunch of critical features missing (e.g. no multiprocessor support, no power management).
- Zambyte 3y ago
  > x86 only And limited x86_64 :)
  - duskwuff 3y ago
    I'm not sure how far that support even goes. There's one page on the wiki which claims that "A 64-bit GNU/Hurd is also coming soon", but all of the downloadable images are 32-bit only, and Git history suggests that it's still a work in progress.
    - Zambyte 3y ago
      I don't think this release technically includes the 64 bit support, but there is an image here: https://lists.gnu.org/archive/html/bug-hurd/2023-05/msg00484.html https://lists.gnu.org/archive/html/bug-hurd/2023-05/msg00484... that can supposedly get you a minimal Debian 64 bit system running on Hurd after some configuration. Also I just found that they have a directory for packages here: http://ftp.ports.debian.org/debian-ports/pool-hurd-amd64/ http://ftp.ports.debian.org/debian-ports/pool-hurd-amd64/ but none have been added yet.

anthk 3y ago

Hurd should be able to load linux-libre drivers in the userland for a compatibility boost.

pshirshov 3y ago
If you only knew how bad things really are. That's, probably, not possible.
- sandos 3y ago
  I assume that would require such an insane amount of "framework" around it as to be practically impossible, not literally impossible?
  - pshirshov 3y ago
    From my understanding - yes, the kernel APIs never meant to be portable.

mo_42 3y ago

This micro kernel vs. monolithic kernel still puzzles me. From a computer science perspective micro kernels make so much sense. But when I compiled the Linux kernel, I was always baking everything into one file. It seemed much more practical to do so.

dijit 3y ago
With Linux it makes sense to go with the one file approach because it's a monolith. The difference would be if there was a seperate "kernel" that handled disk devices. Imagine being able to upgrade it without swapping out anything to do with process control. I mean; we already do this with userland programs of course.. but I think we're not used to this in kernel land conceptually. The closest we have is kernel modules which are simply not in the same arena.. like comparing function calls to RESTFul RPC; they just operate too differently to compare mentally.
- samus 3y ago
  We have something like this already on mobile phones. NFC chips and the radio are pretty much independent systems and the host system has to use message passing to talk to them. The OS as a micro kernel doesn't really yield benefits in this case. Graphics cards and other accelerators are trickier since they can also access main memory. Therefore, restarting its driver might not resolve the problem, and the whole system has to be rebooted anyways. Anyways, the system might not be that usable anymore if a critical driver keeps crashing and restarting...
nequo 3y ago
Linux is not a microkernel, whether you compile it with modules or as one file. In a microkernel, the various modules run as separate processes rather than as part of the kernel. For example, if your network driver crashes, your kernel keeps running. Whereas in a monolithic kernel, a driver crashing crashes the whole kernel.
- arp242 3y ago
  It's not quite that black/white, because drivers in Linux can and do crash without bringing down the whole system. I don't really know the technical details on how this works exactly, but I've seen drivers crash while the system remained running.

_joel 3y ago

No arm or x86_64 love?

rascul 3y ago
I guess 64bit needs some more work still: > * APIC, SMP, and 64bit support was improved a lot: they now do boot a complete Debian system, but some bugs remain to be fixed. https://lists.gnu.org/archive/html/bug-hurd/2023-06/msg00038.html https://lists.gnu.org/archive/html/bug-hurd/2023-06/msg00038...
jlpcsl 3y ago
I'd be much more interested into RISC-V support.
- wwtrv 3y ago
  Most people are generally more interested in functioning software running on existing hardware. Focusing on that might actually make Hurd actually relevant at some point in the future.
  - _joel 3y ago
    Quite a few RISC-V boards on the market now, no?
    - wwtrv 3y ago
      Maybe? I don't think there are many practical uses cases for it though.. I'l admit I'm not really sure what market segment Hurd is targeting. Presumably the goal is to replace in the GNU stack Linux at some point? If so only supporting niche/hobbyist CPUs (unless we're talking about really low power embedded applications) seems not like the best approach
  - pshirshov 3y ago
    RISC-V SBCs are on the market in abundance and they are affordable.

lincpa 3y ago

[dead]

Gigachad 3y ago

[flagged]

petepete 3y ago
Confusingly if you follow QEMU images there's a link to the LiveCDs: https://www.gnu.org/software/hurd/hurd/running/live_cd.html https://www.gnu.org/software/hurd/hurd/running/live_cd.html I love that they're referred to as CDs, I built my computer a couple of weeks ago and am running one with an optical drive for the first time in more than a decade. Might burn one for old times' sake.
rascul 3y ago
> I looked around and I couldn't find a way to even download the ISO to try it out. On the right side, under "Hurd", the "Running" link can get you there.
cies 3y ago
> really shows how irrelevant the GNU foundation (and even the FSF) have become I've seen several posts here in the last month about proprietary software being used to basically exploit the users: steeply increase fees, hold files ransom (upgrade for money or loose access to files), spying on users. My conclusion is very different from yours: GNU Foundation and FSF are very relevant! They seem to lack in the PR dept, which makes them look (by simply looking at the website) outdated and hence "possibly irrelevant". Looks can be deceiving though.
- dale_glass 3y ago
  The cause they fight for is very relevant. Now whether the organizations are actually doing a good job on that front is more questionable.
- arp242 3y ago
  We have Linux though, and mountains of non-GNU projects. It's not really about "proprietary vs. free software", it whether the FSF and GNU are still a driving force for Free Software. And to me this seems ... not really? They're still trying to create their anno-1985 Unix replacement. That's great and all, but also not really driving anything forward.

gattilorenz 3y ago

@dang this is maybe a better url, since it provides more info and download links: https://lists.gnu.org/archive/html/bug-hurd/2023-06/msg00038.html https://lists.gnu.org/archive/html/bug-hurd/2023-06/msg00038...

dredmorbius 3y ago
Please email suggestions to hn@ycombinator.com as mods don't monitor comments for such actions. I've done so in this case.
- dang 3y ago
  Thanks to you both! Changed to that from https://www.gnu.org/software/hurd/news/2023-06-11-debian_gnu_hurd_2023.html https://www.gnu.org/software/hurd/news/2023-06-11-debian_gnu....

29athrowaway 3y ago

The Hurd website is a mess. Where is the code?

yrro 3y ago
Contributing -> Source Repositories lands you at https://www.gnu.org/software/hurd/source_repositories.html https://www.gnu.org/software/hurd/source_repositories.html
- 29athrowaway 3y ago
  http://git.savannah.gnu.org/cgit/hurd/hurd.git/ http://git.savannah.gnu.org/cgit/hurd/hurd.git/ Here it is

xyproto 3y ago

It's the anti-Alpine, in terms of GNU-ness.