I believe the removal of the "experimental" nomenclature is just an indication that Rust is "here to stay" in the kernel (which essentially means that developers can have confidence investing in writing Rust based drivers).
The overall rules haven't changed.
Strictly speaking they've always been obligated to not break the Rust code, but the R4L developers have agreed to fix it on some subsystems behalf IIRC so Rust can be broken in the individual subsystem trees. But I think it's been the case all along that you can't send it to Linus if it breaks the Rust build, and you probably shouldn't send it to linux-next either.
That was way way blown out of proportion. https://lwn.net/Articles/991062/ has a much less somber quote from just three months later:
> Ted Ts'o said that the Rust developers have been trying to avoid scaring kernel maintainers, and have been saying that "all you need is to learn a little Rust". But a little Rust is not enough to understand filesystem abstractions, which have to deal with that subsystem's complex locking rules. There is a need for documentation and tutorials on how to write filesystem code in idiomatic Rust. He said that he has a lot to learn; he is willing to do that, but needs help on what to learn
Ted was being an asshole, nobody was asking him to learn Rust, he completely misinterpreted the point being made and then proceeded to go on an angry rant for like 5 minutes in the middle of a presentation which just is kind of disrespectful.
Linus Torvalds greenlit Rust in the kernel, and as a BDFL, he is the one to decide. He has no reason to be upset with any decision because ultimately, all decisions are his own.
If he didn't want Rust in the kernel, he would have said it, and there would have been no Rust in the kernel. It is also the reason why there is no C++ in the kernel, Linus doesn't like C++. It is that simple.
And I respect that, Linux is hugely successful under Linus direction, so I trust his decisions, whatever opinion I have about them.
I only typed Linus Torvald not realizing the person was asking for a "movie character" quite literally, lol. I thought "you mean the guy famous for (among many things..) his behavior?"
This is the first time I've had a comment hit -3 which, I mean, I get it!!
I can't find the movie, but there was a guy angry that stated that he should not have to learn Rust, nobody should. And Rust should not be in the kernel.
Its in a talk about File systems in Rust for Linux. Basically the rust maintainer who I think stepped down was talking about how the C-code base for VFS has a lot of documented but complex orderings where you have to call a lock, or pin before accessing an Inode(or something) one way but not the other. They made a bunch of Rust Types so you basically could not produce an illegal ordering and got heckled pretty hard by the "bearded guy". They basically run out the presentation time with heckling and I think the Rust maintainer quit a few months later (over many similar instances of this. don't quote me time line here)
IIRC, the point was actually that they were undocumented in many cases, and that the Rust developers were willing to take on a lot of work, but they would need help with understanding all of the hidden and implicit "rules", but that they had received pushback for simply asking questions or asking for documentation to be comprehensive.
Okay I felt that they were undocumented but I was trying to be charitable to the bearded man :D. I didn't have time to watch the video again haha. But Yeah the push back at the suggestion was very surprising.
From kernel side, I meant - I wasn't clear. Now I understand what's the meaning of "don't break rust code". Happy that rust's journey in the kernel is successful so far. The pace seems strong.
What they mean is that the Linux kernel has a long-standing policy to keep the whole kernel compilable on every commit, so any commit that changes an internal API must also fix up _all_ the places where that internal API is used.
While Rust in the kernel was experimental, this rule was relaxed somewhat to avoid introducing a barrier for programmers who didn't know Rust, so their work could proceed unimpeded while the experiment ran. In other words, the Rust code was allowed to be temporarily broken while the Rust maintainers fixed up uses of APIs that were changed in C code.
I guess in practice you'd want to have Rust installed as part of your local build and test environment. But I don't think you have to learn Rust any more (or any less) than you have to learn Perl or how the config script works.
As long as you can detect if/when you break it, you can then either quickly pick up enough to get by (if it's trivial), or you ask around.
The proof of the pudding will be in the eating, the rust community better step up in terms of long term commitment to the code they produce because that is the thing that will keep this code in the kernel. This is just first base.
No matter how hard you try to paint it as such, Rust is not a tribe. This is such a weird characterization.
Rust contributions to the Linux kernel were made by individuals, and are very obviously subject to the exact same expectations as other kernel contributions. Maintainers have responsibilities, not “communities”.
Not only that, those individuals were already Linux kernel contributors. This is not an amorphous external group forcing their will on Linux, it's Linux itself choosing to use Rust.
Learn rust to a level where all cross language implications are understood, which includes all `unsafe` behaviour (...because you're interfacing with C).
Rust's borrowing rules might force you to make different architecture choices than you would with C. But that's not what I was thinking about.
For a given rust function, where you might expect a C programmer to need to interact due to a change in the the C code, most of the lifetime rules will have already been hammered out before the needed updates to the rust code. It's possible, but unlikely, that the C programmer is going to need to significantly change what is being allocated and how.
There is, I understand, an expectation that if you do make breaking changes to kernel APIs, you fix the callers of such APIs. Which has been a point of contention, that if a maintainer doesn't know Rust, how would they fix Rust users of an API?
The Rust for Linux folks have offered that they would fix up such changes, at least during the experimental period. I guess what this arrangement looks like long term will be discussed ~now.
Without a very hard commitment that is going to be a huge hurdle to continued adoption, and kernel work is really the one place where rust has an actual place. Everywhere else you are most likely better off using either Go or Java.
I'm using it for frontend web development and it's perfect. Much better than Go or Java would be. It's pretty wild that the language I use in the browser is also in the kernel.
Rust is being used a lot in video and audio processing where C and C++ had been the main players. Fixed-latency streaming is not really the best place for Go, Java, or Python.
I'd say no, access to a larger pool of programmers is an important ingredient in the decision of what you want to write something in. Netscape pre-dated Java which is why it was written in C/C++ and that is why we have rust in the first place. But today we do have Java which has all of the rust safety guarantees and then some, is insanely performant for network code and has a massive amount of mindshare and available programmers. For Go the situation is a bit less good but if you really need that extra bit of performance (and you almost never really do) then it might be a good choice.
> But today we do have Java which has all of the rust safety guarantees and then some, is insanely performant for network code and has a massive amount of mindshare and available programmers.
I'm not entirely convinced that Java has much mindshare among system programmers. During my 15 years career in the field I haven't heard "Boy I wish we wrote this <network driver | user-space offload networking application | NIC firmware> in Java" once.
I've seen plenty of networking code in Java, including very large scale video delivery platforms, near real time packet analysis and all kinds of stuff that I would have bet were not even possible in Java. If there is one thing that I'm really impressed by then it is how far Java has come performance wise, from absolutely dog slow to being an insignificant fraction away from low level languages. And I'm not a fan (to put it mildly) so you can take that as 'grudging respect'.
The 'factory factory' era of Java spoiled the language thoroughly for me.
I never said it is due to performance considerations (although developers in a projects like you described tend to always become experts in things like tuning Java GC). It is more like "If we wanted to write this in a shitty verbose OOP language we would just use C++".
While it might be possible to get the performance required for a web rendering engine out of Java, I think you'd miserable writing Java in the style you'd need to get that kind of performance. And you'd likely still end up with issues around memory usage, app bundle size (remember that browsers ship to client devices), GC pauses, and integrating with the JavaScript engine.
Absolutely. Again, not a fan of the language. But you can transcode 10's of video streams on a single machine into a whole pile of different output resolutions and saturate two NICs while you're at it. Java has been 'fast enough' for almost all purposes for the last 10 years at least if not longer.
The weak point will always be the startup time of the JVM which is why you won't see it be used for short lived processes. But for a long lived process like a browser I see no obstacles.
It’s only fast enough if it is as fast or faster than the alternatives. Otherwise it is wasting battery power, making older/cheaper computers feel sluggish and increasingly inefficient.
The linked tweet shows the door of an exosuit opening and a human climbing in. Is there any more context, like video of the door closing, the human/exosuit performing any tasks, or the exosuit surviving harmful environments? xcancel doesn’t show any more context to this thread.
Hey, there was some text that gave a bit of context on the video. And the OG post has a couple more videos of it doing stuff. Attached to the same post talked about the company the name of the suit some of the history I think.
There's widespread issues with power banks in China, with a new CCC certification required, and recently something about upgraded enforcement because previously certified devices having been found to have issues.
I'd rather go with a brand that does proper costly recalls over one that just lets everybody keep the dangerous products around.
The difference here is that Anker will recall a faulty product. Lesser known brands will not. If you know of another brand that has a better safety and reliability record, please share.
This is what macOS codesigning does. Notarization goes one step further and anchors the signature to an Apple-owned CA to attest that Apple has tied the signature to an Apple developer account.
As I understand it, this attack works because the worm looks for improperly stored secrets/keys/credentials. Once it find them it publishes malicious versions of those packages. It hits NPM because it’s an easy target… but I could easily imagine it hitting pip or the repo of some other popular language.
In principle, what’s stopping the technique from targeting macos CI runners which improperly store keys used for Notorization signing? Or… is it impossible to automate a publishing step for macos? Does that always require a human to do a manual thing from their account to get a project published?
It’s useful background if you don’t understand how paying tariffs works for small individual shipments. This is something most Americans who buy stuff from abroad haven’t had to deal with until the ending of de minimis.
I guess we can’t know precisely how this happened without seeing UPS’s original Form 7501.
The amended one sounds strange. Why did they claim that the duty for the actual HTS code is $0, and attribute the entirety of the tariff to the special EU-origin code?
reply