Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)T

thecoffeehobbit

@ thecoffeehobbit @sopuli.xyz

Posts
3
Comments
44
Joined
2 yr. ago

  • Ready to jump into Linux for everything

    Jump

  • Right, okay. If you want to fool around as you have a stable daily driver already, sure get a more DIY distro or just try out multiple things before settling. Debian should do the trick though, it's somewhat DIY while being very stable so the updates rarely break anything. But you might also like Arch, or NixOS, or just Mint. I think the point is it's just not very easy to predict how each of these is gonna actually run on your actual hardware. So to really find out you'll have to install something and acknowledge you may need to re-do it a couple times before finding something that works for you.

  • Ready to jump into Linux for everything

    Jump

  • As you already use Pop, why change? Is there something bothering, or something does not run well? How old is this laptop?

    If you don't feel like continuing with Pop, I'd try Debian as you value stability. It may be a slight pain to set up initially, but when it's done it should generally Just Work until eternity. The expert installer allows you to enable non-free repos for any proprietary drivers by default.

  • Ready to jump into Linux for everything

    Jump

  • Mint has the downside of not coming with mainstream desktop environments. Otherwise a great distro, but the message it gives to newcomers is that Linux still looks like it looked 10 years ago. Still very worth for some installs, and op is not a newcomer, but anyway.

  • Ready to jump into Linux for everything

    Jump

  • Arch defaults to pipewire I think even if you select pulseaudio in archinstall (might have changed by now ofc) If your laptop is older pulseaudio might work much better (did for me)

  • The Debian project is proud to release Debian 13 "Trixie", a major update that brings new features, updated components, and numerous other improvements

    Jump

  • Get base Debian, you'll have more options for desktop environment. Once you get past the installation hassle it should just work for the rest of times. MX has its place but it's specifically made to have no systemd which may not be something a new user is looking for. It feels very opinionated, is what I'm trying to say. May be your thing of course, but I'd recommend reading more on its philosophy before picking.

    8 years is probably not old enough to require lighter desktops if the machines were at least mid range at the time. You should be able to use gnome or KDE as you please. Nothing against XFCE in principle, but it can be a little clunky especially for a laptop. No touch gestures, for example.

  • What Git clients do you use?

    Jump

  • Vscode and gitlens for routine stuff, and then just CLI when push comes to shove and I need some more advanced feature.

  • Question: Linux desktops for programming

    Jump

  • Thanks!

    For the record, which DE do you run on it? KDE?

  • Question: Linux desktops for programming

    Jump

  • Thanks!

    Regarding gaming, I had big trouble trying to play some steam games on gnome. After switching to KDE stuff just works.

    Also you can't (feasibly) run Hyprland on Debian stable, nor can you (easily) run GNOME on MX Linux, etc. So there are a few points where distro choice does have an effect. But I think I got the point across enough with the question

  • 3-2-1 Backups: How do you do the 1 offsite backup?

    Jump

  • I have an external storage unit a couple kilometers away and two 8TB hard drives with luks+btrfs. One of them is always in the box and after taking backups, when I feel like it, I detach the drive and bike to the box to switch. I'm currently researching btrbk for updating the backup drive on my pc automatically, it's pretty manual atm. For most scenarios the automatic btrfs snapshots on my main disks are going to be enough anyway.

  • Filesystem and virtualization decisions for homeserver build

    Jump

  • Oh yeah and I did enable Proxmox VM firewall for the TrueNAS, the NFS traffic goes via an internal interface. Wasn't entirely convinced by NFS's security posture when reading about it.. At least restrict it to the physical machine 0_0 So I now need to intentionally pass a new NIC to any VM that will access the data, which is neat.

  • Filesystem and virtualization decisions for homeserver build

    Jump

  • A wrap-up of what I ended up doing:

    • Replaced the bare metal Ubuntu with Proxmox. Cool cool. It can do the same stuff but easier / comes with a lot of hints for best practices. Guess I'm a datacenter admin now
    • Wiped the 2x960GB SSD pool and re-created it with ZFS native encryption
    • Made a TrueNAS Scale VM, passed through the SSD pool disks, shared the datasets with NFS and made snapshot policies
    • Mounted the NFS on the Ubuntu VM running my data related services and moved the docker bind mounts to that folder
    • Bought a 1Gbps Intel network card to use instead of the onboard Realtek and maxed out the host memory to 16GB for good measure

    I have achieved:

    • 15min RPO for my data (as it sits on the NFS mount, which is auto-snapshotted in TrueNAS)
    • Encryption at rest (ZFS native)

    I have not achieved (yet..):

    • Key fetch on boot. Now if the host machine boots I have to log in to TrueNAS to key in the ZFS passphrase. I will have to make some custom script for this anyway I guess to make it adapt to the situation as key fetching on boot is a paid feature in TrueNAS but it just makes managing the storage a bit easier so I wanna use it now. Disabled auto start on boot for the services VM that depends on the NFS share, so I'll just go kick it up manually after unlocking the pool in TrueNAS.

    Quite happy with the setup so far. Looking to automate actual backups next, but this is starting to take shape. Building the confidence to use this for my actual phone backups, among other things.

  • Filesystem and virtualization decisions for homeserver build

    Jump

  • Really good to know. Planned to keep using very mainstream LTS versions anyway, but this solidifies the decision. Maybe on a laptop I'll install something more experimental but that's then throwaway style.

  • Filesystem and virtualization decisions for homeserver build

    Jump

  • I guess I'll give it a spin. There seems to be a big community around it. I initially thought I might migrate later so keeping the host OS layer as thin as possible. Ubuntu was mainly an easy start as I was familiar with it from before and the spirit in this initiative is DIY over framework - but if there's a widely used solution for exactly this.. Yeah.

  • Filesystem and virtualization decisions for homeserver build

    Jump

  • Always a good reminder to test the backups, no I would not sleep properly if I didn't test them :p

    Aiming to keep it simple, too many moving parts in the VM snapshots / hard to figure out best practices and notice mistakes without work experience in the area, so I'll just backup the data separately and call it a day. But thanks for the input! I don't think any of my services have in-memory db's.

  • Filesystem and virtualization decisions for homeserver build

    Jump

  • Right, thanks for the heads up! On the desktops I have simply installed zfs as root via the Ubuntu 24.04 installer. Then, as the option was not available in the server variant I started to think maybe that is not something that should be done :p

  • Filesystem and virtualization decisions for homeserver build

    Jump

  • Aight thank you so much, confirms I'm on the right path! This clarifies a lot, I'll keep the ext4 boot drive :)

  • Filesystem and virtualization decisions for homeserver build

    Jump

  • Right, so my aversion to live backups comes initially from Louis Rossmann's guide on the FUTO wiki where he mentions it's non trivial to reliably snapshot a running system. After a lot of looking elsewhere as well I haven't gotten much hints that it would be bad advice and I want to err on the side of caution anyway. The hypervisor is QEMU/KVM so in theory it should be able to do live snapshots afaik. But I'm not familiar enough with the consistency guarantees to fully trust it. I don't wanna wake up one day to a server crash and trying to mount the backed up qcow2 in a new system and suddenly it wouldn't work and I just lost data.

    It won't matter though as I'll just place all the important data on the zpool and back that up frequently as a simple data store. The VMs can keep doing their nightly shutdown and snapshot thing.

  • Filesystem and virtualization decisions for homeserver build

    Jump

  • Ok so wrapping my head around this, what I think I need to be clear about is the separation between applications and data. Applications get the nightly VM snapshot way of backing up, and data will get the frequent zfs snapshots (and other backups). Kinda what I tried to do to begin with, so I will look more on how to do this separation for the applications I intend to use.

    Still unsure if samba is the way to go for linking it together on the same physical machine.

    Should I just run syncthing on the bare metal host...? Will sleep on it.

  • Filesystem and virtualization decisions for homeserver build

    Jump

  • This is what I'm doing currently, but it's not really feasible to have the services shut down hourly for snapshots. This is indeed why I started looking towards filesystem-level snapshotting Obviously I will have other types of backups as well, I'm simply looking to have the on-the-fly immutable snapshot capability here somehow.