trevor (he/they)

Correction: Ente is also self-hostable.

Your move, Rust. I’d love to see it happen.

Zig isn’t memory safe by default. Safety needs to be opted-in to, which isn’t free.

And merely recompiling C projects with the (very good) Zig toolchain wouldn’t add any form of memory safety whatsoever as far as I’m aware. You can get some safety checks that way, but you still have to fix the buggy C code manually, which is a nontrivial task in best-case scenarios.

If you’re expecting stability for any Ubuntu release, that went out the window when Canonical started forcing Snaps.

But non-LTS Ubuntu releases have always been a testing ground for less-than-stable changes. uutils is just one of them, and the only way to make them stable is to see how they’re being used in the wild.

Again: Google would not be doing this if there was no perceived benefit for them. If it was merely a matter of adding a scarier warning, then what purpose does the new “student/hobbyist” account type that restricts the number of devices your app can be installed on serve??

The headline is incomplete to an extent that it’s dishonest because it doesn’t reflect the reality of what Google is saying.

Google will only allow “experienced users” to “continue” sideloading with the new, draconian restrictions that Google will be the arbiter of. “Continue” implies that sideloading will continue as it is in its currently acceptable form. However, that is not the case. If it were, Google would not be changing anything at all because there would be no perceived benefit for them doing so.

So in a way, yes, the entire article is wrong, because it doesn’t adequately push back on the premise that it implies and instead uncritically parrots what Google would prefer people to believe, which is that people that want to sideload their apps and use third-party app stores like F-Droid will not be negatively impacted, which is not true.

It’s not FUD. The “install unknown apps” toggle already does what you’re describing. Whatever the intentionally vague blurbs from Google imply, whatever the new toggle ends up being will be worse.

And that doesn’t account for the need they’re creating for a “student/hobbyist” account that Google is creating. If you use such an account, your app can only be installed on a limited number of devices, which Google will control.

The “install unknown apps” toggle already does that. Whatever that vague blurb implies, whatever the new toggle ends up being will be worse.

And that doesn’t account for the need they’re creating for a “student/hobbyist” account that Google is creating. If you use such an account, your app can only be installed on a limited number of devices, which Google will control.

Yeah, this is garbage. Nobody should accept this. People need to keep fighting this because the “hobbyist account” bullshit still gives Google full control over what apps you can install by creating an arbitrary restriction that they can change on a whim.

Nothing short of leaving the process of installing apps from outside the Play Store exactly the same as it is now should be accepted.

The Verge is laundering Google’s Big Brother bullshit with their headline by making it sound like Google responded in an adequate manner, which is exactly what Google wants.

I prefer this as well, but just adding that Fish also supports $() for those that don’t know.

I keep hearing people that haven’t used modern versions of Fish say that it’s somewhat different from Bash and strays from POSIX compatibility quite a bit. While the latter is true, Fish has added many bash-isms over the years, so most scripting idioms you’re familiar with will work there too.

I’m replying to you from Asahi Linux on an Apple Silicon Macbook. The drivers are definitely there!

FEX emulation of x86 on ARM CPUs has made many x86 games playable on my Macbook.

I’m replying to you from Asahi Linux on an Apple Silicon Macbook. The drivers are definitely there!

FEX emulation of x86 on ARM CPUs has made many x86 games playable on my Macbook.

Wrong. Have to start adoption somewhere, and doing it in a non-LTS release is a great move.

Same.

The detractors of this project portray it like it’s a far-off pipe dream to be a drop-in replacement for GNUtils. Meanwhile, it’s still a relatively young project that already has 85% compatibility. I think we can do it. Lol.

He’s a self-described democratic socialist, which is different from a social democrat, as you labeled him. Yes, many of his proposed policies are steps toward social democracy, rather than actual socialism, but I can’t expect one mayor, even in one of the largest cities, to somehow enact real socialism.

That distinction aside: all we can do is apply pressure and hope that Mamdani doesn’t meaningfully sell-out the working class in NYC.

You’re a different kind of VM enjoyer than me, and that’s okay 😎 I’m glad GNOME Boxes and virt-manager are getting the job done for you. I’m okay with the latter, but I think it needs some love, which is why I’m eager to see alternative frontend options.

Docker works. Podman requires a ton of workarounds and wastes my time. I hope it gets good one day, but I’m not reverting to using systemd to manage containers.

This isn’t just VirtualBox. It’s VirtualBox with a KVM back end. So you get the performance of KVM, but with a much better GUI than virt-manager.

Well, MIT projects can be forked into a new GPLv3 project, right? If Canonical cared, they could have done that to assuage this concern.

I think it’s a valid concern. Pushover licenses are bad. But even if a GPL Rust coreutils project exists (I actually have one, but I don’t have the same goals), it seems unlikely that Canonical would be bothered to pivot to it.