[KronisLV]

> If the author had a service that didn't take up much time for them to maintain because of the various problems that appeared, they probably wouldn't close down the project.

Is this even possible in our modern day world, where there are constantly breaking updates and security risks that need fixes (look at the recent log4j debacle, for example)?

Because while sites like TPB and even HN don't outwardly change often (for example, if the UI works it's generally left that way, without a redesign every year), there is no doubt that they still take attention and effort to maintain, keep running and more importantly, keep running securely.

Of course, if you're talking about the domain complexity (which you need to deal with) vs accidental complexity (which you introduce because of either lacking knowledge or chasing after the latest and shiny technologies), then i fully agree with you in that regard! That's why i rather enjoyed the "Choose Boring Technology" talk: http://boringtechnology.club/

[selfhoster11]

That really depends on your stack. A plain LTS Linux distro + bind9 + zonefile formatted blocking data + security auto updates is pretty hands off to me.

[KronisLV]

That's funny, because it's not unheard of for even simple unattended updates to break something, for example: https://blog.kronis.dev/everything%20is%20broken/debian-and-...

(the tone of that blog post of mine is a bit vitriolic and the advice isn't exactly serious, but the fact of the matter is that sooner or later things will break)

[selfhoster11]

OK, fair enough. I guess you can minimally complicate this by updating an exactly identical machine/boot drive first, and then immediately alerting if health checks fail on that. But it really doesn't seem that bad to me. I've run a VPS that's been self-updating continuously since Feb 2019, and I've not had many breaking issues with the OS.