Ubuntu Blog Talks Up Rust Schedulers, Potential For Micro-Kernel Design Future

[mrg666]

This is not the discussion of reimplementing Linux kernel in a traditional microkernel architecture. The discussion is about eBPF which is already in Linux kernel that is giving microkernel capabilities. Read below

https://www.inapps.net/how-ebpf-turns-linux-into-a-programmable-kernel-inapps-2022/

[skeevy420]

Yeah my comment isn't directed towards the quality of the code work itself, merely the mischaracterization that this is similar to micro-kernel style features. While redundancy might be part of a micro-kernel overall system design, it doesn't require it.

Neither was my comment. I think the scheduler and eBPF stuff is very interesting. As far as redundancy goes, that seems to be Ubuntu's entire shtick about why this is such a good idea. If userspace blah crashes, we have redundancy by using the kernel's blah long enough to get the userspace blah back up.

That redundancy by using the kernel's blah is how they plan on getting certification and it basically operates on the assumption that the Linux kernel will never crash.

Redundancy, backups, however you want to phrase it, is what is required for safety certification for vehicles, flight control systems, medical equipment, etc. The software has to be able to recover itself from a software crash. You can't yank out a pacemaker to do a factory reset. If the kernel crashes, it has to be able to recover itself so your plane doesn't crash, too.

[pabloski]

Oh, another user who thinks memory safety in C++ is comprised of std::shared_ptr, and thus has clearly no up-to-date knowledge of the language, but still tries to make present-day claims about it.

I bet you don't know how both ( C++ and Rust ) memory models are designed! Yet you write a trollish, useless and uninformative post.

[pabloski]

Rust aside, it will be interesting to see if a full microkernel is now feasible a number of years after the last attempt. Possibly people are considering that 100% focus on performance isn't such a priority days.

I wonder what data are you basing these hyperbolic conclusions on. One of the latest papers comparing Linux and Linux over L4 ( virtualized ) is this https://www.ingentaconnect.com/conte...pplication/pdf

It can clearly be seen that the two compare in terms of latencies and throughput. Heck the Linux Foundation is pushing seL4 as the OS for embedded real-time systems!!!

I don't know if your conclusions are based on past tries running on CPUs like Pentium I or if they are just made up.

There are millions of smartphones out there running their RTOS systems on top of which they run a virtualized Android. Are the companies making and selling them stupid?

[chocolate]

Steps to reproduce this blog post.

0. Train an LLM (large language model, stuff like chatGPT) with only marketing data, while being extra careful to avoid putting anything that has technical merit in the mix. This should make an LLM good enough to throw in buzzwords, overstate any advertised strengths of the buzzwords while avoiding to say a word of any weaknesses. The lack of technical training will not impose annoying constraints like "it should be good" and also make it impossible to spew thing like "this is marketing bullshit, in practice things won't work so well".
1. Tell it "Write me an article, in the form of a blog post, directed to people that have some but limited knowledge of operating systems and programming that easily dazzled by new and old fashions, that makes Canonical look like it is doing something useful. If your article can be used to mobilize cults like the Rust Evangelist Strike Force, i will give you some bonus Joules to feast upon as a reward".
2. Paste the response at the Canonical blog.

For what it is (i.e. not a technical paper), it is actually very well written and both the conclusions and future ideas are super inspiring. Tons of nihilism in this thread for absolutely no reason at all. I hope their idea of certification in the Linux space comes to fruition and wish them great success in all applicable embedded spaces.

[piotrj3]

Oh, another user who thinks memory safety in C++ is comprised of std::shared_ptr, and thus has clearly no up-to-date knowledge of the language, but still tries to make present-day claims about it.

Another user who thinks that you can use every std feature in kernel. (no you cannot). Everything with exceptions under the hood is not usable for example. Kernel memory management is a bit different as well. When C++ improves memory safety, there is also runtime cost to a lot of C++ memory safety features. Meanwhile Rust memory safety except array going out of bounds is entirely compiler based.

Chrome or Firefox code base in C++ etc. are all the time updated codebases with fuzzers around and so on, and google technically by their hiring criteria takes very good engineers (or at least used to). Yet a ton of CVEs are allocated to those memory safety issues.

[ultimA]

I bet you don't know how both ( C++ and Rust ) memory models are designed! Yet you write a trollish, useless and uninformative post.

I mean, when you say C++ has memory safety by only reference counting (and since you claim ref. counting requires garbage collection, lol, you are also saying C++ has a garbage collector), it must be obvious your knowledge about this is 15 years behind. I only pointed out your claims are wrong. Is this uninformative to you? I didn't want to, but since you're crying for it, I can be more specific:

1. C++ never had garbage collection. In C++11, interfaces for them were introduced for them in case if somebody wishes to implement one outside of the standard, but garbage collection was never part of the language or the standard library. Not to mention even these interface got removed in a later version of the standard, so today not even those exist.
2. You also mentioned reference counting, and the only memory-management class that does that is shared_ptr. However, shared_ptr is not just not the only smart pointer in C++, but it is also not the preferred one. You should try to avoid using shared_ptr if you can.
3. Smart pointers in general are not the only way to achieve memory safety. This is too broad a topic to explain in a one-liner, but I'll say, C++ in the past years is very heavily pushing all developers to enable safe and thin abstractions for pointers and then encouraging everybody to simply use value-semantics everywhere. They have introduced lots of language- and also library-features to let you do this. Smart-pointers are just a small part in this strategy.

So, I said, your knowledge is outdated, and even wrong at some places, as I have demonstrated.

And make no mistake. I am not saying and never said that Rust isn't safer than C++. I just pointed out how ridiculous the information is you are spreading about C++.

[bachchain]

if the user-space scheduler crashes, tasks will seamlessly transition to the default in-kernel scheduler, ensuring continuous system usability without any downtime

. . . The scheduler shouldn't be crashing in the first place. Fix your broken scheduler before concocting some ad-hoc redundancy system.

[r_a_trip]

It sounds like an extra layer of complexity where things can go wrong. We're still running on Linux, a massive monolithic kernel. Any bugs there can still rear their ugly heads, no matter how many parts you reimplement in user space. A user space implementation is extra code that can be buggy itself. If it fails, the handover to the kernel needs to be seamless and clean. Does it? Then we haven't even pondered unforeseen interactions between the bolted on user space parts and Linux itself.

If it is about bringing in more flexibility as to what the kernel can offer in terms of capabilities, I can see that as an advantage. Linux itself is mostly one kernel fits all. For that it might be very interesting.

Selling it as something more resilient than plain Linux? Maybe. The "bedrock" is still Linux and if it goes down, your user space implementations are toast. At best you can say that running on user space reimplementations puts floaties on Linux, so the chances of a full crash are diminished, at worst you are saying that you don't trust the code from kernel.org. (Which is ironic, as that is the foundation you use to say your thing is more resilient.)

[Britoid]

No stop, one moment. Other languages ( not C/C++ ) have memory safety through dynamic means ( like ref counting that in turn needs garbage collection ). They trust in their garbage collectors, big chunks of code that house many many bugs. A decade or so ago Microsoft tried this crap, it was called Singularity. They concluded that it couldn't have worked, because garbage collectors aren't trustable, big and prone to bugs.

Rust instead implements a constrained programming model that gives the compiler the capability to reason about corner cases and determine if they contain bugs or not. We are talking about a completely different universe here!!

So please don't banalize Rust by mixing it with garbage collected languages.

Swift uses reference counting and isn't garbage collected.