You’re describing the boot keyboard, not the full USB HID protocol. It is true that there are some keyboards that only support NKRO, but the USB HID protocol has supported NKRO forever. https://www.devever.net/~hl/usbnkro

About as wide as my oversized fridge.

Can’t wait to get rid of that shit and have something that actually fits in my kitchen.

Me replacing GNU coreutils with the rust ones.

That doesn’t get you a good text editor. That just gets you emacs with two bad next editors.

My experience with Apple has been more like

I credit Apple in many ways for their choice to design their business in a way that their profit motive often aligns with their users’ interests.

Their app store model for iOS is one of the strongest examples of them not doing that though.

A cat and a bike

But how am I going to use capabilities to have my equivalent of sl having setuid to nobody?

They’re downloaded somewhere under /var/snap and by default a snap only has access to a limited set of directories - one under /var/snap for system-wide data (generally used by snaps that run services like cups or MySQL) and one under ~/snap for each user. When you snap remove an app, it bundles that up into a file that’s kept for a while in case you reinstall, but it won’t if you use --purge.

Obviously many apps request access to other places (such as non-hidden directories in your homedir) so they can read or write stuff, but that’s down to the app to then behave correctly (same as with any other packaging system).

Let me know when I can get cups as a flatpak.

(Oh and snaps predate flatpaks.)

Yeah the API is open and there used to be an open store, but lack of interest ended up with the project shutting down. As it turns out people don’t like alternative stores nearly as much as they like the idea of alternative stores.

Yeah, Steam is pretty much a monopoly. But I haven’t seen what I’d call monopolistic practices from them. It’s just that everyone else appears to fall flat on their faces when trying to make a competing product.

I’m less mad at Steam and Google because there are clear, simple ways to avoid their cuts.

I have no basis to say whether they’re providing a service worth the 30% charge. I’m also less mad at Steam than at Google because they’re being less shady about trying to push people into their store too.

The Reminder bot

My ex: what charging cables do you have? They last forever, mine break after a year!
Also my ex: so I got a bunch of the same charging cables you have and they all broke after a year

Great way to damage a power cable.

Kate

I think a better analogy would be that you’re tuning your bike for better performance because the trade-offs of switching to a car are worse than keeping the bike.

It’s all about trade-offs. Here are a few reasons why one might care about performance in their Python code:

1. Performance is often more tied to the code than to the interpreter - an O(n³) algorithm in blazing fast C won’t necessarily perform any better than an O(nlogn) algorithm in Python.
2. Just because this particular Python code isn’t particularly performance constrained doesn’t mean you’re okay with it taking twice as long.
3. Rewriting a large code base can be very expensive and error-prone. Converting small, very performance-sensitive parts of the code to a compiled language while keeping the bulk of the business logic in Python is often a much better value proposition.

These are also performance benefits one can get essentially for free with linter rules.

Anecdotally: in my final year of university I took a computational physics class. Many of my classmates wrote their simulations in C or C++. I would rotate between Matlab, Octave and Python. During one of our labs where we wrote particle simulations, I wrote and ran Octave and Python simulations in the time it took my classmates to write their C/C++ versions, and the two fastest simulations in the class were my Octave and Python ones, respectively. (The professor’s own sim came in third place). The overhead my classmates had dealing with poorly optimised code that caused constant cache misses was far greater than the interpreter overhead in my code (though at the time I don’t think I could have explained why their code was so slow compared to mine).