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

The Jury Is In: Monolithic OS Design Is Flawed [pdf]

ts.data61.csiro.au

Post reply on HN
Print view View original

81–90 of 199 posts

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#81

Post by badpun »

naasking wrote: post #76
nine_k wrote: post #53

I'd hazard to say that every design is "flawed" in some regards: there's no way to achieve all desirable qualities and none of undesirable qualities. For one, some desirable qualities contradict each other. So "${thing} is flawed" is not precise enough; an interesting statement would be "${thing} is not the best choice for ${conditions}". A monolithic OS is not the best choice for a high-reliability system on unrelia…

> For one, some desirable qualities contradict each other. Such as?

Security, performance, ease of use.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#82

Post by mrsteveman1 »

KMag wrote: post #45
andrewstuart2 wrote: post #13

Earlier quoted context omitted.

If parallel dimensions exist, then it's most certainly one of the closest dimensions to ours. If I'm sure of one thing, it's that as soon as we decided to build everything as Microkernels, we'd have the same squeaky wheels touting the massive benefits of Monotlithic OS design. We're hilariously cyclical in our preferences. "Think of all the runtime efficiencies of the shared memory, and how much easier it would be to…

The dirty secret is that we take a microkernel, rename the syscalls as "upcalls", throw in some hardware emulation code as a less efficient and uglier API for software that can't be bothered to be ported, and call it a hypervisor. Also, your phone's baseband processor almost certainly runs a microkernel, and likely so does your car.

Any recent iPhone/iPad, Apple Watch, the iMac Pro, and Macbook Pro touch bar, all contain Apple's "Secure Enclave", which runs the L4 microkernel:

> The Secure Enclave runs an Apple-customized version of the L4 microkernel. This microkernel is signed by Apple, verified as part of the iOS secure boot chain, and updated through a personalized software update process.

https://www.apple.com/business/docs/iOS_Security_Guide.pdf

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#83

Post by rleigh »

jonny_eh wrote: post #62
iforgotpassword wrote: post #32

Earlier quoted context omitted.

This is your opinion. I prefer using hardware with stable drivers, working reliably.

That's why I use a Mac. Seems like a good solution is to have the OS and HW manufacturer to be one and the same.

On the flip side, there are vastly fewer drivers. I can plug a random USB device into a Linux system and the chances are it just works. Same with Windows, though it might require the driver installing first. MacOS might not have any driver at all.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#84

Post by naasking »

badpun wrote: post #81
naasking wrote: post #76

Earlier quoted context omitted.

> For one, some desirable qualities contradict each other. Such as?

Security, performance, ease of use.

I don't see why any of those are mutually exclusive. Capability based operating systems provide least privilege security, experiments with capability-based UIs have shown they are quite intuitive and secure because they align user actions with explicit access grants, and they don't perform any worse than monolithic or microkernel operating systems.

The problems are really the flawed mental models people insist on bringing to these problems, despite decades of research showing these models are irreparably flawed.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#85

Post by pjmlp »

monocasa wrote: post #79
pjmlp wrote: post #55

Earlier quoted context omitted.

AMD Fusion Brazos APU, Radeon HD 6250

Certainly looks supported by /dev/radeon, just not /dev/amdgpu.

I didn't said it wasn't supported, I said:

> My Asus Netbook no longer gets all the acceleration options that it used to have pre 16.04.

Which holds true, because /dev/radeon no longer offers hardware video decoding support it once did unless I force enable it, and even then it usually leads to random X crashes when watching videos.

And then there is this,

"For one, AMD users can’t use applications that require OpenGL 4.3 or later without the fglrx/Catalyst drivers."

https://www.omgubuntu.co.uk/2016/03/ubuntu-drops-amd-catalys...

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#86

Post by yjftsjthsd-h »

steveklabnik wrote: post #47
snug wrote: post #43

Earlier quoted context omitted.

A reasonably secure os? I think that's one thing I don't want just reasonable

It's kinda self-deprecating humor; the (now ex) Tor developers I know use it. Nothing is ever 100% secure.

It's like the lesswrong folks; step one was accepting that there are too many flaws to fix everything, and then step two was to do our best anyways.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#87

Post by naasking »

monocasa wrote: post #31
pjmlp wrote: post #16

Earlier quoted context omitted.

Lack of performance on microkernels is a myth nowadays. QNX and many embedded OS, some of which driving high integrity software, are all microkernel based. Including the one most likely handling the real time communication of this mobile radio.

It's not a myth. Real time doesn't mean fast, it just means deterministic. And I'll throw out there that many times the the term microkernel in a lot of embedded OSs has been contorted by marketing speak into something unrecognizable. Basically if you have multiple threads in the kernel, structure the kernel code into modules (but perhaps don't even allow dynamic loading of modules), and can communicate through async…

> Real time doesn't mean fast, it just means deterministic.

Strictly speaking, "hard realtime" means strictly bounded latency. Full determinism is overkill.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#88

Post by btilly »

nasoieu wrote: post #73
iforgotpassword wrote: post #32

Earlier quoted context omitted.

This is your opinion. I prefer using hardware with stable drivers, working reliably.

That's not what I said. Would you rather have no hardware or hardware that BSODs once a month?

That's a false dilemma.

The actual choice is whether to have limited hardware choices or hardware that crashes regularly. Put that way, it is obvious to me that limited hardware is the right answer.

Why? Because what I care about is having a system that works well for me. Limited choices are fine as long as I can determine in advance whether the system that I'm considering will work. (I usually can.) So now my choice boils down to, "Do I want to be able to buy a reliable system, or be forced to put up with a buggy one?"

Put that way, who wants to be forced to put up with bugs?

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#89

Post by naasking »

monocasa wrote: post #78
JdeBP wrote: post #46

Earlier quoted context omitted.

vezzy-fnord had a lot to say on that subject. * https://blog.darknedgy.net/technology/2016/01/01/0/ ( https://news.ycombinator.com/item?id=10824382 ) * https://news.ycombinator.com/item?id=10301375

Wow, that's a gish gallop if I've every seen one. But hey, it's lunch and why not. 1) Microkernels are defined by their small size > In summary, the microkernel provides mechanisms corresponding to hardware features. It doesn’t provide services, just fundamental mechanisms. In particular, it does not duplicate OS services. This misunderstanding was one of the causes for the failure of first-generation microkernels. T…

> 3) Microkernels are a diversion, because a userland server failure will be just as catastrophic as a kernel failure anyway

Yeah, no. A kernel has access to all of the data on the machine. A compromised userland is much more strictly limited.

Certainly if a compromised disk driver exposes a lot more data, not so much if you compromise your video driver. Compromising either in a monolithic kernel provides the same level of access. Strong isolation boundaries strictly limit risk.

> 6) Hah, those stupid fucks are running Linux on top of their microkernel! What happened to microkernels being so great, fags?

Driver support is always an issue. I don't see the problem.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#90

Post by bitwize »

pjmlp wrote: post #59
KMag wrote: post #45

Earlier quoted context omitted.

The dirty secret is that we take a microkernel, rename the syscalls as "upcalls", throw in some hardware emulation code as a less efficient and uglier API for software that can't be bothered to be ported, and call it a hypervisor. Also, your phone's baseband processor almost certainly runs a microkernel, and likely so does your car.

And what many seem to be unaware, is that project Treble made Android Linux into a microkernel where drivers use Android IPC to talk with the kernel. https://source.android.com/devices/architecture/kernel/modul... https://source.android.com/devices/architecture/hidl/ So everyone running Android Oreo or newer on their phones, not only has a microkernel on their basebase radio, they also have a Linux tamed into a micro…

So, MkLinux 2?
Post reply on HN