posted in Selfhosted

Why homelab?

I was reading a homelab discussion about NUTs (Network UPS Tools) that left me scratching my head and wondering "…why? Is complexity for complexities sake part of homelabs? Isn’t this a huge overkill for one machine? Just…use a UPS? "

Then I got to thinking more broadly about homelabbing and I started to wonder if there weren’t maybe (at least) two different schools of thought.

Using home media as example -

  • Store the original.
  • Detect the client.
  • Transcode when required.
  • Monitor the GPU.
  • Add reverse proxy et al
  • Track bandwidth.
  • Add user accounts
  • Add failover.
  • Graph the result.
  • Dashboard.

Vs

  • Store a common compatible file for your devices.
  • Play it directly.

Which school of thought are you and why?

PS: not throwing shade. I get it; for some people, complexity, learning infrastructure, practicing skills for work etc is part of the why. For me, complexity as recreation is suspiciously like work after work.

Perhaps there’s an odd Venn diagram between homelabbing, interest in ownership / useful capability and infrastructure that could make for a fun discussion. For you, is homelabbing a means to an end or is it an end in itself?

EDIT: Feel free to consider “home-lab” and “self hosted” as synonyms for the purpose of this discussion (although I am aware they are somewhat different in scope).

Replying to @⁨SuspiciousCarrot78@aussie.zone⁩

I was reading a homelab discussion about NUTs (Network UPS Tools) that left me scratching my head and wondering "…why? Is complexity for complexities sake part of homelabs? Isn’t this a huge overkill for one machine? Just…use a UPS? "

So, you don’t need to run any software at all on a host on a UPS. You don’t need NUT or anything similar. You can just plug a PC into a UPS.

However, traditionally, the purpose of a UPS isn’t “just power a machine through an extended outage”. It’s to provide enough time to cleanly shut down a machine. Save work, and—once upon a time, filesystems that weren’t cleanly unmounted could become corrupt—unmount filesystems.
It can also provide time for something like a backup generator, if you have something like that up. The UPS may only have enough juice to run the PC for a few minutes. If you look at traditional UPS units, they have very limited amounts of time that they can keep a PC running. They aren’t aimed at the “whole house multi-day keep things running” capability that some lithium ion battery setups are these days.

So traditionally, one would have software on a machine that takes some action, like shutting it down cleanly, when the battery gets low.

If what you have a UPS for is to keep a PC running through momentary power interruptions, and you don’t care about, say, remotely monitoring power status, then, sure. NUT isn’t necessary. Same thing if you just want to provide a short amount of buffer time to let a generator that comes on automatically in an outage fire up.

But if you want remote monitoring of power status or you want hosts to shut down cleanly, then it may be useful. For some people, that’s the reason that they have a UPS at all.

Replying to @⁨SuspiciousCarrot78@aussie.zone⁩

Modern filesystems can corrupt as well with unclean shutdown. They are just less likely to do so. My server stores photos of our life over couple of decades with other nearly irreplaceable data so having the UPS and clean shutdown on power loss gives at least some confidence that the files stay where they are.

Of course I also run backups of the data, but it’s another layer on data safety setup.

Replying to @⁨IsoKiero@sopuli.xyz⁩

Modern filesystems can corrupt as well with unclean shutdown. They are just less likely to do so.

It shouldn’t be possible for them to become corrupt on an unclean shutdown, at all. Not at the filesystem level. It isn’t just a question of probability.

It’s possible that there is some bug in the implementation of a filesystem that causes it to violate its guarantees.

There could be, oh…hardware bugs, say, where hardware violates guarantees.

Files can be partially-written. Software might not handle that, though properly-written software designed like a DBMS will be set up so that a partially-written file will not become corrupt at the file level.

Some filesystems permit disabling features that guard against filesystem corruption.

But absent something like that, it should not be possible for one of the filesystems to become corrupt on an unclean shutdown, at all.

Replying to an earlier post

Not all modern filesystems are CoW like btrfs. ext4 is merely journaled, which means that there are rare instances where it can be corrupted, but recovery is fast. However in both cases you can still end up with individualy inconsistent files if, say, the power goes out while the CoW b-tree is percolating up and so the file never gets updated or if the ram cache never has a chance to flush.

Replying to @⁨BartyDeCanter@piefed.social⁩

ext4 is merely journaled, which means that there are rare instances where it can be corrupted, but recovery is fast.

None of these things mean that the filesystem becomes corrupted; the filesystem will be in a filesystem consistent state when remounted. You can have a write that is partially performed on a file, but that does not cause the filesystem to become corrupt when it does not complete being written. The journal can contain that write, but it can not yet be committed, and won’t yet be visible to a user. But that doesn’t make the filesystem corrupt; the commit itself is atomic.

Edited ⁨⁨Aug⁩ ⁨28⁩, ⁨2026⁩, ⁨14:59⁩⁩en