For a technologist or engineer, yes. For a layperson, no. The average consumer who desires privacy is probably neither a technologist or engineer, so the longterm target is something that just works.

Laypeople also aren't going to entertain the kind of pedantry that is systemd vs systemD vs System D vs SystemD so making systems that abstract further away from those communities is beneficial.

Edit: Thank you for your correction, as a systems engineer, but I couldn't help but highlight this is a big hurdle even in the Linux communities that I've been a part of as desktop Linux as gained wider adoption by laypeople.

I want to edit a service to harden it for example. Oh, wait I shouldn't edit it directly with vi? Because it gets overwritten by package updates. Okay, makes sense, I need to use systemctl edit instead. But that opens a file that has everything commented out. Do I uncomment the [Unit] heading? What do I need to keep and where do I add my additions? I recall there being a comment at the start of this file, but unless I'm misremembering it doesn't answer that.

All I ask of it to do one thing - start something.service after other.service. yet it just refuses to order them this way. Why? I have no idea. I also have no idea where to start debugging a problem like this. There's a billion ways to try and do this after all: do I add Before=something to other.service? Do I add After=other to something.service? Both? Wants=something?

The better question is why should a layperson ever need to know about systemd in the first place.

I'm a technical person and I don't know about systemd, nor have I ever needed it.

When designing products for end users who are not technical, the overriding design goal should be easiness and reliability.

Easy: does not require special knowledge or expertise to operate.

For someone who just wants to self host, having to learn about systemd, by definition makes the product/system not easy.

Reliability: does the system implode in unexpected way based on the slight variations in the environment? If it implodes as such then it is fragile. If it does not, then it is robust and reliable.

For the end user, what matters is that the system is easy and reliable.

If the system is easy but not reliable, the user is effectively forced to become an expert in order to fix the system when it breaks. Thus, if a system is not reliable, then it doesn't matter that it's "easy".

Simple/Complicated only concerns the developers. It's important to keep systems as simple as possible under the hood, because a system that is simple is easier to make reliable than a system that is complicated. But for the end user it does not matter directly. Simplicity is about how many parts the system is composed of and how these parts interact. If there are many many parts that all have to interact with each other, then the system is complex.

Maybe once someone learns about systemd they can find it conceptually simple. But that's a moot point. The point is: they should not even have to learn about its existence.

A system where editing text files can make or break the system, is not a reliable system. It's easy to make mistakes in text files. Specially for users without expertise.

Imagine yourself a windows user. You edit a text file. Restart the machine, and now it doesn't boot, or boots in a special text-only mode. (This is not unheard of on linux based systems).

(This can, of course, happen if you put a technologist outside their element, too)

It is for me with Systemd - I had to spend hours (on two different occasions, if I remember correctly on Debian & Linux Mint) trying to understand how to set a dependency against an NFS filesystem mount so that a DB would not be started before that, and to make that work reliably => Systemd's docs & behaviour (& special distro settings related to systemD?) weren't that great for me.

Sorry, but an actual layperson would already be lost upon reaching the word "abstraction".

I think the abstractions are good, but there's a lot of terms that are needed just for the basic "Spin up this process on boot" (one might say that explicit is better than implicit, but I dunno).

I am not an expert here, but to the best of my knowledge systemd has no concept of inter-host dependencies, making it effectively useless for anything distributed. For example classic lb+app+db cannot be directly controlled by systemd.

Sorry but i don't understand what this means. Internet outage should not affect your LAN services, no matter what selfhosting distro you use.

And yes, having a web hosting company manage your server isn't "real" self hosting, for all the reasons you described, but it's a far cry from dumping all your data with a big data-guzzling giant. Your data isn't calling home, isn't being used by a company, it's sitting on your server under your control, and only you manage it.

I think that's their main gripe.

For example, an OS that has a nextcloud-like suite of services, and a very easy to use GUI to enable a VPN / mesh network for all of your devices pretty much removes much of the concerns you mentioned regarding networking/firewalls/etc.

Except that:

Build servers took a day or so depending on the approval chain.

Hardware could be leased, or the capital expendite written off over 3 years, plus it came with a 4-hr onsite service warranty (if you worked with the right partners), and it being a capital, rather than operational, cost had bottom-line benefits.

24/7 service coverage for major incidents was very doable if you planned correctly, plus you owned the kit and so could control how you brought in resources to support incident recovery, rather thank waiting for your service provider to put the green dot back on their service status page.

//CSB The max total outage time for one corporate where I ran the IT dept was 12 minutes in 3 years, while we swapped out an HP battery-backed disk cache controller that took itself offline due to a confidence check failure.

What do you mean? Did you interrupt the reboot process (eg. repetitive ^C)? Otherwise the OS should flush everything properly.

> after this i have to figure out a better backup solution

If you have other friends doing selfhosting, giving them a HDD to put in their server so you can rsync your data is a good solution. Also, keeping another local backup is a good solution. Doing both is even better.

> AFAICT it’s pretty much impossible to 100% self-host email because of blacklisting

It depends. It's almost impossible with some bad-faith providers (google/microsoft) otherwise everything works well. And even with those bad-faith providers, residential IPs usually have better reputation (if only because your ISP likely blocks outgoing TCP 25 by default and you have to ask them to unfilter it) than VPS IPs which all have a long history of abuse.

> and in between that i may spin up a DNS server to overcome the part where it takes 60min for any new service to be accessible

If you didn't previously query that domain name on your resolver, it will not be cached and will resolve quasi-instantly. The question is how long does your authoritative name server take to apply your changes to the config: if it takes any longer than 10s you should consider switching providers.

> but maybe we can federate, so that you just need to have one friend who cares about this stuff manage the infra and provide it to their peers as a social good.

Very good point! That's the entire premise behind hosting coops like disroot.org or various members of the libreho.st/chatons.org federations.

Which is exactly why OP pointed out this is where we should be headed if we care about privacy.

If you truly believe that a layperson can "easily follow" a technical guide or that a guide with the most common cases is sufficient to maintain a webserver... then the only thing I can say is that your experience with both laypeople and webservers is worlds apart from mine.

And thanks! I'll show it off as soon as I can.

I do have plans to add context to one's timeline; for example, to optionally overlay the weather on that day, or major world or local events. That might be helpful in understanding your own timeline entries in hindsight.

So the life choices thing is interesting. You're talking about divergence points, or nexus events (there are different terms in different literature/cinema), and charting your world lines, basically. (Some Loki and Steins;Gate would be recommended watching.) I am not sure how to do that, but would like to figure that out...

I'm not really sure what you mean by "optimized parts" but I'm happy to get more feedback on that!

(As soon as Timelinize has a private beta I'll probably create a forum for more in-depth discussions like this.)

Now I'd rather leave hosting to a someone dedicated to it who has internalized the latest state of things for all the relevant bits of software and is constantly keeping this knowledge in their brain. Set and forget self hosting can't work in the current environment we have where things require constant security updates and complex security hardening.

I used to backup to external drives. Now I use bare ones since finding big externals got difficult.

I use (and probably abuse) docker compose. K8s is great but compose is easier.

I use a single makefile. Kinda ugly but it's fine.

Bunch of friends and family use my "services". They usually chip in for hard drives and stuff.

I have a few central points of failure but it keeps things easy. My uptime still beats most big clouds - though I have it easier.

I accidentally took down my server for a few days from a botched hardware install. It's a bit funny because now we realize how critical the home server has become to us.. on the other hand, already got the spouses blessing to build a backup standby server.

Maintaining inherited environments is also much more painful than ones you get to design from the ground up. I work with varied environments, and one with ~250 RHEL / CentOS machines has approximately the same level of maintenance burden as another with a dozen or so Ubuntus because the first environment has had configuration management from the beginning and the second is a complete mess that I've slowly tried to reverse-engineer and clean up.

When your change management works, maintaining a dozen servers isn't all that different from maintaining a thousand or more; and the need for change management and automation doesn't really go anywhere even when you don't self-host things.

All these script kiddie tutorials are terrible at showing how to maintain a server for years.

Lots of things I'd consider self-hosting are functionally useless if I can't access them from my phone while out and about.

I could put my phone on a VPN, but that's just another layer of complexity to add to the self-hosting process.

I think Tailscale opens up all kinds of new opportunities for self-hosting.

I would really like to make such devices for home or office use. What would be a good device to use for this? Unfortunately, RaspberryPIs do not come with 2 or 3 NICs. Any recommended alternatives?

It also does “waterfall” egress packet delaying.

I recognize that this embarrassment of riches is in part my own fault. But this is my answer to your “why”

If it becomes simple again I would gladly self-host.

I'd say the point being: I'm a software engineer who knows better about these sorts of things and still got caught with my pants down. You have to be very judicious with respect to security. You can't just plug and play and say "I'm too busy to worry about that."

Another thing I'll add is the amount of software tools they have on these NAS machines strikes me as 1) very impressive for a company their size and 2) a huge surface area rife for being hacked. When it happened I wasn't surprised at all.

I've since stopped using it because at the end of the day I'd rather pay Dropbox to have peace of mind.

_anyway_

I haven't been hacked.. yet. /me knocks on wood

The precautions I take are basic:

  - Use unique and secure credentials on each service I expose.
  - I only expose ports 80 and 443 to the public. 80 HTTP redirects to HTTPS/443
  - I keep my software updated (docker-compose pull)
  - Nightly backups to cloud storage and local disk
  - I "airgap" my home network from my hosting network. There is no shared hardware between them including firewalss/routers, switches, etc.

I'd like to believe the engineers running Google Photos or iCloud are spending a lot more time on keeping my photos secure and available than I would be willing to put into a server running in my basement.

In the case of a business hiring an MSP to manage something complex like firewalls, Active Directory, server patching, then sure it's reasonable to assume that if they made a mistake, the impact would be equivalent to you making the mistake yourself.

It's possible you need to tell whomever you are reporting to for these post-mortems, they should be outsourcing to reputable service providers in order to free up time and man-hours, not necessarily just to save financially. I suspect that is the real problem.

Maybe I'm too old (experienced) and cynical, but I always read that as "apps that are going to brick themselves". No thanks.

And there is actually imho no black and white answer. Take a current, very small freelance client of mine. I built them a homepage based on Kirby CMS. Hosted on uberspace.de. On the same shared server there is Matomo being hosted for basic stats.

Another client I was involved in went another way. They had their site built by a team of designers with webflow and are using Google Analytics.

In both cases the decision makes sense given the conditions and constraints of the respective projects.

Personally I would have not recommend to use webflow, but that was not my call to make. For GA I provided a pro/con evaluation and the client decided to go with GA (not my primary recommendation). I still think for his use case at the time a sensible decision.

You're still managing a server, but now you're paying through the nose to do it.

The costs just simply don't work out nicely to anyone who can afford to buy at even small scales.

A 4 cpu, 8gb ram machine will pretty commonly run you $50 a month, with less than 200gb storage. You're paying 600/year for a machine that I can build (with better specs) for ~400.

Not to mention that the machine you buy yourself will have a lifespan of 3 to 8 years.

So sure - once you factor in bandwidth, storage location, power - you're probably not going to save money in the first year. But by year 2 you are, and by year 4 you've saved a considerable sum.

We host out own servers, and the bulk of the time is ensuring that the power doesn't go out, that there is a backup internet connection, that the HDs are on RAID, that the server has a backup server available (and the router, and the switch, and the NICs), and that the management network is available, and that the location has proper security monitoring, and that the offsite backup happens nightly, and that we have an employee that knows how to do all of the above... All of that is time consuming and expensive.

...BUT, some people/some companies actually enjoy that sort of thing, in which case, it can work out financially - though often you're sacrificing one of the 9's in your 99.99% uptime/reliability.

The cost of purchasing a lower power SBC (x86, ARM) might be very quickly offset.

A RaspberryPi can handle a surprising amount, especially the 4/8GB models. The trick is using low resource software.

Honestly - Most cloud services are exorbitantly over-priced. There's a reason AWS is ~15% of amazon's total revenue, and Azure now pulls in more revenue than any other MS product.

I throw old machines into a micro-k8s cluster. It costs me literally pennies on the dollar for much better computing hardware compared to a vps.

Like a good edge router, redundant power supplies, RAID arrays, a backup mechanism, and a very good upload connection (ie 500mbit). By the time you setup all that, you may as well be using new hardware to make the investment worth it.

It results in a better experience for end-users because applications are actually sandboxed. This (mercifully) means that any security issues in the out-of-date applications does not become a cause for panic. The downside is that packaging those applications is not trivial.

Unfortunately their default for my raspberry pie didn't "just work" on the Saturday evening I tried it. It was my first foray with that raspberry pie, so installed a different server OS and spent the rest of the evening setting up a basic server for an HTML file and learning more about SSH. That was my experience as a non-IT engineer. I'd be interested in other people's experiences using yunohost (or sandstorm for that matter).

Maybe the solution isn't to make an idiot-proof stack of tech. Maybe we need a central repo of tutorials and how-tos so that any idiot could self host? Something better than the scattered YouTubes and blogs I remember seeing when I Googled after this.

But the general problem with those projects is, they all are packaging their own apps, and most of those have a very low number available. Some of thise apps are outdated, or are not well tested. It's quite strange that we have dozens of linux-distributions, each with thousand of packages, yet we have no good solution that actually works well enough.

You either have solutions which are hiding everything in a tanglement which is hard to understand, or you must do all the work yourself, or you live with the in-betweens which offer only a handful of apps. Maybe in another 20 years we have something workable on all levels...

imo the reproducability guarantees of docker aren't enough and domething like NixOS is needed.

Ultimately I also gave up and now have a combination of port forwarding, nat64, and 10+ socat proxies in my docker-compose file. (Specifically, intranet->container and container->intranet are ipv6; but container->container is still ipv4)

More generally, I now try to keep my docker host as stock as possible. Whenever I'm reaching for daemon.json I just catch myself, take a step back, and say "what's the stupid but easy way to get this working".