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

161–170 of 199 posts

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

#161

Post by Dylan16807 »

nasoieu wrote: post #27
btilly wrote: post #24

Earlier quoted context omitted.

This is your opinion. The opinion of informed observers who are actually doing the work is the opposite - OEMs produce buggy, incomplete drivers and don't care to fix the bugs. In fact, given the choice, they don't want to allow anyone else to dig into their drivers because doing so can only lead to embarrassment. Plus exploits that are discovered are likely to be cross-platform exploits. Any operating system that wi…

It's better to have buggy, incomplete drivers than no drivers at all.

If you control the desktops and take strong measures to stop horribly-buggy drivers from working, 95% of manufacturers will fix the drivers because they want to sell the product.

In that tradeoff, I'll easily pick the marginally smaller market with vastly better drivers.

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

#162

Post by snaky »

monocasa wrote: post #98
dkersten wrote: post #95

Earlier quoted context omitted.

> It's not a myth. As was posted elsewhere, they seem to be fast enough for games on the Nintendo Switch: https://news.ycombinator.com/item?id=17768537

I mean, on the switch, the filesystem is incredibly slow, and the GPU drivers use a ported version of Linux's Nvidia DRM drivers that runs most of the driver in the same process as the user code. So the only place where they've really optimized for performance between subsystems, they took a more exokernel like model.

Quote from Linus, 2003

>>

>>Why do the file systems have to be so tightly integrated in the "ring0" core? This is one subsystem that screams for standard callouts and "ring1" level.

>>

> Because only naive people think you can do it efficiently any other way.

> Face it, microkernels and message passing on that level died a long time ago, and that's a GOOD THING.

> Most of the serious processing happens outside the filesystem (ie the VFS layer keeps track of name caches, stat caches, content caches etc), and all of those data structures are totally filesystem-independent (in a well-designed system) and are used heavily by things like memory management. Think mmap - the content caches are exposed to user space etc. But that's not the only thing - the name cache is used extensively to allow people to see where their data comes from (think "pwd", but on steroids), and none of this is anything that the low-level filesystem should ever care about.

> At the same time, all those (ring0 - core) filesystem data structures HAVE TO BE MADE AVAILABLE to the low-level filesystem for any kind of efficient processing. If you think we're going to copy file contents around, you're just crazy. In other words, the filesystem has to be able to directly access the name cache, and the content caches. Which in turn means that it has to be ring0 (core) too.

> If you don't care about performance, you can add call-outs and copy-in and copy-out etc crap. I'm telling you that you would be crazy to do it, but judging from some of the people in academic OS research, you wouldn't be alone in your own delusional world of crap.

> Sorry to burst your bubble.

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

#163

Post by ngrilly »

andrewstuart2 wrote: post #13
pweissbrod wrote: post #8

I wonder if there exists a parallel dimension where linux is microkernel design and folks are pushing for monolothic citing the driver friendliness and performance

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…

Reminds me of the TV show "Counterpart"!

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

#164

Post by bryanbuckley »

mrsteveman1 wrote: post #82
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.

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

Same for many Android phones and AMD chips with PSP (trustonic's l4 forked OS).

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

#165

Post by tinco »

thsowers wrote: post #143
enitihas wrote: post #77

Reminds me of the famous Torvalds Tanenbaum debate. https://groups.google.com/forum/m/#!topic/comp.os.minix/wlhw...

Thanks so much for the share, great gems in here, I still found myself surprised at this: > True, linux is monolithic, and I agree that microkernels are nicer. It's hard to believe that he was only 23 when he wrote this

I think thinking about operating systems is precisely the sort of thing 23 year old college students do. I know a few in my class did, I was hyped up by MS's Singularity OS back then.

Unfortunately they were not aware yet that Windows was going to lose the Server OS war and they never pulled Singularity out of research.

Operating Systems is a 2nd year course in most universities.

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

#166

Post by renox »

hinkley wrote: post #156
btilly wrote: post #24

Earlier quoted context omitted.

This is your opinion. The opinion of informed observers who are actually doing the work is the opposite - OEMs produce buggy, incomplete drivers and don't care to fix the bugs. In fact, given the choice, they don't want to allow anyone else to dig into their drivers because doing so can only lead to embarrassment. Plus exploits that are discovered are likely to be cross-platform exploits. Any operating system that wi…

Three words: Creative Fucking Labs. Someone told me back then that the sound blaster drivers were responsible for more crashes than the next several causes combined, so I started watching and I’ll be damned if I didn’t see the same thing.

If I remember well, there was a sound card which talked on the PCI bus after it should have stopped talking, these kind of bugs can break any OS, microkernel or not..

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

#168

Post by AnIdiotOnTheNet »

nasoieu wrote: post #3

That chart with the growth of the Linux kernel discredits everything. The Linux kernel continues to grow because they are obsessed with keeping all drivers in mainline instead of having a stable API for them as any sane project would.

If you insist that all drivers must be a part of the kernel, then it is perfectly fair to count all driver code as part of the kernel code.

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

#169

Post by AnIdiotOnTheNet »

monocasa wrote: post #111
pjmlp wrote: post #85

Earlier quoted context omitted.

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

OK, that calls out X.org as the reason why the drivers aren't being supported rather than Linux. You can use fglrx with newer kernels just fine, it's just that user space went out of it's way to break support. I really fail to see how that has anything to do with Linux's unstable kernel driver API.

> OK, that calls out X.org as the reason why the drivers aren't being supported rather than Linux.

Ah, the Linux evangelist blame-game. It's a big advantage of a system being so haphazardly thrown together from separately developed components. Start by blaming the choice of distro, end up at "Linux is just a kernel".

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

#170

Post by AnIdiotOnTheNet »

nasoieu wrote: post #17
rhencke wrote: post #4

Earlier quoted context omitted.

I believe one of the reasons Linux continues to be successful today is _because_ they keep the drivers in mainline _without_ a stable API. It is a key motivator to ensure drivers remain available and supported well into the future of Linux.

Linux on the desktop would have succeeded with a stable driver API. Having hardware with closed source drivers supported could have being a walk in the park for OEMs. Bad 3D, wireless, etc. support is what killed Linux. OEMs would have probably made more and better drivers if they didn't have to make changes to them every few months or go through the effort of releasing and mainlining the source.

> Linux on the desktop would have succeeded with a stable driver API.

I doubt it. Linux desktop's problems run far, far deeper than that one questionable choice.

Post reply on HN