MuQSS/CK's Con Kolivas Becoming Concerned Over The Increasing Size Of The Linux Kernel

[geearf]

We need a microkernel to solve issues like this one, and many other issues.

How would a microkernel solve this issue? The scheduler code and all it depends on would still be the same size wouldn't it?

[birdie]

How would a microkernel solve this issue? The scheduler code and all it depends on would still be the same size wouldn't it?

Pluggable schedulers? A feature also proposed for the Linux kernel and rejected I don't remember why. Even a compile time switch was rejected for f's sake. That was simply harsh and mean.

[geearf]

Pluggable schedulers? A feature also proposed for the Linux kernel and rejected I don't remember why. Even a compile time switch was rejected for f's sake. That was simply harsh and mean.

Oh I see, there'd be an interface used between CFS and the kernel, which MUQSS and co could also use without patching things out heavily.
Yeah it'd be nice if we could have multiple schedulers, the same way we can have multiple elevators.

[marlock]

There's a couple things I've been considering, but I'm sure I need to read more about to be able to make up my mind about monolithic vs. microkernels...

One would be about development practices <> code quality... I am under the (possibly wrong) impression that linux drivers, since only upstreamed into the mainline kernel after thorough review, are gererally well peer-reviewed (which obviously relates to code quality) and more able to share/reuse code parts (eg gpu code between AMD and Vivante and others, which in the end may help coding new stuff more easily than each doing their own in their own way, despite the learning curve being steeper to get something accepted)... a microkernel with userland drivers seems like it could become a shitty-driver nightmare (like windows, only worse because every manufacturer under the sun wants to write drivers for windows.... like android more likely, with hiddeous binary blobs for *every little thing* which make it mission impossible to develop new linux distros for android hardware and zero interest from manufacturers and part producers to mainline ir even maintain anything... lots of trashed phones stuck in old kernels, etc and not sure for now that any API would be enough to fix it... maybe improve, less shims, but not entirely fix it).

plus there is licencing under GPL, which may not be perfect, but the "terrible" "harsh" "scary" clause that says you have to contribute back improvements if they're to be used by others than yourself, etc... it may be what gave linux a future instead of being quickly a victim of a "take the money and run" policy which would not build a dev comunity around it... again, just my current impression, is that userspace drivers wouldn't have to worry about gpl-compatibility at all so would tend to look like androd driver licenses and such.

all in all, having a centralized integration effort puts a throttle on some works, sure, but it also seems essential to there existing such a massive organized effort around a common goal to ensure it all fits together well and that this growth isn't abandoned for "next shiny thing" and to drowning in "technical debt", etc

any merit to these impressions?

[marlock]

oh, also... doctor in psndemic is tired and cranky... news at 11?

lets just be glad covid didn't reap him yet and hope that maybe his cranky contribuitions are soon met with someone else getting more involved in his effort and letting him breathe? it's a wonder he has time to code at all right now, really... kernels stuff even more so!

[bug77]

Nah, I don't like copyrighted stuff for OS.

The OS I am looking for might be GNU Hurd somewhere in the future.

I don't think Hurd will happen. Linux was a good idea and it only took Linus (initially) to make it happen. Hurd, as good as it may be on paper, has an entire organization behind it, yet it's still going nowhere.

That's not to say Hurd is useless. I like it when people get to experiment with stuff. Even if it ends in failure, the lessons learned are useful for the future.

[ayumu]

just the microkernel will push the bloat out into userland and be slower for it.

Actually, it'd be faster. Refer to Liedtke's microkernel construction paper. This became later known as principle of minimality.

Anything that doesn't need to be in the kernel should be moved outside.

[ayumu]

I don't think Hurd will happen. Linux was a good idea and it only took Linus (initially) to make it happen. Hurd, as good as it may be on paper, has an entire organization behind it, yet it's still going nowhere.

That's not to say Hurd is useless. I like it when people get to experiment with stuff. Even if it ends in failure, the lessons learned are useful for the future.

The hurd is hopeless for as long as it doesn't

• Address the issues highlighted in the hurd critique paper
• Move away from Mach (horrible 1st gen microkernel) and into a 3rd generation microkernel (principle of minimality + capabilities).

[Danny3]

Running perfectly fine with 5.8.1 and Virtualbox. And Nvidia 450.57.
A new kernel is almost always an issue, esp. for Nvidia drivers.

Hmm... this is weird and I don't understand how is this possible.
The ticket is still open and there's no new Virtualbox release saying that they have added support for 5.8
Which distro are you using ?

[birdie]

Hmm... this is weird and I don't understand how is this possible.
The ticket is still open and there's no new Virtualbox release saying that they have added support for 5.8
Which distro are you using ?

Download a test build, extract and overwrite /usr/share/virtualbox/src