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

61–70 of 132 posts

Re: Debian GNU/Hurd 2023

#61

Post by Nextgrid »

cies wrote: post #19
Gigachad wrote: post #13

[flagged]

> 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,…

The way I see it:

* Proprietary software allows me to get things done, sometimes with some user-hostility baked in, but in general, no software explicitly forces me to use it and I can weigh the pros of doing the thing vs the cons of user-hostility and decide whether to use it.

* Free software is more interested to promote some impractical ideology, at the expense of getting things done. More effort is spent on ideology rather than useful (and usable, in terms of UX) functionality, which is why proprietary (and even extremely user-hostile) software thrives.

Keep in mind that recent deviances of proprietary software with regards to privacy are more due to the effective legalization of spyware and fraud (when committed by a business as opposed to an individual) as well as an adtech/marketing and VC bubble rather than proprietary software itself.

We've had commercial, paid, proprietary software back in the day that was respectful of the user and where the incentives were actually aligned - the software was as good as it could be in order to convince the user to pay for it and recommend it to others. You get the occasional annoying DRM but I'm happy to take that in exchange for a healthy ecosystem of usable software.

Proprietary software doesn't have to be malicious, and its maliciousness can be fixed with legislation and regulation (enforcing the existing ones would be a good start) without getting rid of the concept of proprietary software itself.

Free software doesn't just have a PR problem - there are many verticals where a free software implementation either doesn't exist, can't get off the ground (because more resources are spent on bikeshedding and furthering ideology rather than making software) or is perpetually half-baked and its backers are deluded in thinking it's a viable alternative to the proprietary competition. I'd argue they wouldn't actually need PR if they had good software/hardware, it would sell itself (if anything, merely by being free as in money compared to paid, proprietary competition).

Re: Debian GNU/Hurd 2023

#62

Post by taylodl »

iso1631 wrote: post #42
taylodl wrote: post #40

Earlier quoted context omitted.

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

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?

Re: Debian GNU/Hurd 2023

#63

Post by arp242 »

Palomides wrote: post #50
arp242 wrote: post #35

Earlier quoted context omitted.

Can I run Firefox or Redis on L4? What's the performance of that compared to Linux?

check out genode

As I understand it Genode "just" runs Linux for many real-world applications, but with extra steps (via a VM). Either way, that doesn't really answer the question what real-world performance looks like.

Re: Debian GNU/Hurd 2023

#64

Post by rcxdude »

dale_glass wrote: post #8
mo_42 wrote: post #5

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.

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

Re: Debian GNU/Hurd 2023

#65

Post by lucideer »

dale_glass wrote: post #8
mo_42 wrote: post #5

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.

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…

> * Hardware became far more complex. A modern video card or anything else is its own computer, with a very uncomfortable amount of state and access to the host. If your video card driver does something wrong and crashes it's by no means a given that the situation is recoverable by rebooting the driver -- the video card itself may be left in some weird state.

The rest of your points make sense but I don't understand fully how this is an argument for monoliths? Isn't recovery from an unknown state an equally hard problem in both cases?

Re: Debian GNU/Hurd 2023

#66

Post by Volundr »

taylodl wrote: post #62
iso1631 wrote: 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?

Your governing system isn't a single system, it's multiple using a suitable algorithm to establish quorum. This is a well studied problem in distributed systems.

Re: Debian GNU/Hurd 2023

#67

Post by krger »

lucideer wrote: post #65
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…

> * Hardware became far more complex. A modern video card or anything else is its own computer, with a very uncomfortable amount of state and access to the host. If your video card driver does something wrong and crashes it's by no means a given that the situation is recoverable by rebooting the driver -- the video card itself may be left in some weird state. The rest of your points make sense but I don't understand…

>The rest of your points make sense but I don't understand fully how this is an argument for monoliths? Isn't recovery from an unknown state an equally hard problem in both cases?

He's not saying that monolithic kernels make recovery easier in this case. He's saying that microkernels don't make these failures easier to recover from in practice, so you may as well take the performance gains that you will get from the monolithic kernel instead of giving up those gains for theoretical recoverability advantages that you won't actually usually see in practice.

Re: Debian GNU/Hurd 2023

#68

Post by iso1631 »

taylodl wrote: post #62
iso1631 wrote: 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?

So one computer is out and the other 2 are giving different answers to the same question?

Re: Debian GNU/Hurd 2023

#69

Post by martin8412 »

dale_glass wrote: post #49
senko wrote: post #34

Earlier quoted context omitted.

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

Hurd is never going to be more than at best a research project, more likely a hobby project. All semi-modern hardware requires proprietary blobs to function properly.

It would be great if all firmware and drivers was open source, but that's not going to happen anytime soon.

FSF is largely a joke in the way they certify RYF hardware. Proprietary blobs are all good as long as they're loaded from a separate flash that can't be updated by the main CPU, but if you load exactly the same firmware from the filesystem it's not okay.

Re: Debian GNU/Hurd 2023

#70

Post by knome »

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…

>Weapons systems are another environment you'd prefer to have resiliency. You'd hate to lose control of a missile while in mid-flight.

https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

Post reply on HN