I need help installing Fedora CoreOS on a Raspberry Pi 5.

I've tried this method that uses Fedora Media Writer. The Raspberry Pi fails to boot from the flash drive.

I've tried this method that uses the Fedora Arm Installer. The Raspberry Pi fails to boot from the microSD card.

I've tried adapting this method but it seems to be exclusively for the Raspberry Pi 4, and no substitute tools exist. It didn't seem to even install anything on the microSD card.

I'm at a loss. I have no idea how to install it. Can anyone help? I'd be happy to give a step-by-step process of exactly what I did for each method, if needed.

I'm making this post to share some interesting less talked about things about privacy, security, and other related topics. This post has no direct goal, it's just an interesting thing to read. Anyways, here we go:

I made a post about secureblue, which is a Linux distro* (I'll talk about the technicality later) designed to be as secure as possible without compromising too much usability. I really like the developers, they're one of the nicest, most responsible developers I've seen. I make a lot of bug reports on a wide variety of projects, so they deserve the recognition.

Anyways, secureblue is a lesser known distro* with a growing community. It's a good contrast to the more well known alternative** Qubes OS, which is not very user friendly at all.

* Neither secureblue, nor Qubes OS are "distros" in the classical sense. secureblue modifies and hardens various Fedora Atomic images. Qubes OS is not a distro either, as they state themselves. It's based on the Xen Hypervisor, and virtualizes different Linux distros on their own.

** Qubes OS and secureblue aren't exactly comparable. They have different goals and deal with security in different ways, just as no threat model can be compared as "better" than any other one. This all is without mentioning secureblue can be run inside of Qubes OS, which is a whole other ballpark.

secureblue has the goal of being the most secure option "for those whose first priority is using Linux, and second priority is security." secureblue "does not claim to be the most secure option available on the desktop." (See here) Many people in my post were confused about that sentence and wondered what the most secure option for desktop is. Qubes OS is one option, however the secureblue team likely had a different option in mind when they wrote that sentence: Android.

secureblue quotes Madaiden's Insecurities on some places of their website. Madaiden's Insecurities holds the view that Linux is fundamentally insecure and praises Android as a much better option. It's a hard pill to swallow, but Madaiden's Insecurities does make valid criticisms about Linux.

However, Madaiden's Insecurities makes no mention of secureblue. Why is that? As it turns out, Madaiden's Insecurities has not been updated in over 3 years. It is still a credible source for some occasions, but some recommendations are outdated.

Many people are strictly anti-Google because of Google's extreme history of privacy violations, however those people end up harming a lot of places of security in the process. The reality is, while Google is terrible with privacy, Google is fantastic with security. As such, many projects such as GrapheneOS use Google-made devices for the operating system. GrapheneOS explains their choice, and makes an important note that it would be willing to support other devices as long as it met their security standards. Currently only Google Pixels do.

For those unfamiliar, GrapheneOS is an open source privacy and security focused custom Android distribution. The Android Open Source Project (AOSP) is an open source project developed by Google. Like the Linux kernel, it provides an open source base for Android, which allows developers to make their own custom distributions of it. GrapheneOS is one such distribution, which "DeGoogles" the device, removing the invasive Google elements of the operating system.

Some Google elements, such as Google Play Services can be optionally installed onto the device in a non-privileged way (see here and here). People may be concerned that Google Pixels can still spy on them at a hardware level even with GrapheneOS installed, but that isn't the case.

With that introduction of secure Android out of the way, let's talk about desktop Android. Android has had a hidden option for Desktop Mode for years now. It's gotten much better since it was first introduced, and with the recent release of Android 15 QPR2, Android has been given a native terminal application that virtualizes Linux distros on the device. GrapheneOS is making vast improvements to the terminal app, and there are many improvements to come.

GrapheneOS will also try to support an upcoming Pixel Laptop from Google, which will run full Android on the desktop. All of these combined means that Android is one of, if not the, most secure option for desktop. Although less usable than some more matured desktop operating systems, it is becoming more and more integrated.

By the way, if you didn't know, Android is based on Linux. It uses the Linux kernel as a base, and builds on top of it. Calling Qubes OS a distro would be like calling Android and Chrome OS distros as well. Just an interesting fact.

So, if Android (or more specifically GrapheneOS) is the most secure option for desktop, what does that mean in the future? If the terminal app is able to virtualize Linux distros, secureblue could be run inside of GrapheneOS. GrapheneOS may start to become a better version of Qubes OS, in some respects, especially with the upcoming App Communication Scopes feature, which further sandboxes apps.

However, there is one bump in the road, which is the potential for Google to be broken up. If that happens, it might put GrapheneOS and a lot of security into a weird place. There might be consequences such as Pixels not being as secure or not supporting alternative Android distributions. Android may suffer some slowdowns or halts in development, possibly putting more work on custom Android distribution maintainers. However, some good may come from it as well. Android may become more open source and less Google invasive. It's going to be interesting to see what happens.

Speaking of Google being broken up, what will happen to Chrome? I largely don't care about what happens to Chrome, but instead what happens to Chromium. Like AOSP, Chromium is an open source browser base developed by Google. Many browsers are based on Chromium, including Brave Browser and Vanadium.

Vanadium is a hardened version of Chromium developed by GrapheneOS. Like what GrapheneOS does to Android, Vanadium removes invasive Google elements from the browser and adds some privacy and security fixes. Many users who run browser fingerprinting tests on Vanadium report it having a nearly unique fingerprint. Vanadium does actually include fingerprint protections (see here and here), but not enough users use it for it to be as noticeable as the Tor Browser. "Vanadium will appear the same as any other Vanadium on the same device model, and we don't support a lot of device models." (see here)

There's currently a battle in the browser space between a few different groups, so mentioning any browser is sure to get you involved in a slap fight. The fights usually arise between these groups:

• The group that is strictly anti-Google and uses Firefox-based browsers
• The security focused group that recognizes that Firefox is insecure and opts for privacy enhanced versions of Chromium
• The political group that only care about the politics behind an organization rather than the code itself (examples: Firefox Terms of Use update, Brave Browser including a crypto wallet)

For that last one, I would like to mention that Firefox rewrote the terms after backlash, and users have the ability to disable bloatware in Brave. Since Brave is open source, it is entirely possible for someone to make a fork of it that removes unwanted elements by default, since Brave is another recommended browser by the GrapheneOS team for security reasons.

Another interesting Chromium-based browser to look at is secureblue's Trivalent, which was inspired by Vanadium. It's a good option for users that use Linux instead of Android as a desktop.

Also, about crypto, why is there a negativity around it? The reason is largely due to its use in crime, use in scams, and use in investing. However, not all cryptocurrencies are automatically bad. The original purpose behind cryptocurrency was to solve a very interesting problem.

There are some cryptocurrencies with legitimate uses, such as Monero, which is a cryptocurrency designed to be completely anonymous. Whether or not you invest in it is your own business, and unrelated to the topics of this post. Bitcoin themselves even admit that Bitcoin is not anonymous, so there is a need for Monero if you want fully decentralized, anonymous digital transactions.

On the topic of fully decentralized and anonymous things, what about secure messaging apps? Most people, even GrapheneOS and CISA, are quick to recommend Signal as the gold standard. However, another messenger comes up in discussion (and my personal favorite), which is SimpleX Chat.

SimpleX Chat is recommended by GrapheneOS occasionally, as well as other credible places. This spreadsheet is my all time favorite one comparing different messengers, and SimpleX Chat is the only one that gets full marks. Signal is a close second, but it isn't decentralized and it requires a phone number.

Anyways, if you do use Signal on Android, be sure to check out Molly, which is a client (fork) of Signal for Android with lots of hardening and improvements. It is also available to install from Accrescent.

Accrescent is an open source app store for Android focused on privacy and security. It is one of the default app stores available to install directly on GrapheneOS. It plans to be an alternative to the Google Play Store, which means it will support installing proprietary apps. Accrescent is currently in early stages of development, so there are only a handful of apps on there, but once a few issues are fixed you will find that a lot of familiar apps will support it quickly.

Many people have high hopes for Accrescent, and for good reason. Other app stores like F-Droid are insecure, which pose risks such as supply chain attacks. Accrescent is hoped to be (and currently is) one of the most secure app stores for Android.

The only other secure app store recommended by GrapheneOS is the Google Play Store. However, using it can harm user privacy, as it is a Google service like any other. You also need an account to use it.

Users of GrapheneOS recommend making an anonymous Google account by creating it using fake information from a non-suspicious (i.e. not a VPN or Tor) IP address such as a coffee shop, and always use a VPN afterwards. A lot of people aren't satisfied with that response, since the account is still a unique identifier for your device. This leads to another slap fight about Aurora Store, which allows you to (less securely) install Play Store apps using a randomly given Google account.

The difference between the Play Store approach and the Aurora Store approach is that Aurora Store's approach is k-anonymous, rather than... "normal" anonymity. The preference largely comes down to threat models, but if you value security then Aurora Store is not a good option.

Another criticism of the Play Store is that it is proprietary. The view of security between open source software and proprietary software has shifted significantly. It used to be that people viewed open source software as less secure because the source code is openly available. While technically it's easier to craft an attack for a known exploit if the source code is available, that doesn't make the software itself any less secure.

The view was then shifted to open source software being more secure, because anyone can audit the code and spot vulnerabilities. Sometimes this can help, and many vulnerabilities have been spotted and fixed faster due to the software being open source, but it isn't always the case. Rarely do you see general people looking over every line of code for vulnerabilities.

The reality is that, just because something is open source, doesn't mean it is automatically more or less secure than if it were proprietary. Being open source simply provides integrity in the project (since the developers make it as easy as possible to spot misconduct), and full accountability towards the developers when something goes wrong. Being open source is obviously better than being proprietary, that's why many projects choose to be open source, but it doesn't have to be that way for it to still be secure.

Plus, the workings of proprietary code can technically be viewed, since some code can be decompiled, reverse engineered, or simply read as assembly instructions, but all of those are difficult, time consuming, and might get you sued, so it's rare to see it happen.

I'm not advocating for the use of proprietary software, but I am advocating for less hate regarding proprietary software. Among other things, proprietary software has some security benefits in things like drivers, which is why projects like linux-libre and Libreboot are worse for security than their counterparts (see coreboot).

Those projects still have uses, especially if you value software freedom over security, but for security alone they aren't as recommended.

Disclaimer before this next section: I don't know the difference in terminology between "Atomic", "Immutable", and "Rolling Release", so forgive me for that.

Also, on the topic of software freedom, stop using Debian. Debian is outdated and insecure, and I would argue less stable too. Having used a distro with an Atomic release cycle, I have experienced far less issues than when I used Debian. Not to mention, if you mess anything up on an Atomic distro, you can just rollback to the previous boot like nothing happened, and still keep all your data. That saved me when I almost bricked my computer motifying /etc/fstab/ by hand.

Since fixes are pushed out every day, and all software is kept as up to date as possible, Atomic distros I argue give more stability than having an outdated "tried and tested" system. This is more an opinion rather than factually measured.

Once I realized the stable version of Debian uses Linux kernel 6.1, (which is 3 years old and has had actively exploited vulnerabilities), and the latest stable version of the kernel is 6.13, I switched pretty quick for that reason among others.

Now, many old kernel versions are still maintained, and the latest stable version of Android uses kernels 6.1 and 6.6 (which are still maintained), but it's still not great to use older kernel versions regardless. It isn't the only insecurity about Debian.

I really have nothing more to say. I know I touched on a lot of extremely controversial topics, but I'm sick of privacy being at odds with security, as well as other groups being at odds with each other. This post is sort of a collection of a lot of interesting privacy and security knowledge I've accrued throughout my life, and I wanted to share my perspective. I don't expect everybody to agree with me, but I'm sharing this in case it ever becomes useful to someone else.

Thanks for taking the time to read this whole thing, if you did. I spent hours writing it, so I'm sure it's gotten very long by now.

Happy Pi Day everyone!

This post is long and kind of a rant. I don't expect many to read the whole thing, but there's a conclusion at the bottom.

On the surface, recommended security practices are simple:

• Store all your credentials in a password manager
• Use two factor authentication on all accounts

However, it raises a few questions.

• Should you access your 2FA codes on the same device as the password manager?
• Should you store them in the password manager itself?

This is the beginning of where a threat model is needed. If your threat model does not include protections against unwanted access to your device, it is safe for you to store access your 2FA codes on the same device as your password manager, or even in the password manager itself.

So, to keep it simple, say you store your 2FA in your password manager. There's a few more questions:

• Where do you store the master password for the password manager?
• Where do you store 2FA recovery codes?

The master password for the password manager could be written down on a piece of paper and stored in a safe, but that would be inconvenient when you want to access your passwords. So, a better solution is to just remember your password. Passphrases are easier to remember than passwords, so we'll use one of those.

Your 2FA recovery codes are something that are needed if you lose access to your real 2FA codes. Most websites just say "Store this in a secure place". This isn't something you want to store in the same place as those (in this case our password manager), and it's not something you will access often, so it's safe to write it down on a piece of paper and lock it in a safe.

Good so far, you have a fairly simple system to keep your accounts safe from some threats. But, new problems arise:

• What happens if you forget your master passphrase?
• What happens if others need access to your password manager?

The problem with remembering your passphrase is that it's possible to forget it, no matter how many times you repeat it to yourself. Besides naturally forgetting it, things like injuries can arise which can cause you to forget the passphrase. Easy enough to fix, though. We can just keep a copy of the passphrase in the safe, just in case we forget it.

If someone else needs to access certain credentials in your password manager, for example a wife that needs to verify bank information using your account, storing a copy of the password is a good idea here too. Since she is a trusted party, you can give her access to the safe in case of emergencies.

The system we have is good. If the safe is stolen or destroyed, you still have the master passphrase memorized to change the master passphrase and regenerate the 2FA security codes. The thief who stole the safe doesn't have your password manager's data, so the master passphrase is useless. However, our troubles aren't over yet:

• How do you store device credentials?
• How do you keep the password manager backed up?

Your password manager has to have some device in order to access it. Whether it's a phone, computer, tablet, laptop, or website, there needs to be some device used to access it. That device needs to be as secure as your password manager, otherwise accessing the password manager becomes a risk. This means using full disk encryption for the device, and a strong login passphrase. However, that means we have 2 more passwords to take care of that can't be stored in the password manager. We access those often, so we can't write them down and store them in the safe, Remembering two more passphrases complicates things and makes forgetting much more likely. Where do we store those passphrases?

One solution is removing the passwords altogether. Using a hardware security key, you can authenticate your disk encryption and user login using it. If you keep a spare copy of the security key stored in the safe, you make sure you aren't locked out if you lose access to your main security key.

Now to keep the password manager backed up. Using the 3-2-1 Backup Strategy. It states that there should be at least 3 copies of the data, stored on 2 different types of storage media, and one copy should be kept offsite, in a remote location (this can include cloud storage). 2 or more different media should be used to eliminate data loss due to similar reasons (for example, optical discs may tolerate being underwater while LTO tapes may not, and SSDs cannot fail due to head crashes or damaged spindle motors since they do not have any moving parts, unlike hard drives). An offsite copy protects against fire, theft of physical media (such as tapes or discs) and natural disasters like floods and earthquakes. Physically protected hard drives are an alternative to an offsite copy, but they have limitations like only being able to resist fire for a limited period of time, so an offsite copy still remains as the ideal choice.

So, our first copy will be on our secure device. It's the copy we access the most. The next copy could be an encrypted hard drive. The encryption passphrase could be stored in our safe. The last copy could be a cloud storage service. Easy, right? Well, more problems arise:

• Where do you store the credentials for the cloud storage service?
• Where do you store the LUKS backup file and password?

Storing the credentials for the cloud storage service isn't as simple as putting it in the safe. If we did that, then anyone with the safe could login to the cloud storage service and decrypt the password manager backup using the passphrase also stored in the safe. If we protected the cloud storage service with our security key, a copy of that is still in the safe. Maybe we protect it with a 2FA code, and instead of storing the 2FA codes in the password manager, we store it on another device. That solves the problem for now, but there are still problems, such as storing the credentials for that new device.

When using a security key to unlock a LUKS partition, you are given a backup file to store as a backup for emergencies. Plus, LUKS encrypted partitions still require you to setup a passphrase, so storing that still becomes an issue.

Conclusion

I'm going to stop here, because this post is getting long. I could keep going fixing problems and causing new ones, but the point is this: Security is a mess! I didn't even cover alternative ways to authenticate the password manager such as a key file, biometrics, etc. Trying to find "perfect" security is almost impossible, and that's why a threat model is important. If you set hard limits such as "No storing passwords digitally" or "No remembering any passwords" then you can build a security system that fits that threat model, but there's currently no security system that fits all threat model.

However, that doesn't let companies that just say "Store this in a secure place" off the hook either. It's a hand wavy response to security that just says "We don't know how to secure this part of our system, so it's your problem now". We need to have comprehensive security practices that aren't just "Use a password manager and 2FA", because that causes people to just store their master passphrase on a sticky note or a text file on the desktop.

The state of security is an absolute mess, and I'm sick of it. It seems that, right now, security, privacy, convenience, and safety (e.g. backups, other things that remove single points of failure) are all at odds with each other. This post mainly focused on how security, convenience, and safety are at odds, but I could write a whole post about how security and privacy are at odds.

Anyways, I've just outlined one possible security system you can have. If you have one that you think works well, I'd like to hear about it. I use a different security system than what I outline here, and I see problems with it.

Thanks for reading!

cross-posted from: https://lemmy.ml/post/26453685

Not many people have heard about secureblue, and I want to spread the word about it. secureblue provides hardened images for Fedora Atomic and CoreOS. It's an operating system "for those whose first priority is using linux, and second priority is security."

secureblue provides exploit mitigations and fixes for multiple security holes. This includes the addition of GrapheneOS's hardened_malloc, their own hardened Chromium-based browser called Trivalent, USBGuard to protect against USB peripheral attacks, and plenty more.

secureblue has definitely matured a lot since I first started using it. Since then, it has become something that could reasonably be used as a daily driver. secureblue recognizes the need for usability alongside security.

If you already have Fedora Atomic (e.g. Secureblue, Kinoite, Sericea, etc.) or CoreOS installed on your system, you can easily rebase to secureblue. The install instructions are really easy to follow, and I had no issues installing it on any of my devices.

I'd love more people to know about secureblue, because it is fantastic if you want a secure desktop OS!

Not many people have heard about secureblue, and I want to spread the word about it. secureblue provides hardened images for Fedora Atomic and CoreOS. It's an operating system "for those whose first priority is using linux, and second priority is security."

secureblue provides exploit mitigations and fixes for multiple security holes. This includes the addition of GrapheneOS's hardened_malloc, their own hardened Chromium-based browser called Trivalent, USBGuard to protect against USB peripheral attacks, and plenty more.

secureblue has definitely matured a lot since I first started using it. Since then, it has become something that could reasonably be used as a daily driver. secureblue recognizes the need for usability alongside security.

If you already have Fedora Atomic (e.g. Secureblue, Kinoite, Sericea, etc.) or CoreOS installed on your system, you can easily rebase to secureblue. The install instructions are really easy to follow, and I had no issues installing it on any of my devices.

I'd love more people to know about secureblue, because it is fantastic if you want a secure desktop OS!

(In honor of Holiday. You know who you are.)

I didn't like Kodi due to the unpleasant controls, especially on Android, so I decided to try out Jellyfin. It was really easy to get working, and I like it a lot more than Kodi, but I started to have problems after the first time restarting my computer.

I store my media on an external LUKS encrypted hard drive. Because of that, for some reason, Jellyfin's permission to access the drive go away after a reboot. That means something like chgrp -R jellyfin /media/username does work, but it stops working after I restart my computer and unlock the disk.

I tried modifying the /etc/fstab file without really knowing what I was doing, and almost bricked the system. Thank goodness I'm running an atomic distro (Fedora Silverblue), I was able to recover pretty quickly.

How do I give Jellyfin permanent access to my hard drive?

Solution:

1. Install GNOME Disks
2. Open GNOME Disks
3. On the left, click on the drive storing your media
4. Click "Unlock selected encrypted partition" (the padlock icon)
5. Enter your password
6. Click "Unlock"
7. Select the LUKS partition
8. Click "Additional partition options" (the gear icon)
9. Click "Edit Encryption Options..."
10. Enter your admin password
11. Click "Authenticate"
12. Disable "User Session Defaults"
13. Select "Unlock at system startup"
14. Enter the encryption password for your drive in the "Passphrase" field
15. Click "Ok"
16. Select the decrypted Ext4 partition
17. Click "Additional partition options" (the gear icon)
18. Click "Edit Mount Options..."
19. Disable "User Session Defaults"
20. Select "Mount at system startup"
21. Click "Ok"
22. Navigate to your Jellyfin Dashboard
23. Go to "Libraries"
24. Select "Add Media Library"
25. When configuring the folder, navigate to /mnt and then select the UUID that points to your mounted hard drive

A couple years ago when I was first interested in privacy I stumbled across a privacy website that I found very cool. I regret not saving it, but I'm certain it's not lost. I only remember this about the website:

• It had this song as its background music
• The website was for educating about privacy, and you would "unlock" new knowledge as you went
• Some of that knowledge was in a "cave" where some dark stories and articles surfaced
• One of the interactive segments was about "What do you think step counter data could reveal about you?" and the answer was things like religion (if your step count increased on certain days such as Sunday or Tuesday which correlates with some religions), rough location (based on which times you walked), etc.

That's all I remember. Thank you so much to anyone who can help me find it!

Yesterday I decided to start "officially" selfhosting. With almost no experience with Docker, I struggled for eight hours straight, but I finally have it working.

Currently, the two tools I am selfhosting with Docker Compose are LibreTranslate and spotDL. I'm only accessing them over the local network using a direct IP:PORT, so there's no domain name. I don't want to use a custom DNS, since it is fingerprintable online, so I want to keep it the same as my VPN.

With that said, I want to add encryption to the connections. I was able to generate my own self signed certificates with this command:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./certs/key.key -out ./certs/cert.crt

spotDL was easy to setup with these self signed certs, since it has command flags for --enable-tls, --key-file, and --cert-file. LibreTranslate has an environment variable for - LT_SSL=true, however it gives the following error:

libretranslate  | (URLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1006)')),)

That led me to this issue which is 2 and a half years old. LibreTranslate doesn't have a way to specify certificates that I know of.

I tried using Nginx Proxy Manager to create a reverse proxy, but I couldn't quite figure it out. (I also didn't understand Docker Compose at the time. I had a few hours to go before I did) NPM also seems to want Let's Encrypt certificates which can't be given without a DNS record. I tried manually providing certificates in the config file, but I don't quite understand NPM enough to be able to set it up properly on my own.

My requirements are:

• No changing the DNS from my VPN's default
• No port forwarding, everything should be accessed by the local network only
• No email required (ability to use a fake email without risk is fine)
• Only free and open source software
• Modern security standards where available

I also would like help adding the self signed certificates as a permanent exception in Brave browser, if possible.

This question has been answered. Please stop trying to repeat information that has already been said many times before. Everything in this thread is in good faith, I am here to learn, so I will make mistakes. Furthermore, if you want to contribute something new, please read the entire post to avoid misunderstanding the purpose of this post.

Selfhosting is useful when you either need a lot of storage or a lot of processing power. For example, Kiwix is useful to selfhost on a server because a lot of its content can take up terabytes of storage, which a phone may not have. LLMs are also useful to selfhost because they require a degree of processing power that, again, a phone may not have.

In both cases, there is also a need for perpetual access. If you simply hosted an LLM on your home computer, it wouldn't be very useful to access from your phone since your computer won't be running all the time. So, a separate always-on server is needed.

However, there are some selfhosted software that I don't see a use for. For example, Immich. Immich requires to be run on a server to function, but a lot of (or even all) of its functions are things that could reasonably done entirely on-device. Aves combined with some automatic backup solution such as Nextcloud gets (from what I can tell) most of the functionality Immich offers. Obviously, some features like AI image tagging are missing, but you get the point. AI image tagging is also something that could be run on-device as well, since it's mostly lightweight (iPhones are capable of it). Having a setup like that also comes with the benefit of automatic backups being completely optional, rather than required.

There's no reasonable need for extra storage or extra processing power needed for that use case, from what I can tell. (Disclaimer: I haven't actually used Immich before, so this is speculation. I apologize if I'm missing something obvious) There's a lot of other selfhosted tools like spotDL which have a selfhosted web UI, but no GUI that can be installed outside of a web browser.

I guess my question is why there are so many selfhosted tools that unnecessarily require being run on a separate device. I do understand the legitimate use cases some of them have, but others seem better off on-device airgapped. This especially became an issue trying to find a notes app for Android that requires no account and runs fully locally, or an RSS reader that loads from the device itself. I found Joplin and Feeder or Read You as the software for each of those. I don't like "server-based" selfhosting for things that could be done from the device itself.

I'm sorry if this turned into a rant. If someone could help me understand, I would appreciate that very much.

Cheers!

Edit: The comparison here isn't between selfhosting and using a cloud provider. The comparison here is between selfhosting on a server and running explicitly on-device (besides where extra storage or processing power is required)

Answer

So that nobody has to dig through the comments for answers, this is what I've learned: In the case of Immich, its purpose isn't designed to be a photo gallery. It's designed to be a more polished backup solution, designed explicitly for photos and not general files. While Nextcloud could be used to backup photos, it's not as focused on photos as Immich, and so it isn't as nice to use for that purpose. Immich also allows you to share photos with a link, rather than relying on a cloud provider to do that for you. There's also another benefit to selfhosting that I hadn't entirely realized, which is availability across devices. Some things like an eBook library may not take up much space, but it's convenient to not have to sync manually (or automatically) across devices, and instead access it from a central server. That same logic is true for RSS readers as well, since it's inconvenient to manually add and sync feeds across devices. Syncing across devices can be done with something like Syncthing in some cases, but not all, and so that's where selfhosting can be useful.

After about 2 and a half years of battling for my privacy, I'm finally at a place where I can step back and be happy. Technically the seed of privacy was planted 5 years ago, but it hadn't become a goal yet.

I used to use Windows 7 (even 10 and 11, eventually), an iPhone 6, Gmail, Google Hangouts (anyone else remember when it was called that?) and Discord as my main messengers, Snapchat, Instagram, Spotify, Netflix, Reddit, ChatGPT, Chrome, Google, Avast and Avast VPN, YouTube, Authy, and so, so much more.

I am so fortunate to be able to be where I'm at now. I use Fedora (Silverblue. I tried secureblue but it was too strict for my taste), a Pixel 8 running GrapheneOS, Proton Mail + addy.io (although I try to use email as little as possible), Signal and SimpleX Chat, a "self-hosted" music library, some cheaper ways to stream movies, Lemmy (duh), HuggingChat (because I don't have the hardware to run my own model quite yet), Tor Browser and another (I want to avoid arguments about my browser choice), SearXNG, Proton VPN (until I can get Mullvad VPN paid for), FreeTube, Aegis Authenticator, and a plethora of other software.

I got quite lucky with device compatibility. My computer and laptop just so happen to be compatible with every distro I've tried, and I've sure dragged them through hell to find the one I want. I'm blessed to have been able to snag a decent phone for GrapheneOS, and so glad to have automated the transition from Spotify.

It's been a good run. I'm glad to finally be satisfied with where I'm at. I started to see the fruit of my labor months ago. Now I can rest easy and do my part to help others become more privacy aware. I'd love to hear your story too, maybe mine isn't far off!

Bonus story: The straw that broke the camel's back that caused me to fully switch to Linux was Windows 11's Efficiency Mode. It's a cute feature that throttles the performance of programs to save on carbon emissions... and (at the time) you couldn't disable it. You could disable it per-process, but it would re-enable itself shortly after. ChatGPT was becoming quite popular at the time, but Efficiency Mode slowing down the browser made it nearly unusable. I did look for ways to permanently disable it, but either I wasn't experienced enough or it didn't exist yet. Well, no way except to replace Windows altogether!

All of us have made privacy mistakes at some point in our privacy journeys. In an effort to help those earlier on in that journey, please share some of the mistakes you've made, and how you could have prevented it.

I use an RSS reader to curate my Lemmy feed, which means I see every post, including deleted ones. Every so often, posts will crop up with pessimistic content such as "Why try anymore?" etc. Most of the time these are a result of privacy burnout, where the individual has a threat model that is too strict for their own tolerance.

We all wish we have perfect privacy. We all wish the world could be more pro-privacy than anti-privacy. One day, that may be the case. For now, we have to accept that nobody can be completely private. Privacy is a spectrum, and doing what you can to minimize data collection goes a long way. You can't become private overnight, so taking small steps like these means you can grow a strong foundation for future privacy. Privacy takes time, so take it as slow as you need to.

Even if a company already has your data or another means to track you, by minimizing you are making it harder for them to extract that data, and it increases the odds that your data becomes stale. By caring about privacy to begin with, you're showing companies and other people that the data collection is not ok.

I've been a privacy activist for years now, and I will also face periods of privacy burnout. I handle it by stopping, taking a step back, and reevaluating my threat model. It's good to take breaks like those, because it means you don't push yourself past your limits and become burnt out.

It's really easy to get caught up in the "breaking news" of privacy, too. This is more of a personal stance, but getting caught up in politics and news often leads to stress and makes it harder to make real progress. (This is one of the reasons I use an RSS reader, I can curate my information without stressful headlines.) You don't need to use the most private software or jump ship the moment anything goes wrong. If you feel you need to switch, do it when you have time and when it won't cause problems elsewhere.

Take a look at how far you've come, and realize that even if you're not where you want to be yet, you've taken steps to get there. Every person who starts to care about privacy, even you, is one more person to help make the world a more privacy respecting place. It may not seem like you make that much of a difference, but it's not just you. You and everybody else who cares about privacy makes a huge difference.

Don't give up now. Privacy is an uphill battle by design, but the payoff is worth it.

Good luck!