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

71–80 of 132 posts

Re: Debian GNU/Hurd 2023

#71

Post by goodpoint »

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…

> The debate is sort of obsolete really.

Says who?

> * Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now.

That has very little to do with real microkernels.

> * The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore.

Not at all. The "modern" approach you are describing is many decades old and single systems are still extremely common.

Re: Debian GNU/Hurd 2023

#72

Post by mtlmtlmtlmtl »

Nextgrid wrote: post #55
unmole wrote: post #29

Earlier quoted context omitted.

HURD is does not have a stable release. It's unlikely to even boot on real hardware, which is why they have QEMU images. I don't know what screenshots of a kernel would look like. Generalising this to GNU and the FSF is daft. Claiming this somehow shows their irrelevance is even more so.

> Generalising this to GNU and the FSF is daft I disagree - this isn't some isolated example, this pattern is seen across many other GUN, FSF and other free as in freedom projects. A lot of free as in freedom projects are completely out of touch with the modern world and waste their (already thin) resources on irrelevant, half-baked projects furthering some ideology rather than practical projects that would bring fre…

You're using "free as in freedom" very deliberately here...

Probably to pretend you're not also talking about open source. But you are, because there's essentially no distinction in most cases. But hopefully you don't mean to say that most open source software is practically useless, because that would be pretty silly, right?

So what exactly are you saying? That there are very niche open source projects around? Sure, but that's fine. There's also open source code that runs on almost literally everything though, some of it even from the GNU project. There's also proprietary software that is incredibly niche and only a small handful of people would know what to do with it or have even heard of. So what?

Name some examples, I genuinely don't understand what you're trying to say.

Re: Debian GNU/Hurd 2023

#73

Post by samus »

dijit wrote: post #6
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.

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

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

Re: Debian GNU/Hurd 2023

#74

Post by b112 »

jbverschoor wrote: post #51
ant6n wrote: post #3

Earlier quoted context omitted.

Obligatory xkcd: https://xkcd.com/1508/

The pre-iOS Android was a blackberry clone

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

Re: Debian GNU/Hurd 2023

#75

Post by unmole »

Nextgrid wrote: post #55
unmole wrote: post #29

Earlier quoted context omitted.

HURD is does not have a stable release. It's unlikely to even boot on real hardware, which is why they have QEMU images. I don't know what screenshots of a kernel would look like. Generalising this to GNU and the FSF is daft. Claiming this somehow shows their irrelevance is even more so.

> Generalising this to GNU and the FSF is daft I disagree - this isn't some isolated example, this pattern is seen across many other GUN, FSF and other free as in freedom projects. A lot of free as in freedom projects are completely out of touch with the modern world and waste their (already thin) resources on irrelevant, half-baked projects furthering some ideology rather than practical projects that would bring fre…

The bulk of the work done for such free as in freedom projects is by unpaid volunteers. The only resources being expended are their own time and effort. Even if the work doesn't cater to the tastes of the general populace, there is nothing wasted. Unless you think someone making art for themselves or baking cookies for their friends is also wasting resources.

Re: Debian GNU/Hurd 2023

#76

Post by vanviegen »

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 aren't written like that. In a MK architecture, your system survives video card driver dying by restarting it and taking over serving its clients (in this case, the compositor). Of course, Linux doesn't work like that, but we've already established Linux is not a microkernel.

That does require the compositor (and its applications) to help the new driver instance to re-establish its full state (which will typically consist of GBs of VRAM, among other things).

Re: Debian GNU/Hurd 2023

#77

Post by dale_glass »

goodpoint wrote: post #71
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. Says who? > * Linux has microkernel-like functionalities like FUSE. You can do filesystems in userspace now. That has very little to do with real microkernels. > * The modern approach to High Availability is to have redundant hardware. A single machine being fault tolerant isn't that important anymore. Not at all. The "modern" approach you are describing is many decades old an…

> Says who?

I'm writing my comment, so me, based on observations over time.

> That has very little to do with real microkernels.

It doesn't matter if it's "real" or not. My point was that any selling point a microkernel can come up with can be grafted into a monolithic one.

So one of the usual selling points of a microkernel is that you can run a filesystem in userspace and eg, can allow an user to mount a network drive. Well, no need to switch kernels just for that since they added FUSE to Linux.

As an user I don't care if it's pure, I care that the job gets done.

> Not at all. The "modern" approach you are describing is many decades old and single systems are still extremely common.

Modern compared to the very old idea of the microkernel, I mean. I can see that the idea had a lot of appeal back in the era of rare, room sized computers. Keeping a single machine going is far less important in modern times, where most serious uses try their best to treat any single machine as disposable.

Re: Debian GNU/Hurd 2023

#78

Post by orev »

b112 wrote: post #74
jbverschoor wrote: post #51

Earlier quoted context omitted.

The pre-iOS Android was a blackberry clone

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.com/android-with-chet-haase/

Re: Debian GNU/Hurd 2023

#79

Post by msla »

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…

> In a MK architecture, your system survives video card driver dying by restarting it and taking over serving its clients (in this case, the compositor).

If your video card driver died, something is deeply wrong with your system, hardware or software, and blindly (literally) continuing is dangerous to the integrity of the data on that system. Things don't crash for no reason, this isn't a canned test where we're sure that only the one component is being fuzzed, this is reality.

Re: Debian GNU/Hurd 2023

#80

Post by chem83 »

b112 wrote: post #74
jbverschoor wrote: post #51

Earlier quoted context omitted.

The pre-iOS Android was a blackberry clone

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

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

Post reply on HN