trevor (he/they)

Thanks for sharing! Bounds checks are a fair critique. The Rust Performance Book suggests that bounds checking has little performance impact compared to many other factors that you could optimize out, but it’s certainly not zero performance impact, as I initially claimed.

Unless you’re talking about some sort of reference counting, which has to be explicitly added by the programmer in cases where doing so is required for memory safety, I’m not sure what runtime checks you’re referring to?

From what I’ve seen, the performance of programs written in C and Rust are generally the same, more or less, with C or Rust coming out on top with roughly coinflip odds in a handful of cases. This feels like the primary differentiator in performance really comes down to the implementation of the person writing it, and less to do with any performance differences inherent to either language.

This is an awesome tool, and I love to see it get a Rust rewrite.

But the one thing I really wish it could do is embed properly in GitHub’s markdown UI so that when I click them in READMEs it doesn’t have to send me to the asciicinema site.

I’m sure that has way more to do with GitHub than it does asciicinema, but still, that’s why I don’t use it for my projects. I hope that can change one day.

“Thing I say is good, is better than thing I say is mediocre.”

Indeed.

This is not true. If you know Rust and C equally well, you’re likely going to write equally performant Rust.

You could say that Rust is harder to learn than C. I’d disagree based on my personal experience, but you wouldn’t be wrong.

I have no idea how. I write better Rust than I do C 🤷‍♂️

Rust and C are basically identical in terms of performance (more or less). Idk where the myth that Rust is somehow less performant than C came from.

The ill-informed Rust hatred goes in the Phoronix comments. Rust isn’t inherently slower than C. This was a bug.

So many Rust projects are dual-licensed under Apache or MIT. It’s just a convention that many Rust projects have adopted. Yes, it’s true that there’s nothing intrinsic about Rust the language that requires a certain license type. But it doesn’t mean that the Rust community hasn’t adopted a convention of licensing with pushover licenses. That’s my point.

Using Rust != required to use pushover licenses. It’s just a bad convention that a lot of Rust projects adopt.

The Rust code is licensed under GPLv2-or-later.

The trusted publishing is really cool, but all I want is the ability to publish crates without needing to link an OIDC account (like GitHub). I have so many crates that I don’t publish because I hate mixing accounts/identities like that.

The grown-ups that run Fedora and the community are overwhelmingly against this very bad proposal, so I don’t think the reich-wing creep’s toy project is going to replace the official XServer implementation any time soon.

This probably has a lot to do with the new DOA XServer fork being “anti-DEI” (pro-discrimination). When these slimy shitweasels go out and vice signal about how bigoted they are, they congregate around it and form a new harassment campagin because they have no life.

Sorry you’re getting harassed. I hope you can take solace in the fact that these little pissbabies lead miserable lives.

Linux on Apple Silicon is a totally different story than it was for Intel Macs because of the work put in by the Asahi team. It’s actually one of my favorite pieces of hardware to run Linux on. The trackpad works great too, btw.

It’s not for no viable reason. Rust is just safer than C. There absolutely are bugs with GNU coreutils, so it’s not even a hypothetical like you implied. But beyond safety, some of the Rust equivalents are more performant than their C counterparts.

And uutils is already heavily tested against the GNU coreutils. It’s not some fly-by-night rewrite that people aren’t serious about. I don’t know if it’s been formally audited yet, but it absolutely will be when companies like Canonical (and hopefully SUSE and Red Hat, one day) want to start shipping them.

Just adding to this for other people that don’t know: you can also install most* standard Linux applications and tools on SteamOS, as long as it’s available as a Flatpak, or you can install it to your user directory. Technically, you can even bypass that last caveat and install whatever you want, but you’re going to have a bad time if you don’t know what you’re doing.

Alternatively, you can install any Linux distro on your Steam Deck if game dev isn’t a good experience for you on SteamOS. In fact, Bazzite is working on a GDX (Game Developer eXperience) edition, and will likely be a solid choice once it’s ready.

I don’t dislike GNOME (except for their insistence on shirking and breaking standards that everyone else uses), but I’m curious about why you prefer KDE on your laptop, but GNOME on your desktop. If anything, I’d think that GNOME’s larger UI might be easier to use with a less precise pointing device than default KDE.

internationalization

Interesting point. I don’t actually know about that. What can the GNU coreutils do with regard to internationalization? Just the output of commands, or can they also internationalize stuff like command args?

I fully agree with you on the accessibility front. It’s not even good on X11, but it’s unusable on Wayland, from what I understand :( Accessibility on Linux needs a massive funding and development initiative, and it needed to be done a long time ago.

But uutils is pretty solid. I’ve swapped out my GNU coreutils entirely (on Arch, not Ubuntu, because I value my time too much to be troubleshooting broken snaps) and haven’t run into any issues. I think people are underestimating how close the compatibility already is. I’m sure something I use at some point will try to invoke an option that doesn’t exist in the uutils version, but it’s been solid for me so far.

That’s not what I mean. Yeah, getting the environment variables are simple enough, but if you simply exec something as the root user, whatever you exec will naturally be looking for configs in /root/.config and not your ~/.config dir, so any configurations to things like your text editor won’t be read.

I don’t think it’s that simple. The challenge is that you need to still behave as if it’s invoked as the user so that the editor uses their configurations instead of simply execing it as root.

I could be wrong though ¯\_(ツ)_/¯