neobrain

The buyers are anonymous, the recipients (i.e. shops/merchants, generally) are not. The idea is that this will effectively prevent money-laundering and tax evasion as merchants wouldn't be able to hide any earnings.

One strength of nixpkgs that probably appeals to Arch users too is how much software is available and how easily you can just re-compile apps with custom patches. In fact, the latter is enabled exactly through reproducibility :)

That said, cool if pacman and AUR work for you, no need to change just for the sake of it!

Just adding to this since the point might be lost for people new to nix:

You can assign a value to `services.restic.backups.my_repo.paths = [ ... ]` in multiple places throughout your system configuration. When applying the config, all the values will be merged into a single list.

This is important because other standard tasks besides backup (e.g. firewall, monitoring, ...) also require per-service configuration. If every one of these tasks had only a single place where you needed to put a megalist of services (which is basically how `/etc` works on typical Linux distros!), this would quickly scatter the configuration that pertains to FreshRSS over N different files, making it hard to track where everything lives.

Running Cosmic (which is a Wayland-only DE) on a DGX Spark. It just works.

Can't speak for all countries ofc, but the happy path isn't just the US. I've heard positive reports in Europe where banking apps work without Play services more often than not, and if it doesn't some banks will actually change implemented policy once a customer complains.

> This comes up every time, I just don't understand the argument. You can fork AOSP when that happens

Hacking on the Linux stack is several orders of magnitude more practical than AOSP though. AOSP's build system is massively unwieldy for individual contributors to work on. You can't easily work on any of the system components without dedicating >100 GiB of storage for a build, for example. Everything is scattered across hundreds of repositories tied together with a bespoke repository management tool.

This all works for a company equipped with entire build infrastructure teams, not for a grassroots project trying to keep up maintenance with (at best) limited funding. It's why Nura (fka postmarketOS) is a thing whereas the various AOSP forks barely ever modify the core experience.

Sounds OpenShell locks filesystem access on sandbox creation - arguably the most important isolation feature, at least for my use cases. Architecturally it looks right though!

Very interesting concept to make permissions specific to individual shell commands though. Certainly good that people are experimenting with these approaches, hopefully ideas will eventually converge so we don't need to know like a 100 different sandbox projects :)

Even for pure research/prototyping, you quickly run into the problem that your sandbox is either prohibitively minimal or overly permissive. Depending on the exact task, you may need GPU access, Docker/Nix socket access, ability to ptrace processes (gdb), run webfetches, etc. If I define a "research" sandbox profile to allow all of these, I might as well not have any sandbox at all.

Do any of these sandboxing solutions have a dynamic component to them that lets you grant permissions, starting with a minimal sandbox and asynchronously adding permissions as they become necessary? Harnesses try to do this when accessing non-project folders, but it's not always strictly enforced and generally not revocable. Harnesses also block agent execution until a decision is made, which requires constant monitoring to ensure progress can happen when the agent could easily proceed with an alternative method right away.

I like the idea of a minimal sandbox that protects against accidental `rm -rf` and against personal data leakage, but such a setup then often gets in the way of the specific task to be done. Ideally the sandbox would be able to aggregate blocked accesses and then expose them in an external TUI dashboard, where I can then enable access (without blocking any running agent on this, since that's prone to "press okay" fatigue).

Does anything close to this exist yet?

> because it’s the same process of intermediaries accumulating, inferring and sharing data to each other

Except that YouTube doesn't need any of that to recommend Minecraft videos to you. One mundane explanation that seems more likely is that it's the type of content that on average works best on people they don't yet have information on.

Reminds me a little of these "phones listen to everything we say, otherwise I wouldn't have been shown this ad" anecdotes that don't hold up against empiric evidence.

> Google somehow got to know that I played Minecraft again after a decade. [...] I knew at that point already that probably all my PI is public information anyway

How are you jumping from Minecraft (probably one of the most watchtime-generating content types out there) being displayed on your main page to… your personal information being known to everyone?

Obviously not ideal, but update latency is much better with other third party distributions like iodéOS or CalyxOS.

At least in contrast to other vendors, FP provides official support for microG, so this has been without noticeable loss of stability/quality for my use cases so far.