Live data from Hacker News

Debian GNU/Hurd 2023

lists.gnu.org

111–120 of 132 posts

Re: Debian GNU/Hurd 2023

#111

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

Please email suggestions to hn@ycombinator.com as mods don't monitor comments for such actions.

I've done so in this case.

Re: Debian GNU/Hurd 2023

#112
post #62
post #42

Earlier quoted context omitted.

On a plane or missile I'd assume several computers, with the majority winning the decision

One of those computers just went out. Now how do you form your majority? Besides which, in such systems there's a governing system coordinating the election. What happens if your governing system goes out?

The question is increased resilience not perfection.

At some point, a military device / weapons system recognises that it's not operating to spec and either disables itself or diverts and destroys itself in a non-target region.

Keep in mind that for most weapons, not activating when not specified is far more useful than failing to activate where and when specified. See the case of several "broken arrow" nuclear weapons incidents in which failsafes prevented unintended detonation. In once case with only a single fail-safe preventing that detonation which would have been in a civilian populated region of the United States.

Re: Debian GNU/Hurd 2023

#113
post #40

Earlier quoted context omitted.

The debate is sort of obsolete really. * Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now. * The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore. * Hardware became far more complex. A modern video card or anything else is its own computer, with a very uncomfortable amount of state and ac…

> > The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore. You're making a lot of assumptions with regards to the operating environment. What about a probe being sent to Mars, the Moon or wherever? In fact let's just generalize to space-faring craft. That environment demands incredible resiliency and the ability to continue running e…

> any of the hardware comprising the system

You probably mean the other way around: the system comprising hardware.

Re: Debian GNU/Hurd 2023

#114
post #93

Earlier quoted context omitted.

Open source and software freedom are relevant, the FSF is not. In an era of insane surveillance, AI technology, mass corporate insanity, the FSF is still arguing about firmware blobs on hardware vs loaded in by the OS, or advocating for switching from .docx to .odt when the world has moved on from even having document files.

Good luck stating that in any modern office. I dare you. Most gen-zers have no clue about how the real world works outside your smartphones. Hint: not as you think. At all.

I work in a modern office in a multi national company. I haven't seen actual document files sent around for years. It's all links now which enable collaboration and always show the latest version.

Re: Debian GNU/Hurd 2023

#115

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

Please email suggestions to hn@ycombinator.com as mods don't monitor comments for such actions. I've done so in this case.

Thanks to you both! Changed to that from https://www.gnu.org/software/hurd/news/2023-06-11-debian_gnu....

Re: Debian GNU/Hurd 2023

#116
post #103

Earlier quoted context omitted.

Which is why in aerospace and safety critical systems, RTOSes are used and not fully fledged OSes. Also, redundant hardware is quite common (and mandatory by most standards), look up TMR, triple modular redundancy

>RTOSes are used and not fully fledged OSes. The idea that "RTOS" and "fully fledged OS" are incompatible with each other is outdated. seL4 advanced the state of the art with its formally-verified support for mixed criticality, years ago already.

There’s actually a real-time microkernel that millions of children use daily. It’s called the Nintendo Switch.

(But seriously, it’s a homegrown microkernel RTOS. Look up “Nintendo Switch System Software” if that sounds bizarre.)

Re: Debian GNU/Hurd 2023

#117
post #99

Earlier quoted context omitted.

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

> x86 only And limited x86_64 :)

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.

Re: Debian GNU/Hurd 2023

#118
post #64

Earlier quoted context omitted.

The debate is sort of obsolete really. * Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now. * The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore. * Hardware became far more complex. A modern video card or anything else is its own computer, with a very uncomfortable amount of state and ac…

Funnily enough windows actually manages your two points about videos cards pretty well. I've experienced full graphics driver crashes which were recovered from cleanly with only the process which triggered the crash as a casualty. But this needs more than just "slap it in a microkernel".

YMMV...video drivers (esp 3rd party) are one of the things that still mange take the whole machine out for me.

Re: Debian GNU/Hurd 2023

#119
post #78
post #74

Earlier quoted context omitted.

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?)

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

Exactly. I remember the alpha screenshots. Although not many seem to somehow

Re: Debian GNU/Hurd 2023

#120
post #78
post #74

Earlier quoted context omitted.

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?)

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

[deleted]
Post reply on HN