systemd → does a lot of things on modern Linux systems, amongst which is dealing with services that should autostart (think: both low-level stuff like Bluetooth or user-level stuff like a Dropbox client or a VPN or whatever).
Unit files → fairly simple text files that are used to define such stuff for systemd (usually in /etc/systemd/system and /usr/lib/systemd/system).
Package manager → essentially the same as an app store on a phone. It's how you install and update packages (packages could be a fully fledged graphical app or just a terminal command).
Webserver → what allows you to "run websites" on your own machine. For the simplest example, if you run `python -m http.server` in a terminal on a Unix-like system, congrats, you can now browse your files in a browser (127.0.0.1:8000). If you know your local IP, you can also open it from a phone and download stuff from your desktop, zero apps or cables or FTPs necessary.
So, to decipher that comment above: you usually don't have to worry about how things run automatically because that's usually pre-configured when you install them. In most simple self-hosting scenarios you just "install a website" on your spare laptop or whatever and you're good to go. That website usually serves traffic via a webserver on some port, and you access it via local network IP and a port (example: 192.168.1.100:8000).
Now if you go deeper and want to run multiple things simultaneously, each accessible via a domain instead of a port, accessible from outside of your home, properly backed up and with a valid HTTPS connection, and then you hear about this thing called Docker... well, from my experience, you're gonna wake up on a day like this and go to work as a sysadmin with 3 years of experience, basically writing YAML for a living.
So in conclusion, apart from some outliers like Plex.tv, I wouldn't call the process layperson-friendly, but hey, it might make your tinkering into a career.
It's a bit crazy that it even matters. Or that systemd comes up at all in a selfhosting convo.
I have friends that selfhost stuff on mac, windows, and linux. They are probably above average as far as tech goes but they are all 30 somethings in non-tech jobs, real-estate, finance, advertising, sales.
I field questions from time to time, but it's pretty rare. Never once got a question about an init system. On any os or distro.
These guys aren't writing init scripts, they are going through the apps documentation and typing 'systemctl start appName.service' and then moving on.
or starting it with docker or even one of the clever little web UIs that you can install that helps you install selfhosted apps.
I thing there's a part of us that wants to believe this shit matters to normal users but they just don't care. And if the service doesn't start, they file a bug upstream and the maintainer usually takes care of it.
To be honest, I think the reason systemd comes up in a self-hosting conversation at all is because
- Some people want to talk about how difficult things are, and come up with reasons to make things sound difficult,
- Some people have an axe to grind, regarding systemd.
The original poster brought up "workload scheduling" and while I've done plenty of that at work, I'm at a complete loss trying to guess why you would need workload scheduling for any self-hosting project.
I defiantly agree with you. I've never heard mac people sit around and talk about which init system it's running it's a complete non issue. It just doesn't matter to self-hosters and end users in any way shape or form.
Unit files → fairly simple text files that are used to define such stuff for systemd (usually in /etc/systemd/system and /usr/lib/systemd/system).
Package manager → essentially the same as an app store on a phone. It's how you install and update packages (packages could be a fully fledged graphical app or just a terminal command).
Webserver → what allows you to "run websites" on your own machine. For the simplest example, if you run `python -m http.server` in a terminal on a Unix-like system, congrats, you can now browse your files in a browser (127.0.0.1:8000). If you know your local IP, you can also open it from a phone and download stuff from your desktop, zero apps or cables or FTPs necessary.
So, to decipher that comment above: you usually don't have to worry about how things run automatically because that's usually pre-configured when you install them. In most simple self-hosting scenarios you just "install a website" on your spare laptop or whatever and you're good to go. That website usually serves traffic via a webserver on some port, and you access it via local network IP and a port (example: 192.168.1.100:8000).
Now if you go deeper and want to run multiple things simultaneously, each accessible via a domain instead of a port, accessible from outside of your home, properly backed up and with a valid HTTPS connection, and then you hear about this thing called Docker... well, from my experience, you're gonna wake up on a day like this and go to work as a sysadmin with 3 years of experience, basically writing YAML for a living.
So in conclusion, apart from some outliers like Plex.tv, I wouldn't call the process layperson-friendly, but hey, it might make your tinkering into a career.