AWS Introduces a Rust Language-Oriented Linux for Containers (zdnet.com) 35
An anonymous reader shares this enthusiastic report from ZDNet:
Earlier this year, Linus Torvalds approved of adding drivers and other components in Rust to Linux.* Last week, at the virtual Linux Plumbers Conference, developers gave serious thought to using the Rust language for new Linux inline code. ["Nothing firm has been determined yet," reported Phoronix, "but it's a topic that is still being discussed."] And, now Amazon Web Services (AWS) has announced that its just-released Bottlerocket Linux for containers is largely written in Rust.
Mozilla may have cut back on Rust's funding, but with Linux embracing Rust, after almost 30-years of nothing but C, Rust's future is assured. Rust was chosen because it lends itself more easily to writing secure software. Samartha Chandrashekar, an AWS Product Manager, said it "helps ensure thread safety and prevent memory-related errors, such as buffer overflows that can lead to security vulnerabilities." Many other developers agree with Chandrashekar.
Bottlerocket also improved its security by using Device-mapper's verity target. This is a Linux kernel feature that provides integrity checking to help prevent attackers from overwriting core system software or other rootkit type attacks. It also includes the extended Berkeley Packet Filter (eBPF), In Linux, eBPF is used for safe and efficient kernel function monitoring.
* Linus's exact words were "people are actively looking at, especially doing drivers and things that are not very central to the kernel itself, and having interfaces to do those, for example, in Rust. People have been looking at that for years now. I'm convinced it's going to happen one day."
The article also reminds readers that AWS's Bottlerocket "is also designed to be quick and easy to maintain... by including the bare essentials needed to run containers..."
"Besides its standard open-source elements, such as the Linux kernel and containerd container runtime, Bottlerocket's own code is licensed under your choice of either the Apache 2.0 or the MIT license."
Mozilla may have cut back on Rust's funding, but with Linux embracing Rust, after almost 30-years of nothing but C, Rust's future is assured. Rust was chosen because it lends itself more easily to writing secure software. Samartha Chandrashekar, an AWS Product Manager, said it "helps ensure thread safety and prevent memory-related errors, such as buffer overflows that can lead to security vulnerabilities." Many other developers agree with Chandrashekar.
Bottlerocket also improved its security by using Device-mapper's verity target. This is a Linux kernel feature that provides integrity checking to help prevent attackers from overwriting core system software or other rootkit type attacks. It also includes the extended Berkeley Packet Filter (eBPF), In Linux, eBPF is used for safe and efficient kernel function monitoring.
* Linus's exact words were "people are actively looking at, especially doing drivers and things that are not very central to the kernel itself, and having interfaces to do those, for example, in Rust. People have been looking at that for years now. I'm convinced it's going to happen one day."
The article also reminds readers that AWS's Bottlerocket "is also designed to be quick and easy to maintain... by including the bare essentials needed to run containers..."
"Besides its standard open-source elements, such as the Linux kernel and containerd container runtime, Bottlerocket's own code is licensed under your choice of either the Apache 2.0 or the MIT license."
Misleading (Score:1)
Re: (Score:2)
Rust already lost to Go. Deal with it.
I've heard a lot of back-and-forth concerning Go versus Rust. I'm not familiar with either of them and I'd be interested to hear your take on the advantages/disadvantages of one over the other.
If I was going to start learning one of them, which would you recommend and why?
Re: (Score:3)
Re: (Score:1)
Re:Misleading (Score:5, Informative)
Both have memory safety and type safety, both compile architecture native code, and both are capable enough for systems development (i.e. drivers, kernels, etc.) Go has more libraries and is easy to learn, faster to compile, but is subject to garbage collection pauses like Java and C#, and overall doesn't perform as well as C. Rust doesn't need a garbage collector (compiler does it for you at build time by discarding objects when they go out of scope) and has performance similar to C (in some cases, better performance) but it's harder to learn and slower to compile, and as of right now, not as many libraries available.
IMO Rust, or possibly a derivative of it, will within two decades by and large replace c and c++ for systems development and in applications where performance is a very high priority. Again, IMO, though others may disagree. Go is probably more suitable for business level applications that need more performance than a higher level language while at the same time able to be more easily and quickly developed and maintained than a lower level language like C or Rust, though as I understand it Google is using Go in some components of their Zircon microkernel for their Fuschia OS.
Rust is still relatively early in its lifetime, so now may not be the time to learn it unless you really have a need for it. It will probably result in more frustration than usefulness for the time being if (like me) you rely a lot on googling how to do a given thing in a given language as you're learning it. Meanwhile, Go is pretty easy to pick up if you've had the itch to learn a native compiled language, or if you're (like me) tired of dealing with classes, namespaces, etc, that make languages like Java and C# kind of annoying for those times when you just want to quickly write something simple for a very specific short-lived purpose, while not having to worry about memory and type safety like you have to with C.
I love the idea of what Rust is and what it can do as it solves a ton of problems that other languages struggle with, but I personally don't use it for the aforementioned reasons.
Re: (Score:2)
Thank you very much, I appreciate your giving me a comparison of the languages and some pros/cons.
Re: (Score:2)
and has performance similar to C
My understanding was that Rust had similar performance to C mostly when sprinkled with some unsafe code. The main reason why Go doesn't currently approach the speed of Rust seems to be less an issue of automated memory management (which has gotten very good recently in Go) and more an issue of Go rolling out its own (WIP, Plan 9 C compiler-derived, and also written in Go) compiler, where Rust relies on the group effort of LLVM. Go-as-a-language has fewer performance issues than Go-as-the-current-reference-i
Re: Misleading (Score:2)
That's like saying C code is only fast if you embed assembly language blocks everywhere.
"unsafe" is not some kind of "go faster" flag. It's useful for some critical section code where pointer ownership and lifetime analysis is beyond the capabilities of the compiler to manage, but most Rust code is perfectly fast without resorting to "unsafe".
Large or numerous "unsafe" blocks are considered a code smell in Rust, just like dumping assembly language blocks everywhere in a typical C program would be. For 99.9%
Re: (Score:2)
It's useful for some critical section code where pointer ownership and lifetime analysis is beyond the capabilities of the compiler to manage
Clearly the presence of Arc in Rust shows that lots of ownership and lifetime analysis actually *are* beyond the capabilities of the compiler to manage. But why they decided to patch this hole with a solution known as massively inferior is beyond me.
Re: Misleading (Score:2)
Reference counting has its place. I suppose you could bolt a garbage collector on instead, but by that point you should probably be examining (a) whether Rust is the right tool for the job and (b) whether you truly understand the problem space well enough to accurately describe it.
I know of no one in the Rust community who considers Arc to be their go-to reference type. Far more likely someone rethinks their approach so that ownership and lifecycle are more clearly and cleanly defined. Perhaps even includin
Re: (Score:2)
whether Rust is the right tool for the job and (b) whether you truly understand the problem space well enough to accurately describe it.
Well, Rust people seem to think that you should be doing everything highly performant in it. But if I were to implement something like, for example, AllegroCache in Rust, I'd have to deal with this issue no matter how accurately described that task is.
Far more likely someone rethinks their approach so that ownership and lifecycle are more clearly and cleanly defined.
That sounds to me a little bit like the weaker version of Sapir-Whorf applied to programming languages. Sure, you do that...to a large extent because apparently you have little choice in Rust to not do that.
That said, C++ is like writing Rust as one, big unsafe block. Maybe that's what you want to do
For starters, I never said that I preferred C++, of a
Re: Misleading (Score:2)
> Well, Rust people seem to think that you should be doing everything highly performant in it.
The Rust core group and the community at large have been trying very hard not to do this. While Rust is looking promising for more and more areas, no one prominent in the community describes it as a silver bullet. The zealotry of Java in the 90s and Haskell in the 00s is explicitly not a community goal.
If it works for you, great. If something else works better for you, use that instead. Solving problems is the r
Re: (Score:2)
Your post motivated me to take another look at Rust, and I happened to notice that Pluralsight (which I have a subscription to through my work) has a course on it, and I noticed that the documentation has lots of nice to-the-point examples. I'm not a seasoned software developer at all, in fact I don't even call myself one and my cup is rather empty in this area, but suddenly rust doesn't seem that daunting, and may even be easier to use when it comes to multi-threading than c#, which is my current soup-du-j
Re: (Score:1)
If I was going to start learning one of them, which would you recommend and why?
They are fundamentally different kinds of languages. OMBad's claim that Rust has somehow "lost" to Go is misguided; like saying green lost to Boeing.
Rust aims to be a "systems" language. Rust programs compile to native machine code, like C/C++ and others, and has no "runtime," or rather its runtime is (supposed to be) extremely small and easy-ish to accommodate while developing things like shared objects and embedded programs. Go is an "applications" language; it also compiles to native machine code, b
Re: (Score:2)
The designers have little interest in "systems" language requirements.
That doesn't really make sense; Go's designers themselves (Thompson, Pike, Griesemer) are systems language designers (Plan 9 C, Alef, Limbo, Oberon...). Why would renowned systems language designers have "little interest in systems language requirements"?
Re: (Score:2)
Why would renowned systems language designers have "little interest in systems language requirements"?
I can't provide you with a certain explanation why these engineers made the design choices they made. The most likely reason in my mind is that they're Google employees working towards Google's prerogatives, which don't (didn't?) necessarily include creating virtual memory managers or high performance process schedulers; the sort of devices found at the heart of general purpose operating systems. Rust designers didn't necessarily have these in mind either, but they did consciously make a number or choices
Re: (Score:2)
Re: (Score:2)
Thank you, this was informative and gives me some insight into the languages and how they differ.
Nothing new to see here (Score:5, Funny)
Static binaries (Score:3)
Am I crazy or did everyone forget what a static binary is? Why does everything need to be a container now? I mean the shitty calculator that ships with Gnome is a docker file and the thing takes several seconds to load.
Re: (Score:3)
Simple: People are stupid, arrogant and can not leave things alone that work well. Classical Unix process isolation is quite enough for almost anything. Add MAC and it is. It does require people that know what they are doing and that is not fashionable these days. Today, we have "cretin level" developers and they need all the help they can get to sometimes manage to create barely acceptable results.
Re: Static binaries (Score:1)
Re: (Score:2)
Containers are good if you need to scale services but pretty silly otherwise. I hope you were joking about the calculator but I am afraid now.
Your job must not have anything to do with system administration and system security. Containers are a nightmare for both of those groups.
Re: (Score:1)
Re: (Score:3)
I've done the former and currently do the later. Containers can work well depending on your environment. For one, everybody who maintains each containerized application has to have the same ideas about how the applications will be configured and how they'll interact with the host OS. If they have differing approaches to things like file structure and user/group security, then it will be a real pain in the ass for the admin to figure out which is trying to do what, and that is a very common scenario, unfortu
Re: (Score:2, Insightful)
Dynamic linking with traditional applications has nightmares of its own. They're just fobbed off to applications developers. Linux can be challenging to develop for and deploy to, due to many potential distros, each with many potential versions or variations, resulting in a combinatorial explosion of potentially different dynamic dependencies. There's no simple way to assure stability except to lock down those dependencies. Containers are the response to this problem.
Yes, it's potentially problematic fo
Re: (Score:1)
I understand Linus Torvalds is dead against C++ finding its way into the Linux kernel. I do not see Rust being any better than C++. When I last looked into Rust, the compile time guarantees regarding memory management looked attractive, but as I read further, more and more complexity was layered on to cope with real life requirements. C++ can actually be good for memory management, using RAII.
Re: Static binaries (Score:2)
"More and more complexity"?
Rust provides compile-time safety checks eliminating 70% of all bugs that lead to security and/or crash bugs in C and C++.
https://msrc-blog.microsoft.co... [microsoft.com]
Imagine turning on a C or C++ compiler flag that for all practical purposes eliminated double free, use after free, concurrent mutability, buffer overrun, buffer underrun, and deadlock bugs. It didn't get rid of the remaining 3 out of 10 vulnerabilities, but wouldn't you love to have an option like that? Wouldn't you prefer the
Re: (Score:2)
Re: Static binaries (Score:2)
A bit more. Imagine if you didn't use a smart pointer and the C++ compiler errored out. Also there's the concept of lifetimes, which doesn't exist at all in C++ (or any other language I'm familiar with).
Let's say you are writing a string splitter that returns an iterator (as opposed to an array). The iterator has a lifetime bound to the caller of the "split" function. However, the string you want split has a lifetime that may extend beyond the iterator or the caller. It may have a lifetime of the whole prog
Re: (Score:2)
From the point of someone actually running that code in production, I have to tell you that static binaries inside containers are the greatest leap forward since POSIX. A static binary can cause a lot of havoc to the rest of the system, but put it in container and you are clearly specifying all of the boundaries for it. It goes way beyond what processes allow. The second important part is the inversion of defaults. Process can do anything that is not disallowed. Process in a container can only do what is al