In the sense that allowing a malicious application to steal your SSH keys is "fixing", yes.

This is interesting, but I wouldn't consider this to be at all comparable to Flatpak. From what I can see the only purpose of using bubblewrap here is the dependency isolation (without having to recompile the world ala Nix), which does have some value but it feels misleading to even call it a sandbox.

It mounts /home and /run into the ~~sandbox~~ chroot, which means that "sandboxed" applications can do things like reading your SSH keys, dumping your keyring or escaping the sandbox via write to .bashrc (so most of the attacks you'd want to prevent). This is presumably done because without /home access you wouldn't be able to write to the filesystem and without /run access you can't even display a graphical window, which would make the packages quite useless.

XDG Desktop Portal solves this by allowing filtered dbus access controlled by package metadata (/.flatpak-info), and then having sandboxed applications use portals to access files, secrets and other resources. The metadata is a major flaw in Flatpaks design (note that a lot of the most popular Flatpaks want full $HOME access), but it's also what allows Flatpak to be useful. In this project, there's no metadata since the packages just come from Alpine repositories.

I haven't heard of Coldbrew before, it looks very interesting.

The unfortunate thing about snap is that of all options, it is the most capable. You get GUI, CLI, server, full filesystem access if needed (aka classic snaps). But Canonical really drags the project down and handicaps it with poor decisions.

That's also how I feel about it. I've heard many good things about it technically, but Canonical really killed its adoption outside of Ubuntu.

Then you look into it a bit more and the story changes to "oh actually you need to enable this experimental feature to get better reproducibility".

This unfortunately gets misunderstood a lot, mostly because of the stupid flake hype. You do not need flakes for reproducibility, Nix comes with a fetchTarball builtin function which allows you to pin a specific Nixpkgs commit and output hash.

You're right though, I agree on basically every point (including the part about flakes).

Auf der einen Seite stehe das staatliche Interesse an effektiver Strafverfolgung, auf der anderen das Eigentumsrecht des Betroffenen – einschließlich des fortschreitenden Wertverlusts der Geräte. Entscheidend war, dass es über 2,5 Jahre keine ernsthafte Auswertung gegeben hatte. Und das, obwohl es sich überschaubare 56 GB handelte, es keine Verschlüsselung gab, die PINs bekannt waren und die Daten bereits gesichert.

Was für ein Saftladen. Erinnert mich an XKCD 538, nur umgekehrt.

All of the 5 people who use (non-ESR) Firefox on their 2002 Pentium 4s will certainly be very unhappy about this.

In defense of the author and their education... They're Brazilian so English probably isn't their native language, and their history education was almost certainly in Portuguese. I don't think it's necessarily an indictment of their education that they weren't taught about the English translation of a German phrase, and I don't think it's reasonable to apply the same standards of subtext awareness to native and non-native speakers either.

Nu's find builtin isn't a GNU find repacement. I think what you actually want is ls piped into where:

ls **/* | where type == file

I do question the choice to alias a well-known program with a builtin that does something entirely different. You can also use ^find to avoid calling the builtin. I would've expected \find (bash-like) or command find (fish-like) to work as well, but alas...

Many people who don't know what they're talking about in this thread. No, used memory does not include cached memory. You can confirm this trivially by running free -m and adding up the numbers (used + cached + free = total). Used memory can not be reclaimed until the process holding it frees it or dies. Not all cached memory can be reclaimed either, which is why the kernel reports an estimate of available memory. That's the number that really matters, because aside from some edges cases that's the number that determines whether you're out of memory or not.

Anyway the fact that you can't run Linux with 16GB is weird and indicates that some software you are using has a RAM leak (a Firefox extension perhaps?). Firefox will use memory if it's there but it's designed to cope with low memory as well, it just unloads tabs quicker so you have to reload often. There are also extensions that make tab unloading more aggressive, maybe that would help - especially if there's memory pressure from other processes too.

Insightful article. I have to confess I never realized the accessibility situation was this bad.

I also want to highlight this excerpt from the comments:

Making things accessible isn't hard technically. But it requires coordination and people to care about it enough to work on it at the expense of other features. If [I] developed an application on a team and said I had 'one security guy that works on that stuff as long as it doesn't interfere with the rest of our work' I'd be dragged over the coals and have my project forked by the public.

But with accessibility? There's really no sense of priority or urgency despite it being broken for years and not putting much effort in to fixing it.

Try launching Steam from the terminal so you have a chance at seeing an actual error message, at least for the crashing games.

It might be the kernel as the other comment says since the 9070 is pretty new. If it works without issues on something like Fedora or OpenSUSE TW then that was probably the issue.

To be fair this also happened to Eagle Dynamics, developer of DCS, the other "realistic" flight sim that players take far too seriously. Except there it was a Dev that got arrested in Georgia and extradited to the US...