I’m running on postmarketOS, SailfishOS includes significant proprietary components, besides firmware. Like the user-interface. My Android daily driver is already running strict FOSS-only ROM and apps (with an exception in firmware), there’s no reason for me to switch to sometbing proprietary.
Yes, it’s called Sober. It is not official, and may lose functionality at any time due to updates to client-side anti-cheat.
Nobody is helping Google do anything, phone OEMs develop their own private spin on Android (for example, Samsungs OneUI). They make sure their device works in their OS, nothing else.
Depending on your bank, you may be able to use their website.
The “no apps” isn’t “that big of an issue” (at least for me), as there’s Waydroid available, and it’s just standard Linux with all the desktop apps right from Flathub. There’s also plenty of webapps available.
There’s tons of other issues with Linux mobile, like general usability, battery life, responsiveness (especially when receiving calls or notifications), and hardware support.
The biggest one I’m running into is sleep states. I can either have 4-ish hours of battery life, but if my phone is charged, I get notifications, alarms go off, and calls come in immediately. Or I can have about a day idle battery life, but have to check my phone before any of that stuff comes in.
There’s also the fact I use my phone for media a lot (Jellyfin, Lemmy), and the experience isn’t great on Linux mobile. “Apps” integtate less with each other, and video playback is kind of a mess. (For example, I can’t “share” on a photo from Lemmy to send it to a friend on Matrix).
Frankensteins monster of both ports. Source: https://www.youtube.com/watch?v=M9ZCjMtthqY
Not bluetooth though. That’s now a menu of your recently paired and currently connected devices.
Not to mention the A12+ increase in spacing and button size. Removing that, you could easily fit 2x the buttons in the same area.
Personally I have seen the opposite from many services. Take Jitsi Meet for example. Without containers, it’s like 4 different services, with logs and configurations all over the system. It is a pain to get running, as none of the services work without everything else being up. In containers, Jitsi Meet is managed in one place, and one place only. (When using docker compose,) all logs are available with docker compose logs, and all config is contained in one directory.
It is more a case-by-case thing whether an application is easier to set up and maintain with or without docker.
With a custom, very restrictive license. Builds are not reproducible, and code from the project cannot be used elsewhere. For the purposes of security, transparency, and advancing development of (proper) FOSS YouTube clients, Grayjay is effectively closed source.
it seems a bit pointless
Quite the opposite. Linux is currently frequently matching Windows in performance when running games through Wine/Proton. Targeting Linux native avoids this translation layer, and can result in better performance or less CPU overhead for the same performance (which is noticable especially on devices like the Steam Deck).
making games for Linux is ironically difficult
Yes, because of the tooling. If you make a game in Unity, and build for Windows, ““things just work””. If you then build for Linux, you can face any number of random engine issues, like bad controller support, broken mouse grabbing, etc.
as they can break as libraries change over time
Valve has thought about this, and designed the Steam Linux Runtime. This does effectively the same thing as Flatpak, except it pulls in the system native graphics drivers. Steam Linux Runtime provides effectively a full (minimal) Linux distribution that game developers can target, ensuring their games keep running, even on more modern systems.
Gaming on Linux has always been a chicken and egg problem. Gamers see there’s no games on Linux, so they stick to Windows. Developers see there’s no Linux gaming market, so they stick to Windows. With Valve’s Proton, they interrupted this cycle. Most games now work on Linux, but game developers haven’t switched yet. For them to switch, there needs to be a market of Linux users, and the tooling needs to be sufficiently developed for Linux, ensuring the same (or better) quality as the Windows versions of games. This includes game engines, common libraries (like online multiplayer frameworks or voicechat), and possibly development software, 3D modeling software like Blender, the Adobe suite, etc.
“jellyfin isn’t immune to security incidents”
Well, no software is. The difference is that Plex just leaked data of all their users, where Jellyfin can’t, because they don’t have this data.
IRC does not have any federation, and XMPP does it in a completely different way from Matrix that has unique pros and cons.
IRC is designed for you to connect to a specific server, with an account on that server, to talk to other people on that server. There is no federation, you cannot talk to oftc from libera.chat. Alongside that, with mobile devices being so common, you’d need to get people to host their own bouncer, or host one for nearly everyone on your network.
XMPP federation conceptually has one major difference compared to Matrix: XMPP rooms are owned by the server that created them, whereas Matrix rooms are equally “owned” by everyone participating in it, with the only deciding factor being which users have administrator permissions.
This makes for better (and easier) scaling on XMPP, so rooms with 50k people isn’t that big of an issue for any users in that room. However, if the server owning the room goes down, the whole room is down, and nobody can chat. See Google Talk dropping XMPP federation after making a mess of most client and server implementations.
On Matrix, scaling is a much bigger issue, as everyone connects with everyone else. Your single-person homeserver has to talk with every other homeserver you interact with. If you join a lot of big rooms, this adds up, and takes a lot of resources. However, when a homeserver goes down, only the people on that homeserver are affected, not the rooms. Just recently, matrix.org had some trouble with their database going down. Although it was a bit quieter than usual, I only properly noticed when it was explicitly mentioned in chat by someone else. My service was not interrupted, as I host my own homeserver.
The Matrix method of federation definitely comes with some issues, some conceptually, and some from the implementation. However, a single entity cannot take down the federated Matrix network, even when taking down the most used homeservers. XMPP is effectively killed off by doing the same.
Discord is one of the greedy AI companies training on your data
FOSS only, no proprietary spyware here. Daily driver on Android 15.
Being able to choose the OS and kernel is also important. I would not want my hypervisor machine to load GPU kernel modules, especially not on an older LTS kernel (which often don’t support the latest hardware). Passing the GPU to a VM ensures stability of the host machine, with the flexibility to choose whatever kernel I need for specific hardware. This alongside running entirely different OSes (like *BSD, Windows :(, etc) is pretty useful for some services.
Same here, though more out of lack of control over the host. Libvirt works on basically any distro, and you can easily configure whatever Linux distro you like best for running it. I can’t configure my boot process the way I want on Proxmox (at least not without learning/sidestepping its “convenience” tools/setup).
If you’re this unsure about running potential malware in a VM, the best method is to just not run it at all.
You should be perfectly fine running with networking on your host, as long as you disable it in the VM configuration before running the potential malware.
It’s not. There’s no way to be 100% certain the shared folder daemon on the host has absolutely zero exploits, same thing for the networking stack used for transport. That also includes VM disk I/O, virtual graphics output, and any other communication between guest and host. It’d take some really advanced malware to abuse such exploits, but you’re better off minimizing attack surface as much as possible. That means disabling (or removing) every possible form of communication between host and guest, unless absolutely necessary for operation.
Start off with a clean slate. Windows, freshly installed from a Microsoft provided ISO (Assuming you’re looking at a Windows executable). Try to follow a guide on bypassing the MS account requirement (AtlasOS has a section of their guide telling you how to do this).
When you’re setting things up, there’s no restrictions to internet access, sharing, etc. You just have to be careful not to open/view the files you want to isolate, which is easy enough by for example putting the files in a password protected zip. You can also install any required tools now (like maybe 7zip).
At this stage, there’s a few options:
python3 -m http.server on your host. Then download it on the VM.When you’re ready to actually open the file, close off all access from the VM to the host. No networking, clipboard sharing, etc. Do this on the hosts VM settings, not inside the VM. Also note that without further tooling, it’s extemely difficult to tell if there’s any advanced malware present.
As soon as you view the potentially malicious files, consider anything coming from that VM as malicious. Don’t try to view/open files on your host, do not give it network access.
Malware can be (but often isn’t) incredibly advanced, and even an isolated VM isn’t a 100% guaranteed method of keeping it contained.
There is no justification. The “Ends” in E2EE mean the initial sender, and intended recipient. The “transport” should have zero insight into the content. Encrypting a message to the servers is standard even for “non-private” messaging services, it’s usually done with SSL (part of HTTPS).
Lets compare it to traditional mail. If you send something, the postal company can always just open your mail and read it. With computers, we have black magic (E2EE) that physically prevents the postal company from doing that. In this hypothetical, Facebook (owner of WhatsApp) is the company that provides you with the pen and paper (the app), and is a postal company (their servers). They promise that the black magic on the paper prevents them from reading what you wrote, but then they clearly read the content of your letter to send you a summary of the conversation.
Mid-message quick edit: They could’ve also done something to the pen (other parts of the app) to have it tell them what you wrote. This would mean the black magic (E2EE) is applied, but is completely useless. (End of edit)
If the process for making the pen and paper (the app) was publicly known (open source), you could make your own, and be sure the black magic (E2EE) is applied properly. That way you can be certain the postal company (servers) can’t read your letter, only the recipient can.
If the postal company gives you the pen and paper without telling you how to make it, it’s nearly impossible to tell if the black magic was applied properly.
The RomM project does exactly that