Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian GNU/Hurd 2023

lists.gnu.org

Post reply on HN
Print view View original

41–50 of 132 posts

Re: Debian GNU/Hurd 2023

#41

Post by arp242 »

josefx wrote: post #39
arp242 wrote: post #33

Earlier quoted context omitted.

> switching from .docx to .odt Also, isn't the whole .docx / OOXML thing just a published standard? The process may not be as "open" as one might like (i.e. not everyone can contribute) but that seems like a detail. IIRC there was a lot of FUD simply because it came from Microsoft. That said: I don't think it's entirely irrelevant; e.g. my country's parliament publishes a lot of their files in .docx. But I can read t…

> IIRC there was a lot of FUD simply because it came from Microsoft. It was annoying because we already had odt as open format and OOXML was reported to be more of a text dump of what Microsoft did in binary than a standard meant for interoperability. > But I can read them on my Linux machine and you don't need a byte of non-free software for it, and I had a lot more trouble with the .doc files they published 20 year…

> text dump of what Microsoft did in binary than a standard meant for interoperability.

Isn't it all XML based?

> OpenOffice was already better at reading old doc files than Microsoft Word was well before OOXML was a thing.

It's been a long time, but that was certainly not my experience from what I recall; I had a lot of trouble with this. And writing files and then expecting Word users to be able to read them well was another source of problems.

And look, maybe ODT would have been better; but that ship has sailed, and OOXML seems free for all intents and purposes, even though perhaps it's not 100% ideal. This is just not something that's all that important today.

Re: Debian GNU/Hurd 2023

#42

Post by iso1631 »

taylodl wrote: post #40
dale_glass wrote: post #8

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…

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

Re: Debian GNU/Hurd 2023

#44

Post by lucozade »

taylodl wrote: post #40
dale_glass wrote: post #8

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…

You are describing environments where it is very common to have hardware redundancy. I mean, sure they may have hardening for each component to reduce the likelihood of losing one of them. But hardware redundancy is a standard tool in safety critical systems.

Re: Debian GNU/Hurd 2023

#45

Post by _joel »

wwtrv wrote: post #36
jlpcsl wrote: post #16

Earlier quoted context omitted.

I'd be much more interested into RISC-V support.

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.

Quite a few RISC-V boards on the market now, no?

Re: Debian GNU/Hurd 2023

#46

Post by 4gotunameagain »

taylodl wrote: post #40
dale_glass wrote: post #8

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…

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

Re: Debian GNU/Hurd 2023

#47

Post by pshirshov »

wwtrv wrote: post #36
jlpcsl wrote: post #16

Earlier quoted context omitted.

I'd be much more interested into RISC-V support.

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.

RISC-V SBCs are on the market in abundance and they are affordable.

Re: Debian GNU/Hurd 2023

#49

Post by dale_glass »

senko wrote: post #34
dale_glass wrote: post #8

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 debate is sort of obsolete really. Microkernels are not obsolete (see seL4), but HURD unfortunately is. > Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now. FUSE is far cray (capability, security and performance-wise) from real microkernels. Linux is a monolithic kernel and unashamedly so. > The modern approach to High Availability is to have redundant hardware. A sin…

> Microkernels are not obsolete (see seL4), but HURD unfortunately is.

Why HURD specifically?

But I didn't mean microkernels, but the debate. Basically my view is that nothing stays pure. If microkernels have significant upsides a monolithic kernel like Linux doesn't have, then the logical outcome is that Linux copies the required feature like eg, FUSE.

Yeah, it's not a true microkernel, but who cares? It can do the cool thing. Nobody cares about purity. Computing is about getting stuff done.

> Also, to give just one counter-example, I don't think many people have redundant mobile phones in case one of them crashes.

A modern cell phone has a tendency to forget stuff anyway. I mean Android will just randomly stop background programs when it pleases, so every app has to deal with that possibility. So the phone rebooting has little effect, other than taking time.

> This was more-or less true from the moment discreete GPUs started shoping up. Modern PCs have dozens of independent processors (some of them running their own opertaing systems)! If anything, that's more reason for microkernels.

How so? I have two overall points here:

1. With hardware being complex and stateful, rebooting the driver may just not help. If something inside the video card is locked up, no amount of rebooting the driver is going to fix that.

2. There are complex webs of dependency, which often aren't easy to resolve in a fault tolerant manner. Most stuff will probably just crash anyway even if recovery is theoretically possible. Recovery paths are very rarely exercised.

> Yeah, I agree Linux will never changi its system architecture, but that doesn't mean thinking, researching and building other operating systems using different architectures is obsolete.

No, I mean it's not worth it to the average person to switch to a different OS for the sake of a benefit that might materialize extremely rarely. I'm not itching for a better OS which can survive a driver crash because the time when that happens for me is essentially never.

I think in the last 3 years I might have seen one kernel panic. Switching to a very different OS for the sake of having a system that can survive such a freak occurrence would be wasting my time. I'd spend far more time learning HURD than I'd gain in productivity.

> Ah yes, ye olde "just don't write bugs!" argument :-)

This, but unironically. If you're concerned about reliability, then the better approach is to avoid failures to start with. Rather than having a system that can tolerate something overflowing a buffer and crashing, how about a system that doesn't allow you to even compile something that does that?

Huge advancements have been made in creating languages that lack many of the stupid pitfalls of C.

Post reply on HN