• 1 Post
  • 73 Comments
Joined 3 years ago
cake
Cake day: June 15th, 2023

help-circle
  • Unfortunately most companies don’t have a software culture or even understand it. Heck there are entire nations (like Japan) that are culturally at odds with software. It doesn’t stop them from making software (you can’t NOT make software in today’s day and age), they just go about it in furtive, roundabout and ultimately very inefficient ways.

    It’s weird because modern software development borrows heavily from industrial process optimizations (some of which were invented and perfected in Japan, ironically) and there are clear, proven benefits to cooperation upstream in projects like Linux… and yet they still fight it every step of the way in the name of “IP”.

    It doesn’t help either that there are countries (US, Japan, what do you know) that nurture the concept of software patents that have a chilling effect on sharing.





  • In Docker’s case is a non-issue because they were careful to use completely different names for all their packages. It’s only when the external repo uses the same names as the core that the dependency resolver can get confused.

    Rant:

    apt should either completely forbid external repos from using core package names (like Arch does), or look at both the package name and repo URL when deciding if a package is the same, not just package name.

    I’m guessing that letting external repos “hijack” a package name was once upon a time seen as a feature and then they never got around to fixing it.


  • You say that but sometimes they come up with stuff that’s really useful and it can be very annoying to not have it. Like when they integrated compose into the main.

    Also, if you later decide to switch to the official version you’ll have to handle the upgrade carefully or you risk wiping out all your images, containers, networks, volumes etc. Which can be fine if you have backups of all the relevant functional definitions and the volumes and so on, but obviously a huge pain if it catches you unprepared.

    Mind you, this can also happen by tinkering with stuff in /etc/docker/daemon.json, which is how I originally learned to back up my shit.



  • If you already know Debian that’s a big point in its favor. Nothing beats a distro you’re familiar with. (And I’d make the same argument if you were used to Ubuntu.)

    I’ve used both Debian and Ubuntu Server on my home servers and I ended up returning to Debian.

    • Debian embodies and follows the most essential Linux values. It’s open, it’s run by an open organization, it avoids proprietary stuff.
    • Debian is long-lived. It’s been around for 30 years, it’s mature, self-sustaining, community-run project, and it will be around 30 years from now. Whereas I wouldn’t bet on Canonical being around in 30 years.
    • The upgrade path for Debian is better than for Ubuntu Server LTS.(1) You can upgrade it in-place between major versions a lot more reliably and painlessly than Ubuntu.
    • Debian is dedicated to being stable. (Please run stable, btw.)
    • Debian is a lot more resource-friendly than Ubuntu Server.

    I’ve ended up concluding that Ubuntu Server is Debian, just with more quirks. It offers nothing essential that you can’t do on Debian, and it will just complicate your life when the LTS support period eventually runs out (and even during LTS, when you have to jump through hoops like Ubuntu One to keep updates coming.)

    (1) You can fuck up both Ubuntu and Debian’s upgrades by adding a lot of 3rd-party repos because apt doesn’t safeguard against external repos interfering with the core repos’ dependency graph.

    So the trick is to keep the OS minimal, install only Docker from its repo and install anything else in Docker containers. That way you benefit the most from Debian being stable and very little from Ubuntu Server.

    If you also need to run system containers and virtual machines you can add Incus later to the mix alongside Docker and still keep your host OS lean and simple.

    You can also consider completely migrating to Proxmox later, which is also Debian under the hood but it’s a more turnkey solution. I wouldn’t recommend jumping straight into Proxmox unless you’re fairly sure that you’d need to run VMs. (If you’re unsure stick to plain Debian for now.)


  • I would recommend reconsidering how you obtain LE certs. I ended up on Certbot too because it lets you own what is a critical part of your selfhosted identity. Plus Certbot works well and it’s maintained by the EFF who also see it as a critical project. As a local script (basically) sky’s the limit regarding automation.

    This is personal preference but I strongly prefer to locally control critical automations about my setup (certs, DDNS etc.)

    The certs produced by Certbot are portable and you can use them with CF, local reverse proxies, or whatever other infrastructure you may need. Just need to get a copy to the proper place (securely).

    I guess in the bigger scheme of things the question is whether you’re ok being tied to a particular service (like CF). I don’t, and I also don’t want to depend on the LE implementation of any particular reverse proxy (or their plugins).

    PS: Oh and another tip: if you do end up using a CLI tool for certs, stick to Certbot. I’ve tried pretty much everything else and they all suck. It’s actually unbelievable how much they suck. Arcane and opaque, the lot of them, which is not something you want from a critical tool.



  • How is Unraid? I’ve been meaning to build a backup PC for my folks out of spare parts and I’ve been wondering what I should install on it.

    I’d like it to start with a couple of mirrored HDDs, and have two writable Samba shares. One for random stuff and discardable stuff like music and movies, and one for important files where they’d put their photos and documents and which would get incremental backups with something like borg.

    I can set this up on Debian ofc but it’s not a bad idea for it to be an OS that doesn’t need arcane knowledge to add/replace HDDs when needed.


  • On servers: Red Hat -> Debian (with a brief detour through Ubuntu Server for a couple of years).

    On desktop: Red Hat -> Ubuntu -> Manjaro.

    Switched away from Red Hat around 2004 after RHL was discontinued and split into RHEL and Fedora. You may think Fedora would’ve been a more obvious choice but it was still new in 2004 while Debian had 10 years under its belt. We also migrated the servers at work to Debian around that time and I had used Debian at school in the '90s so it made a lot of sense to use it at home.

    Ubuntu on desktop was a fucking revelation when it came out (on CDs shipped free to your home 😃) in 2004. Early days Ubuntu was soooo good that I stayed with it until 2020, long after the magic was gone.

    I mean I would’ve probably left eventually anyway given the whole snap and privacy and so on debacles but what really put me off was how it would almost never upgrade cleanly once you’ve added a bunch of 3rd party repos (which you wanted to do all the time on a desktop PC). Eventually I got so sick of it that I was determined to find a rolling distro where upgrades would never be a problem.

    Tried a bunch of them during stay at home during the pandemic and settled on Manjaro + XFCE on the desktop and a fresh install of Debian stable + Docker on the server as a happy medium between “hands off” and “up to date”. I’m at a point where I like my Linux machines to just work and to need zero maintenance so I can put the time into other things instead.



  • I absolutely love the ecosystem that’s sprung around Arch over the years.

    And ofc I wish the fans of the various Arch-based distros had a less antagonistic approach to each other. 🙄 I mean Arch’s main goal is to be flexible and having a diverse family of derived distros downstream is the ultimate confirmation of that goal.

    It’s also very healthy for any distro to have a big “family tree” because the upstream benefits from contributions from a larger community that may not have vibed with the parent distro otherwise.



  • I think the problem is, ironically, trying to use programmers for this. Not only are most of them opposed to vibe-coding out of principle; they work in ivory towers of pure math and can’t seem to wrap their heads around the real world and real users being random; they also have surprisingly little respect for deterministic behavior, statistics, reproducibility, controlled environments, ACID, CAP theorem, you name it, they just don’t give a shit as long as they can play with code.

    Should use QA people instead. Their entire work revolves around getting reproducible results; they don’t mind what tools they use to get there; they’re not burdened by preconcieved dellusions of grandeur about knowing how to program; and they understand that the real world can be unpredictable.



  • I never understood why they don’t support the subsonic protocol.

    I mean… you might as well ask why the DLNA plugin has been broken for years. Or why they don’t add a custom HTTP header to the client app so people can lock access in their reverse proxy.

    As usual it’s a mix of not enough developer manpower and “I don’t use that so it’s not a priority” i.e. the whimsies of FOSS.



  • Because apt is fundamentally broken and it shows most readily on a desktop-oriented distro like Ubuntu.

    In order to benefit from packages not included by the distro you need to use 3rd party apt repos, but there’s no rule against those repos using package names used by another repo, including the distro’s repos. It could’ve also been fixed by identifying packages by [repo name + package name] instead of just [package name]… but it hasn’t.

    The result is that when Ubuntu packages get replaced by 3rd party packages by the same name it can mess up the dependency graph if the 3rd party repo isn’t super careful about it.

    It’s not a huge issue immediately after installing something but as time passes and more updates pile on top of each other (from both Ubuntu and the 3rd parties) it can get completely ruined and eventually the update solver can’t find an upgrade path anymore and you can’t use Ubuntu’s newer releases.

    At that point you have two options. One is to use an advanced solver like the one in aptitude, for example, but in order to fix the mess it will recommend to uninstall and reinstall a huge number of packages, including very core, essential packages, which is very risky and you lose the 3rd party stuff anyway. At which point you might as well use option two, which is to reinstall a newer Ubuntu release from scratch.

    Eventually after you go through this a few times it starts to get really annoying and you either get stuck on an old release out of dread, or you start looking for a distro that can be updated in-place indefinitely.