• 0 Posts
  • 6 Comments
Joined 27 days ago
cake
Cake day: January 26th, 2025

help-circle
  • I don’t believe those MBA types should be in the discussion at this level at all.

    That’s the thing. They are in the discussion. It doesn’t matter what we think about it. If touching Rust risks yielding lower profits this quarter, it’s an automatic ”fuck off you filthy hobbyists”. Even having the discussion costs money.

    Rust in the kernel isn’t about technology, it’s about economics and risk management. I’d like to see the discussion move on from ”C bad unsafe rust gud typesaf” to a level where the suggested benefits of Rust are made clear to the people holding the bags of money, preferably presenting some actual monetary benefits. (Oh, and to make things worse, there are thousands of different stakeholders, with different interests, many of which are in conflict. Good luck!)

    So yeah, I get that you don’t care about it. But you probably should.


  • I’m still kind of on the fence about Rust in the kernel. Linux isn’t some random hobby project, there are serious people working for serious companies in the project. Rust has a clear value proposition w.r.t. it’s qualities as a language, but I don’t think it’s as clear on a system level.

    Say I’m working for a large company as a dev, maintaining a subsystem (let’s say a driver). Letting other people (filthy casual hobbyists) mess around with their filthy type safety will eventually spill into my subsystem and cause extra work. I don’t want the extra work, I just want to have my driver working and then go home. And even if I’m okay with the extra work, my boss won’t be. Even the risk of extra costs down the line will be enough for some to shut it down completely.

    There are boring people working for huge corporations with huge stakes in the Linux kernel. I don’t think they see that much value in Rust at the moment, and I think the Rust crowd might need to hire some MBAs if they want to expand their presence in the kernel.




  • Sure, I’ll do another mini-rant.

    I have no idea what real world threat model and threat actor the Wayland people are going for. A threat actor with code execution on a Linux desktop immediately has access to the filesystem and can do whatever anyway, in practice (see also: Steam deleting home directories). Privilege Escalation is a thing and namespaces in Linux are kinda meh. Run your untrusted code in an ephemeral VM.

    My point is just that once you have a threat actor running code on your system, it’s game over regardless of whatever your desktop tries to do. (I’ll run with the Maginot Line comparison here, but Wayland is more like a locked door without walls.)

    The security issues with X were the X-Forwarding-stuff being kinda bad, not the ”full access to everything”-stuff. I want my applications to access my things, otherwise I wouldn’t run the application.

    If your threat model seriously needs sandboxing, you’ll wanna go the Qubes-route. Anyways, Arcan seems to have a more reasonable threat model than Wayland if you wanna go that route.

    Thanks for reading my yearly mini rant on why Wayland’s security don’t matter and only gets in the way of the user and application developer.


  • So this is my big issue with Wayland - nothing is a ”Wayland problem”. Everything lands on the compositors. Features that existed for the past few decades in X and are deeply integrated into the ecosystem were relegated to second class citizens or just ignored. (Can we share our screens with Zoom yet?)

    I won’t argue that X is flawless or should live forever. X should die. However, X actually solved problems instead of just providing a bunch of (IMHO) half baked ”protocols” so that someone else can solve the problem. From the perspective of a user or application developer, that’s just hot potatoes being passed around. And there have been plenty of hot potatoes the past decade.

    Thank you for reading my yearly Wayland rant. I’ll now disappear into my XMonad-fueled bliss, fully software rendered.