Only a Linux user’s answer to “how do I install software that’s not packaged for my distro” would be “don’t”.

I don’t think so. At this point Linux isn’t really held back by software availability - 90% of things are web based now and games apparently work pretty well (certainly better than on Mac).

The main issue is hardware support and driver quality. Especially on laptops, if you install Linux you’re really rolling the dice on whether or not you’ll get something that works.

Someone always replies to comments like these with “it works for me!” which is not really relevant when it has to work for everyone.

For a while at work I was in the Linux slack channel even when I was using a Mac, just to follow the amusing problems people had (and they had a lot!).

Then I moved jobs and have a Linux laptop… I get to experience it first hand. Hard reboot when it runs out of RAM, or 20% or the time when you undock it. Doesn’t work at 60Hz/4K on some work monitors but only if you are using HDMI. The exact same laptop model & OS works for other people. Battery life is hilarious. I don’t think I’ve ever got over 2 hours.

Looks interesting. Linux ABI compatibility is a herculean task though. Probably on the order of writing a web browser or a MS Word compatible word processor.

Well that just sounds insane. Isn’t the whole point of an abstracted API that you can write code for it once and it works with all of the implementations?

submitting a merge request with changes that don’t compile is an absolute no-go.

Right but unless the tests for all 50 filesystems are excellent (I’d be surprised; does Linux even have a CI system?) then the fact that you’ve broken some of them isn’t going to cause a compile error. That’s what the linked presentation was about! Rust encodes more semantic information into the type system so it can detect breakages at compile time. With C you’re relying entirely on tests.

Ask the Rust maintainers to fix it presumably? The antagonist in the video above claimed there are 50 filesystems in Linux. Do they really fix all 50 filesystems themselves when they change the semantics of the filesystem API? I would be very surprised. I suspect what actually happens currently is either

1. They actually don’t change the semantics very often at all. It should surely be stable by now?
2. They change the semantics and silently break a load of niche filesystems.

I mean, the best answer is “just learn Rust”. If you are incapable of learning Rust you shouldn’t be writing filesystems in C, because that is way harder. And if you don’t want to learn Rust because you can’t be bothered to keep up with the state of the art then you should probably find a different hobby.

These “ooo they’re trying to force us to learn Rust” people are like my mum complaining you have to do everything online these days “they’re going to take away our cheque books!” 🙄

It’s because

1. They’re old and they don’t want to have to spend time learning something new.
2. They spent a lot of time learning C and getting moderately good at it. They don’t want that knowledge to become obsolete.
3. They currently don’t know Rust, and don’t want to feel like the thing they do know is no longer the best option.
4. They aren’t the ones with the idea to use Rust, and they don’t want to lose face by accepting that someone other than them had a good idea. Especially not some young upstarts.
5. Supporting Rust is extra work for them and they don’t care about memory safety or strong types etc.

In order to avoid losing face they’ll come up with endless plausible technical reasons why you can’t use Rust in order to hide the real reasons. They may not even realise they’re doing it.

Some of the reasons might even be genuinely good reasons, but they’ll come up with them as an “aha! So that’s why it’s impossible” rather than a “hmm that’s an issue we’ll have to solve”.

It’s not just Rust Vs C. This naysaying happens wherever there’s a new thing that’s better than the established old thing. It’s a basic human tendancy.

Fortunately not everyone is like that. Linus seems in favour of Rust which is a very good sign.

Operating system interfaces use the C ABI, but they don’t require you to use C.

Actually that’s true on most OSes, but not Linux - that uses syscalls as its interface not function calls to a shared library, so it’s the syscall ABI.

I still feel like designing and bootstrapping your own higher level language is going to be less painful overall than writing a Rust compiler in C. And probably more fun.

I don’t want to sound condescending, but what do you think all this talk about Rust and AI tools is about?

Yeah I am aware. It’s very good that they’re looking at it and great that Linus is supportive and not a stuck-in-the-mud. Doesn’t invalidate my comment thought. He’s still saying security bugs are no worse than other bugs.

And if some feature turns out to be a gaping security hole you’ll quickly see it turn into a bug. That’s what the quote is about. Every security issue is a bug so it has to be handled like a bug and squashed.

I mean… I don’t think that’s what he’s saying. Nobody is saying not to fix security bugs…

Should what be handled? Security vulnerabilities? Here’s how you should handle security bugs differently to other bugs:

1. Report them separately and clearly. Don’t hide by omission the fact that they are security bugs (common practice in Linux apparently). Coordinate with major vendors how to push fixes.

2. They are generally more important than other bugs so you should put more effort into detecting and preventing them. E.g. using fuzzing, sandboxing, formal methods, safer languages, safety annotations, etc.

3. They have high value on the grey market and people actively try to create them, so you need to design your system under that assumption. An obvious thing to do is software isolation so a bug in - to pick a random example xz - can’t bring down ssh. Software isolation, microkernels, sandboxing etc. help with this.

There’s no way you can say “they’re just bugs”. Maybe in the 80s. It’s not the 80s.

security vulnerabilities are simply bugs

I don’t know how he can still maintain this clearly insane stance. Pride?

Torvalds expressed disappointment in the slow adoption of Rust due to factors like resistance from older kernel developers and instability in Rust infrastructure.

This is a good sign at least!

potential for AI tools to assist in code review and bug detection

Definitely agree here. One thing I really liked that I saw a while ago is colour coding code based on how “surprising” each token was to the LLM, the idea being bugs would be more surprising. Neat idea. It didn’t seem to actually work very well but maybe it could be improved.

Biggest issue I have is that no company I’ve worked for is ever going to be ok with sending our code to some AI company’s servers, and the options for local models are super limited. So I can’t actually use any of this stuff except for hobbies.

This, of course, only works on little-endian machines. On big-endian machines, c has to be bytereversed.

Interesting advantage of little endian!

The only good free option for that is SolveSpace. Don’t bother with FreeCAD. It still isn’t usable. SolveSpace is remarkably good for an open source CAD program.

It does have some notable missing features though, e.g. no bevels, fillets, drafts, etc. and last time I used it it had accuracy issues with small holes. But for your use case it’s probably fine.

Not really because RefCell has performance implications and also adds noise to the code.

But I would not be a fan of implicitely allowing multiple mutable borrows without any clue for that in the code.

Nobody is suggesting breaking Rust’s multiple mutable borrow restriction. The macro solution simply doesn’t do that, and the “make the borrow checker smarter” solution just releases the mutable borrows when they aren’t being used so they don’t overlap.

The benefits are that you don’t have to pass out and similar captured variables into the closures/functions.

Yeah that’s pretty unreadable IMO. I think your second link isn’t what you intended?

I dunno, does it even need a new feature? Kind of feels like Rust should be able to figure it out as long as the lambdas aren’t moved/stored/etc?

Sorry that example was a bit too limited to demonstrate the problem actually. Add a second lambda and you hit the issue:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=eb99d3d670bdd9d92006f4672444d611

Still totally fine from a safety point of view, but the borrow checker can’t figure that out.

I disagree. It’s a sign your code isn’t structured in a way that the borrow checker understands, but that is a subset of well-structured code.

In other words, if your code nicely fits with the borrow checker then it’s likely well structured, but the inverse is not necessarily true.

One thing I always run into is using lambdas to reduce code duplication within a function. For example writing a RLE encoder:

fn encode(data: &[u8]) -> Vec<u8> {
  let mut out = Vec::new();

  let mut repeat_count = 0;

  let mut output_repeat = || {
     out.push(... repeat_count ...);
  };

  for d in data {
      output_repeat();
      ...
  }
  output_repeat();
  out
}

This is a pretty common pattern where you have a “pending” thing and need to resolve it in the loop and after the loop. In C++ you can easily use lambdas like this to avoid duplication.

Doesn’t work in Rust though even though it’s totally fine, because the borrow checker isn’t smart enough. Instead I always end up defining inline functions and explicitly passing the parameters (&mut out) in. It’s much less ergonomic.

(If anyone has any better ideas how to solve this problem btw I’m all ears - I’ve never heard anyone even mention this issue in Rust.)

I never did a CS degree but recently I’ve been doing some things that make me wish I had. But it isn’t any of this stuff which seems mostly programming things that you can easily learn outside academia.

The stuff I would like to understand which I haven’t yet been able to learn on my own is the hard computer sciency stuff: lambda calculus, type inference (how do you read that weird judgement syntax?), how SAT/SMT solvers work, dependent typing systems… Does anyone have any good resources for those sorts of things?