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.
344 karma · joined March 15, 2014
That said, cool if pacman and AUR work for you, no need to change just for the sake of it!
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.
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.
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?
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.
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?
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.
It's an interesting example given that Wine considers deriving code from traces of original components (like hypervisor traces) tainted and also bans LLM contributions for legal considerations: https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guide...
Where? You suggested it would go through Murena instead, but you can fully disable third party services by disabling external push providers and by using on-device databases for GPS. e/OS directly offers this configuration during initial setup.
> And what would you say GrapheneOS does of those? Do you know, or do you just assume that GrapheneOS does the worse there?
I'm not necessarily trying to present either as "better" or "worse" since they both have their merits depending what exactly you're after (which I don't feel this is the right time/place to have a detailed rundown of). It was the root comment that posited e/OS was strictly inferior for people who care about freedom.
The last bit of my sentence could easily be misread as an enumeration of three things ("microG", "OTA updates", "everything included"), but it was actually an elaboration: FP is the only vendor to support microG, and (in contrast to "unofficial" microG setups) it doesn't require sacrifices in convenience because standard features like OTA updates work just like with your average Android. Perhaps that's clearer?
(Notably "Everything included" does not mean it ships a thousand apps or something. To the contrary, FP stock OS is mostly vanilla Android)
Point being: I could install LineageOS on my last phone, but it was a poorly documented process, updates were a hassle (having to flash through custom recovery for lack of OTA), and I had virtually no confidence in data integrity when running major updates.
> Is it better to have microG contacting the Google servers or sandboxed Play Services going through a Graphene-powered proxy?
How about microG not contacting Google servers at all?
In any case you're presenting an unnecessarily binary argument though. Letting Google handle push notifications is different from using them as your location provider, and both are different from letting all Play Services lose on your system.
> And of course, fairphone’s hardware and OS are nothing to write home about. For the freedom and security nerds they’re better off with GrapheneOS on Pixel or whatever upcoming Motorola phones will support it.
For the "freedom nerds", FP is one of the only (if not the only?) vendor to have official support for microG-based operating systems, seamless OTA updates and everything included. The Murena e/OS offering in particular is simple enough that the non-nerds that (perhaps less outspokenly) care about freedom can just pick it up with little change in habits.
A "modular product" has tradeoffs in and of itself (such as size, price, water resistance, …), which presumably would not fly for a majority of customers.
The contact tracing APIs very deliberately avoided GPS for exactly the reason you mention.
For me the nvidia driver just keeps waking up the system instantly - but my setup is deviating from the upstream flake in a few ways, so I'm just wondering if it's worth setting up the system from scratch if it's working for other people.
Other than that, can fully second that the flake is working great. Only gotcha is that CUDA-enabled packages (including Firefox) require using the flox binary cache unless you want to compile them from source, but then the package versions can lag behind a bit (and debugging nix cache issues is surprisingly difficult).
This is still problematic, but the far more dangerous Chat Control 2.0 that would weaken end-to-end-encrypted messengers like Signal is not being discussed here.
Not to diminish the gravity of the new development, but the defeatist "no way to prevent this" narratives that are already popping up here are getting old -- when in fact it looks like 2.0 is off the table for good because protest against it has proven effective.
The effect is understated there, perhaps because Apple speakers are actually somewhat usable without this feature. For the X13s, the speakers might as well not exist in the current state on Linux.
Apple devices supported by Asahi are a far more polished experience.
Yes, there are certainly banks that block more aggressively, but if you look at e.g. iodéOS's forums most of them work fine: https://community.iode.tech/t/banking-finance-and-insurance-...
Anecdotally, I've also seen a lot of stories of people reaching out to support about overblocking actually seeing success. Apparently there are often enterprise reasons for the block and it literally just needs a customer to complain for engineering to be able to act.
Among the "GPU rendered terminal" options, afaik Ghostty is the only one that has proper search/context menus, tabs, and scroll bars. I'm sure it's easy to get by without, but compared to the overall value-add of these terminals (which exists indeed but isn't tremendous either) I find it quite a significant downgrade, so I appreciate that Ghostty has both.
As a minor bonus, the live-reload is also faster than what frameworks like React do. It truly has subsecond latency, which isn't exactly a game changer but is nice when iterating on visual details of an app.