I think there’s a spectrum and you said it as if there’s only two sides.

For me personally, I built my “data centre” as cheap as possible, but there’s a few requirements that the computers you’re using would not cut it: storage server must be using ZFS with ECC. I started this around a decade ago and I only spent ~$300 at the time (reusing old PSU and case I think).

There are many requirements of a data centre that can be relaxed in a home lab settings, up time, performance, etc. but I would never trade data integrity for tiny bit of savings. Sadly this is a criteria that many, including some of those building very sophisticated home cluster, didn’t set as a priority.

A powerful enough machine (usually limited by RAM, not CPU) will let you run a hypervisor OS like Proxmox which helps a lot with making things secure and flexible. You might also want to have RAID, ECC memory. It quickly starts to make sense to build a proper home server rather than cobbling together a bunch of low end hardware. The tipping point is probably when you want more than 1-2 hard drives worth of storage.

Man, "homelab" is such a wide term. For some it's an old Android, for some it's a literal datacenter in a basement. And everything in between.

Goals are vastly different too. For some it's about hosting a few services to be free from company slop, for others it's a way to practice devops: clustering, containers, complex networking.

Seeing someone recommending Proxmox or Freenas to a beginner that just want to share family photos from an old laptop is wrong in so many ways...

I used to be on the side of single NUC, but when my self hosted services became important enough, I realized I need to take security and reliability seriously, you know, all the SysAdmin/SRE stuff, and that's when I started moving to "that side".

Another Plex (Pass) user here. What exactly is the bullshit you deal with?

Over the years I have been streaming all my movies and shows to as many people I want.

Plex added HDR support for transcoding, live subtitles syncing and more.

Especially the subtitle syncing is fantastic. It completely solved the problem.

Security updates is what's stopping them often.

You also realistically can't fork things unless multiple people do, and they all stay interested in the fork.

you choose if and when you update your back-end software

That's what we say it's about. But it's really about open source devs being our slaves forever. Get to work, Mattermost! (whip crack)

It’s even better than that. You no longer like Plex? Alternatives like Jellyfin are there, you can use them on the same media library

You might be interested in https://www.iroh.computer/

Sounds like you want a k3s based homelab and then connect it all with Tailscale or Netbird.

FWIW: My Intel Nuc on Ubuntu LTS with a cron apt update / upgrade job works for years without a hickup.

I have reliable electricity and internet at home, though.

Ctrl+F "jellyfin" to find this excellent comment.

Same. I have been using Plex for 15 years. For my personal use case, it has not changed, ever. I don't encounter any "enshittification". For my purposes it continues to be exactly what I want, just as it always was.

> You could argue that Plex, MinIO or Mattermost is being enshittified, but definitely not self hosting as a whole.

That's probably not how you should interpret it. Self hosting as a whole is still a vastly better option. But if there is a significant enough public movement towards it, you can expect it to be targeted for enshittification too. The incidents related to Plex, MinIO and Mattermost should be taken as warning signals about what this may escalate into in the future. Here are the possible problems I foresee.

1. The situation with Plex, MinIO and Mattermost can be expected to happen more frequently. After a limit, the pain of frequent migration will become untenable. MinIO is a great example. Even the crowd on HN hadn't considered an alternative until then. Some of us learned about Garage, RustFS and Ceph S3 for the first time and we were debating about each of their pros and cons. It's very telling that that discussion was very lengthy.

2. There is a gradual nudge to move everything to the cloud and then monetize it. Mandatory online account for Win11, monetization of GH self-hosted runner (now suspended after backlash, I think) and cloudification of MS Office are good examples. You can expect a similar attempt on self hosted applications. Of course, most of our self-hosted software is currently open source. But if these big companies decide to embrace, extend and extinguish it, I'm not sure that the market will be prudent enough to stick with the FOSS options. Half of HN was fighting me a few days back when I suggested that we should strive to push the market towards serviceable modular hardware.

3. FOSS projects developed under companies are always at a higher risk of being hijacked or going rogue. To be clear, I'm not against that model. For example, I'm happy with Zulip's development and monetization model - ethical, generous and not too pushy. But mattermost shows where that can go wrong. Sure, they're are open source. But there are practical difficulties in easily overriding such issues.

4. At one time, we were expecting small form-factor headless computers (Plug computers [1]) like SheevaPlug and FreedomBox to become ubiquitous. That should still be an option, though I'm not sure where it's headed, given the current RAM situation. But even if they make a come back, it's very likely that OEMs will lock it down like smartphones today and make it difficult for you to exercise your choices of servers, if not outright restrict them. (If anybody wants to argue that normal people will never consider it, remember how smartphones were, before iPhone. We had a blackberry that was used only by a niche crowd.)

[1] https://en.wikipedia.org/wiki/Plug_computer

What I understood is that the author is hoarding them for the future - not because there is any need for it right now. You could argue that it's too much RAM even at end of server's useful lifetime. But who knows? What if he end up running a few dozen services on it at that time?

Honestly, the problem that they're preparing for, isn't any of our fault. This is inflicted upon the world by some very twisted business models, incentives and priorities. It's hard to predict how it will all end up. Perhaps the market will be flooded with tons of RAM that will have to be transplanted onto proper DIMM modules. Or perhaps we might be scavenging the e-waste junkyard for every last RAM IC we can find - in which case, his choice would be correct.

I've been running syncthing, HA, Samba, jellyfin, and some home made stuff on a Celeron NUC with 8GB. Works fine.

I run quite a few services with a used Dell Wyse 5070 thin client PC from 2018 with 4GB of ram.

I self-host and generally put 64GB of RAM in servers (DDR3, thankfully). Certain arrangements of Docker-based services simply chew up a lot of RAM.

> I suspect you don’t

...today.

If you're self-hosting, do you need 640K of ram?

Mattermost is infamous crippleware and they charge more than slack for a worse product if you pay. Use Zulip.

Nowadays for self hosted DNS the solution I use is Pihole + Tailscale (for the Pihole DNS anywhere) if I could figure it out in one afternoon it is pretty idiot proof.

Maybe the remaining 1/3 answers the question.

What do you want to run? Small services with an handful of users? Anything can serve them. Media libraries? As long as you have a CPU with QuickSync you’re good for on the fly transcoding and the real limiting factor becomes storage.

A TinyMiniMicro https://www.servethehome.com/introducing-project-tinyminimic... used PC is more than adequate for most workloads (except for local AI and if you want to have a huge amount of storage). Last time I checked the prices were in the ballpark of $100/$150 for a working machine.

New machines with a N series Intel CPU are in the similar ballpark.

Honestly maybe we could learn a thing or two from 1990's computing?

Running an OS in 16-32mb ram with GUI...

Memory management for programs...

"Not me," said entropy, "I was already there at the outset."

Less cutely, this is an interesting topical site/newsletter => https://selfh.st

It's not that much headache, and this isn't necessarily about public-facing sites and apps.

Take file storage: Some folks find Google Drive and similar services unpalatable because they can and will scan your content. Setting up Nextcloud or even just using file sharing built into a consumer router is pretty easy.

You don't need to rely on Cloudflare, either. Some routers come with VPN functionality or can have it added.

The self-hosting most people talk about when they talk about self-hosting is very practical.

I don’t think you understand what on-premises means.

Some of us have have LAN for our offices and TBs of data.

People are going to start doing this a lot more as agents improve. Most people only need a very small fraction of the features of SaaS, and that fraction is slightly different for everyone, so the economics of companies trying to use features to chase users is bad. Even worse, if you're on SaaS you can't modify the code, which will be crippling, so the whole SaaS model is cooked.

I think co-management is going to be the next paradigm.

> How is it "self-hosted" if it's "remote streaming?" And if you're hosting it, you can throttle any outgoing traffic you want. Right?

You host the plex service with your media library. Plex allows you to stream without opening up your firewall to others. Not sure now it works exactly because I never hosted it myself.

> This article is lame. How about focusing on back-ends that pretend to support self-hosting but make it difficult by perpetuating massive gaps in its documentation (looking at you, Supabase)?

that's one way of enshittifying, but what the article talks about is nonetheless very important.

People rely on projects being open source (or rather: _hosted on github_) as some sort of mark of freedom from shitty features and burdensome monetization.

As the examples illustrate, the pattern of capturing users with a good offering and then subsequently squeezing them for money can very easily be done by open source software with free licenses. The reason for that is that source code being available is not, alone, enough to ensure not getting captured by adversarial interests.

What you ALSO need is people wanting to put in the work to create a parallel fork to continuously keep the enshittification at bay. Someone who rolls a distribution with a massive amount of ever-decaying patches, increasingly large amounts of workarounds, etc. Or, alternatively, a "final release" style fork that enters maintenance mode and only ever backports security vulnerability fixes. Either of those is a huge amount of work and it's not even sure that people will find that fork on their own rather than just assume "things are like that now".

Given that the code's originating corporation can and will eagerly throw whole teams of people at disabling such efforts, the counter-efforts would require the same amount of free labor to be successful - or even larger, given that it's easy to wreck things for the code's originator but it's difficult to fix them for the restoration crew.

This pattern, repeated in many projects over the decades since GPL2 and MIT were produced, displays that merely being free and open source does not create a complete anti enshittification measure for the end user. What is actually necessary is a societal measure, a safety web made up of developers dedicated to conservation of important software, who would be capable of correcting any stupid decisions made by pointy-haired managers. There are some small projects like this (eg Apache, and many more) but they are not all-encompassing and many projects that are important to people are without such a safety net.

So for this reason, eg when people are upset that mattermost limits the messages to 10000, their real quarrel isn't really even with the scorpion, who is known to sting, it is with the lack of there being a social safety net for this particular software. Their efforts would be well spent on rapidly building such a safety network to quickly force the corporation's hand into increasingly more desperate measures, accelerating their endgame and self-induced implosion. Then, after the corpo's greed inevitably makes them eat themselves in full, the software can enter the normal space of FOSS development rather than forever remain this corporate slave-product that is pact-bound to a Delaware LLC by a chain of corporate greed.

Only once any free fork's competition backed by VCs burning their money on a ceremonial heap has been removed can the free version of the software become the central source for all users and therefore become successful, rather than continuously play catch up with a throng of H-2B holders.