If incus works for yoy, use it. Proxmox locks you out of the option to choose your base server distros.
If incus works for yoy, use it. Proxmox locks you out of the option to choose your base server distros.
I remember updating (maybe a year ago now) and it making all my containers unaccessable.
I very much recommend Kicksecure hardened Debian as a daily driver. Eventually I will test gaming on Kicksecure making use of the steam flatpak, but I currently dont have the time.
IIRC, there is a way to force hardened_malloc for flatpaks, but this breaks many flatpak applications. For another hardened by default OS distromorph (the process of turning one distro into another closely related derivative OS) check out secureblue
Requiring webassembly will break the website for most privacy hardened browsers (arkenfox, Librewolf, cromite, Mullvad, etc). Webassembly is disabled for security and privacy reasons in these browsers. Not worth IMO. See a short snippet of Arkenfox’s reasoning here: https://arkenfox.github.io/gui/?s=javascript.options.wasm
Ok, understandable. I hate mobile devices because of their limited usable life and limited OS compatiblity. Verified boot is nice, libre-android is better. Not worth it for a person of interest to install /e/OS, but neither would stock Android or AOSP without significant hardening. DivestOS is my top pick for degoogled Android, but as I learn more (been reading kicksecure’s wiki on mobile device security) maybe Root isn’t as bad as I thought for security. I trust Kicksecure’s security research because of their significance as the base OS for Whonix and Whonix-qubes.
Related to relockable bootloaders and the security they provide, I was under the impression that if a malicious bit of software were to make use of some privilege escalating vulnerability and modify the kernel, the phone would fail to run in some way (ignore the rest of this if that isn’t the case). I dont think security should be dependent on the user behavior in basically any case.
For example, a FOSS developer in our communities could suddenly lose it and modify an existing app of theirs to inject malicious code making use of a vulnerability in android and we’d have know what of knowing until the damage is reported. Good user behavior is very important for security, but we can’t all be auditing our apps for each new release, even though its quite unlikely to happen.
It still has much of the google proprietary blobs still included and relies on google services, also without significant effort to harden Android. I have also heard that sometimes they fall behind on updates to their apps by weeks at a time (correct me if I’m wrong I am still looking for the source I found this info from). It may be moderately degoogled, but their security just ain’t there. In some cases (like OEM EOSL for older devices) having a 3rd party ROM may improve security with more up to date patches. Unless the bootloader is relockable and secure boot is possible, you will be compromising your device’s security (and privacy along with it) and destroying the Android security model in general.
There is no android ROM that is fully degoogled without losing out on much of base Android’s functionality. See the table I link under the other person’s comment. I have also heard that /e/ OS falls behind on package updates from its forks of other projects, many of its default apps.
/e/ is not very degoogled. DivestOS or GrapheneOS would be better choices, then maybe CalyxOS.
With mull an tubular I being see ads on my phone anyway.
So you are or aren’t seeing ads? I don’t with both.
I’d always shop used for that through a reputable resale store with quality assurance.
The assumption I was under for the parent comment’s scenario was that the device would remain with its default ROM, in which case Google services are installed as a system app and disabling/uninstalling through ADB would do little to change things (cus of the proprietary kernel and all). Moving to alternative FOSS clients helps a new user get used to alternatives and learn better compromises they can use in the future on a degoogled ROM with services they maybe be forced to use.
Ditching your gmail account is the hardest step of degoogling and really isn’t one step. Ditching Gmail the app is good because it is one less permissive google app you have installed.
Tubular is just newpipe with sponsorblock and return YouTube dislike, which have their own Privacy Policies to worry about but are great features to have. Either way, you should be using a VPN because otherwise it isn’t much different then the scenario you mentioned with a FOSS client for a proprietary google service.
I think Rethink DNS would be better in this case because you can block internet to system apps, apply DNS blocklists, and set up a Wireguard VPN with a config file.
Newpipe isn’t an alternative to Gmail, I’m assuming that was just awkward wording. A good alternative to the Gmail app is FairEmail or K-9 Mail. Newpipe (or better yet Tubular) is a good alternative to YouTube (without google signin and local only storage of subscriptions, history, and playlists)
And install it as a PWA (it might just be a shortcut idk) on Android
The difference between FOSS and proprietary (to me) is the motive. FOSS projects are often created out of a genuine need/want to solve a problem. Proprietary may also be trying to solve a problem (we can’t through all of them under the bus because we live in a capitalist system which limits our options, we need to survive before thrive). I still find that proprietary often is just created for profit, and as profit motivated software it has an incompatible goal to actually fixing the problem.
A good (profitable) proprietary app won’t fix any problem, but instead exacerbate it to maintain the reason for its continued existence, all while eliminating competition.
I recommend QUIK SMS as an maintained fork of QKSMS. https://www.f-droid.org/en/packages/dev.octoshrimpy.quik/
Sorry, misunderstood. Proxmox Free broke my containers on updating a while ago.
Now I use Docker-style application containerizing, but I think LXC (the base technology powering Incus/LXD) is useful in a number of situations and perfectly viable for use. I think Incus-containerized applications are easier to upgrade individually (like software updates of your apps, no need to recreate the container image) and gives a closer to native experience of managing. You do lose out on automated deployment of applications from widely available image sources like docker.io, but the convenience-loss is minimal.