Mama told me not to come.
She said, that ain’t the way to have fun.
No we don’t. Trump deserves to be kicked to the curb, but Americans are absolutely fine, if a bit short sighted.
A country is not its leadership, it’s the people. And it’s incredibly hard for the people to replace their leadership outside of election season, and even then, there’s a lot of pressure to make poor choices on your ballot.
We don’t really make anything though, aside from software I guess.
That’s a bit of an extreme take. Surely you can see some differences between them…
Let’s do it again! Let’s make sure nobody can break his record for impeachments.
Does Proton bridge work? I know nothing about that game.
It’s not like Linux compiles down to one binary or anything, most of it is linked together over a pre-determined API. Anything that can satisfy that API (and ABI) can drop in. There are some “magic” bindings, but they still conform to that API.
Read the rest of Greg KH’s thread, here’s the last half of that paragraph:
Adding another language really shouldn’t be a problem, we’ve handled much worse things in the past and we shouldn’t give up now on wanting to ensure that our project succeeds for the next 20+ years. We’ve got to keep pushing forward when confronted with new good ideas, and embrace the people offering to join us in actually doing the work to help make sure that we all succeed together.
And earlier:
Rust also gives us the ability to define our in-kernel apis in ways that make them almost impossible to get wrong when using them. We have way too many difficult/tricky apis that require way too much maintainer review just to “ensure that you got this right” that is a combination of both how our apis have evolved over the years (how many different ways can you use a ‘struct cdev’ in a safe way?) and how C doesn’t allow us to express apis in a way that makes them easier/safer to use. Forcing us maintainers of these apis to rethink them is a GOOD thing, as it is causing us to clean them up for EVERYONE, C users included already, making Linux better overall.
Those are solid arguments. As long as the APIs are well designed and documented, a mixed codebase is fine, and you get most of the benefits of Rust where it’s used.
True. We should have both better tooling and better languages. Someone posted this thread with Greg KH, which has this gem:
The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That’s why I’m wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)
I’m all for moving our C codebase toward making these types of problems impossible to hit, the work that Kees and Gustavo and others are doing here is wonderful and totally needed, we have 30 million lines of C code that isn’t going anywhere any year soon. That’s a worthy effort and is not going to stop and should not stop no matter what.
But for new code / drivers, writing them in rust where these types of bugs just can’t happen (or happen much much less) is a win for all of us, why wouldn’t we do this?
In short, let’s do both.
For the lazy, I liked these parts:
Rust isn’t a “silver bullet” that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going forward, why wouldn’t we want that?
…
Yes, I understand our overworked maintainer problem (being one of these people myself), but here we have people actually doing the work!
The whole thing is great.
Exactly. The kinds of things Rust yells at you for, you should consider changing in C as well.
Unsafe Rust may be similar to C
It’s really not. I’d much rather use C than unsafe Rust…
The best part about Rust is you can isolate your memory safety problems to the unsafe bits, whereas with C, you have to constantly deal with it.
Same, but with tuta for service. It works fine.
As do I. I could jump into a modern C codebase and feel comfortable. I’ve worked on microcontrollers, built servers (UDP, TCP, and HTTP), and worked with cross thread communication. If I know what I want to build, I can achieve it with C. Maybe not as quickly as someone who works with it every day (it has been a while), but within a month I’d be back in shape.
I feel the same about Python, Go, JavaScript (both on server and FE, either React or straight DOM manipulation), and Rust (I use it for personal projects extensively). When I write C++, it usually turns out like C with vectors and smart pointers, so I’ll add that in as well. Except for Rust, I’ve used all of these in a professional capacity (and I did technically do a couple POCs in Rust). I could list a bunch of other languages I’m less confident in, but could also use professionally if needed without needing to study first.
I’m not suggesting they go out and do the same, I’m merely suggesting that when an option comes along that solves some serious problems they run into every day, maybe they should try it. Most of the languages I mentioned are useless for kernel development, so it makes no sense for them to bother with them. However, Rust is really interesting because it comes with some very compelling guarantees, and you don’t get many guarantees when it comes to low level development.
If I told a kernel dev that I had a tool that can identify most if not all memory safety/soundness issues in their C code, they wouldn’t hesitate to try it out. But if I ask them to try out Rust (same guarantees), they’ll refuse. Why? Hubris and stubbornness.
A weeder task is a super simple programming task that should be second nature. Some options for different stacks:
Basically, we just want to know if they can write basic code in the position we’re hiring for.
I only vaguely know what you mean by “We were hoping to say they needed to write some tests to get a code review”.
The “programming challenge” isn’t really a challenge for programming skill, but more of a software engineering challenge to see how they turn vague requirements into a product the company could ship.
Let’s say the task is to build a CLI store, where the user inputs items and quantities they want to buy, and the app updates inventory after a sale. For the sake of time, we’ll say data doesn’t need to persist between runs.
I think any developer could build something like that in about 15-20 min, maybe less if they’re familiar with that kind of task. In Python, it’s basically an input() loop that queries an “inventory” dictionary and updates an “order” dictionary.
However, there are also a bunch of corner cases:
After they build the basic solution, we ask them an open ended question: how confident are you that the code is correct? They wrote it in 20 min or so, therefore the confidence should be pretty low. I’ll then ask what they’d do to get more confidence.
A good software engineer doesn’t only want to ensure the happy path works, but that the corner cases are handled and those uses will continue to work regardless of what other developers add in the future. So I’m looking for one or all of:
If they say it’s perfect and to ship it, that’s concerning, especially if I identified an issue in the process of them solving it. We identified the same issue twice for that candidate that relied on AI, and they still said “ship it,” and we also noticed other issues as well that we didn’t tell them about.
So we’re looking both for competence and self awareness. Know your stuff, but also recognize your limitations. Meeting the requirements is only half of development IMO, you also need to maintain it long term.
Here is a link for some that you can but online though.
Thanks!
When it comes to ebooks, I generally go for Kobo, which seems to be Amazon’s stiffest competition, but I definitely prefer to support DRM-free where I can.
Okay? I know a half dozen languages well, and am pretty productive with a half dozen more. If you’re an experienced software engineer, picking up a new language should be easy. If a language is useful for a given task, I use it. If another language offers benefits I want, I learn it.
It’s like any other profession, why limit yourself to one tool? If a new tool comes out and does the job better, use it.
I love C and it’s my first choice for low level work like microcontrollers. However, it’s not great for larger projects, especially ones with significant security concerns, since subtle vulnerabilities in different areas could be combined to create an attack. Rust provides a lot of protection against common attacks without a performance cost, so it’s a good choice.
That’s not really how evolution works, but who knows!
And it’s totally fair to run your project however you choose. My point is just that FOSS doesn’t automatically mean you can’t make money, tons of businesses are built on a FOSS-first basis. Pick the model that works for your business, and I sincerely hope you find a way to make FOSS part of it.
In general, for me, Rust > C > C++.
I’ve heard people say that C is like a loaded and cocked revolver, and if you’re not careful, you could blow your foot off, whereas C++ is like a loaded and cocked sawed-off shotgun, and if you’re not careful, you could blow your leg off.
I don’t know about you, but I prefer provably correct code over “just trust me bro.”
There’s an analogy I like here. A manager at a trucking company was hiring a new driver, and he asked each of them how close they could get to the edge on a mountain pass. The first said, “I can get within a wheel’s width.” The second said, “I can drive on the edge, with part of the tire hanging off.” And the third said, “I stay away from the edge.” The third applicant got the job, because why take the risk?
That’s how I feel about C/C++. Why use them if Rust can do the job? You get a lot more safety features without sacrificing performance, what’s not to like?
That does literally nothing though. Buying a share of a company is like buying a used product, none of that money goes to the company. The only benefit to a company is the share price rising, and your contribution to that is effectively zero, and it only matters if the company issues or buys back shares, which is somewhat rare.
It’s the same reason that buying “green” shares does nothing.
Invest based on what’s most likely to give you a good return, even if you don’t agree with their products. And then buy products based on your convictions. If you want to feel like you’re “sticking it to the man,” use the profits to buy from their competitors.