trevor (he/they)

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.

The Linux app is just the desktop app, which doesn’t have the functionality that the Android and iOS apps do. It only works when paired with an Android or iOS device, so you’d still be shackled to those ecosystems without proper support for a mobile Linux app.

Canonical does a lot of bad shit, but switching to uutils is not one of them. The “challenges” are expected because it’s going in a non-LTS release, which is basically meant to be a beta of the next LTS. And those challenges are being quickly addressed as they’re being surfaced. This is exactly the right way to introduce something new, IMO.

I don’t like the uutils pushover license license though :/

Because their sandboxing format subtly breaks so many applications (more than flatpak) and Canonical very nefariously co-opts your apt install <package> with a deb package that’s actually a stub to install the Snap version, so when your shit breaks, you can waste hours before you realize that they fucked your installation.

Beyond that, Snap cold start times (installations or updates) are slow as shit (yes, even with LZO compression), and since each snap application can update on its own, you’ll also encounter random times when your shit appears to “freeze” but what’s actually happening is Canonical is busy polluting your loopback devices to decompress their shittified version of your app.

Canonical, being demons, have Snapified things like GNOME, so even your desktop environment will be encumbered by that dogshit packaging format.

Do not use Ubuntu if you value your time and well-being.

Can we avoid calling taking action against valid moral objections “drama”? It only serves to make the people doing the right thing sound like they’re being immature, even when they’re obviously right.

Objecting to a fascist government’s influence over very powerful build infrastructure used around the world is the right thing to do.

This type of comment is indistinguishable from the low-tier, rage bait comments under every Phoronix article.

oniux might be exactly what you’re looking for.

It was still in early development when I played with it months ago, so I’m not sure if it’s ready for daily usage, but it’s from the Tor Project team themselves, so I imagine it will only keep getting better.

If this works out, it’s likely something that container engines would take advantage of as well. It may take more resources to do (we’ll have to see), but adding kernel isolation would make for a much stronger sandbox. Containers are just a collection of other isolation tools like this anyway.

gvisor already exists for environments like this, where the extra security at the cost of some performance is welcome. But having support for passing processes an isolated, hardened kernel from the primary running Linux kernel would probably make a lot of that performance gap disappear.

I’m also thinking it could do wonders for compatibility too, since you could bundle abandoware apps with an older kernel, or ship new apps that require features from the latest kernel to places that wouldn’t normally have those capabilities.

The --stream functionality looks very useful as well. Super cool!

One thing I really miss from Unity is the efficient use of the top bar doubling as a title bar for full screen windows. I wish modern DEs would do this.

Just here to add that, yes, Snaps are very broken. Do not use them if you value your time or well-being.

The annoying thing is that Canonical dishonestly co-opts your apt invocations for snap installations, so you’re likely to waste hours of your life trying to figure out why the thing you installed doesn’t work or takes forever to launch randomly. And they keep Snapifying more of their distro, so even things like GNOME packages are only available as Snaps.

This is the first time I’ve heard “lint” used this way, but I like it. I’ve heard Linus refer to various waste left behind on your system as “turds” 💀

Anyway, this looks like a cool tool. Gonna check this out.

I never used erdtree. What do you like about it that is different from eza?

Extensions. Epiphany can’t run Firefox and Chromium extensions, but Orion mostly can. I can’t live without uBlock Origin or autofill from my password manager, and Orion is the only niche browser I know of that can.

Yes, but don’t mention it to the people that only care about their eye candy because they get very mad when you do that.

Edit: as predicted, the chuds are assmad.

I posted this in another thread, but reposting here because a lot of people, including myself up until very recently, were under that impression:

I’ve packaged a CLI that I made as a flatpak. It works just fine. Nothing weird was required to make it work.

The only thing is that if you want to use a CLI flatpak, you probably want to set an alias in your shell to make running it easier.

I’m not sure why more CLIs aren’t offered as flatpaks. Maybe because static linking them is so easy? I know people focus on flatpak sandboxing as a primary benefit, but I can’t help but think that if static linking was easier for bigger applications, it wouldn’t be needed as much.

I’ve packaged a CLI that I made as a flatpak. It works just fine. Nothing weird was required to make it work.

The only thing is that if you want to use a CLI flatpak, you probably want to set an alias in your shell to make running it easier.

I’m not sure why more CLIs aren’t offered as flatpaks. Maybe because static linking them is so easy? I know people focus on flatpak sandboxing as a primary benefit, but I can’t help but think of static linking was easier for bigger applications, it wouldn’t be needed as much.

I’m not quite sure why you think pointing out someone’s confidently incorrect claim that containers do give you reproducible environments means that I fetishsize anything?

But if you genuinely want to know why reproducibility is valuable, take a look at https://reproducible-builds.org/.

I was quite happy to see that Debian and Arch have both made great strides into making tooling that enables reproducible packages in recent times. It’s probable that, because of efforts like this, creating reproducible builds will become easier/possible on most Linux environments, including traditional container workflows.

For now though, Nix Flakes are much better at enabling reproducible builds of your software than traditional containers, if you can suffer through Nix not being documented very well. This article covers some more details on different build systems and compares them with Nix Flakes if you want more concrete examples.

FWIW, I think that containers are awesome, and using them for dev environments and CI tooling solves a lot of very real problems (“it works on my machine”, cheap and easy cross-compilation for Linux systems, basic sandboxing, etc.) for people. I use containers for a lot of those reasons. But if I need to make something reproducible, there are better tools for the job.