Looks like your wife is lucky.
https://www.protondb.com/app/1034860/ https://www.protondb.com/app/47890/ https://github.com/bvschaik/julius

Assuming you are not in a CGNAT, which is common for mobile networks: DNS with low TTL such as FreeDNS, pointing to your IP. And ofc, if you have a router in between, port-forwarding.

Otherwise, a VPN such as Tailscale. But you would need to install it on all your devices.

Otherwise, for HTTP(S) web services, a reverse-proxy such as CloudFlare.

(Personal opinion not based on scientific evidence.)

I would say that’s not possible for a hobbyist. The main issues with this kind of DIY phones are performance, compatibility with existing software, and most importantly battery life.

The Raspberry Pi was never designed to be used with a small battery while still staying connected to the internet to receive notifications all the time, like a smartphone. If you want to build a usable smartphone you will need an efficient co-processor to do these tasks. This could get complicated fast unless you use a CPU designed for this job.

There has been some interesting progress with desktop environments and small touch screens. Still nothing as good as Android, but nice UI is no longer the main issue imho.

As for compatibility, good luck running Signal, Matrix and Thunderbird in the background without draining the battery.

That being said, if you are just doing it as an excercise without expecting to build a device that will replace your main phone, you can definitely give it a try. Have fun and learn much!

Ah! Sorry for the textdump, and thanks for the feedback. I’ll keep it in mind in the future.

Sorry, not an answer to your exact question… Dockge might be the answer if you need a web UI to manage Docker containers.

If you need something more specific, like a button dashboard to run custom commands, perhaps you could build your own with Vite (Node.js). You will need to understand basic HTML, CSS and JavaScript. (EDIT: OliveTin makes more sense.)

As for authentication, you could configure a basic authentication on your favourite reverse proxy (such as Nginx), or look for something more advanced such as OIDC/OAuth2 through Keycloak.

Link for opting out: https://github.com/settings/copilot/features

In the “Privacy” section, set “Allow GitHub to use my data for AI model training” to “Disabled”.

As far as I understand, audio cards hold a buffer of the audio that should be played at any time. If the CPU can’t keep up producing new audio, it will loop to the beginning of the buffer. My guess is that when you suspend, the CPU stops producing new data before the audio card stops consuming it. And that’s why you hear the last part for a short instant.

It also happens on my devices, and it’s always happened on all my previous devices as far as I can remember.

Disclaimer: this is based on my understanding + a lot of suppositions. It might not be accurate.

Sure, that’s what I thought. And Ecosia doesn’t do the same?

I do have an opinion about Ecosia, but it’s just based on feelings, so it doesn’t even make sense to share it. Apologies for not answering your question.

Instead I would like to focus on this point:

Ecosia isn’t very private, since it sends data to Bing

Also DuckDuckGo does this, but they aggregate and anonymize that data before forwarding it to Bing. That’s probably the best they can do without building their own first-party infrastructure. I would imagine Ecosia does the same.

I think the idea is that the cost of producing standardized hardware is lower than the cost of producing a custom version without that codec just for the Raspberry Pi Foundation. The Raspberry Pi Foundation was not interested in that codec, so they didn’t buy a license. Separately, as a special agreement, they then allowed the few interested users to get a personal license directly from the IP owner. Sounds like a great solution to me.

Not sure if the same reasoning applies to BMW, though.

I just shared my opinion. I didn’t need those keys because I was not interested in using their proprietary codecs.

For what it matters, if Broadcom decided to license the IP for some hardware accelerator I don’t have anything against it. As long as they don’t make me pay for it when I don’t need it.

Dedicating a small portion of the silicon to optional features is cheaper than designing two separate silicons one with and one without such features.

This was actually probably an efuse, so not really just firmware, but hardware. In any case we are not talking about a software/firmware feature to decode videos, we are talking a section in the silicon that stays dormant unless you activate it with a valid license key.

Imho it makes sense from an economical perspective: they develop, test and fabricate a single silicon that does everything, then they allow you to specialize it on demand for a fee.

In any case, we can agree to disagree.

I have to partially disagree on this point. Take the first generation of Raspberry Pi as an example.

The first Raspberry Pis came with hardware to decode certain video codecs, but this feature was protected by royalties (not by the Raspberry Pi foundation, but a third-party I don’t remember the name of). They decided to sell you the base hardware for cheap, and if you wanted to enable hardware decoding you could later purchase a license key for your specific device, which could then be used to flip a switch in the firmware.

In my opinion it makes sense: I would rather pay 35€ + optionally 5€ for that feature, rather than 40€ mandatory.

The gamescope micro compositor does make games run better. You can obviously run that on others distros as well, but on SteamOS it’s out-of-the-box.

Is SteamOS immutable though? I thought that was just Bazzite.

No, only the local FS. But they have recommendations in their README for integrating with S3 with the help of other tools.

You are invited to join the CopyParty! This has a web UI accessible from the browser, also from mobile, files are stored directly on the filesystem (not encrypted or on a database) and you can mount it as a network drive on Windows and Linux. But it doesn’t let you sync files for offline use, at least not without the help of some auxiliary tools.

You won’t find anything simpler to install and configure than this.

Thanks for sharing your opinion and expanding.

In the past I used to think the same. Or rather, probably naïvely, I considered the GPL to be a bit of a nuisance, and preferred LGPL or MIT software.

Now I’ve changed my mind and started preferring AGPL for all my code. If a big company likes your MIT or LGPL code, they can legally steal it. If it’s GPL at least you get some safeguards, but they can still take it and put it on a server without the need to release the source code. That’s why I started to believe AGPL is the only “safe” license approved by the OSI, at least at the moment.

Of course I agree that MIT and GPL or LGPL make sense in some cases, but I would say in general they don’t protect users’ freedom anymore in today’s cloud-first world.

I would say AGPL is the “safest” license still approved by the OSI. Could you share your opinion?

Well… I assume that might be illegal. Or maybe these rules would only apply to public software? For sure it wouldn’t be enforceable, and it would still allow criminals to use it to communicate privately between each other, but it would make it harder to exploit mainstream public apps (e.g.: WhatsApp) to scam or exploit weaker individuals.

I am not OP, but that would be the ideal solution for me. Unfortunately, KPXC does not support communication with the GPG agent and the team is not interested in adding this feature due to it being «[…] far more complicated than ssh-key management. There are already excellent tools for this, Kleopatra being the best».