tylerjl

I've hosted and actively used my own email server for > 10 years and there are two things that are true at the same time:

It is absolutely possible to host, use, and achieve decent deliverability with your own server. It takes work and is a different beast than running a webserver, but that frontier is not dead (yet).

At the same time: it is an ABSOLUTELY TERRIBLE IDEA to suggest that folks operate an email server out of residential IP through your ISP. The spam prevention ecosystem is so draconian now that email traffic flowing out of address ranges belonging to residential owners is yeeted into the sun. If you've operated email infrastructure at decently large scales, you know that SPF/DKIM/DMARC are just one part of how spam is identified, and mixing in the source of email traffic into the detection heuristics is a significant part of that identification process. Achieving decent delivery can often involve "warming up" an IP over time to establish its reputation, and consumer address ranges are a hodge-podge of activity that incur very little trust about what they're doing.

I agree with some commenters that exhort the exercise of self-hosting email to prevent the venerable protocol becoming a homogeneous GMail and Outlook-only world, but there are reliable ways to do this: using a VPS, relying on a company for the sending/SMTP part, or something similar. But footguns abound, and disgorging SMTP packets from your LAN edge is one of them.

Thanks for the kind words! Especially given how ubiquitous systemd is now, skilling up on the toolbox with commands like `systemd-analyze` and `systemctl list-timers` feels super valuable.

Hey everyone, author here. I spotted the hn traffic a little late but I'm happy for any feedback or comments and will try and address the top-level comments as I can.

(Aside: I wrote this article early last month but it caught on only just recently. For better or worse, touching a third rail topic like systemd seems like a sure-fire way to elicit strong and numerous reactions both positive and negative.)

Oh hey, I'm the author. Happy to chat about the post if anyone wants to. (Also the title here probably needs the leading "This" to make sense)

Another sort-of-recent development in the space has made self-hosting dramatically more accessible: even though hardware costs were reasonable before, they're now _very_ reasonable and also resource-efficient.

Repurposing an old tower would offer you enough compute to self-host services back in the day, but now an Intel NUC has plenty of resources in a very small footprint and branching out into the Raspberry Pi-adjacent family of hardware also offers even smaller power draw on aarch64 SBCs.

One experiment in my own lab has been to deploy glusterfs across a fleet of ODroid HC4 devices to operate a distributed storage network. The devices sip small amounts of power, are easy to expand, and last week a disk died completely but I swapped the hardware out while never losing access to the data thanks to separate networked peers staying online while the downed host got new hardware.

Relying on container deployments rather than fat VMs also helps to compress resource requirements when operating lots of self-hosted services. I've got about ~20 nomad-operated services spread across various small, cheap aarch64 hosts that can go down without worrying about it because nomad will just pick a new one.

One convenience of journald is that it exposes a single place to plug in log collection for observability tooling

opentelemetry-collector, promtail, and so on have native plugins for it, which makes aggregation easier to setup

Most tools have "tail this plaintext file" as well, but if it's all flowing to journald, setting up log collection ends up being that much simpler

Hi, author here. The title is intentionally a little attention-grabbing hyperbole but I've appreciated the discussion and feedback about the post. Thanks for reading!

I loved this game growing up, I'm definitely going to give this a try.

As a minor observation, I'm pretty (pleasantly) surprised that the project provides a NixOS package for the application. As somebody who tends to flit between Arch, Fedora, and NixOS, seeing packages for NixOS before Fedora availability is a very surprising signal in terms of Linux distribution popularity.

Slightly off-topic, but my ChatGPT instincts always tend to fire whenever I read copy that concludes with the formula, “Ultimately…” or “Overall…”.

I wonder how much (if any) of this landing page was GPT generated.

> [...] am I understanding correctly that nix could be used instead of packer to generate a vm image/template for proxmox(or whatever hypervisor)?

That's correct, although as you mention later, it's limited to NixOS. It's an unfortunate constraint given how tremendously powerful it is, but the limitation makes sense. nixos-generators is literally a nix function that accepts a NixOS configuration and operates on the nix value in order to construct the VM image, so it wouldn't work quite the same without nix at the core.

Because nix "knows" about the total definition of the system, nixos-generators can do wonderful things like construct an AMI image or VMWare image without talking to any hypervisor APIs or cloud APIs at all - it knows how to construct the system from the "ground up" and you just end up with a big disk image file after the appropriate `nix build ...` command, no AWS keys or running Proxmox API required.

It's a tradeoff, to be sure. But if the use case fits - which for us, it does quite well - you can be outrageously productive. Adding an entirely new image format takes as long as typing a new line in `flake.nix`, and I leverage a common NixOS module between all the image types to invoke a quick and easy local qemu VM when I'd like to experiment locally.

It's become hard to imagine what managing a "normal" system would be like with the features I get by baking it all into a NixOS configuration.