I believe Rust will benefit from the reality check that kernel development represents.
Kernel development is hard, and bullshit doesn't go very far in that context. Success for Rust in that environment (with some changes along the way) will be a proof of value.
You have a valid point although I wouldn't frame it as adversarial as much as mutually beneficial. There will certainly be some bullshit eliminated from Rust, but I would not be surprised if there is a similar quantity eliminated from the kernel. Even in the most scrutinized C codebase in the world, there are likely memory usage bugs. If Rust can find and eliminate them, while also improving its capabilities, we all benefit.
I think Rust is a good position in the sense that the language and community has a track record and culture of going and solving problems instead of sitting on them forever. I agree that many challenges of kernel development are going to end up strengthening and evolving Rust as a language.
Solving async traits, having a proper concurrency runtime story, reducing the reliance on third party crates to ease error handling does seem to take out forever.
While I agree that these are problems (and, they are being addressed), none of these problems are ones that have to do with Rust in Kernel. The developers actually keep a wishlist of potential or unstable Rust/libstd/libcore/tooling features they'd consider helpful: https://github.com/Rust-for-Linux/linux/labels/prio%3A%20met...
Pretty sure async traits are coming soon (next couple of versions?) which is pretty speedy considering what I understand to be a semi-thorny problem.
> having a proper concurrency runtime story
Do you mean the language/stdlib shipping an async runtime?
> reducing the reliance on third party crates to ease error handling
I for one don't rely on 3rd party crates for error handling often? Anyhow is the most common one I use, but mostly out of habit and laziness, not actual hard requirement....
> Pretty sure async traits are coming soon (next couple of versions?)
No. There are ideas for how to do it, but as far as I know they haven't been tested out yet.
It also relies on pretty large features that are not proposed for stabilization yet (GAT and existential types). When that is done and the implementation strategy is chosen there will also need to be a RFC cycle, a phase of ironing out bugs and finally stabilization.
It'll be ... quite ... a while... I can't see it happening this year.
GATs are apparently very close to stabilization, I think I've seen Rust 1.62 suggested as plausible. So that's a big step towards the likely design of async traits. But sure, async traits is not likely to be this year. Fortunately although for some reason async traits are on pjmlp's must-have list, they're nowhere close to the critical path for Linux, which again is written today in C.
"I think Rust is a good position in the sense that the language and community has a track record and culture of going and solving problems instead of sitting on them forever. I agree that many challenges of kernel development are going to end up strengthening and evolving Rust as a language."
So I picked some ongoing language examples where this isn't quite true.
Isn't it though? I think Rust's processes have done pretty well here. Mara has written somewhere about how effective it is - unlike in a setup like WG21 - to just do stuff in Rust instead of waiting around for some imaginary higher power to grant your wishes, write the code and raise a PR to land your change.
For example, suppose you really want Mutex::unlock(). Right now that's behind the feature gate, but it's not controversial, if you feel like this more explicit function call is helpful you could put the work in to stabilize it and get the gate removed in say 1.61.
[[ Mutex::unlock(guard) is just equivalent to drop(guard) since of course dropping the guard will unlock the mutex which is why you usually don't do either, your guard will go out of scope and get dropped automatically, so the reason to want Mutex::unlock() is that it reads more naturally ]]
In C++ the pointer provenance problem has been sat around for almost twenty years as an unresolved defect in, I believe, C++ 98.
In Rust, Aria was like "We should provide a new API to do provenance in a sound way" and she shipped it (admittedly as a nightly feature, not stable) before I'd finished all the prior reading.
Yes, if all error types from various libraries are `Send` + `Sync` it's easy, if not, you are running into issues where you need to wrap them in reference counted containers because some of them aren't copyable either. Crates like failure, thiserror and anyhow didn't simplify this (although I really like their general approach to wrapping low level errors in high level errors with a breadcrumb trail to details).
I like your input, as critical as it is. Rust is developed by a community/foundation in contrast to C# (Java+). Anders Heilsberg, a brilliant language designer/BDFE can ponder and decide, after careful consideration, top down. Consensus takes time.
> Solving async traits, having a proper concurrency runtime story
Something something let the Java guy cast the first stone.
> reducing the reliance on third party crates to ease error handling does seem to take out forever.
I've written a ton of Rust and I've never used any of these third party error convenience libraries. As far as I'm concerned there is no issue in need of solving around error handling in Rust.
The "please don't offend this language I have intertwined with my own identity with" attitude in modern times is so tragic.
I have always been, and will be, plenty of things, and if it makes you feel good to call me Java guy, when someone criticizes your beloved Rust, please do.
Meh. You often reply prolifically in threads that mention Java, defend/praise it profusely, and also seem to be very knowledgeable about the language as well as the JVM. So it's not entirely an insult when I call you a "Java guy".
But you're over-reading into my defense of Rust. My point is that the specific things you criticized as taking a long time for Rust are not actually taking a long time. My point with poking Java, specifically, is that Java is going on 30 years old and doesn't yet have an analogous feature. Moreover, since we're talking about Kernel dev, do C or C++ have a standard async runtime? Considering that there's little-to-no prior art for doing the kind of async API Rust wants without active garbage collection, I'd assert that it's hard to criticize how long it's taking. Do you know how long it "should" take? If so, how?
The lack of context is a pain. For instance, trying to open a file that doesn't exist just gives the error "file not found" without telling you the path you tried to open.
Fair enough. But that doesn't have to do with the error handling mechanism of Rust, nor would any of these error helper libraries fix that. It's just a criticism of the error type that's actually returned. A Java-style exception can be written that's just as lacking. No language that I'm aware of will automatically include function arguments in its errors/exceptions- it's up to the author of the error/exception type to include that info.
It's ironic that the framing of some parts in the article is that the kernel mindset is arrogance and self-assuredness and that somehow isn't applied to the rust developers approaching an ecosystem that isn't familiar. It reminds me of tourists who visit another country and try to get locals to do things the way they are familiar with as if something is wrong with the locals and their way of life. I generally agree with gkh's response here. It avoids the arrogance in the other way ("why can't these kids roll their own leftpad") and presents a more valid concern, that of the kernel's actual constraints.
The person who is leading this project and making it happen, Miguel Ojeda, is a long-term kernel developer. Whatever your experience might be of other RIIR evangelism, this project initiative is coming from an insider rather than an outsider.
I didn't critique the idea of Rust in linux, I am critiquing the attitude of the rust fellow asking for support of importing generic crates into kernel code and thus adding dependencies (that is, the point of the article).
The article is by Jonathan Corbet, who has been a kernel insider for a very very long time, and is generally a strong proponent of the way Linux does things as a project.
Your example is quite funny and also represents how i would approach the matter of becoming a linux kernel developer.
Even if C is not my primary language of choice, i would definitely try adapt myself to the ecosystem and not the other way around.
You have all the knowledge of other peers, manual, books, all the libraries, the whole ecosystem.. this cant be replaced.
Also there's something else about C nowadays, is the lingua-franca, the latim (or english) of programming languages. We use it to expose api's to others in any other language that want to consume it as a library.
There's something about culture that people often forget in tech.. it's the real backbone of any project that it's on its own feet.. and when you want to enter in a community you will be better of if you learn and adapt yourself into this community culture instead of creating cultural clashes into the community and try to overtake it (be it hostile or not).
People should be aware that this effort will make it possible to create rust-based kernel drivers and that's it. the RIIR folks are delusional and hype fueled and its better if the sane Rust community get away from them or start to get them back into reality as i bet they are not willing to expend 10 or 15 years of their lives rewriting big and complex piece of software for a likely no return as people will tend to keep using the software the have more community and that are stronger.
It's a much better approach for Rust or any other programming language to become research darlings and eventually become the primary ecosystem of a research OS that went well and is the thing that will replace Linux. The language alone wont do it, it must be able to be a contender to UNIX and POSIX, and whatever language that is in such a system will probably be the one that will become the dominant one in such a ecosystem.
Also another good approach is to virtualize the Linux Api like gvisor does is userspace or the fuchsia OS(and even FreeBSD) does in the kernelspace. So that you can create your OS and kernel in the best way you can looking ahead, and have this Linux compat layer where applications dont even need to be aware they are not actually running in Linux.
Yes, i'm sure there's an imaginary opponent downvoting my comment.
Also there's a lot into my comment, and people are not even noticing it in the whole context.
If there's no reason, why people get so upset? just move on if you are not being mentioned, as it will clearly be the case if i'm talking about "imaginary opponents"..
> The one proposing it is a long-time kernel contributor.
I'm not saying anything about people working on it specifically, if you read my comment, there's a clear separation between serious people and the hype crowd (which is not just RIIR, but now also cryptocurrency fellows, etc).. i can't say where the people working on this fits, i don't know them. Don't know from which part of my comment you took that conclusion.
There are quiet, clever, serious people doing the work, like Hoare, Matsakis and the people that are real enginners, i have all the respect for them (and im pretty sure Rust have tons of such a people). To be fair, all languages have all kinds of people but i don't know what happen to some of them that tend to attract a certain type of people more than others, like the feeling a got from Haskell community more often than others (but given the community was much smaller)..
For instance talking about culture, C succeeded exactly because it was a pragmatic language very simple and efficient like their founders to get things done. With this culture, things happened to be done around the language and we have the ecosystem we have today.. it's a great hacker spirit of more humble, hard-working, behind-the-cameras sort of people which i sincerely miss in the days of instagram, tick-tock and tech celebritism.
Anyone who believes that Rust will quickly replace C in the kernel clearly knows very little about Rust or the kernel, and definitely should not be taken as a spokesperson for either.
I suspect that this "RIIR" that you seem to believe is some kind of "movement" is just a random assortment of clueless people posting in random places.
A ruling clique spreads quasi-religious beliefs that boil down to "we're the future!" to prospective followers. The ones who join up, are inspired and push ever intensified (yet even more honest) versions of those beliefs onto others "we must get rid the old thing". In one or two cycles of evolution, their evangelism provokes hostility from the unconverted. Unwilling to confront their own motivations, the rulers ignore how the spirit of their beliefs implicitly sanctioned their adherents misbehavior "technically, no one said they want to destroy the old thing".
A simple pattern that rulers to turn a blind eye to the connection between belief and action.
Ugh yeah, now that you point it out, there was one. To be sure, my internal reaction to that comment was "oh, a troll or a loonie", but maybe they were serious, which is kinda worrying.
>Kernel development is hard, and bullshit doesn't go very far in that context.
I don't know what it is about Linux that makes people say this. Kernel development has most of the same constraints as any other embedded context, which Rust has plenty of focus on. No it's not as mature as C, but few languages are.
Plus if you go looking in the kernel you can still find plenty of bullshit hacky code. It's not special, it's just another random open source software. The quality very much depends on the individual maintainer of that subsystem and how much has been invested in that area.
I work on the kernel for a living, and I find this claim exceedingly dubious. We're currently talking about experimentally supporting modules written in Rust, which is an entirely different beast than replacing pieces of the kernel core. The barrier to entry for drivers is significantly lower, and driver quality can be much, much poorer than the quality of the core kernel.
Many parts of the kernel have been fine tuned for decades, and many of the kernel developers that maintain Linux are also C experts (myself included) who aren't going to slow down development to migrate working code to Rust. It's great that we can experiment and see how Rust goes for driver authors, but they are still bus API consumers, not core kernel.
As I understand it the crucial rationale for drivers is that drivers were anyway necessarily platform dependent which undoes one argument against Rust.
Today Rust does not overlap Linux in terms of platform support. There are (small but very much alive) communities doing Linux on architectures that Rust has no support for and in some cases has no plans ever to support. So this makes drivers the only case where choosing Rust doesn't mean some people lose out, as a platform e.g. with no PCI bus doesn't get to run PCI drivers even if they were written in C.
I expect that over the next say, five to ten years, two things will happen to greatly improve this, maybe to the point where you absolutely could rewrite core Linux code in Rust if you wanted to. Firstly, Rust will get more platform support. Linux doesn't really need Rust's "Tier 1" (Linus doesn't check every kernel release passes tests on all real Linux target hardware as I understand it) but clearly you want Rust to at least build and take patches for every Linux platform some day. Secondly, some older platforms will "rust out". If your community is nursing 30+ year old hardware and increasingly more maintenance work is shared between fewer shoulders at some point "Linux-next" is not a priority and your platform will stop being supported while effort moves to exciting new hardware.
There's active work being done on the rust gcc backend and it's progressing nicely. That should help with some of the platform concerns you (rightly) raised.
> Today Rust does not overlap Linux in terms of platform support.
Nit, I believe actually the Rust and Linux platform sets would be considered "overlapping sets" in the mathematical sense :), since neither is a subset of the other.
e.g. Rust platforms include things like the NetBSD Rump Kernel and Redox and I think one would be hard-pressed to claim that Linux supports those as platforms.
I'm interested in kernel development and I like the idea of working on it for a living.
Can you give more details about your job? What does it consist in? Is it mostly code-review? Or are you responsible for maintaining a part of the kernel.
Who is the entity that pays you, and what are the criteria they'd use to pay a new contributor to work on kernel full-time?
Finally, can you point me to beginner-friendly things to work on to get started? how do I know which part of the kernel I should study and contribute to?
Firefox is getting new "oxidized" component all the time, Rust is the recommended language for both refactoring and new development. Of course the lowest-hanging fruits are addressed first, but that's normal and advisable.
There's a big difference between "We don't employ the language's architects" (so far as I'm aware Mozilla also doesn't employ many WG21 members) and "We don't have any engineers who know this language". In 2022 you'd probably have to go out of your way to hire that many engineers and not get some people who know Rust.
Not to mention how much less experience you need in Rust to not blow everybody's feet off by mistake. I reckon if you have 10 years C++ and six months Rust, any Rust you write is already more likely to deliver reasonable performance without setting everything on fire than your C++. Because of the constant exposure to outright malevolent stinking garbage (in the form of other people's HTML, CSS and Javascript) the browser needs to be exceptionally robust, and C++ just isn't very good for that. So Rust is often a better fit for what Mozilla do.
Yet Chrome and Safari, the browsers that really matter in 2022, won't be moving away from C++.
Chrome folks have been playing with Rust, but seem more keen in improving their C++ static analysis tooling instead.
As for Mozilla, it is 10% of Rust code and lets see for how long Firefox still matters, given the existing 3% market, even EdgeChrome has surpassed it.
> Chrome folks have been playing with Rust, but seem more keen in improving their C++ static analysis tooling instead.
I would say that at this point that's good money after bad. Linus of course also put a bunch of effort into static analysis, that's what "sparse" is.
The thing you run into immediately is that your programming language doesn't express the thing you wanted to analyse very well. So you have to annotate your software (Linux is sprinkled with sparse annotations), and now you've added an extra opportunity for mistakes, because the annotations are transparent to the compiler, so you can write code which analyses as correct but compiles to something incorrect. "Hooray".
Please don't spout nonsense. They did not let go of "everyone related to Rust", large parts of Firefox are written in Rust and those parts obviously need to be maintained. New Rust code continues to be written, as others have pointed out.
What Mozilla did do was lay off many of the people working on Rust itself as their full-time job, as opposed to people who use Rust to do their work at Mozilla. And the Servo team, unfortunately.
As you can see from the breakdown someone posted [0], almost two-thirds of the Firefox codebase is HTML / JavaScript / Python (for tests) / assembly / Java (for Android), none of which is a candidate for being rewritten in Rust to begin with.
If you just look at the portion written in native system languages, Rust is slightly more than 1/3 of that code already and still climbing.
I have a very strong doubt about it because Rust debugging still sucks. No debugger allows you to evaluate function calls AFAIK, which is a very strong restriction.
I see reports of it working for trivial top-level functions with basic parameter types, but what about everything else? Like member functions, trait implementations, etc.
he means in the context of a kernel developer. im sure there is some nerd who would rewrite stuff to prove to themselves and shutup their inner imposter syndrome. but mostly its quite accurate.
ffs dont do it. no its not enough. you will always feel that feeling because you are born into this world and it absolutely makes no fucking sense. so you want to atleast feel competent in one thing. but you wont ever feel competent in life because this whole experience of existing is fucking ridiculous. bla bla computer bla bla ping pong. you are an ape and we are spinning around. imposter in the world. not in knowing a "job" skill. haha you comment is so deep i wanna give you a hug and buy you a beer.
I agree that the parent claim ("Rust will quickly replace C in the Linux kernel") was utterly risible, but your comments just seem like the mirror image of theirs. What on earth is an 'impostor language'? Imposture of what or whom?
I'm tired of having to deal with this culture war crap in our profession. These languages are tools. C, C++, and Rust all compile down to the same LLVM IR (or GCC if you stray from rustc). There are certainly semantic and grammatical peculiarities that affect how each of them do so[0], but by and large running a simple Rust program and a simple C program through Godbolt will do a lot to disabuse you of the idea that the two are irreconcilably different.
To anyone else who wants to write performant Rust, my advice: (1) no_std, if only to focus the mind, (2) .try_foo(), not .foo(), b/c allocation is fallible, (3) always set `opt-level` to at least 1 (1 is far further from 0 than 3 is from 1, ime), (4) use stack-allocated alternatives to heap-allocated types ('smallvec' or equiv vs Vec, 'smolstr' vs String, &c) even at the expense of overallocating buffer space, (5) exploit vectorisation where possible (e.g. SIMD), in general practising mechanical sympathy, and (5) parallelism is not a panacea, whereas cache locality usually is. Measure everything, but also: memorise every instruction and how many cycles it takes, and think in those terms - in terms of your assembled, perhaps-handmodified code - rather than unscientific laptop benchmarks. (Jeff Dean's famous 'numbers every programmer should know' are a good start but are just the very basics, and obv his exact values are long obsolete, in some areas [disk] more than others [CPU].)
[0] These are discussed extremely soberly and intelligently here, for you or anyone else who may be interested: https://kornel.ski/rust-c-speed
It's an impostor because it doesn't belong in the kernel. Or anywhere else for that matter - look at Firefox sources. It just causes fragmentation and its security is yet to be proven. From my POV, it's just written by people too lazy for C and too ignorant for C++.
bah to me people who write C and C++ whine too much should be force sterilised so that us real humans can have peace and quiet and write our machine code and bring our albatrosses to work. like you people who use querty? they should just stop smoking pot and learn to use morse code and why arent phone numbers in hex? its like the world is full of ignorant lazy people. i mean its just my POV. i dont mean i want to promote force sterilisation on C++ and C programmers for being too underdeveloped to function and have a home. i just am talking from my POV you know? anyway good comment.
The issue with Kernel development is that it's a dying profession. Nobody is interested in it. That's why there's an attempt with sexy new language, to bring more developers to work on it.
Probably less than 30 people in the world understand the thing as a holistic entity. From evolutionary terms, there's a giant risk of losing relevant technical knowledge to keep it up in the future.
I do not support adding it to the Kernel, I think we should just throw away the kernel entirely, but I understand why they're looking at Rust.
> The issue with Kernel development is that it's a dying profession. Nobody is interested in it.
That's a pretty wild assertion and files in the face of the highly active kernel development process.
e.g.
> Linus has released 5.18-rc1 and closed the merge window for the 5.18 release... 13,207 non-merge changesets were merged during this merge window.
> I think we should just throw away the kernel entirely
That's the dumbest thing I've see on HN in some months.
The kernel is deployed in hundreds of millions of devices worldwide and continues to be the dominant OS in many many sectors.
The issue is about the # of new developers joining the development if you look at the Linux kernel development as an organization, not about # of non-merge changesets merged.
> That's a pretty wild assertion and files in the face of the highly active kernel development process
No, OP is right. 99.9% of things added to the kernel in any given release are drivers (mostly for obscure server hardware that the average LKML lurker would never have access to). So while there's certainly active development, it's all centered around drivers, and the "kernel" part of the kernel are mostly stable (modulo the occasional greenfield project like eBPF). (Note that I said 99.9% of things added, I'm sure security patches make up a lot more than 0.01% of kernel patches).
> The kernel is deployed in hundreds of millions of devices...
There are billions of Android phones alone. Not to mention the huge numbers of servers, IoT devices, embedded computers, and all the SBCs in my closet.
To be charitable, they may have meant something more like 'personal devices which people use directly'. (Though maybe not - it would be odd to exclude servers, which are one of Linux's biggest 'clients'. Perhaps they meant to exclude the more mundane types: routers, lightbulbs, etc.)
That Linux kernel is full of Google specifics, uses a microkernel like architecture since Project Treble, can be compiled since years with clang, now uses Rust for Bluetooth drivers,...
"The timeline for shifting to an "upstream first" cycle for new features starts in 2023, with 2020-2022 dedicated to making it work for pre-existing functionality. The Pixel 6 is expected to be the first Android device to ship with the GKI and Linux kernel 5.10, marking a major step in this process."
Means this is still one year away, if it actually happens, and then only Pixel devices will support it anyway, as so far most OEMs couldn't care less.
Not to mention that upstream will never accept all the things that make Android Linux not really Linux.
Most embedded/embedded-like devices running Linux are running a modified version of the kernel with a heavily customized userspace. These are still Linux by any reasonable definition. I'll leave it at this.
The kernel isn't dying, it's niche. It always has been and it always will be.
Fortunately for the kernel, despite being niche, it has a rock-solid onramp forcing people to get into it. There will always be companies interested in the n'th degree of performance, both generally, and for some specific hardware. Someone has to go do the relevant kernel work for those things. So while you or I may never touch it, it is effectively impossible for a kernel like Linux to just rot away because nobody cares. It would require first a multi-year, if not multi-decade process of fading first.
It's on most of the smartphones on the planet. Plus it is the dominant server OS. Plus in the top 3 in many embedded categories (a highly diverse set of technologies)
Even if Fuchsia is crapware, Google has the money to keep polishing that ball of mud, and eventually force it as the new version of Android, quality be damned. The rest of the world will have no recourse but to switch. It will be painful for quite a while, but people will survive. I mean, people survive using Windows, and not enough people switch away from that, either.
I’m not saying that Fuchsia is necessarily bad, I’m saying that Google will do anything to get away from GPL code, including, if necessary, forcing Android to Fuchsia. It doesn’t actually matter if Fuchsia is any good.
From what I can see, the Fuchsia kernel is actually quite interesting. I like the foci on (1) capabilities and (2) message passing. It's not the most innovative thing in the known universe - in fact both of those concepts are of pretty late-80s-to-early-90s vintage, from the OOP boom when programmers were misspending their ill-gotten performance gains[0] – but they make a degree of sense. The userspace bits I'm less sure about. Like you say, it seems to be a non-GPL-ed clone of Linux. It's the kind of thing I'd expect of some cheap Chinese company. This kind of fragmentation is emphatically not a good thing for our industry and Google knows it, and I very much hope they don't get away with it, but I suspect its being a clone is exactly why it'll be a very easy transition to force on end-users. Programmers will never in a million years use it on the server side, though.
The biggest obstacle might be drivers. A “server” is defined more loosely than “an Android phone”. An Android phone manufacturer has the incentive to make sure that drivers for that hardware exist in Android, regardless if Android is Linux-based or Fuchsia-based. And Google can make Android switch to Fuchsia, and therefore can control where that incentive leads. Google, however, does not control what runs on servers, and server hardware manufacturers know that if they don’t have a driver in Linux, they won’t sell very much of their hardware, since existing hardware run Linux-based systems.
I meant to say "unikernel." Don't know where that brain fart came from!
> Google, however, does not control what runs on servers, and server hardware manufacturers know that if they don’t have a driver in Linux, they won’t sell very much of their hardware, since existing hardware run Linux-based systems.
I'm not sure if "It's the way things are" is quite the argument its made out to be. Some server hardware is beginning to look more and more like a phone/Chromebook. And things do change. "Not in a million years" was the argument made against Linux compared to the traditional enterprise UNIX vendors and where are they now?
If Linux developers are actually afraid of that, then they should simply switch the license away from the GPL, or dual license it, or do anything else than what they're currently doing.
You might not know, but it’s commonly held not to be practially possible to switch the license of Linux, since its copyright is not owned by a single entity – it is owned in myriads of small portions depending on who wrote that piece. Some of those people have since passed away, their copyrights now being held by their descendants.
Yes I know, I've heard that a lot and it's a weak and harmful comment that kernel people should absolutely not be making. It actually pains me to see it typed again. You don't actually want a software project to be like that, it makes it very difficult to enforce the license when it actually needs to be enforced because you can't get consensus from all the copyright holders. It also increases the risk that some copyright holder (like one of those descendents) goes rogue and you have another Patrick McHardy situation.
If there really was enough reason and will to do it, they would just track down those people, or they would remove that code and replace it with something else. Just like they've done every time in the past when there was copyright problems. Just like any other big open source project has done when licensing became a problem.
It might or might not be a good idea in general to not have a centralized copyright holder entity, but at least it cuts down on the humongous license flame wars, which, incidentally, is what you would get if you actually wanted to go through with an endeavor such as you describe.
Anyway, what Linux developers might be afraid of can not be mitigated by simply switching to an MIT license. What would happen is basically some modern variant of this:
> Probably less than 30 people in the world understand the thing as a holistic entity
As we only have two other "big" (popular) kernels to compare to this one, do you think they (Apple and Microsoft) have more people "holistically" understanding the entire kernel or less? Since the nature of those companies are closed-source, I'm fairly certain even less people understand those ones "holistically".
> I do not support adding it to the Kernel, I think we should just throw away the kernel entirely, but I understand why they're looking at Rust.
How would that work in reality? Re-use the existing tests to build a new kernel from scratch? Sounds like a very far-out idea that wouldn't help with any of the current problems, but I'm happy to entertain the idea and hear your reasoning here.
> How would that work in reality? Re-use the existing tests to build a new kernel from scratch? Sounds like a very far-out idea that wouldn't help with any of the current problems, but I'm happy to entertain the idea and hear your reasoning here.
While I would tend to agree that a full production replacement would be such a massive undertaking as to be impractical, https://github.com/nuta/kerla does something very like that - Linux userspace ABI on an all-new Rust kernel. (And even at this small scale, I find it mind-blowing that this worked)
AIUI, you can still build a minimal kernel that's easily understood as a whole. And patches to shrink the minimal build even further are highly sought after because they expand the usability of Linux in deeply embedded environments.
Oh no. We have some early career devs that put up patches to the kernel recently. They were super excited about getting to do that work, and it was a big day for them - as it should be it's awesome.
I guess I need to go let them know they are Nobodies. oxff said so.
There may not be many “big and professional” operating system projects but, at the hobby level, it seems that there is a lot of interest in kernel dev actually.
HaikuOS, SerenityOS, Redox, and ReactOS are all going strong. The BSDs continue to advance as well. Redox is written in Rust even.
I believe Google sees Fuschia as a true Linux competitor.
When you say “we should just throw away the kernel entirely”, what are you suggesting?
> The issue with Kernel development is that it's a dying profession. Nobody is interested in it.
That's simply false. I'd love to work on the kernel. I have immense respect for the people who work on it. Only reason I haven't tried contributing code is I don't think I'm skilled enough.
> 30 people in the world understand the thing as a holistic entity
Probably a lot more than 30. There are probably more than 30 PhD students studying kernels at this very minute. However, I think you're right that no one is interested. People greatly underestimate the effect the kernel has on the full OS. They think it's "just" the kernel. This is why so many people keep saying that Windows will get a Linux kernel in Windows 10, no, 11, no, 12, etc. It's just a "kernel", like a grain of corn, something insignificant. So there isn't much interest in working on kernels. It's as unsexy as it gets.
Kernel development is hard, and bullshit doesn't go very far in that context. Success for Rust in that environment (with some changes along the way) will be a proof of value.