71 ms·

Rustaceans at the border

260 points by bitcharmer 5y ago

jstimpfle 5y ago
In my eyes, the problem isn't precisely whether some components are downloaded separately. What I find problematic is the idea of giving up responsibility by dependending on separately developed components. Components written with more than just one particular project in mind are tough to change. Integrating them into a particular project often requires workarounds and some imperfect abstractions to make things fit, and there tends to be a proliferation of blind spots about "global optimization potential". Not to drag on Rust, but I can see a "global optimization" problem when I try to cargo build a moderate Rust project and have to download hundreds of transitive dependencies, and have a good chance of ending up not building a thing (for reasons that probably include my own incompetence, but still). There are of course tons of C projects that have similar problems in a way - the number of dependencies might be lower but I have to hunt them manually. But well-engineered projects are at most a handful of clearly identifiable dependencies, and everything will generally build without fuss. This is how it is with the Linux kernel today. The main dependency of the Linux kernel is gcc, and as far as I perceive, communication between Linux and gcc projects is alive. I think there is a lesson that can be learned in particular from C development: There is value in growing a system vs mainly integrating existing stuff (junk or not). The larger a project gets, the more sense it makes for it to bring its own tools and implementations so it can continue to build and be maintained as a whole without a lot of complications. This might be the difference between a huge project and an ecosystem, and the question is where are people aiming with Rust support? If it's just about drivers I can see some limited value in the ecosystem approach but it will be a tough sell for any Rust driver that wants its 'M' in the kernel config.
- kibwen 5y ago
  > Components written with more than just one particular project in mind are tough to change. Even in the very worst-case scenario, you can fork the code. That would still leave you far ahead of having to write everything you need from scratch. And my experience is that plenty of libraries are happy to support general use cases when at all possible. > and have to download hundreds of transitive dependencies, and have a good chance of ending up not building a thing Can you give an example of what you mean by this? I'm unclear what the concern is regarding the idea of "not building a thing". > as far as I perceive, communication between Linux and gcc projects is alive The Rust developers also have open and active lines of communication to the Linux developers. > The larger a project gets, the more sense it makes for it to bring its own tools and implementations so it can continue to build and be maintained as a whole without a lot of complications. Certainly, but even very large projects benefit from sharing code in foundational areas.
  - jstimpfle 5y ago
    >> Even in the very worst-case scenario, you can fork the code. You can fork the code that you never knew well enough to write yourself. >> and have to download hundreds of transitive dependencies, and have a good chance of ending up not building a thing > Can you give an example of what you mean by this? I'm unclear what the concern is. My concern is of course that as someone who wants, or is supposed to, mess with a project, I can easily get depressed if I have to invest significant to infinite amounts of energy to bring that project to build. And if I get it to build, have a hard time figuring out how it works because what it does is all over the place, hidden in hundreds of libraries. > Even very large projects benefit from sharing code in foundational areas. "Other crates that I'd like: anyhow, bincode, byteorder, log, once_cell, pin-project, rand, serde, slab, static_assertions, uuid plus some more esoteric ones."
    - kibwen 5y ago
      > You can fork the code that you never knew well enough to write yourself. Certainly. It is hard to envision any circumstance where one is worse off for having the opportunity to stand on the shoulders of giants rather than having to invent the universe from scratch. > I can easily get depressed if I have to invest significant to infinite amounts of energy to bring that project to build Can you give an example of a Rust project where you have had this experience? Nearly every Rust project is as simple to build as `git clone && cargo build`. The exceptions are those with C dependencies, where you will need to turn to your C package manager (apt, etc.) to first install the C dependencies, and it's hard to claim this as a weakness of Rust relative to C when it's no worse than what you'd get in a pure C project. > Other crates that I'd like: Can you be more specific about which of these crates provides functionality which you do not think qualifies as generally foundational?
      - jstimpfle 5y ago
        > Can you give an example of a Rust project where you have had this experience? Trying to make a better experience I just randomly picked "Weylus" from Github's rust/trending list and wasted more than 1 hour building it on Windows 10 and Debian Bullseye, ultimately quitting both. Yes, it was a lot of C library related issues, but also other executables missing, like tsc, or in case of Windows, make. On both systems, the number of transitive dependencies was about 300, and so I guess it was inevitable that there were going to be some problems. I've had similar problems before that trying to build other, less ambitious programs than Weylus using cargo. > it's hard to claim this as a weakness of Rust relative to C when it's no worse than what you'd get in a pure C project. It seems to me that making it more reliable to depend on other modules (like cargo does) does not lead to easier to use projects, since it doesn't change the amount of bullshit that most developers and users are willing to endure. This is an instance of Parkinson's law and I think it was already a learning from the node.js ecosystem. As a consequence, with a system like cargo programs end up having far more dependencies (which is empirically true), but the programs aren't easier to build by a random user. For developers, the situation is changed compared to e.g. C, in that it is easier to add more dependencies before the software becomes unmaintainable. This might shift the development situation to a place where the average developer in this ecosystem is more competent in plumbing things than understanding the problems and coming up with reliable solutions that are easy to maintain without a system like cargo. I'm not sure if this is good or bad - probably it's an evolution that can't be stopped, and which creates new types of developers. What I'm saying is I'm not positive that this attitude is compatible with a central piece of infrastructure, like the Linux kernel is. > Can you be more specific about which of these crates provides functionality which you do not think qualifies as generally foundational? I'm not a Rust developer and I don't know any of these, but looking at those names I'm wondering: which is not some arbitrary helper thing, where it would be easy to maintain an alternative in-tree? At least that's better than each developer bringing their own slightly different preference, resulting in more bloat and maintainability problems.
deleted 5y ago
[deleted]
colonwqbang 5y ago
The kernel today has its own complete standard library of data structures and threading primitives for C. In general I find these much more well-designed and pleasant to use than the user-space C standard library. Give me work queues and kfifos over pthreads any time! Maybe the rust devs can also learn something worthwhile from working with the kernel community.
- klysm 5y ago
  I think this also aligns with one of the comments in the article that suggests we should pursue a more unified kernel space and user space.
  - colonwqbang 5y ago
    Some constructs from the kernel are maybe not so relevant to use in userspace. Spinlocks are great in the kernel where we can just mask interrupts. Not so fantastic in userspace. Intrusive linked structures are necessary in the kernel since they let us manipulate collections without allocating. But they are also less convenient. Etc. However, I'm sure there are lots of things which could be useful in both places. I have from time to time toyed with the idea of porting the kernel "standard library" API into userspace. Maybe something like that already exists?
    - klysm 5y ago
      I'm not aware of a version of it available in user space, but at least there is a useful subset which could probably be extracted. At the same time though, having two consumers of the API means more thought needs to go into changes.
parentheses 5y ago
Rust is in an interesting position, where like C or C++, it's capable of solving very low-level problems. At the same time, it's got a lot of "modern" language features. The kernel being literally the "bottom" of a system presents a challenge as this space rejects complexity and tooling variety that is intrinsic to "higher-level" languages.
- samhw 5y ago
  Could you say in concrete terms what you think is not going to work? This just feels like a jumble of spatial metaphors. I don't see why it matters whether Rust or C are 'high' or 'low' level languages, or how that relates to the kernel being at the 'bottom' of the operating system.
ilaksh 5y ago
This should be a hint to at least some of them that we need a new operating system rather than dragging the old one kicking and screaming into the 21st century.
caslon 5y ago
It's incredible, isn't it? Just as web developers, of all people, are finally, after over a decade, coming to the conclusion that arbitrarily-packaged dependencies are a bad idea for so many obvious reasons, Rust developers are trying to replicate NPM in the kernel. I was told that Rust in the kernel would be a good thing, and that not much would change. If these are the types of people who are writing Rust for the kernel... can we go back? I really want to go back.
- 12baad4db82 5y ago
  You could argue that there are some crates in the Rust ecosystem that suffer from a deep dependency tree, I don't think you can argue that Rust developers are trying to do this for the kernel. The article states: > The Rust-for-Linux developers understand this situation and are not envisioning adding the ability to pull in modules with a tool like Cargo
  - nullc 5y ago
    > You could argue that there are some crates in the Rust ecosystem that suffer from a deep dependency tree Some? Dependency graphs of well over a hundred packages are ubiquitous. I've long since stopped being surprised when I compile a rust package that makes no network connections and see it (indirectly) pulling in multiple HTTPS libraries.
    - Grimburger 5y ago
      > well over a hundred packages Tad understated. Popular rust http frameworks with basic functionality are hitting 300+ deps straight off the bat easily. For the security conscious, move to vendoring or alias cargo to always run in offline mode.
    - 12baad4db82 5y ago
      Right, great example. I think 'understand the situation' refers to this. I imagine the Rust for Linux developers would be going through any dependencies they pull in with a fine comb, in this case a dependency that pulls in HTTPS libraries for presumably no reason should be rejected. If that particular dependency makes it into the kernel, well, then you can start complaining about it. But right now feels a bit premature.
proto_lambda 5y ago
I can sympathize with the need to have all required source code in the repository and not having to fetch a bunch of dependencies at build time. Thankfully, cargo already offers a solution here: `cargo vendor` will download all the specified dependencies once into a local directory, which can then be checked into the source tree. This maintains cargo's dependency resolution/update checking/etc, but also allows for all dependency code to be kept alongside the kernel code and audited accordingly.
- lodovic 5y ago
  Requiring packages to build the kernel source feels like a circular dependency to me. The kernel should contain all of its own source code.
  - nrabulinski 5y ago
    So now a kernel cannot depend on anything? What about all the tooling that’s required like python, perl and many others or the fact that you have to have a working machine with the kernel already on it to build the kernel?
    - yjftsjthsd-h 5y ago
      Obviously you have to bootstrap from something. A more interesting case is NetBSD, which can bootstrap from just about anything; take a NetBSD src checkout, run ./build.sh, and it will first use the local tooling to build its own dependencies, then use those to build the system. So in some OSs, yes, you can more or less vendor in the universe. But that only works because *BSDs are developed as full systems, not just a kernel; Linux probably can't (and arguably shouldn't) do that.
- humanrebar 5y ago
  Will there be a massive review process every time someone updates the vendored dependencies? Or will each dependency change be reviewed one release increment at a time? What happens if a dependency adds a system call something? Libraries intended for kernel-friendly use cases really need that scope to be an intentional goal.
jrimbault 5y ago
> The kernel has to stand alone Why ? (un-opionated "why") To reuse the migrant melting pot metaphor used at the end of the article, the "kernel has to stand alone" seems to mirror the states wanting a "strong border" (while the idea of borders and states has a beginning and will surely end).
- BlueTemplar 5y ago
  Using this metaphor, wouldn't the kernel be more akin to a military base ?
- humanrebar 5y ago
  It makes it easier to get a kernel working on a bare bones system for one. If things get complex enough, step one of getting Linux working on a new architecture will always involve getting a cross compiler working.
- rocqua 5y ago
  I can imagine there are plenty of cases where people build a linux kernel that was moved to an air-gaped server over sneaker-net. Or someone who wants to build linux on some SoC that doesn't even really have an internet connection. I think in your view in melting pot metaphore 'Kernel has to stand alone' might be a lot like christian countries holding the view "Sunday is a forced day of because it is the day of the lord". Whereas I think it might be more like e.g. the Netherlands having the cultural idea of "we should actually work together to prevent the entire country flooding". Or maybe the Spanish "taking a break during midday is smart, not lazy". Its a cultural preference that arises as an adaption to the specific geographic reality of the country.
geijoenr 5y ago
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.
- oxff 5y ago
  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.
  - zozbot234 5y ago
    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.
  - unmole 5y ago
    > That's why there's an attempt with sexy new language, to bring more developers to work on it. At no point did any active kernel developer express any such sentiment. Nobody is worried about not being unable to attract new blood.
    - pohl 5y ago
      It's only spoken of in knowing glances, like Voldemort.
  - capableweb 5y ago
    > 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.
nullc 5y ago
I can't think of anything that could more effectively discredit the effort to use rust in the Linux kernel than suggesting using crates.io/cargo -- I had to check the dates just to make sure this wasn't a delayed April first post. But I guess some people just really want the unicode ukrainian flags being appended to every email they send or something and are too lazy to implement it themselves. :P
- ratorx 5y ago
  Why does a single bad idea discredit an entire language being included? If someone suggested including a C dependency manager in the kernel, does that mean that the use of the entire C language in kernel should be discredited? It is fair to say that the developer suggesting it (especially considering some of the proposed crates they want) has some massive misconceptions about the constraints of current Linux kernel development though.
  - sanderjd 5y ago
    Yeah, my stance on this is that it probably makes sense to pull some libraries into the tree that would be useful in kernel development and which have comprehensible dependency trees such that everything could be reviewed and audited. But then I saw the quoted list and thought "oh this doesn't seem like a very serious proposal".
- xorvoid 5y ago
  Same thought. Seriously, what a great way to trigger some senior kernel dev to come down and straight veto rust with some rant about how it’s “worse C++” Rust is very slowly winning (but it’s a really hard space and this is impressive). But some people have to come and try snatching defeat from the jaws of victory. (sigh)
- OskarS 5y ago
  Indeed. The comment cited in the article is pretty stunning: > Other crates that I'd like: anyhow, bincode, byteorder, log, once_cell, pin-project, rand, serde, slab, static_assertions, uuid plus some more esoteric ones. This makes Rust devs look infantile, with no real understanding of what it means to develop for the kernel. Or what it takes to develop security and performance critical software of any kind, frankly.
enriquto 5y ago
Rust is alright as a language, but cargo is extremely scary. I hope a culture of coding in rust outside of the cargo "ecosystem" develops. The current situation is alienating to reproducibility-oriented developers.
- Ar-Curunir 5y ago
  I hope that never ever happens. We don't need a C-like mess where every library has a bespoke build process that doesn't work across OSes.
  - proto_lambda 5y ago
    OP seems to be conflating the concepts of cargo (the rust build system with dependency management functionality) and crates.io (the main and default package repository today). It is totally possible to use cargo without ever touching crates.io, but if you need any dependencies you'll of course have to provide them through some other means (local file system, git repositories, or a custom package repository).
    - mort96 5y ago
      Cargo defaults to downloading stuff from crates.io. I certainly wish cargo was just a build system which doesn't care where you get your packages from, but that's not what it is.
      - steveklabnik 5y ago
        Cargo does not care where you get your packages from, but it does have a default place. If you don't like it, it is easy to change.
        mort96 5y ago
        That... is caring where I get packages from. Something like make or cmake doesn't care at all how packages end up on my drive. Almost everyone uses cargo in a way which makes cargo automatically download them from the web.
throwaway15908 5y ago
Tangetial question: Seen all the recent supply chain attacks, is there a way to defend FOSS projects with something like project defined capabilities for every third party dependency? So eg. you could include a math lib and mask everything regarding filesystem or network, etc? Especially for rust i would like to see a holisitic solution to this growing thread, facing the accelerating trend of central repositories.
- cillian64 5y ago
  This is more plausible for a language with a runtime like Python. But Rust is fundamentally designed to be a systems language where you have full access to everything (and, if you use unsafe, raw access to memory and arbitrary code execution). It’s hard to imagine how you’d add a sandboxing layer to the language, it seems more like something the OS would have to do for you.
  - throwaway15908 5y ago
    On a broad scope, you could solve this at compile time. The source simply does not compile when filesystem or networking crates/builtins are not defined. If you want to have more fine grained white listing, like only grant access to a certain directory, this could get really messy quick, trying to solve this at compile time.
    - oconnor663 5y ago
      You'd probably have to start by banning unsafe code in general, but then whitelisting/allowlisting specific versions of specific crates that are allowed to use it, so that at least the most popular dependencies don't break.
- mkj 5y ago
  My rough understanding is that Caja for JavaScript kind of did that. Libraries didn't have access to the whole scope, could only access what they were given via capabilities. https://en.wikipedia.org/wiki/Caja_project https://en.wikipedia.org/wiki/Caja_project
spaintech 5y ago
OMG, here comes a bunch of bloat into the kernel. I like rust (well, the idea and principle) but when you are doing low level stuff, something as trivial as a structure to bind an address then manipulate those bits by writing to them (enabling and disabling features) it becomes a no go. If you even consider how exhaustive it is to manage OBMR at this level of code, it becomes counter productive, not to mention unreadable. Now for the bloat part, take a simple code (one of their examples) which is a showcase of their capabilities and “zero cost” abstraction for something like embedded, their blinky app is like 100KB versus a initialize the clock/ set GPIO to read mode, and write to it that come out shy of 4K in C++ with all the hall form STM for example. Object lifetime analysis is really cool at compile time, but any un defines behavior is still present when you compile the code… Show me someone doing a baremetal implementation of blinky (that is, no HAL) on rust or a struct for bit banging and I’ll be a believer that you can do “some” of the stuff needed for kernel development but not all.
- PoignardAzur 5y ago
  "Please show me some amazing features of your language but I'll still believe your language sucks". That's, uh, not a very compelling request.
- varajelle 5y ago
  > their blinky app is like 100KB I just compiled the blinky example for a cortex m4 board (the example in the rust hal crate for that board, not using any unsafe), and the striped binary is 420 bytes. So you probably want to review your stence, because you're about 3 orders of magnitude off.
  - spaintech 5y ago
    Yes its 420 bytes, which is why I’m commenting as my fingers played me on my thoughts. Do the same for one writer in C++ and report back on the orders of magnitudes… Cheers!
  - AnyTimeTraveler 5y ago
    I am currently working with the ATTiny85 and the stripped blinky binary is 275 bytes. I was worried that the ATTiny85 wouldn't have enough flash space (6K) for Rust and now I don't know what to do with all that free space :)
scoutt 5y ago
Building the kernel shouldn't require an internet connection.
- kibwen 5y ago
  Building Rust code, and even using Cargo, doesn't require an internet connection.
  - jvanderbot 5y ago
    ah, yes it does? 'cargo build' absolutely goes and finds dependencies, updates them, and so on. 'rustc' does not, but we are talking about cargo here.
    - miloignis 5y ago
      It doesn't have to, you can "cargo vendor" all your deps (I do so for some of the things I work on, regularly building and developing without an internet connection).
    - KptMarchewa 5y ago
      https://doc.rust-lang.org/cargo/commands/cargo-vendor.html https://doc.rust-lang.org/cargo/commands/cargo-vendor.html
    - estebank 5y ago
      https://doc.rust-lang.org/cargo/faq.html#how-can-cargo-work-offline https://doc.rust-lang.org/cargo/faq.html#how-can-cargo-work-...
    - deleted 5y ago
      [deleted]
    - jvanderbot 5y ago
      OK, I have been sufficiently reminded of a mostly-offline build process and punished for my flippant remark which I can no longer edit or delete. Thank you!
- 5y ago
gquery 5y ago
- zozbot234 5y ago
  > Some of them have been directly involved in cancelling non-native English speakers over pronouns. This is the kind of claim that could do with a source. In general, it seems Rust is rewarding enough and complex enough to master that people just don't pay much attention to the silliest kinds of 'activism' compared to other dev communities.
simion314 5y ago
Still makes no sense to me to spend energy into pushing Rust into Linux instead of creating some new better kernels, I mean having some of this big companies paying a few experts to do such a kernel and keep compatibility with user applications. If Rust is much better then C and adding on top the fact you start fresh with no baggage you should get a better Linux and everyone would use it since is safer and faster especially on servers. I don't know of such a Rust kernel being worked on that is not some hobby side project but something more like Servo was, where you have paid experienced in domain developers.
- proto_lambda 5y ago
  "starting fresh with no baggage" also means starting fresh with no drivers. Having drivers for a wide range of hardware is a major factor in operating system adoption.
  - psychoslave 5y ago
    Didn't FreeBSD incorporated an interface that allow to use Linux drivers? Not that I think it would make the point of having a bright new kernel easily compete with such a huge and firmly grounded project as Linux though. All the more, there already are multiple projects using Rust to build OSes out there, if I'm not mistaken.
  - simion314 5y ago
    I was not suggesting this kernel to be used on laptops, it would be a server kernel, if it would actually be faster and safer then Google and Amazon will use it on their servers and they will make sure there are drivers, Google could use it in some mobile devices too if they care for safety. AMD has an open source driver so if desired that could be ported to Rust to also make sure the GPU is safe.
    - xxpor 5y ago
      Things work the opposite way. In order to get companies to adopt things you need to get people working their interested in it. Which means they need to be able to run it on their PCs. There's a reason why x86 ate the world. The exception to this is when you can develop something and have a good case to use it yourself, like Google and Fuchsia. But I doubt Fuchsia will gain wide organic adoption because of the same factors.
2wrist 5y ago
Thats a really well written article, nicely balanced. I also agree, it can be great opportunity to learn.
fmajid 5y ago
Rust’s cavalier attitude to language and compiler stability, their absurd bootstrapping situation and limited platform support, not to mention their belief that “curl something|bash” is acceptable procedure are all reasons why I’ve avoided it despite the many good qualities of the language.
- jopsen 5y ago
  Aren't many of those things stuff that can be fixed as the ecosystem matures? Is C ecosystems much better?
- humanrebar 5y ago
  I wouldn't phrase my concerns that way, but it is concerning that Rust doesn't do LTS releases (someone correct me if I missed something here). Because C compilers, make, etc. are really stable, existing Linux source tarballs have a habit of building fine for decades after initial release.
  - tialaramex 5y ago
    In what sense is Rust 1.0 not already an LTS release ? If you wrote some Rust 1.0 code back in 2015, put it away in a drawer (maybe on a USB stick) but now get it out today it will still build with current Rust tooling -- except for some very narrow cases where you might have done something inherently unsound and subsequently the compiler was corrected to fix that so it's an error. Rust's language shifted slightly in those years. However the Editions system - even though it hadn't yet been invented in 2015 - allows for that. Your 2015 code lacks any Edition metadata, so, the modern tools understand that as Rust 2015 edition, and will compile accordingly, while still interoperating correctly with modern Rust. Suppose your 2015 code named a variable await. That's a keyword in modern Rust. But it isn't a keyword in Rust 2015 edition, so your code compiles just fine. This would not work in C of course, which is why its newer keywords are ugly stuff like _Bool but in Rust it's fine.
    - humanrebar 5y ago
      Modern releases of GCC still support C89. If rustc, at least, will keep supporting 1.0 features for all future releases, I guess that's fine. But that also means that crates used by the kernel would need to likewise be conservative about updating to new Editions so as to not break expected support surfaces.
oxff 5y ago
I don't think people should be looking at adding another language to the kernel, mostly because every OS build on it has been a disaster. We just need approach and definition for operating systems.
- samhw 5y ago
  > I don't think people should be looking at adding another language to the kernel, mostly because every OS build on it has been a disaster. We just need approach and definition for operating systems. What does "we need approach and definition for operating systems" actually mean? (If you know, that is.) Also, it's the Linux kernel, not just the kernel. There are more than one, and every operating system has one[0]. You might be interested in looking at the Mach kernel (Apple[1]) or Google's new Zircon kernel (in Fuchsia). Both of those are microkernels, and as such minimise the amount of work that the kernel does, as well as removing drivers to userspace. Inasmuch as I can extract any meaning from your comment, it seems like your problem might be with the size and scope of Linux's kernel, in which case those might appeal to you. [0] I'm sure this absolute claim will summon someone to point out some recondite 1980s operating system that doesn't have a kernel. [1] Yes, yes, used by Apple.
HidyBush 5y ago
I already loathe the fact that I need Perl to compile the kernel just because people are too lazy to rewrite a few parsing scripts in C. The moment Rust is introduced in Linux without being a complete replacement is the day I leave for greener pastures
- sophacles 5y ago
  Why haven't you rewritten those parsing scripts you loathe so much? Since you haven't, it seems a bit ironic that your are complaining about those who didn't.
- deleted 5y ago
  [deleted]
- bitcharmer 5y ago
  I agree on the Perl requirement bit but see Rust as a complete replacement for C or at least great alternative in systems engineering domain in the long term.
  - HidyBush 5y ago
    Please read again my comment. If tomorrow all the Linux C codebased switched to Rust I would have almost zero problems about it. My problem stems from having multiple toolchains to build the foundations of an operating system.
    - bitcharmer 5y ago
      The expectation for the switch to happen overnight in its entirety is very unrealistic.
IYasha 5y ago
So, I assume soon there'll be a pure-C kernel fork and some distributions adopting it. And I'd switch to that.
- orf 5y ago
  Why?
  - IYasha 5y ago
    Because there are many people who oppose mandatory Rust integration. For various reasons, not just plain dislike of Rust itself. And, for example, there's a Libre Kernel that is blob free and it has its users. There might be an audience for Rustless Kernel too.
    - samhw 5y ago
      I think they meant "why?" as in "what reason do they have?", rather than "do there exist people who think that?". I don't really care what tool was used to generate my assembly, and the kind of Rust that will be written in a kernel context[0] will - I guarantee you - produce virtually identical assembly to C. [0] i.e. no standard library ('no_std'), no unwinding panics, no dynamically sized types, &c.
- bitcharmer 5y ago
  It might, and if so you will switch but a very small minority of Linux users ever have the need to compile it themselves and out of that small minority only a small fraction will migrate to alternatives over this. I see Rust as a replacement for C long term. From this perspective it's absolutely ok to have a transition period (years in fact) where there are multiple toolchains used to build the kernel.
Bessie69 5y ago
[dead]

260 points by bitcharmer 5y ago

In my eyes, the problem isn't precisely whether some components are downloaded separately. What I find problematic is the idea of giving up responsibility by dependending on separately developed components. Components written with more than just one particular project in mind are tough to change. Integrating them into a particular project often requires workarounds and some imperfect abstractions to make things fit, and there tends to be a proliferation of blind spots about "global optimization potential". Not to drag on Rust, but I can see a "global optimization" problem when I try to cargo build a moderate Rust project and have to download hundreds of transitive dependencies, and have a good chance of ending up not building a thing (for reasons that probably include my own incompetence, but still). There are of course tons of C projects that have similar problems in a way - the number of dependencies might be lower but I have to hunt them manually. But well-engineered projects are at most a handful of clearly identifiable dependencies, and everything will generally build without fuss. This is how it is with the Linux kernel today. The main dependency of the Linux kernel is gcc, and as far as I perceive, communication between Linux and gcc projects is alive. I think there is a lesson that can be learned in particular from C development: There is value in growing a system vs mainly integrating existing stuff (junk or not). The larger a project gets, the more sense it makes for it to bring its own tools and implementations so it can continue to build and be maintained as a whole without a lot of complications. This might be the difference between a huge project and an ecosystem, and the question is where are people aiming with Rust support? If it's just about drivers I can see some limited value in the ecosystem approach but it will be a tough sell for any Rust driver that wants its 'M' in the kernel config.

kibwen 5y ago
> Components written with more than just one particular project in mind are tough to change. Even in the very worst-case scenario, you can fork the code. That would still leave you far ahead of having to write everything you need from scratch. And my experience is that plenty of libraries are happy to support general use cases when at all possible. > and have to download hundreds of transitive dependencies, and have a good chance of ending up not building a thing Can you give an example of what you mean by this? I'm unclear what the concern is regarding the idea of "not building a thing". > as far as I perceive, communication between Linux and gcc projects is alive The Rust developers also have open and active lines of communication to the Linux developers. > The larger a project gets, the more sense it makes for it to bring its own tools and implementations so it can continue to build and be maintained as a whole without a lot of complications. Certainly, but even very large projects benefit from sharing code in foundational areas.
- jstimpfle 5y ago
  >> Even in the very worst-case scenario, you can fork the code. You can fork the code that you never knew well enough to write yourself. >> and have to download hundreds of transitive dependencies, and have a good chance of ending up not building a thing > Can you give an example of what you mean by this? I'm unclear what the concern is. My concern is of course that as someone who wants, or is supposed to, mess with a project, I can easily get depressed if I have to invest significant to infinite amounts of energy to bring that project to build. And if I get it to build, have a hard time figuring out how it works because what it does is all over the place, hidden in hundreds of libraries. > Even very large projects benefit from sharing code in foundational areas. "Other crates that I'd like: anyhow, bincode, byteorder, log, once_cell, pin-project, rand, serde, slab, static_assertions, uuid plus some more esoteric ones."
  - kibwen 5y ago
    > You can fork the code that you never knew well enough to write yourself. Certainly. It is hard to envision any circumstance where one is worse off for having the opportunity to stand on the shoulders of giants rather than having to invent the universe from scratch. > I can easily get depressed if I have to invest significant to infinite amounts of energy to bring that project to build Can you give an example of a Rust project where you have had this experience? Nearly every Rust project is as simple to build as `git clone && cargo build`. The exceptions are those with C dependencies, where you will need to turn to your C package manager (apt, etc.) to first install the C dependencies, and it's hard to claim this as a weakness of Rust relative to C when it's no worse than what you'd get in a pure C project. > Other crates that I'd like: Can you be more specific about which of these crates provides functionality which you do not think qualifies as generally foundational?
    - jstimpfle 5y ago
      > Can you give an example of a Rust project where you have had this experience? Trying to make a better experience I just randomly picked "Weylus" from Github's rust/trending list and wasted more than 1 hour building it on Windows 10 and Debian Bullseye, ultimately quitting both. Yes, it was a lot of C library related issues, but also other executables missing, like tsc, or in case of Windows, make. On both systems, the number of transitive dependencies was about 300, and so I guess it was inevitable that there were going to be some problems. I've had similar problems before that trying to build other, less ambitious programs than Weylus using cargo. > it's hard to claim this as a weakness of Rust relative to C when it's no worse than what you'd get in a pure C project. It seems to me that making it more reliable to depend on other modules (like cargo does) does not lead to easier to use projects, since it doesn't change the amount of bullshit that most developers and users are willing to endure. This is an instance of Parkinson's law and I think it was already a learning from the node.js ecosystem. As a consequence, with a system like cargo programs end up having far more dependencies (which is empirically true), but the programs aren't easier to build by a random user. For developers, the situation is changed compared to e.g. C, in that it is easier to add more dependencies before the software becomes unmaintainable. This might shift the development situation to a place where the average developer in this ecosystem is more competent in plumbing things than understanding the problems and coming up with reliable solutions that are easy to maintain without a system like cargo. I'm not sure if this is good or bad - probably it's an evolution that can't be stopped, and which creates new types of developers. What I'm saying is I'm not positive that this attitude is compatible with a central piece of infrastructure, like the Linux kernel is. > Can you be more specific about which of these crates provides functionality which you do not think qualifies as generally foundational? I'm not a Rust developer and I don't know any of these, but looking at those names I'm wondering: which is not some arbitrary helper thing, where it would be easy to maintain an alternative in-tree? At least that's better than each developer bringing their own slightly different preference, resulting in more bloat and maintainability problems.

deleted 5y ago

[deleted]

colonwqbang 5y ago

The kernel today has its own complete standard library of data structures and threading primitives for C. In general I find these much more well-designed and pleasant to use than the user-space C standard library. Give me work queues and kfifos over pthreads any time! Maybe the rust devs can also learn something worthwhile from working with the kernel community.

klysm 5y ago
I think this also aligns with one of the comments in the article that suggests we should pursue a more unified kernel space and user space.
- colonwqbang 5y ago
  Some constructs from the kernel are maybe not so relevant to use in userspace. Spinlocks are great in the kernel where we can just mask interrupts. Not so fantastic in userspace. Intrusive linked structures are necessary in the kernel since they let us manipulate collections without allocating. But they are also less convenient. Etc. However, I'm sure there are lots of things which could be useful in both places. I have from time to time toyed with the idea of porting the kernel "standard library" API into userspace. Maybe something like that already exists?
  - klysm 5y ago
    I'm not aware of a version of it available in user space, but at least there is a useful subset which could probably be extracted. At the same time though, having two consumers of the API means more thought needs to go into changes.

parentheses 5y ago

Rust is in an interesting position, where like C or C++, it's capable of solving very low-level problems. At the same time, it's got a lot of "modern" language features. The kernel being literally the "bottom" of a system presents a challenge as this space rejects complexity and tooling variety that is intrinsic to "higher-level" languages.

samhw 5y ago
Could you say in concrete terms what you think is not going to work? This just feels like a jumble of spatial metaphors. I don't see why it matters whether Rust or C are 'high' or 'low' level languages, or how that relates to the kernel being at the 'bottom' of the operating system.

ilaksh 5y ago

This should be a hint to at least some of them that we need a new operating system rather than dragging the old one kicking and screaming into the 21st century.

caslon 5y ago

It's incredible, isn't it? Just as web developers, of all people, are finally, after over a decade, coming to the conclusion that arbitrarily-packaged dependencies are a bad idea for so many obvious reasons, Rust developers are trying to replicate NPM in the kernel. I was told that Rust in the kernel would be a good thing, and that not much would change. If these are the types of people who are writing Rust for the kernel... can we go back? I really want to go back.

12baad4db82 5y ago
You could argue that there are some crates in the Rust ecosystem that suffer from a deep dependency tree, I don't think you can argue that Rust developers are trying to do this for the kernel. The article states: > The Rust-for-Linux developers understand this situation and are not envisioning adding the ability to pull in modules with a tool like Cargo
- nullc 5y ago
  > You could argue that there are some crates in the Rust ecosystem that suffer from a deep dependency tree Some? Dependency graphs of well over a hundred packages are ubiquitous. I've long since stopped being surprised when I compile a rust package that makes no network connections and see it (indirectly) pulling in multiple HTTPS libraries.
  - Grimburger 5y ago
    > well over a hundred packages Tad understated. Popular rust http frameworks with basic functionality are hitting 300+ deps straight off the bat easily. For the security conscious, move to vendoring or alias cargo to always run in offline mode.
  - 12baad4db82 5y ago
    Right, great example. I think 'understand the situation' refers to this. I imagine the Rust for Linux developers would be going through any dependencies they pull in with a fine comb, in this case a dependency that pulls in HTTPS libraries for presumably no reason should be rejected. If that particular dependency makes it into the kernel, well, then you can start complaining about it. But right now feels a bit premature.

proto_lambda 5y ago

I can sympathize with the need to have all required source code in the repository and not having to fetch a bunch of dependencies at build time. Thankfully, cargo already offers a solution here: `cargo vendor` will download all the specified dependencies once into a local directory, which can then be checked into the source tree. This maintains cargo's dependency resolution/update checking/etc, but also allows for all dependency code to be kept alongside the kernel code and audited accordingly.

lodovic 5y ago
Requiring packages to build the kernel source feels like a circular dependency to me. The kernel should contain all of its own source code.
- nrabulinski 5y ago
  So now a kernel cannot depend on anything? What about all the tooling that’s required like python, perl and many others or the fact that you have to have a working machine with the kernel already on it to build the kernel?
  - yjftsjthsd-h 5y ago
    Obviously you have to bootstrap from something. A more interesting case is NetBSD, which can bootstrap from just about anything; take a NetBSD src checkout, run ./build.sh, and it will first use the local tooling to build its own dependencies, then use those to build the system. So in some OSs, yes, you can more or less vendor in the universe. But that only works because *BSDs are developed as full systems, not just a kernel; Linux probably can't (and arguably shouldn't) do that.
humanrebar 5y ago
Will there be a massive review process every time someone updates the vendored dependencies? Or will each dependency change be reviewed one release increment at a time? What happens if a dependency adds a system call something? Libraries intended for kernel-friendly use cases really need that scope to be an intentional goal.

jrimbault 5y ago

> The kernel has to stand alone Why ? (un-opionated "why") To reuse the migrant melting pot metaphor used at the end of the article, the "kernel has to stand alone" seems to mirror the states wanting a "strong border" (while the idea of borders and states has a beginning and will surely end).

BlueTemplar 5y ago
Using this metaphor, wouldn't the kernel be more akin to a military base ?
humanrebar 5y ago
It makes it easier to get a kernel working on a bare bones system for one. If things get complex enough, step one of getting Linux working on a new architecture will always involve getting a cross compiler working.
rocqua 5y ago
I can imagine there are plenty of cases where people build a linux kernel that was moved to an air-gaped server over sneaker-net. Or someone who wants to build linux on some SoC that doesn't even really have an internet connection. I think in your view in melting pot metaphore 'Kernel has to stand alone' might be a lot like christian countries holding the view "Sunday is a forced day of because it is the day of the lord". Whereas I think it might be more like e.g. the Netherlands having the cultural idea of "we should actually work together to prevent the entire country flooding". Or maybe the Spanish "taking a break during midday is smart, not lazy". Its a cultural preference that arises as an adaption to the specific geographic reality of the country.

geijoenr 5y ago

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.

oxff 5y ago
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.
- zozbot234 5y ago
  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.
- unmole 5y ago
  > That's why there's an attempt with sexy new language, to bring more developers to work on it. At no point did any active kernel developer express any such sentiment. Nobody is worried about not being unable to attract new blood.
  - pohl 5y ago
    It's only spoken of in knowing glances, like Voldemort.
- capableweb 5y ago
  > 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.

nullc 5y ago

I can't think of anything that could more effectively discredit the effort to use rust in the Linux kernel than suggesting using crates.io/cargo -- I had to check the dates just to make sure this wasn't a delayed April first post. But I guess some people just really want the unicode ukrainian flags being appended to every email they send or something and are too lazy to implement it themselves. :P

ratorx 5y ago
Why does a single bad idea discredit an entire language being included? If someone suggested including a C dependency manager in the kernel, does that mean that the use of the entire C language in kernel should be discredited? It is fair to say that the developer suggesting it (especially considering some of the proposed crates they want) has some massive misconceptions about the constraints of current Linux kernel development though.
- sanderjd 5y ago
  Yeah, my stance on this is that it probably makes sense to pull some libraries into the tree that would be useful in kernel development and which have comprehensible dependency trees such that everything could be reviewed and audited. But then I saw the quoted list and thought "oh this doesn't seem like a very serious proposal".
xorvoid 5y ago
Same thought. Seriously, what a great way to trigger some senior kernel dev to come down and straight veto rust with some rant about how it’s “worse C++” Rust is very slowly winning (but it’s a really hard space and this is impressive). But some people have to come and try snatching defeat from the jaws of victory. (sigh)
OskarS 5y ago
Indeed. The comment cited in the article is pretty stunning: > Other crates that I'd like: anyhow, bincode, byteorder, log, once_cell, pin-project, rand, serde, slab, static_assertions, uuid plus some more esoteric ones. This makes Rust devs look infantile, with no real understanding of what it means to develop for the kernel. Or what it takes to develop security and performance critical software of any kind, frankly.

enriquto 5y ago

Rust is alright as a language, but cargo is extremely scary. I hope a culture of coding in rust outside of the cargo "ecosystem" develops. The current situation is alienating to reproducibility-oriented developers.

Ar-Curunir 5y ago
I hope that never ever happens. We don't need a C-like mess where every library has a bespoke build process that doesn't work across OSes.
- proto_lambda 5y ago
  OP seems to be conflating the concepts of cargo (the rust build system with dependency management functionality) and crates.io (the main and default package repository today). It is totally possible to use cargo without ever touching crates.io, but if you need any dependencies you'll of course have to provide them through some other means (local file system, git repositories, or a custom package repository).
  - mort96 5y ago
    Cargo defaults to downloading stuff from crates.io. I certainly wish cargo was just a build system which doesn't care where you get your packages from, but that's not what it is.
    - steveklabnik 5y ago
      Cargo does not care where you get your packages from, but it does have a default place. If you don't like it, it is easy to change.
      - mort96 5y ago
        That... is caring where I get packages from. Something like make or cmake doesn't care at all how packages end up on my drive. Almost everyone uses cargo in a way which makes cargo automatically download them from the web.

throwaway15908 5y ago

Tangetial question: Seen all the recent supply chain attacks, is there a way to defend FOSS projects with something like project defined capabilities for every third party dependency? So eg. you could include a math lib and mask everything regarding filesystem or network, etc? Especially for rust i would like to see a holisitic solution to this growing thread, facing the accelerating trend of central repositories.

cillian64 5y ago
This is more plausible for a language with a runtime like Python. But Rust is fundamentally designed to be a systems language where you have full access to everything (and, if you use unsafe, raw access to memory and arbitrary code execution). It’s hard to imagine how you’d add a sandboxing layer to the language, it seems more like something the OS would have to do for you.
- throwaway15908 5y ago
  On a broad scope, you could solve this at compile time. The source simply does not compile when filesystem or networking crates/builtins are not defined. If you want to have more fine grained white listing, like only grant access to a certain directory, this could get really messy quick, trying to solve this at compile time.
  - oconnor663 5y ago
    You'd probably have to start by banning unsafe code in general, but then whitelisting/allowlisting specific versions of specific crates that are allowed to use it, so that at least the most popular dependencies don't break.
mkj 5y ago
My rough understanding is that Caja for JavaScript kind of did that. Libraries didn't have access to the whole scope, could only access what they were given via capabilities. https://en.wikipedia.org/wiki/Caja_project https://en.wikipedia.org/wiki/Caja_project

spaintech 5y ago

OMG, here comes a bunch of bloat into the kernel. I like rust (well, the idea and principle) but when you are doing low level stuff, something as trivial as a structure to bind an address then manipulate those bits by writing to them (enabling and disabling features) it becomes a no go. If you even consider how exhaustive it is to manage OBMR at this level of code, it becomes counter productive, not to mention unreadable. Now for the bloat part, take a simple code (one of their examples) which is a showcase of their capabilities and “zero cost” abstraction for something like embedded, their blinky app is like 100KB versus a initialize the clock/ set GPIO to read mode, and write to it that come out shy of 4K in C++ with all the hall form STM for example. Object lifetime analysis is really cool at compile time, but any un defines behavior is still present when you compile the code… Show me someone doing a baremetal implementation of blinky (that is, no HAL) on rust or a struct for bit banging and I’ll be a believer that you can do “some” of the stuff needed for kernel development but not all.

PoignardAzur 5y ago
"Please show me some amazing features of your language but I'll still believe your language sucks". That's, uh, not a very compelling request.
varajelle 5y ago
> their blinky app is like 100KB I just compiled the blinky example for a cortex m4 board (the example in the rust hal crate for that board, not using any unsafe), and the striped binary is 420 bytes. So you probably want to review your stence, because you're about 3 orders of magnitude off.
- spaintech 5y ago
  Yes its 420 bytes, which is why I’m commenting as my fingers played me on my thoughts. Do the same for one writer in C++ and report back on the orders of magnitudes… Cheers!
- AnyTimeTraveler 5y ago
  I am currently working with the ATTiny85 and the stripped blinky binary is 275 bytes. I was worried that the ATTiny85 wouldn't have enough flash space (6K) for Rust and now I don't know what to do with all that free space :)

scoutt 5y ago

Building the kernel shouldn't require an internet connection.

kibwen 5y ago
Building Rust code, and even using Cargo, doesn't require an internet connection.
- jvanderbot 5y ago
  ah, yes it does? 'cargo build' absolutely goes and finds dependencies, updates them, and so on. 'rustc' does not, but we are talking about cargo here.
  - miloignis 5y ago
    It doesn't have to, you can "cargo vendor" all your deps (I do so for some of the things I work on, regularly building and developing without an internet connection).
  - KptMarchewa 5y ago
    https://doc.rust-lang.org/cargo/commands/cargo-vendor.html https://doc.rust-lang.org/cargo/commands/cargo-vendor.html
  - estebank 5y ago
    https://doc.rust-lang.org/cargo/faq.html#how-can-cargo-work-offline https://doc.rust-lang.org/cargo/faq.html#how-can-cargo-work-...
  - deleted 5y ago
    [deleted]
  - jvanderbot 5y ago
    OK, I have been sufficiently reminded of a mostly-offline build process and punished for my flippant remark which I can no longer edit or delete. Thank you!
5y ago

gquery 5y ago

zozbot234 5y ago
> Some of them have been directly involved in cancelling non-native English speakers over pronouns. This is the kind of claim that could do with a source. In general, it seems Rust is rewarding enough and complex enough to master that people just don't pay much attention to the silliest kinds of 'activism' compared to other dev communities.

simion314 5y ago

Still makes no sense to me to spend energy into pushing Rust into Linux instead of creating some new better kernels, I mean having some of this big companies paying a few experts to do such a kernel and keep compatibility with user applications. If Rust is much better then C and adding on top the fact you start fresh with no baggage you should get a better Linux and everyone would use it since is safer and faster especially on servers. I don't know of such a Rust kernel being worked on that is not some hobby side project but something more like Servo was, where you have paid experienced in domain developers.

proto_lambda 5y ago
"starting fresh with no baggage" also means starting fresh with no drivers. Having drivers for a wide range of hardware is a major factor in operating system adoption.
- psychoslave 5y ago
  Didn't FreeBSD incorporated an interface that allow to use Linux drivers? Not that I think it would make the point of having a bright new kernel easily compete with such a huge and firmly grounded project as Linux though. All the more, there already are multiple projects using Rust to build OSes out there, if I'm not mistaken.
- simion314 5y ago
  I was not suggesting this kernel to be used on laptops, it would be a server kernel, if it would actually be faster and safer then Google and Amazon will use it on their servers and they will make sure there are drivers, Google could use it in some mobile devices too if they care for safety. AMD has an open source driver so if desired that could be ported to Rust to also make sure the GPU is safe.
  - xxpor 5y ago
    Things work the opposite way. In order to get companies to adopt things you need to get people working their interested in it. Which means they need to be able to run it on their PCs. There's a reason why x86 ate the world. The exception to this is when you can develop something and have a good case to use it yourself, like Google and Fuchsia. But I doubt Fuchsia will gain wide organic adoption because of the same factors.

2wrist 5y ago

Thats a really well written article, nicely balanced. I also agree, it can be great opportunity to learn.

fmajid 5y ago

Rust’s cavalier attitude to language and compiler stability, their absurd bootstrapping situation and limited platform support, not to mention their belief that “curl something|bash” is acceptable procedure are all reasons why I’ve avoided it despite the many good qualities of the language.

jopsen 5y ago
Aren't many of those things stuff that can be fixed as the ecosystem matures? Is C ecosystems much better?
humanrebar 5y ago
I wouldn't phrase my concerns that way, but it is concerning that Rust doesn't do LTS releases (someone correct me if I missed something here). Because C compilers, make, etc. are really stable, existing Linux source tarballs have a habit of building fine for decades after initial release.
- tialaramex 5y ago
  In what sense is Rust 1.0 not already an LTS release ? If you wrote some Rust 1.0 code back in 2015, put it away in a drawer (maybe on a USB stick) but now get it out today it will still build with current Rust tooling -- except for some very narrow cases where you might have done something inherently unsound and subsequently the compiler was corrected to fix that so it's an error. Rust's language shifted slightly in those years. However the Editions system - even though it hadn't yet been invented in 2015 - allows for that. Your 2015 code lacks any Edition metadata, so, the modern tools understand that as Rust 2015 edition, and will compile accordingly, while still interoperating correctly with modern Rust. Suppose your 2015 code named a variable await. That's a keyword in modern Rust. But it isn't a keyword in Rust 2015 edition, so your code compiles just fine. This would not work in C of course, which is why its newer keywords are ugly stuff like _Bool but in Rust it's fine.
  - humanrebar 5y ago
    Modern releases of GCC still support C89. If rustc, at least, will keep supporting 1.0 features for all future releases, I guess that's fine. But that also means that crates used by the kernel would need to likewise be conservative about updating to new Editions so as to not break expected support surfaces.

oxff 5y ago

I don't think people should be looking at adding another language to the kernel, mostly because every OS build on it has been a disaster. We just need approach and definition for operating systems.

samhw 5y ago
> I don't think people should be looking at adding another language to the kernel, mostly because every OS build on it has been a disaster. We just need approach and definition for operating systems. What does "we need approach and definition for operating systems" actually mean? (If you know, that is.) Also, it's the Linux kernel, not just the kernel. There are more than one, and every operating system has one[0]. You might be interested in looking at the Mach kernel (Apple[1]) or Google's new Zircon kernel (in Fuchsia). Both of those are microkernels, and as such minimise the amount of work that the kernel does, as well as removing drivers to userspace. Inasmuch as I can extract any meaning from your comment, it seems like your problem might be with the size and scope of Linux's kernel, in which case those might appeal to you. [0] I'm sure this absolute claim will summon someone to point out some recondite 1980s operating system that doesn't have a kernel. [1] Yes, yes, used by Apple.

HidyBush 5y ago

I already loathe the fact that I need Perl to compile the kernel just because people are too lazy to rewrite a few parsing scripts in C. The moment Rust is introduced in Linux without being a complete replacement is the day I leave for greener pastures

sophacles 5y ago
Why haven't you rewritten those parsing scripts you loathe so much? Since you haven't, it seems a bit ironic that your are complaining about those who didn't.
deleted 5y ago
[deleted]
bitcharmer 5y ago
I agree on the Perl requirement bit but see Rust as a complete replacement for C or at least great alternative in systems engineering domain in the long term.
- HidyBush 5y ago
  Please read again my comment. If tomorrow all the Linux C codebased switched to Rust I would have almost zero problems about it. My problem stems from having multiple toolchains to build the foundations of an operating system.
  - bitcharmer 5y ago
    The expectation for the switch to happen overnight in its entirety is very unrealistic.

IYasha 5y ago

So, I assume soon there'll be a pure-C kernel fork and some distributions adopting it. And I'd switch to that.

orf 5y ago
Why?
- IYasha 5y ago
  Because there are many people who oppose mandatory Rust integration. For various reasons, not just plain dislike of Rust itself. And, for example, there's a Libre Kernel that is blob free and it has its users. There might be an audience for Rustless Kernel too.
  - samhw 5y ago
    I think they meant "why?" as in "what reason do they have?", rather than "do there exist people who think that?". I don't really care what tool was used to generate my assembly, and the kind of Rust that will be written in a kernel context[0] will - I guarantee you - produce virtually identical assembly to C. [0] i.e. no standard library ('no_std'), no unwinding panics, no dynamically sized types, &c.
bitcharmer 5y ago
It might, and if so you will switch but a very small minority of Linux users ever have the need to compile it themselves and out of that small minority only a small fraction will migrate to alternatives over this. I see Rust as a replacement for C long term. From this perspective it's absolutely ok to have a transition period (years in fact) where there are multiple toolchains used to build the kernel.

Bessie69 5y ago

[dead]