[tptacek]

Because different applications have different needs and there is nothing intrinsically safer or better about having the stack be kernel-resident and, in fact, a lot to recommend moving things out of the kernel and into userland, which has a better application cotenancy model (full cr3 context switches between different users).

[anonymousiam]

Circumventing the role of the operating system in the name of improved efficiency and duplicating a once-centralized function in (some) applications doesn't seem like a well thought out course of action. Why have an operating system at all? Why not just boot your computer to each application you want to run, as was done on the early PCs of the 1980's?

Perhaps we shouldn't use computers to run our applications anymore. Everything could run on a gaming console. That would certainly be more efficient for the applications.

[tptacek]

"The role of the operating system" is whatever we decide it is. The operating system exists to serve applications, not the other way around. This isn't an aesthetic thing; it's an engineering choice. Moving parts (or all) of the networking stack into userland is often better engineering, for the reasons I just supplied, any of which I'm happy to go further into.

[anonymousiam]

It's "better" for the application, but not necessarily better for the whole system, or the users. I'm sure it makes perfect sense from the (selfish) application developer point of view, but it goes against the philosophy that defines the roles of the OS vs. the applications.

[tptacek]

That's not engineering, that's just religion.

https://groups.csail.mit.edu/ana/Publications/PubPDFs/Archit...

[mardifoufs]

Considering that a lot of people use their OS just to navigate the web, you could use the logic you are applying here to argue that the browser should be an OS provided component. Plus, networking is one of the easiest things to move to userland. An OS is still extremely useful for everything else, so I'm not sure I see your point

[anonymousiam]

I don't believe it's my responsibility to cover these basic concepts here, but the role of the OS is to abstract the hardware from the applications.

All browsers are applications, regardless of what Microsoft argued in their 1998 anti-trust suit defense.

The OS knows how to talk to your networking hardware, and it provides services for the applications to do so, and even implements some standard protocols so the applications don't need to do that.

This is all very basic stuff, but I've been out of school for many decades, so maybe they don't teach it anymore.

https://www.theringer.com/2018/05/18/tech/microsoft-antitrus...

[mardifoufs]

What? Don't worry, I understand "the basic concepts". It's just that you yourself said that it was about a philosophy so it's weird to claim that disagreeing with said philosophy is just ignorance.

Also, I'm not sure you understand what quic is then? The kernel still handles most of the hardware abstraction, and in most cases still interacts exclusively with the hardware at the driver level (except for very high performance networking).

Yes, it can also help with protocols, but even going by your own definition ("but the role of the OS is to abstract the hardware from the applications"), protocols don't have to be at the kernel level.

You missed my original point, providing a browser was obviously an exaggerated example of doing more than just abstracting and handling the hardware. Which is also what implementing protocols at the kernel level is. The kernel still handles QUIC's UDP layer (and thus the hardware).

[tptacek]

It's not even true that kernels universally handle hardware abstraction! Their argument is an overgeneralization of what Linux and WinNT happen to do.

[mardifoufs]

Yes exactly, I completely agree! I was about to say that, but even with that rather restrictive definition it still doesn't make sense to want things like QUIC anywhere else but in userland.

But whenever I hear about "philosophy" in a discussion about kernels, I just default to assuming that they mean "whatever Linux does is the right way™".

But hey, I should've just skipped my kernel courses since they didn't teach me a lot about "kernel philosophy" lol.

[tptacek]

Could you maybe explain it to David D. Clark too? He appears not to have learned it at school either.