SDL is at the application layer though. Each individual game has to support it.

As absurd as it might seem, the Steam Controller is technically not compatible with Linux.

What I mean by this: officially, it only works with Steam Input, which only works for Games you launch from Steam. It is not fully recognized and supported by Linux yet, and perhaps it never will.

EDIT: alright. This comment was obviously partially driven by frustration, I apologize for my tone. Since this comment received a low upvote/downvote ratio, I decided to educate myself a bit more on the topic. Here are my findings and understandings…

There are a lot of controllers. Some of them have a somewhat standard layout (think Xbox, Play Station, Switch), and some of them are just special (think controllers with special buttons or trackpads like the Steam Controller).

Computers and controllers can communicate through various protocols, such as XInput, DirectInput, “Switch mode”, or other less common ones. Some of these protocols expect a fixed layout with an exact number of buttons, joysticks, triggers, etc (such as XInput), some are more flexible. Some of these protocols support gyro, some don’t. Some of these protocols have a higher bandwidth, and thus can offer lower latency.

Option 1 (ideal): Linux can support some of these protocols through drivers. Unfortunately some of these drivers do not work very well with non-standard controllers. They might not see some buttons, they might not see some features such as gyro, or even worse (this is what I personally experienced) they can map buttons incorrectly. These inconsistencies can make a controller unusable without some tinkering, or they might limit the set of supported features for a specific controller.

Option 2 (per-game fallback): SDL is FOSS application-level layer to communicate with controllers. If a game makes use of SDL, it can support all controllers that its specific SDL version supports. Even if the operating system doesn’t fully recognize it. But this only works if the game does make use of SDL. If it doesn’t, you are out of luck.

Option 3 (user fallback): Steam Input is a proprietary (i.e. non-FOSS) way to try to bring some order in this mess. It takes any random controller, and allows the user to remap buttons to make it behave consistently, in a way that all games can understand. Even games that were never designed to be played with a controller can be coerced to work.

Basically, if Linux supports the controller fully and maps all features correctly (option 1, this is the ideal situation), it will work with every game that supports it. Otherwise, (option 2) games that implement SDL can try to make it work anyway. Otherwise (option 3) if the game doesn’t use SDL, or if its SDL version doesn’t recognize the controller, Steam Input can still make it work with some help from the user.

So… Why am I upset with Valve? That’s because, as far as I understand, Valve decided to make their controller only compatible with Steam Input. Some volunteers adapted it to make it work with SDL, but that only works for games that make use of an SDL layer. And what about Linux? Does Linux have a driver for this controller? No. As far as I understand, this controller doesn’t make use of any of the standard protocols, so a new ad-hoc driver would have to be developed just for this controller. Valve decided to reinvent the wheel.

There would be an “Option 0”, which some controllers support: protocol-switching. When you buy an Xbox controller, it runs as XInput. When you buy a Switch controller, it runs in “Switch mode”. When you buy a third party controller, it usually implements one or multiple of these, and allows the user to switch on-demand. This way the system is more likely to recognize it correctly using at least one mode.

As far as I understand, the newest Steam Controller does not support any of these. This is why I am upset with Valve. Hopefully they will eventually release a firmware update to add XInput or another standard protocol, then Linux will recognize this controller natively. But right now, the Steam Controller is technically not compatible with Linux.

(This is my understanding of the situation, some of my findings may be incorrect. Please correct me if this is the case!)

I don’t think you need a guide. Just install the extension and give it a try. It’s pretty simple and intuitive.

still no possibility to set default container for Ctrl + T

It might be possible now, you could give it a try. But anyways, I don’t see how changing the default container for new tabs could be useful. There is a default container which is the “no container”, why would you want to change it?

EDIT: yes, it is possible now.

Are you talking about these containers?

Each container is isolated from the others. If you don’t want a tab to track you, just use a dedicated container for it.

You can also configure Firefox to always use a dedicated container for certain domains.

As for destroying the data, you probably just need to clear cookies on close. That’s configurable. If you are extra paranoid you can also clear the cache.

Did I miss something?

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.

In that case I would say start with a Debian-based or Ubuntu-based distro of your choice. Ubuntu-based distros are also Debian-based, since Ubuntu is Debian-based. Mint is Ubuntu-based so it’s a good choice imho. Mint should work pretty well for backups and Minecraft.

As a counter-example, Mint would (probably) be a poor choice if you want to turn that PC into a router or a DNS server, but sounds like that’s not what you have in mind.

If you plan to Install more stuff in the near future, you could optionally look into containerization (Docker) which would allow you to someday swap Mint with another distro when you decide that you feel like changing. All of this, without having to reconfigure anything. Portainer might be a good soft-entry to Docker if you don’t love the terminal, it gives you a nice UI. And it’s compatible with Mint, ofc.

As for the fedi instance, it’s a good exercise, you will learn a lot about networks. Personally I tried installing a Lemmy instance too, but I ended up turning it off as I realized that it didn’t make sense for my use case. It just wasted bandwidth to stay in-sync with the rest of the fediverse.

It depends. What do you plan to use it for? Depending on the answer, perhaps Mint might not be the best option, but I can share my personal experience.

My use case is a headless server running OCI containers through rootless Podman (this is Docker’s modern equivalent). I’ve been running this on Linux Mint on a compact PC for a few years. I enabled unattended upgrades, and once in a while I VNC into it and upgrade Mint itself. I also installed a CRON job to reboot automatically every few days. So far I’ve not encountered any major issues.

Euro-Office and Office EU (office.eu) are not the same project.

How does Euro-Office compare to IONOS Workspace, office.eu, the Proton productivity suite, Nextcloud Hub or XWiki: Euro-Office is more of an integration component. It merely handles document editing itself. Storage, as well as navigation, permissions and sharing logic has to be offered by a platform it is integrated in, like Proton Docs, Nextcloud Hub or OpenProject. – https://github.com/Euro-Office/.github/blob/main/profile/README.md#faq

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.

Sorry for being pedantic. I might be dumb, but I don’t see any assets (sprites/models/sounds) in this repository. I think the license you linked might just be referring to the code.

The lack of recent releases isn’t a discriminator for this list. And active development is certainly a plus.