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

101–110 of 132 posts

Re: Debian GNU/Hurd 2023

#101

Post by snvzz »

ori_b wrote: post #53
pshirshov wrote: post #47

Earlier quoted context omitted.

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

Which come with well documented peripherals? The CPU is boring -- x86 instruction encoding is a bit ugly, but it works. It's all the stuff hanging off them that make the difference, and as far as I'm aware, risc-v hasn't done anything interesting here. It hasn't even enhanced discoverability (eg, by hanging internal peripherals off a virtual PCI bus).

>Which come with well documented peripherals?

Refer to OS-A Platform.

RISC-V is going beyond anybody else, standardizing peripherals that are common and very much solved problems, but aren't standardized elsewhere.

Things such as GPIOs, watchdogs, uart, timers and what not.

Re: Debian GNU/Hurd 2023

#102

Post by snvzz »

arp242 wrote: post #63
Palomides wrote: post #50

Earlier quoted context omitted.

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.

>"just" runs Linux for many real-world applications, but with extra steps (via a VM).

You can run a modern web browser, with 3d hardware acceleration, on Genode itself.

It has Virtualbox support, which is super convenient for covering any functionality gaps, but you don't need that for the above.

Virtualbox simply enabled the developers to dogfood Genode years ago already, instead of today.

Re: Debian GNU/Hurd 2023

#103

Post by snvzz »

4gotunameagain wrote: post #46
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…

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.

Re: Debian GNU/Hurd 2023

#104

Post by snvzz »

msla wrote: post #79
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…

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

>continuing is dangerous to the integrity of the data on that system

Not really. IOMMUs have been a thing for a while. As for the GPU's hardware, it can be reset w/o affecting the rest of the system.

Even Linux and Windows can do that, it isn't a microkernel-exclusive thing. The latter just handle it better architecturally.

Re: Debian GNU/Hurd 2023

#105

Post by snvzz »

marcosdumay wrote: post #91
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.

Our current hardware doesn't support microkernels because there is no demand, and nobody is creating general purpose microkernels because all the important hardware doesn't support it. So, I'm not sure we will ever see that change. A proper microkernel isn't like Linux with a bunch of modules. It's something that can your game direct access to the GPU, while restricting access to a pseudo-root on your disk, and to an…

>Our current hardware doesn't support microkernels because there is no demand, and nobody is creating general purpose microkernels because all the important hardware doesn't support it. So, I'm not sure we will ever see that change.

RISC-V and seL4 cooperate closely, ensuring this does not apply anymore.

Re: Debian GNU/Hurd 2023

#106

Post by dale_glass »

snvzz wrote: post #104
msla wrote: post #79

Earlier quoted context omitted.

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

>continuing is dangerous to the integrity of the data on that system Not really. IOMMUs have been a thing for a while. As for the GPU's hardware, it can be reset w/o affecting the rest of the system. Even Linux and Windows can do that, it isn't a microkernel-exclusive thing. The latter just handle it better architecturally.

IOMMUs that can individually handle every device seem fairly rare still.

You can check with this script: https://pastebin.com/4t3WD5R1

On quite a lot of hardware you can't really isolate devices from each other properly.

Re: Debian GNU/Hurd 2023

#107

Post by sneed_chucker »

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.

It's just classic worse is better

Re: Debian GNU/Hurd 2023

#108

Post by kramerger »

senko wrote: post #100
kramerger wrote: post #98

Earlier quoted context omitted.

Do you have any actual (and professional) experience with sel4 and qnx? Because we have shipped products with those and boy I wish we had used Linux instead! Limited, expensive, developer unfriendly and surprisingly, quite unstable under certain loads.

Not professional experience (I wasn't paid to build stuff on it), no, just hobby use (of earlier version of L4, L4Ka::Pistachio, and QNX once they started opening up before selling to RIM). I believe you the developer experience was years behind Linux. That doesn't invalidate my claim that microkernels are interesting (and that these two are innovative), unless your pain was explicitly due to the microkernel nature o…

Interesting, yes. Not questioning that.

But just last month we have had some _serious_ issues with QNX (which is supposed to be the top dog ukernel in 2023). For example IPC performance takes a nosedive in certain (not very uncommon) situations, which is not good for an RTOS. Talked to other people working with QNX and they have had similar problems.

Linux in a similar product has worked far far better. I understand the hype around microkernels and all that, but there is a reason they are not used in anything but the most basic products.

Re: Debian GNU/Hurd 2023

#109

Post by [deleted] »

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…

[deleted]

Re: Debian GNU/Hurd 2023

#110

Post by arp242 »

snvzz wrote: post #102
arp242 wrote: post #63

Earlier quoted context omitted.

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.

>"just" runs Linux for many real-world applications, but with extra steps (via a VM). You can run a modern web browser, with 3d hardware acceleration, on Genode itself. It has Virtualbox support, which is super convenient for covering any functionality gaps, but you don't need that for the above. Virtualbox simply enabled the developers to dogfood Genode years ago already, instead of today.

Alright; neat. Last time I tried Genode it didn't run in QEMU for whatever reason so I have to go on the documentation.

So how does the real-world performance compare? That's what I'm interested in, because I keep hearing "performance is not an issue" and every time I ask for details, measurements, or something I never really get an answer.

Post reply on HN