/tech/ - Technology★

>>918910 (OP)

What's the smallest practical kernel size possible on a modern (((x86))) desktop?

AmigaOS' Exec got by with 13kb in the late 80s.

>>918914

idk about compiled size, but minix3's kernel according to them is 12k lines. seL4 is probably even less.

>>918910 (OP)

>but sadly they aren't really usable full time yet

Yes they are. They are used commercially all the time. The big one is called QNX.

>superior microkernel design!

Microkernels are slower because of context switching cost. Having to go through 3 or 4 different programs for one task is very slow. Note that this is NOT the same thing as IPC limits which have gotten much faster.

Microkernels are good for some things that require stability and security but not speed.

>>918919

QNX was pretty fast though. And most computationally expensive stuff isn't syscall bound (see what was and what wasn't impacted by the spectre fixes).

>>918910 (OP)

How many little boys have your greasy fat hands touched?

Microkernels are generally a good thing, but microkernels written in C and/or emulate UNIX all suck. Microkernels are supposed to reduce costs and development time, but C and UNIX increase costs and development time instead. If the Hurd didn't have to emulate UNIX, it would have been completed the same year it started and it would have been faster than UNIX and use much less code overall. Even better is not needing a kernel.

Anyway, you have to have hard links to your kernel file in
both root directories.  Then since mach is not a kernel but
a microkernel (the micro kernel binary with symbol tables,
debugger, etc is a svelte 950k on a MIPS box, unix emulation
is only another 1500k; I actually *needed* the extra 10 megs
on the root partition) you have to create a mach_servers
directory and populate it with various programs that mach
uses to emulate unix.

   Try the case where the interpreter specified on the #!
   line is *itself* implemented by an interpreted
   script. Now if a reasonable person were implementing
   this, it would just work.  Recursion is a concept
   understood by most 18-year-old CS majors.  Apparently
   this notion escaped the notice of the BSD/SunOS guys,
   because on my Unix, one level is all you get.

You Just Don't Understand.  Writing Code To Run Inside
Kernels Is A Hard Problem.  (That's why we have
microkernels; so you can have programmers of average ability
writing system software and not necessarily crashing
everything when it breaks.)  You can't just allow unbounded
recursion inside the Kernel.  You might overflow your Kernel
stack which is of course set at some small wired in constant
in keeping with unix tradition (Simple!).  And of course, No
One Would Ever Want To Specify Another Shell Script In The
#! Line.

I have a machine named EXXON-VALDEZ on my desk.  This was
from when I nominally worked in fault tolerant computing; I
figured it would be good karma to name the machine after a
huge disaster as a precautionary measure.  (I'm quite
superstitious in strange ways.)  Now the hardware has been
replaced and I'm about to name the machine something else.
I'm thinking of the name MBUF.  I suppose it wouldn't be
such a big change; the machine would still be named after a
huge disaster...

>>918927

well at least we can agree on microkernels being good, mister lisp meanie!

>>918926

zero of course!

>>918910 (OP)

OwO

microkernels are nice

gas the jews with mk-powered robots

>>918926

6 gorillion

>>918910 (OP)

Why are microkernels so consistently unpopular in server and desktop use? Other than being the ME botnet OS (Minix) they haven't really taken off. The idea sounds good to me, but it it also seems like it's universally hard to implement (see HURD).

>>919050

Because they are slow.

>>919051

See the thingy I wrote about Fuchsia. As botnet as it’s likely to be given its creator being Jewgle, the fact that one of its platforms will be mobile phones is proof to me that the performance decrease can’t be that bad. Also see what others in this thread mentioned about QNX.

>>919050

I’d attribute it to Windows, MacOS, and GNU/Linux getting popular first, and also the FUD about performance.

>>918910 (OP)

http://www.draketo.de/english/free-software/howto-hurd-140-chars

>>919062

UwU who's alex?

>>919073

Yeah ive seen that. Tried HURD already and like I said its kinda not great in terms of usability for full-time.

>>918918

>du -k /boot/minix_latest

HAHAHAHA retarded faggotposter can't into du -s

protip: du -k counts the size of the directory entry, not the files inside LOL

>>918927

>it's the fucking retard whose only arguments are in the form of copypastas from obscure 9000-year-old texts

>>919060

>and also the FUD about performance.

Remember guys anything thats shit about your favorite thing is always FUD. Everything is free, they are better in every way.

>>919385

Do you not understand the FUD going around that's directed towards microkernels? The FUD says that microkernel overhead is too large to be usable. That is the definition of fear, uncertainty and doubt.

>>919420

kill yourself, obnoxious tripfag

>>918910 (OP)

don't forget about MirageOS, HalVM, and OSv. They're excellent.

>>918910 (OP)

>tripfag thread

sage

>>919499

umm those are the exact opposite of what im talking about. Those are unikernels, silly!

microkernels are 50% slower than monolithic. let that sink in

50%

>>920932

1. [Citation needed]

2. This is offset quite a bit by increased modularity. If you look at HURD they have filesystem translators for all kinds of protocols like ftp/gopher/xml/etc. Having standard components like this allows user applications to be far less bloated. Instead of having a dozen monolithic applications each using their own libraries you can have a couple translators and a dozen thin client programs served by the translators.

>>920940

>2. This is offset quite a bit by increased modularity

>Microkernel speed penalty is mitigated by turning it into a monolithic kernel

really makes you think

>>920976

>modular == monolithic

You're a moron.

>>920940

>This is offset quite a bit by increased modularity.

Remember guys modular means good. Increased modularity in no way means more bloat.

>>921869

> Increased modularity in no way means more bloat.

Yes and no, the hurds way of doing things reduces a lot of needs that ask for their own project, for example most of the mess that is docker isn't necessary anymore thanks to subhurds and neighborhurds isolation, same thing for debugging you can live debug the microkernel thanks to that system, init systems becomes trivial etc...

>>921875

>he hurds way of doing things

Ah yes if there is something GNU code is known for its not bloating shit up for supporting random shit no one uses.

>>920932

>50%

Nope more like 10~20% and that was a understandable to not want that in the 90s but nowadays it's stupid.

To completely remove the performance problem hardware must be adapted to support the hurds microkernels design.

>>921876

Yes because other OS are known to no insert the blob bloat or support proprietary software.

> shit no one uses

If it's in there then someone used it at some point.

>>921879

>If it's in there then someone used it at some point.

Yes anon if literally anyone ever used it, it should be included forever on everyones system and never deleted from the source.

>>921909

The "eunuch philosophy" for software design is an abject failure, as is the C language.

>>921913

hi mister lisp meanie!

>>921909

>After all, if it did, then poetteringd would be the most /minimal/

<If something is not modular that makes it minimal

retarded

>>921869

>i have no idea how the unix philosophy works

>>921946

Thats what you said!

You sarcastically said "Remember guys modular means good. Increased modularity in no way means more bloat."

which to me implies that you believed that reduced modularity means less bloat. But clearly thats not the case.

>>922223

Only if you are an idiot and interpret what I said as "If you make something non modular it cannot also be bloated".

>>918927

Why do you keep posting?, we don't need you to post anymore, we can already predict with precision where you are going to post and what you're going to post an hour before you do it, you're like that one guy who insist in blurting out the obvious joke that is so obvious noone wated to say it because they knew everyone was thinking of the same thing. Keep lurking if you want, but there's no point in you to keep posting anymore when we already know exactly what you're thinking.

>>922264

I see the block quote and don't even read them at this point

>>921913

But it works today. Wake me up when I can buy a multi-user, multi-processing general purpose computer that doesn't rely on either a Unix-like or C.

>>922275

This.