Kernels

Since everyone liked the last one, let's talk kernels again, Jow Forums!
Topics from last thread Does it make sense to ever call a monolithic kernel bloated, due to the fact that it naturally needs to get bigger as more hardware support and drivers are added?
Genode OS: A microkernel OS framework that supports multiple architectures, has a collection of various drivers and components, and seems to be aiming to make the kernel itself interchangeable. Supports seL4 as one of the kernel options.
Barrelfish: An experimental research OS developed in part by Microsoft. A multi-kernel OS that has one small kernel running on each of your CPU cores.

Attached: kernels.png (2000x511, 76K)

guise?

Can you use another kernel for an OS anyway you want for example if I use Gentoo or arch(or any customisable distro) or must the distro support it?

Also opinion on hurd?

yay a person!
I'm not sure exactly what you're referring to here. Are you talking about something like being able to use the FreeBSD or OpenBSD kernels with a Gentoo/Arch and GNU userland? If so, then no. There were some projects that tried to make this work like Debian/kFreeBSD, but afaik they're dead now.
If you're just talking about using a different Linux kernel, I don't see why not. I remember one of the options for Funtoo if you didn't want to bother compiling was to just grab the Debian kernel and use that.

What I mainly was thinking about was using like hurd instead of the Linux kernel but I assume it's same as if it were the openbsd kernel(save the distros that offer a hurd compatible version). Would be fun though if there were a bit more diversity among kernels since centralisation usually means increased vounderability due to everyone using the same basis i.e. Same flaws

No real opinion on HURD, other than that it's basically never going to actually be developed and good. It's kind of a shame, because I would have liked to see what it would have been capable of.

Why not a mode in between Kernel and User?

elaborate. Keep in mind that "User" is just in reference to anything outside of the kernel.

bump

lol whats that

Attached: Bml-uBZCUAA0G03.png (454x515, 154K)

I'd like to contribute but I'm too much of a brainlet
I'll come back when I'm not

Attached: 1522088220301-g.jpg (1024x609, 465K)

GNU tried to make a microkernel system
They were working on it, but then Linux came around and they didn't really need it anymore, so the project is basically dead now.

Team Application IPC

It's trash.

Because you get into the realm of container faggotry. In the proprietary microkernel systems I've worked on there are "containers" or groups of services. You have one module running in kernel mode with the specific job of managing one or more modules out in user mode. So if a user mode module crashes, you can have this kernel mode one restart it. Then you get sub-containers which is a user mode group managed by a user mode group which is managed by a kernel mode module. So basically you a hierarchy of program groups (like privilege levels, but different) all tied to a kernel mode process. And it's horrible.

Container faggotry.

Soooo how does TempleOS figure in this kernelwise

I took some linux device driver courses and would like to make a LDD for practice but I have no ideas. what is something relatively easy but interesting to learn linux kernel internals?

I don't understand the advantage of Micro Kernel, and never did. So it's smaller, but everything is moved to user space, making the gross outcome the same.

You isolate components in their own address space.

Doesn't Linux do that already?

No, everything in kernel space share the same address space and you have full access to do whatever fuckup you want. If you write a buggy driver, you'll bring down the entire system.

Oh I see what you mean.
But on Micro Kernel if you fuck up, you will fill your memory with garble and bring down your whole system.
Sure it's easier on Monolith but then again, so what? How often is this a problem for you that it needs to be addressed?

what happed to minix running netbsd userland?

there was massive hype when it was announced but now everything is quiet

there are other more convicing arguments but debugging a device driver or module that doesnt crash the system is a breeze on microkernels. on linux its a pain in the ass. also, when kernel modules crash in microkernels the memory is not filled or destroyed, it is reclaimed for other tasks.

>you will fill your memory with garble and bring down your whole system
Only the memory belonging to the component, which the idea is that you can easily reset again and won't affect other components.

>How often is this a problem for you that it needs to be addressed?
Kernel panics happen all the time, mang. And not only bad addresses, you've also got stuff like deadlocking in the kernel.

Main problem I have with microkernel I guess is that it's easier. give a dev an inch they will take a mile, we have seen with C# and Java how fucking god awful code is made by devs, give this freedom to fuck up on kernel and in 10 years our Kernel will require 8GB of RAM on it's own.

So you hate convenience?? That's really not a good argument, user.

No, I hate the side effect. Laziness.

gnu software sucks. i thought i would help the open source community out by sharing my patches to libc. after submitting my patch i found 4 more bugs in the same module. fixed those bugs. great lets run the libc unit tests. unit tests pass, great, lets add some tests to cover the bugs. open test file, wow unit test only covers open* read* and close* with random options and not testing any functionality. write unit tests only for my fixes. give patch to libc, maintainer complains the existing tests need work. idgaf, i dont have time for it. sots for a year with no acceptance. oh man, so glad i found an openbsd dev job. their code and license is far superior. fucking gnu dorks.. dont believe me? code review libc.

So you wrote code that didn't pass the existing unit tests, and you're complaining about how your patch isn't reviewed?

>existing tests needs work
i knew after i typed this it would be misunderstood. original tests pass with my fixes but the maintainer wanted me to prepare tests for the whole module, not just my changes.

>original tests pass with my fixes but the maintainer wanted me to prepare tests for the whole module, not just my changes.
Post link to email list, this sounds too retarded to be true.

lets get this straight. you favour a more difficult approach to development to filter out developer laziness? ive never worked on a kernel team that had even half decent kernel module testing, even component testing for that matter. the laziness exists my friend.

that is my point exactly, they are lazy now, give them environment where more laziness is acceptable, they won't even try.

should we pick a micro kernel that gets Jow Forums approved? I'd be keen to write a small game on a random OS

>should we pick a micro kernel that gets Jow Forums approved?
Plan 9 is already Jow Forums approved.

what about Redox?

Seconding the call for proof, but I have to say I wouldn't be surprised. This kind of shit happens all the time. You would think glibc would have slightly less retarded maintainers than the average github project, though.

It will never "take off" because FSF cares for not their little autistic kid and it has no corporate support.
I had hope up like a fool when they got a $80mil worth donation in buttcoins, but after this almost 1 month without a single commit to hurd I'm sure hurd and mach will not see a single cent of that money.

Why would they invest time and money into a Linux competitor? It would be the single most retarded thing the FSF could possibly do.

It happened. Minix3 now has netbsd's pkgsrc.
I mean, a lot of the software in there fails to compile for some reason, but it's there, and you can give it a go.

This.
They have Linux-libre as their freetard kernel. There's no actual NEED for hurd.
It would have been nice to see though...