• 0 Posts
  • 5 Comments
Joined 1 year ago
cake
Cake day: August 8th, 2023

help-circle

  • My whole infrastructure is designed so that my homeserver is expendable.

    Therefore my most important tool is Syncthing. It is decentral, which is awesome for uptime and reducing dependance on a single point of failure. My server is configured as the “introducer” node for convenience.

    I try to find file-based applications, such as KeePassXC or Obsidian, whenever I can so that I can sync as much as possible with Syncthing.

    Therefore there is (luckily) not much left to host and all of it is less critical:

    • Nextcloud AIO: calendar, contacts, RSS, Syncthing files via external storage
    • Webserver: Firefox search plugins (Why is this necessary, Mozilla?!), custom uBlock Origin filter list, personal website

    So the worst thing that can happen when my server fails is: I need to import my OPML to a cloud provider and I loose syncing for some less important stuff and my homepage is not accessible.

    Since I just rebuilt my server, I can confirm that I managed a whole week without it just fine. Thank you very much, Syncthing!


  • FOSS Is Fun@lemmy.mltoOpen Source@lemmy.mlDistrochooser
    link
    fedilink
    English
    arrow-up
    4
    ·
    1 year ago

    Linux Mint nowadays supports release upgrades, but you have to follow their blog to know when a new major Mint release is out and you have to manually install mintupgrade and do the upgrade.

    So it is definitely not caused by technical constraints, as Mint has implemented the difficult part (providing and testing an upgrade path) already. Notifying the user about a new release upgrade shouldn’t be too difficult? E. g. in the most simple form you could probably preinstall a package that does nothing at first, but receives an update once the next Mint release is out to send a notification to the user to inform about a new Mint release.

    When it comes to elementary OS, I think they could support in-place upgrades, as they properly use metapackages (unlike Mint, which marks most packages as manually installed and doesn’t really utilise automatically installed packages and metapackages in a way that you would expect on a Ubuntu-based distro), but they probably don’t want to allocate / don’t have the resources to test an official upgrade path.

    But again, I don’t understand why it is so difficult for elementary OS to at least provide a simple notification to the user that a new version is out. Even if the users have to reinstall, it is critical to inform them that their OS is about to become end of life. You know, people do things like online banking on their computers …

    It’s the first thing I check with every distribution and if it doesn’t have an EOL / upgrade notification, it is immediately out.


  • FOSS Is Fun@lemmy.mltoOpen Source@lemmy.mlDistrochooser
    link
    fedilink
    English
    arrow-up
    17
    ·
    1 year ago

    It misses one important choice: “I want to get notified of new releases of the operating system and want to have a graphical upgrade path.”

    Otherwise people just run their no longer supported OS until something stops working (I’ve seen this countless times …), as very few people follow blog posts or social media feeds of their operating system.

    This rules out lots of supposedly “beginner friendly” distributions, such as elementary OS or Linux Mint, as they don’t notify users about the availability of a new distribution release. Elementary OS doesn’t even offer in-place upgrades and requires a reinstallation.


  • For servers there’s Docker/Kubernetes/Podman, which is well-established and serves a similar purpose as Flatpak on the desktop. Servers were actually first with the increase in popularity of containers.

    90 % or more of my desktop (Fedora Kinoite and Silverblue) apps are Flatpaks already. I only have four rpm-ostree overlays (native packages) left: android-tools, brasero/k3b, syncthing (I could switch to SyncThingy for a Flatpak) and virt-manager/virtualbox

    With Flatpak there is “flatpak override” which gives you the ability to grant additional permissions or restrict them even further. E. g. I use it to connect KeePassXC with Firefox or to disallow access to the X server to force almost all apps to use Wayland instead of X. It also allows me to prevent apps from creating and writing into arbitrary directories in my home.

    Once I reinstall my home server, all its server software will be containerised as well (five years ago I didn’t see the necessity yet). I am tired of having to manage dependencies with every (Nextcloud) upgrade. I want something that can auto update itself completely with minimal or no breakage, just like my desktops.


  • You can select a local folder in Obsidian for Android and sync the folder with Syncthing. You can even revoke network permissions for Obsidian and it all works completely offline (Flatpak override: --unshare=network / GrapheneOS: don’t allow the network permission).

    This is my current setup, even though Obsidian is not FOSS. I like that it stores standard Markdown files in a traditional filesystem hierarchy, instead of what Joplin does with using Markdown files as a database. This means that with Obsidian I can use any text editor or any other Markdown app to access and edit my notes, whereas with Joplin I would have to export them first to standard Markdown and then potentially rename and reorganise all the files and their attachments.