[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vr / w / wg] [i / ic] [r9k / s4s / vip / qa] [cm / hm / lgbt / y] [3 / aco / adv / an / asp / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / qst / sci / soc / sp / tg / toy / trv / tv / vp / wsg / wsr / x] [Settings] [Search] [Home]
Board
Settings Home
/g/ - Technology


Thread archived.
You cannot reply anymore.



File: microkernel.jpg (59 KB, 845x637)
59 KB
59 KB JPG
Microkernels DESTROY monolithic kernels by implementing PHASE ANGLE controls utilized IN CONJUNCTION WITH composite thyristor/VPI intelligent PREBINDING...!!! This saves time by avoiding unnecessary CTP calculations when addressing non-binary PLATE QUADS sequenced by the integrated data interface.
>>
Microkernels are a meme. They're a OOP of kernel design; just a bad idea.
Get over it.
>>
>>71841420
Don't want to sound like a dick or nothing, but ahh ... says on your chart that you're fucked up. Ahh, you talk like a fag, and your shit's all retarded.
>>
>>71841420
Dunno what that nigger shit is, but I agree that microkernels are such a better design it aint even funny.
>>
>>71841463
For low-power tablets sand memephones.
>>
>>71841420
microkernels and monolithic kernels are good but what in the love of fuck are you talking about
>>
File: microkernel.png (127 KB, 800x400)
127 KB
127 KB PNG
>>71841420
(((Microkernel)))
>>
>>71841420
ok
what now?
>>
File: 1554294888495.png (867 KB, 813x1024)
867 KB
867 KB PNG
>microkernels are slow
>t. brainlet
http://blog.darknedgy.net/technology/2016/01/01/0/
Pic: Multiserver system architect working out the fine details on some interfaces while doing some healthy exercise.
>>
File: 1552792276190.png (425 KB, 907x1138)
425 KB
425 KB PNG
Google's Fuchsia: Microkernel multiserver.
Huawei's hongmeng OS: Microkernel multiserver.
Genode: Multikernel multiserver.
Linux fanbois: On suicide watch.
>>
>>71841420

Microkernels are great in theory. Shame about in practice tho. All that message passing will never be as fast, and everyone wants to get the most value from their hardware. Plus, more data copying = more processing needed = more environmental pollution.

Obviously a smaller kernel is more secure, but then linux makes use of a hybrid approach where it makes sense to anyhow.
More suitable CPU designs would probably help more.

'Pure' Microkernels have been proported to be 'coming soon' for the last 40 years. Give it up already Tanenbaum. Even Mach in OS X is no longer a microkernel.
>>
File: TEMPLE_OS.png (354 KB, 734x566)
354 KB
354 KB PNG
>>71841420
we have the TempleOS
so f-ck (You)
>>
>>71841717
>Shame about in practice tho. All that message passing will never be as fast
Oh look, it's the 'muh performance' FUD again.
Anon, it's not the 80s anymore. Mach is irrelevant, and even Apple doesn't use the original anymore.
https://en.wikipedia.org/wiki/XNU
>After Apple acquired NeXT, the Mach component was upgraded to OSFMK 7.3 from OSF

If even Google is behind this idea and apparently seems to be developing this technology for fucking smartphones, tablets, chromebooks, etc, clearly they're not so inefficient that they would cause excessive "environmental pollution".
Linux is not a hybrid. It's monolithic. Loadable kernel modules does not make it hybrid.
>>
>>71841717
> linux makes use of a hybrid approach
The hybrid approach of unfortunate design and incompetent implementation
>>
>>71841659
2019 is the year of Hurd.
>>
File: 1548452967929.png (1.19 MB, 1250x1250)
1.19 MB
1.19 MB PNG
>>71841717
>will never be as fast
Go to >>71841633
homework:
What's the context switch cost of seL4? is it bounded? How about Linux? Is that bounded?
How many extra message passings would a multiserver system have to do to actually be slower than Linux?
Do this much before you come spew your incoherent rambling, you dimwit.
>but then linux makes use of a hybrid approach where it makes sense to anyhow.
Linux is a monolithic kernel, not an hybrid kernel, you imbecile.
The Trusted Computing Base of Linux is millions of lines of code, or megabytes of object code. It cannot be made secure, ya dunce.
Besides, Linux doesn't use capabilities (not to be confused with POSIX capabilities, which are something else), but a weak permission model that's not suitable for actual security, and a bunch of band-aid alternative security models that don't fit with its design, moron.
>'Pure' Microkernels
What is a 'pure' microkernel? Do you have even a semblance of a clue what you're talking about? Brainlet.
> have been proported to be 'coming soon' for the last 40 years.
They're young compared to monolithic operating systems (now those ARE old!). There's been massive progress in microkernel design during this time.
Did you even figure out why L4 spawned the second generation of microkernels?
Is your brain not getting enough nutrients?
>Even Mach in OS X is no longer a microkernel.
Mach3 is an academic, first generation microkernel not designed for performance. It should never have been used in the real world, and it's seldom used in multiserver systems without actually running the servers in supervisor mode. This is as a workaround to its broken design which makes performance impossible.
So what are you getting at, that first generation microkernels were slow? Well, your brain is stuck 40 years ago. we're on the third generation of microkernels now. Go away, and don't come back until you figure out the state of the art. Or preferably, don't come back. Kindly KYS.
>>
>>71841872
Hurd is dead. Move on. It's basically research OS-tier like Plan9 and Minix3 outside of Intel MEs. Things like seL4/Genode and Fuchsia are the future, and their development teams seem invested in actually getting these things off the ground and usable.
>>
File: 1555120777648.png (734 KB, 850x1200)
734 KB
734 KB PNG
>>71841872
HURD is currently a containment project so that feebleminded developers who do not even lift can play around without affecting the actual good microkernel, multiserver, capability-based operating system projects made by /fit/ system engineers with a clue.
>>
>>71841908
Monolithic kernels actually exist though, while you and your kind are busy jerking off over your formal proof the rest of us in the real world are actually doing something productive, come back when seL4 supports at least 64-bit and multi-core CPUs, until then, stop shitting up the board with your imaginary tech
>>
File: 1535220294339.png (1.2 MB, 1191x1684)
1.2 MB
1.2 MB PNG
>>71842163
Multicore for 64-bit ARM and x64
Available in seL4 since: Q1 2018.
>come back when seL4 supports at least 64-bit and multi-core CPUs,
Are you actually retarded?
>>
File: 1550589680623.png (1005 KB, 1000x1285)
1005 KB
1005 KB PNG
>>71842163
>What's the context switch cost of seL4? is it bounded? How about Linux? Is that bounded?
>How many extra message passings would a multiserver system have to do to actually be slower than Linux?
Done your homework yet?
>>
File: 1553052277199.png (484 KB, 700x509)
484 KB
484 KB PNG
>>71842208
Guidance: You can assume the worst case for seL4 and the best case for Linux, in your calculations.
Tip: It won't change the result.
>>
Redox OS will fix it.
>>
>>71841574
when will MINIX become microkernel though?
>>
>>71842314
It did by the first release Minix 3, over ten years ago.
>>
Does hurd werk yet?
>>
>>71841420
>>71841463
Lovely ideas, come back when someone's put them into practice outside the embedded space and gained traction with it.
>>
>>71842875
>about to be blindsided by fuchsia and genode
>unironically
>>
>>71841914
> It's basically research OS-tier like Plan9
First of all it's called Plan 9, not Plan9.
Then, nobody uses Plan 9 in 2019, the de facto standard today is 9front which is not a "research os" by any definition.

It's funny that you cited genode which practically implements the same "TCB" mechanism of 9front(private namespaces) just in a more complex fashion.
It is clear you don't knoe what are you talking about, so please stop it
>>
>>71841914
>actually getting these things off the ground and usable.

And as for today 9front is way more usable as general purpose os than what you listed.
I have 9front on x220 and works just fine ootb. Do your research better before writing bullshit
>>
File: 1545202044306.png (954 KB, 700x991)
954 KB
954 KB PNG
>>71841914
>HURD is dead, move on
Agreed.
>It's basically research OS-tier like Plan9 and Minix3 outside of Intel MEs.
Wrong, wrong, very wrong, Anon.
Have you been exercising properly, Anon?
>>
>>71841420
>phase angle
>composite thyristor/vpi intelligent prebinding
>CTP calculations
>non-binary plate quads sequenced by the integrated data interface
Can't believe that no one actually read OP and actually responded seriously to this.

/g/ really is full of retards
>>
File: 1535074425957.png (347 KB, 512x483)
347 KB
347 KB PNG
>>71843723
>can't figure out people talk here because this is the current microkernel general
>unironically
>>
>>71843723
haha, fuck jokes! amirite?
>>
>>71841423
>They're a OOP of kernel design
No, they're the MVC of kernel design, which is a good thing, but with no proof of concept other than Plan Nein and GNU Turd, they'll never take off.
>>
>>71841908

>repeated ad hominem attacks

kek. Have I touched a nerve?
>>
>>71844771
Plan 9 is not a microkernel
>>
>>71841463
So why isn't it used more often, then?
>>
>>71847847
It's already seeing military use
>>
>>71841659
Market share of all of those OSes combined: 0.00%
>>
I'm glad Linux isn't microkernel, seeing how a terrible fragmented and obsolete mess userspace is. This monolithic kernel project umbrella is beneficial.
>>
Friendly reminder that Linux has 100% market share in supercomputers, >90% in server, embedded, mobile, netbook, and non-zero market share in consumer desktop.

Meanwhile, market share of microkernels is 0% in all areas.
>>
>>71849224
But market share of fellow microkernel OS Minix3: 100.00%
https://www.networkworld.com/article/3236064/minix-the-most-popular-os-in-the-world-thanks-to-intel.html
>>
>>71849275
False. >>71849331
Also, I don't know about embedded usecases outside of ME, but I'm fairly certain QNX has a bigger hold there than 10%.
>>
>>71849331
ARMs (read as phones) don't have Intel ME
32-bits don't have Intel ME
AMDs don't have Intel ME
so not 100%
>>
>>71849224
>>71849275
Also, when did popular == good?
>>
>>71849361

Folks have had 40 years to vote with their feet. The Gnu Hurd project started before Linux. Why isn't Android based on it now huh?
>>
seething plate quad shills all over the place.
>>
>>71841736
based. 2 million context switches per second. Terry was a genius.
>>
>>71849361
When did unusable == good?

Let's say for the sake of argument that everyone agrees that microkernels are good. Yay! Microkernels are good!

No one is going to run a microkernel. Everyone is still going to run *nix/Windows with monolithic kernels.

What the fuck even is the point of this thread? Yes, let's agree microkernels are good. So what? No one will use them.
>>
>>71851050
>When did unusable == good?
You're conflating the usability of implementations of the architecture with the viability of the concept itself. We're talking about IDEAS here, not their execution.
To you and to >>71849508, I want to make it clear the cycle that has persisted for so long now. Why aren't microkernel OSes good yet? Because nobody uses or develops for them. Why doesn't anyone use them or develop for them? Because they're not good yet. Add in a metric ton of FUD about the performance of the legacy Mach, and you have the sorry state of most microkernels in $CURRENT_YEAR.

Hurd will never be good. That much is clear. GNU threw it aside for Linux since that was generating hype and worldwide attention and was under their license. That wasn't always the case though.

>I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones.
>I can (well, almost) hear you asking yourselves "why?". Hurd will be out in a year (or two, or next month, who knows), and I've already got minix.
-- Linus Torvalds

>But in all honesty, I would suggest that people who want a modern "free" OS look around for a microkernel-based, portable OS, like maybe GNU or something like that.
-- Andrew S. Tanenbaum

Hurd will never be good. I want to say that again to drive home the fact to those of you who continue to linger on the Hurd point that I am not calling for a "Year of the Hurd desktop" or anything. I am speaking about microkernels as a CONCEPT, which has Google, seL4/Genode (American Military-backed), and Huawei carrying the torch today.
>>
>>71841420
The exokernel is the white man's kernel. Get with the program you fucking nigger
>>
>>71841420
Is this a test to notice that what you wrote makes zero sense whatsoever and you're just tossing a bunch of random tech words?
If its so, congratulations, 51 posts before someone noticed you did this weird shit.
>>
>>71852598
I really don't see what an exokernel even does or would be used for. My understanding is it can offer the same kinds of functions that a microkernel can but also allows for applications to just bypass all of that and directly interact with the hardware or resources. At that point is it even a kernel or just an application that can multiplex other applications?
>>
>>71847847
Safe to say, you're not in embedded.
>>
File: 1536250671563.png (362 KB, 600x853)
362 KB
362 KB PNG
>>71849803
>2 million
That's fast! Compared to Linux.
Still slow next to seL4.
>>
File: 1552382312903.png (35 KB, 438x233)
35 KB
35 KB PNG
>>71853151
F-F-Fast.
>>
>>71853183
>haswell 90ns
Obviously pre mitigations for intel fail, but that's 90ns. What the fuck.
Holy shit.
>>
>>71852764
The exokernel securely multiplexes hardware. The original exokernel project used capability based security. The library operating systems and application were able to custom tailor abstractions that would have been impossible to create with other kernels. Read Kashoek's paper
>>
>>71841659
you arent aware that GNU, commonly mistaken as linux, can adapt to most if not any kernel
>>
>>71853183
The pentium 4 will be forever the butt of all jokes, won't it?
>>
>>71853316
>talking about kernel
>responding about kernel
>ARE YOU TALKING ABOUT GNU? I THINK I HEARD YOU TALKING ABOUT GNU
>>
>>71853345
With the mitigations, the new Intel CPUs are considerably worse than that pentium 4.
And, even without the mitigations, they're also an order of magnitude worse on Linux
>>
File: 1548171910374.png (576 KB, 574x960)
576 KB
576 KB PNG
>>71853349
Wrong thread. Kindly go to the Linux containment thread.
>>
>>71849224
seethe more, tranny.
>>
>>71853183
M-m-misleading. Because while you save order of magnitude on context switch speed, you're also doing order of magnitude more IPC than lincuck.



Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.