FACE IT, MICROKERNELS DEFEAT MONOLITHIC KERNELS

what is zoomer

but can it run crisis?

Depends on whether it's an N type or P type thyristor.

>P type
P types can only be turned off by switching the direction of the current.

OP, explain yourself.

Pic related.

Attached: Screenshot_20181017-114013.png (480x854, 101K)

Everyone here understood that microkernels, in theory, are faster and more secure than monolithic kernels. However this does not mean this is easely achievable in the real world. Per microkernel added the system will grow exponentionally more complex. You need to have an architecture that scales from 50$ phones to NSA's database in order to begin offering drop in replacements to monolithic kernels.

Come back when you ported Linux over to individual microkernels. EZ task right?

Not OP but, Pic is right exept todays microkernel goes further. If an application wants to allocate RAM it wouldn't go trough a sys call but rather call the "RAM microkernel" The "OS" would go trough the same procedure exept, maybe, with higher priviledge. Same with Ethernet, same with storage.

Perfection

Attached: 2018-09-21-sculpt-vc.png (1600x900, 1002K)

Attached: 2018-06-13-desktop-tc.png (1920x1080, 703K)

Aren't microkernels theoretically slower than monolithic ones? How can they be faster if every task runs in a seperate process? Doesn't inter-process communication have an overhead? The only advantage I see is security.

do microkernels imply that the TCP/IP stack is done in userspace? do apps send the messages to some userspace daemon or they implement the entire protocol using some embedded library?

>virtue of phase angle controls utilized through composite thyristor/VPI intelligent prebinding. This saves time by avoiding unnecessary CTP calculations when addressing binary plate quads sequenced by the integrated data interface.
This means nothing

IMO the biggest hurtle historically for microkernels is the market pressures. Monolithic/hybrid kernels are convenient because they can be hacked together as needed to ship ASAP. There's been a ton of great work on microkernels in research and the military where these pressures are less relevant, but alas.

>do microkernels imply that the TCP/IP stack is done in userspace?
Not necessarily, but often.

>do apps send the messages to some userspace daemon or they implement the entire protocol using some embedded library?
The former.

They are slower. Context switching is hardware overhead, and therefore unavoidable. You can try to mitigate this by moving components into the kernel (making it a hybrid), and trying to intelligently queue requests for services to minimise the number of context switches, but at the end of the day, a monolithic kernel will always be faster.

Microkernels don't really provide a security advantage. If anything, security is put at risk by loading malicious kernel processes (but the same can be said for monolithic kernels with loadable modules/drivers).

The appeal of a microkernel was that components could be swapped at runtime, or restarted if they failed, just like a normal process. Sadly, this benefit is never really seen in the wild with current microkernel based systems.

what's even the reason of putting common important functionalities like the the TCP/IP stack in userspace? let's just have one standard implementation done in the kernel with good performance and security checks

Reliability. Say there's a bug, or a cosmic ray switches a bit in a cpu register, it won't crash the whole system, it just will be restarted and keep trucking along.

>There are people on Jow Forums right now not using a NP type thyristor

And don't give me that "It's the same as P thyristor" bulshit. We all know they are very different

that's nice. now make hurd usable

Protection, modularity, resilience.
In some cases user space code can be specialized making it faster than kernel code.

Some microkernels do most things themselves - for example a library OS.

Then why doesn't *any* serious operating system use one?

en.wikipedia.org/wiki/L4_microkernel#Commercial_deployment

Context switching being expensive is mostly on x86, L4 did 30 cycles null-IPC on Itanium for instance. An x86 processor on Linux can't even reach kernel mode that quickly.

Microkernels are more secure. Basic fucking logic and proven.

No the appeal is that they are modular and easier to make secure among other things.

Lack of thyristors in current processors.

I agree kernels made out of a single large piece of stone probably don't work too well

Attached: grug.png (798x490, 95K)

> microkernels are more secure
Do you have anything to backup that statement besides your "basic logic"?

> the appeal of microkernels is that they are modular and more secure
Again, they are not more secure. If your referring to the ability to run a kernel module in Ring 1, then whoopdeedoo. MS drivers do this and they still bring down the system when they fail. As for the appeal being that they are modular, yes, that is what I originally said. The problem is, that the benefits are often not seen in practice. The only useful side-effect being a very easy to maintain codebase (something that is definitely not worth it for the complexity of the message passing logic).

And yes, microkernels may be better on specific CPU architectures (embedded systems mainly), but they don't stack up on x86, which is the most important of them all for what I hope are obvious reasons.

SokalBot is getting pretty good. One day we'll no longer need actual bullshit artists.

Oh don't worry, it's just SHODAN trying to get out again, we'll send in another hacker, it'll be fine.

Theoretically they are not slower. exept on x86 they most definitely are slower due to context switching being expensive.
>but at the end of the day, a monolithic kernel will always be faster.
Yes, it will be more expensive. Just like encryption adds overhead. We just accept certain kinds of overhead for the sake of sanity checks or reduce the ring of trust in cryptography scenarios.
>Microkernels don't really provide a security advantage.
I disagree, There is a paper on bugs which do or do not compromise security/availability on theoretical microkernels compared to monolithics. In laymans terms,

The application running on a microkernel is only suceptible to leaking data and denial of service if one of the kernels that is required for them to run is used. ( Other bugs can still bring down the system which would ruin availability but that one is obvious. )
>The appeal of a microkernel was that components could be swapped at runtime
I think you can make monolithic kernels do this but yeah, micro's are more friendly towards that. It would be absolutely rad to switch graphics cards on an active system. Things like RAM would probaly be nearly impossible as I wouldn't want to be the guy to program emptying the DIMM of active data while running the system.

>Context switching being expensive is mostly on x86
Thanks

>Do you have anything to backup that statement besides your "basic logic"?
See above
>they are not more secure
If you assume every driver, kernel and bios programmer is a literal god or Terry Davis then, Yes. you're right. and thanks for the compliment.
>but they don't stack up on x86
x86 is indeed terrible for microkernels. But that doesn't mean microkernels are a bad idea. But lets not pretend that x86 is the pinnacle of engineering ( or Intel/AMD's choices in instruction sets for that matter )

Addentum:
microkerneldude.wordpress.com/2018/08/23/microkernels-really-do-improve-security/

I read another document but I skipped trough this one and it is even MORE compelling for microkernels, The one I've read was more conservative with the amount of bugs that wouldn't affect microkernels ( only around 20% )

Why did you reply to me

Meant to link this one

We can discuss this as much as we want, but there is only one way to prove it: create a microkernel that is objectively better than any monolithic kernel currently existing and can potentially support as much hardware.
Ultimately, only facts count. The rest is pseudoacademic wankery.

>We can discuss this as much as we want, but there is only one way to prove it: create a microkernel that is objectively better than any monolithic kernel currently existing
You know where you are right? Linux on desktop only makes up 1%. While Jow Forums makes up of only linux users and the rest are /v/ users.
>Ultimately, only facts count. The rest is pseudoacademic wankery.
You know where you are right? This is the same site that has 20 threads on shilling rust versus Go and every language while most people probaly just use c and jump up and down the chain to asm and C++. Facts are not irrelivant and I would like to see a new operating system based on microkernels that would succeed in a niche market. doesn't mean I can't enjoy pseudoacademic wankery when I see one.

Because you know jack shit about operating systems.

true, but didn't you forget the hyperbicopular extending field dampener module?
Not only does the monolithic design prefer fastjoint lanes, it also maintains the extended period sidebuffer in a better way that micro kernel's direct access lanes.

This alone makes microkernels fail in their very architecture.

>Everyone here understood that microkernels, in theory, are faster and more secure than monolithic kernels¡

You mean noone here has the basic knowledge that monolithic kernels are faster, since they avoid one indirection per system call ?

But how do you get precise timing for your drivers in userspace?

Attached: 1512147345270.jpg (499x547, 59K)

The separation between user and kernel space is partly framed in the context of monolithic kernels. The separation becomes much more granular in microkernels in that there can exist a hierarchy of "spaces", with each governed by the principle of least authority. Precise timing could be handled any number of ways through IPC or interrupt systems. I don't know enough about current trends in OS research to say what's considered best practice, though.

What about exokernels or "the operating system kernel as a software multiplexer" or shit like that?

Have you been absent to the past decade of research? The direct access lane paradigm has been all but superceded by polyphase switching, which not only outperforms fastjoint lanes, but ensures synchronicity between hyper threaded resources. Good luck dealing with sidebuffer corruption when the "fast" (AKA asynchronous) lanes aren't managed.

Yeah, but then you realize that your supposedly faster micro kernel is not only a fucking nightmare to write but it also not even faster than monolithic kernels. Write one that does the same as the Linux kernel that is also faster, you just can't.

>because my CS teacher said it so

just read up on this, that's interesting.
However i also read that latency degradation is a thing due to the direct acess lane's fast flow mechanism. Not sure on this tho, as the reports on that kind of contradict at times.
Also sidebuffer corruption is only a thing when dealing with multiple overhead processes which are not designed but purposely sent through the core lane. The bpu (instruction blueprint unit) is implemented since quite a time now.

Curious to hear your opinion on the flow regulator.

What about hybrid/modular kernels? Best of both world right?

there are a lot of morons on here spouting bullshit. context switching is not slow (it is a common myth that it is slow), microkernels do have a security advantage. stallman (in 2001) said that the reason hurd was hard to develop is because debugging was a pain as it's hard to trace messages between modules (not sure if this problem has been solved yet).

That's because Hurd tried to do too much shit instead of bringing a basic microkernel and start to develop from it.
Also, MACH.

About ten hours after GNU/Food.

>taken almost 30 years to develop
>design is already obsolete
What a fucking joke.

Attached: richardo_stallmanu_by_rware-d3af4xz.jpg (766x758, 235K)

>the 30,000 BC boomer

will we ever use cornells instead of kernels?

I would have liked HURD anyways. You can do shit like virtual filesystems in a more "natural" manner than Linux, for example
But since Linux is here, and it can sing Virtual Filesystems, nobody cares. Probably Fuchsia could be an alternative for a funcional free microkernel, but I highly doubt it.
If I had time, knowledge and resources, I would like to create a full microkernel desktop OS, like QNX, but free and libre.

That's what Rinus Torvalds asked when he invented the Ubuntu Colonel.

Attached: rinus.jpg (300x242, 15K)

Fuchsia, or Little Kernel on which it is based will probably be something of a revolution. But L4 has existed for almost as long as Hurd and they should've adopted that design instead.

I forgot to say that I would like to use seL4 for my design.
We can dream, lads.

yeah QNX, here is a paper showing how it can be faster than monolithic UNIX back in 92... cseweb.ucsd.edu/~voelker/cse221/papers/qnx-paper92.pdf. micr0krnalslowfags BTFO

I can't picture the face of stallman when faced with the fact that a propietary software literally do what he wanted to do in first place.

>tfw no Photon MicroGUI
This shit should replace The Rootkit formerly know as X.org and The Redhat Meedling formerly know as Wayland.

Attached: μ A E S T H E T I C.png (1024x768, 139K)

>Things like RAM would probaly be nearly impossible as I wouldn't want to be the guy to program emptying the DIMM of active data while running the system
On IBM's z/Architecture mainframes you can even hotswap CPUs

What are the latest developments with googlel fuchsia

QNX should just replace tranny/linux