12 ms·

> SystemD is complicated for a layperson Is it? It has clean and logical abstractions, and consistency. Services depending in each other isn‘t complex or diffi

> SystemD is complicated for a layperson Is it? It has clean and logical abstractions, and consistency. Services depending in each other isn‘t complex or difficult to understand. I suspect that a nice GUI would make systemd quite usable for non-expert users. BTW: It‘s called ”systemd“: > Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. [0] [0]: https://www.freedesktop.org/wiki/Software/systemd/#spelling https://www.freedesktop.org/wiki/Software/systemd/#spelling

kodah 5y ago
> Is it? It has clean and logical abstractions, and consistency. Services depending in each other isn‘t complex or difficult to understand. 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.
- nobody9999 5y ago
  >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. In comparison to system V initd startup files, systemd unit files are, arguably, less complicated. I'd say the "complexity" of systemd unit files is mostly irrelevant to end users. For a relatively non-technical user, implementing whatever application/service one might want to use should be as simple as installing the relevant package(s) and dependency(ies) via existing, well managed package management systems. That said, too many developers encourage self-hosting, but don't provide appropriate packages and defaults for most popular distributions. If developers spent just a little more time creating buildable packages (supporting the creation of binary and source .rpm, .deb, etc. packages) with sane defaults/startup files could make the inclusion of such apps into the standard/extras repositories of a broad swathe of Linux distributions much simpler and, for the non-technical user, easy to install and configure. Matrix Synapse[0] and Diaspora[1] both come to mind in this respect. Installation and configuration of these platforms requires the installation of several software development frameworks and separate (from the standard system package managers, e.g., DNF, apt, dpkg, etc.) package management tools for the language dependencies. Requiring installation of software dev environments and building the software/databases/admin tools for such "self-hosted" solutions just confuses non-technical users. As a professional with decades of Unix/Linux implementation and management experience, I find implementing such platforms simple enough. Just read the docs, install the dependencies and compile/install/configure the software. For a non-technical person, that's likely a non-starter unless there's a UI that will do so automagically. Fortunately, there is such a UI for most Linux/Unix distributions -- it's called the system package manager. Unless and until developers provide distribution developers/maintainers with appropriate packageable sources (or even separate repositories with binaries!) to be added to the default repositories, self hosting many apps will only be the purview of technical users. This annoys me. A lot. Not because I, personally, mind a complicated set up process for such applications, but because it limits the ability of both Linux/Unix distributions and self-hosted applications/platforms to be used more broadly by non-technical users. Especially with tools like Diaspora, Matrix/Synapse and others which have the potential to overturn centralized hell holes like Twitter, Facebook, Instagram, WhatsApp, etc. It's been at least five years since I first installed a Diaspora pod and a year since I installed Synapse and a STUN server. In both cases, had I not been a long-time user/manager/implementor of Unix/Linux and associated sw dev environments, the install would have been nightmarish. For both platforms, installation pretty much requires knowledge of software development tools and practices, as well as more than a passing familiarity with Unix/Linux shells and environments. I can't imagine my 64 year-old sister in-law (a reasonably well educated and smart cookie with decent problem-solving skills) taking the time to learn how to use git, clang/gxx or even docker to install this "self hostable" stuff. That should be the target audience for such self hosted tools, not devs and other technical people. Taking the time to make one's application/platform easily installable/configurable (and building from git repos and/or Docker-compose aren't "easy" for non-technical folks) by non-technical end users could make a huge difference in this space. [0] https://matrix.org/docs/projects/server/synapse/ https://matrix.org/docs/projects/server/synapse/ [1] https://en.wikipedia.org/wiki/Diaspora_(social_network) https://en.wikipedia.org/wiki/Diaspora_(social_network)
  - hsn915 5y ago
    I'd go a step further: programs aimed to make self-hosting easy should not even need a package manager. They should be self contained (statically linked) binaries. Luckily we have Go which makes this very easy to achieve, and to make things better, Go is designed for web servers. I believe we've had this ability for almost a decade, and still no one is harnessing it to make self-hosting easy and reliable. Further more, they should require absolultely zero configuration to get up and running. We've had SQLite for many years now, so it's easy to make a webserver that does not require a separate sql server to be installed and configured in order to get going. (There are also non-sql embedded data storage engines, many of them written in pure Go, eliminating the CGO problem). Ideally the user will download a program for their own operating system (say, windows). They will run this program, provide it with the ip and root password of their linux server which they rented from some provider, and this program will then upload the actual server program to the host machine and launch it.
    - Seirdy 5y ago
      Echoing this. All the services on my servers (Web, Gemini, Matrix, Fediverse servers and a CSP violations collector) are statically-linked binaries running in sandboxed chroots, with no access to the outside filesystem except a subdir of my data volume mounted into the chroot. Privs are limited to a defined list of acceptable syscalls and other limitations. I'm currently working on enforcing the use of this setup with SELinux policies and transitioning my OCSP fetching and session ticket key rotating scripts to statically linked binaries so I can just stick to one template shared across all services. It would have been much harder to pull this off if these services required large interpreters, adjacent daemons running, and complex orchestration. Given the amount of time I have, I might have just skipped the SELinux step.
      - BarbaPeru 5y ago
        I hope you are not saying this is a layperson doable setup. ;-)
      - hsn915 5y ago
        The reason I want things to be self contained is not for someone else to use it as a base upon which to build additional layers of complexity. That defeats the whole point.
- ndiddy 5y ago
  Laypeople don't know that systemd exists. They will install a webserver or something and the package manager will automatically install and enable its unit file.
  - hotpotamus 5y ago
    You know, nothing is really ever that simple and this comment makes me realize that. You actually hit on a philosophical difference in package managers lol. Ubuntu (not sure about Debian) will install, enable, and start a package, But Red Hat only installs it, because they expect you to configure the service first.
    - ncphil 5y ago
      Which 90% of the time makes sense because if you want anything more than the barebones default config (which you usually do), that's best done before everything gets spun up. But I've worked with Ubuntu (and Debian) long enough that I now take for granted that some services are going to have to be downed for reconfig almost immediately after installation. The "auto start after install" practice rarely makes much difference in the final result. After over 25 years as a sysadmin I do wonder how non-experts navigate some of this stuff, what with the often incomplete doc and horribly uninformed (or just plain reckless) forum posts they have to work with. The best place to start is still æLeen Frisch's Essential System Administration (whose 1st ed is where I learned the sysadmin craft), but there really isn't much beyond it (unless you go the BSD route and so have the FreeBSD Handbook to lean on).
    - ddaalluu2 5y ago
      That is actually not true for the most part. RHEL-based distros have a vanilla config file, where Ubuntu yes does make some extra efforts to configure the packages in a sensible manner.
  - Aeolun 5y ago
    Hence I have never cared about the difference. As long as the package installs and the service is enabled.
  - 5y ago
- lnxg33k1 5y ago
  I think it has come the time where the society starts to advance without caring about laypeople, if some folks can learn it, if there is documentation, then we can just go on without caring about who doesn't know how to use it, because that's fixable. And I speak considering the German government who had to pull back from Linux because employee didn't know how to use it Let's start treating tech as the world treats everything else: Ignorance is not a justification
  - prox 5y ago
    It is about expendable time. I mean it might take you a few hours or so do it, or even less. People working in other sectors, maybe with a family when they come home, do not have that skill or luxury. And speaking from experience, documentation is often greatly lacking. For example just today I had to thumb down a couple of google docs because it was riddled with inconsistencies and lacking crucial information. And that’s a company with near infinite money. And its like that for most software, with great docs an exception rather than a rule.
    - lnxg33k1 5y ago
      I don't agree with you, only for the fact that right now, in this age computers are everywhere, everything is digital, it is not luxury to learn how things work, it's survival, it's not expendable time, it's professional time
      - IggleSniggle 5y ago
        You could say the same thing about any number of fundamental disciplines: “chemistry is survival,” “roof making is survival” “SQL is survival.” The truth is, there’s only so much time, and we each must specialize. Software that decreases the need for broad reaching high-specialization is a public good, and software that increases the need for specialized knowledge across all economic activity is hurting productivity, whatever the bean counters may say.
      - asoneth 5y ago
        I have various friends who have made similar statements about food (everyone should cook meals for themselves), cars (everyone should do their own basic repairs and maintenance), homes (everyone should do their own basic home maintenance), keyboards (everyone should do basic soldering and learn a non-qwerty layout), accounting (everyone should have a budget and do their own taxes), gardening, fitness, investing, education, etc. The number of people who can learn all of the skills that someone in the world considers essential is small. The number of people who can do all those things while having a job, kids, and a working partner is smaller still. The rest of us have to focus on a proper subset. For me, every minute I waste learning how to configure my server is a minute I could have been playing Legos with my kids or riding my bike or sleeping.
- fps_doug 5y ago
  I think this discussion thread is basically people looking at this in different contexts. A lot of the replies seem to interpret your post as saying "systemd is more complicated than sysvinit was" which is most definitely not what you meant regarding your further replies in this thread. You seem to say "even systemd is too complicated for the layperson". I somewhat agree, if we assume someone totally not dealing with tech in any way on a daily basis, except for typical Office work. But the "in-betweeners"? They totally could. Like, not even Linux users, but curious tinkerers that fiddle aound with .ini files and registry settings to tweak their machines; do overclocking? They totally have what it takes to chew through a tutorial that tells you how to set up a Linux VPS with a couple services running. For the layperson that's a bus driver by day, not so much, most definitely, but I think no matter how simple you make setting this up, just having to maintain this and having to do something when the setup eventually has some unexpected bug a few years down the line is just too much.
  - jethro_tell 5y ago
    To be fair, a bus driver probably isn't writing a self-hosted service anyway. So if there is an issue with the service init 3 years later, they will probably file a bug and let the maintainer handle it. And they wouldn't be parsing a bash script for a sysV-init if that broke either? SysV-init was to complex for the layman as well. Because gracefully starting and stopping system services with their dependency chains is generally too complex for the layman as well. There's this strange idea that laymen self-hosters are doing all this stuff and the choice of init system matters in the lease. They were going to run the command to start the service blindly regardless of which init system it was and if it breaks, they aren't going to really troubleshoot either one.
    - fps_doug 5y ago
      Sure, the bus driver was supposed to represent the other extreme. In reality, they probably wouldn't care no matter how simple the setup is. But the at-least-somewhat-curious non-tech person has probably better chances finding a problem with a systemd service than a sysvinit script, even if they just open a ticket in the end. The info they can provide is more likely to be useful with systemd, I'd argue.
GrayShade 5y ago
I swear, writing it as SystemD isa shibboleth of systemd haters.
- kodah 5y ago
  For the record, I actually like and use it. I'm just at work and didn't put much thought on how to spell it. I also didn't really expect someone to care that much in a general, high-level discussion.
- cozzyd 5y ago
  they are all in favor of SystemE
  - bqmjjx0kac 5y ago
    More like SystemSh
    - cozzyd 5y ago
      SystemŞ?
spiffytech 5y ago
Technologists have a very skewed idea of what's complicated vs easy with computers. Things we think are absolutely trivial are often insurmountable hurdles for laypeople. (This can, of course, happen if you put a technologist outside their element, too)
teekert 5y ago
What lay person does anything with systemd though? I have all my services in a docker-compose.yaml... Sure, I remember the days before systemd, I remember upstart, Gentoo's rc.conf. I still think it's useful I can find my way trough the internals of a Linux box, but for me all that stuff is far in the past. This is how it goes nowadays: Install the system in 20 min, clone the infra as code, put the data back, start the infrastructure... Where does the init system still play a role?
0xdeadb00f 5y ago
I'm certainly not a layperson, but systemd frequently confuses me. 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?
- bmn__ 5y ago
  > it gets overwritten by package updates This doesn't happen. The package manager installs the new configuration under a different name so that you do not lose your changes and can merge them easily.
  - johnny22 5y ago
    what they are saying is that they edited the file in /usr/lib , which definitely would get overwritten. You're supossed to copy it into /etc/systemd/ for the appropriate service type.
    - v_p_n_p_v 5y ago
      I think you all proved the point that this system is too complicated for anyone outside of a small group of professional IT people.
      - lmns 5y ago
        Are you implying that getting init script customisations overwritten by package managers isn't a problem with non-systemd init managers? I have lost track how often that happened with sysvinit, because the "logic" how to treat customisations was usually handled by the package manager and they messed it up regularly. systemd has a standard way to handle customisations. As long as you put everything you do in /etc/systemd/system, everything is fine. It's simple and works across distributions.
zepearl 5y ago
> Services depending in each other isn‘t complex or difficult to understand. 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.
hsn915 5y ago
Comments like yours are a great example of why Linux has a hard time being user friendly. You take something that's deeply technical but easy to understand for yourself, and somehow generalize it to everyone. "If it's easy for me, it is easy for everyone", without noticing that perhaps your expertise plays a big role in making it easy. 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).
- klodolph 5y ago
  Systemd is easy compared to init scripts. Maybe that’s the comparison point. I know that’s my comparison point, since I wrangled init scripts for a couple decades before systemd, and when systemd came out, suddenly it felt a million times easier to run services. > 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. I don’t think that’s a salvageable notion of “reliability”. I could bork Mac OS or Windows easily enough by editing text files, if I really wanted to.
takinola 5y ago
If you know what systemd is, you are, by definition, not a layperson.
- Hendrikto 5y ago
  End users would not need to know. They could just click the activate button in a GUI.
bavila 5y ago
> It has clean and logical abstractions, and consistency. Sorry, but an actual layperson would already be lost upon reaching the word "abstraction".
- Hendrikto 5y ago
  I am talking to technical people here. You would not expose that terminology to end users.
vineyardmike 5y ago
If someone says it’s complicated, then yes it’s complicated. It may not be complicated for you, but by definition someone finding it complicated makes it complicated.
rtpg 5y ago
I loved using LingonX on Mac, one of the things I'd really love to do is make that but for systemd stuff. 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).
friendzis 5y ago
> Services depending in each other isn‘t complex or difficult to understand. 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.

kodah 5y ago

> Is it? It has clean and logical abstractions, and consistency. Services depending in each other isn‘t complex or difficult to understand. 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.

nobody9999 5y ago
>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. In comparison to system V initd startup files, systemd unit files are, arguably, less complicated. I'd say the "complexity" of systemd unit files is mostly irrelevant to end users. For a relatively non-technical user, implementing whatever application/service one might want to use should be as simple as installing the relevant package(s) and dependency(ies) via existing, well managed package management systems. That said, too many developers encourage self-hosting, but don't provide appropriate packages and defaults for most popular distributions. If developers spent just a little more time creating buildable packages (supporting the creation of binary and source .rpm, .deb, etc. packages) with sane defaults/startup files could make the inclusion of such apps into the standard/extras repositories of a broad swathe of Linux distributions much simpler and, for the non-technical user, easy to install and configure. Matrix Synapse[0] and Diaspora[1] both come to mind in this respect. Installation and configuration of these platforms requires the installation of several software development frameworks and separate (from the standard system package managers, e.g., DNF, apt, dpkg, etc.) package management tools for the language dependencies. Requiring installation of software dev environments and building the software/databases/admin tools for such "self-hosted" solutions just confuses non-technical users. As a professional with decades of Unix/Linux implementation and management experience, I find implementing such platforms simple enough. Just read the docs, install the dependencies and compile/install/configure the software. For a non-technical person, that's likely a non-starter unless there's a UI that will do so automagically. Fortunately, there is such a UI for most Linux/Unix distributions -- it's called the system package manager. Unless and until developers provide distribution developers/maintainers with appropriate packageable sources (or even separate repositories with binaries!) to be added to the default repositories, self hosting many apps will only be the purview of technical users. This annoys me. A lot. Not because I, personally, mind a complicated set up process for such applications, but because it limits the ability of both Linux/Unix distributions and self-hosted applications/platforms to be used more broadly by non-technical users. Especially with tools like Diaspora, Matrix/Synapse and others which have the potential to overturn centralized hell holes like Twitter, Facebook, Instagram, WhatsApp, etc. It's been at least five years since I first installed a Diaspora pod and a year since I installed Synapse and a STUN server. In both cases, had I not been a long-time user/manager/implementor of Unix/Linux and associated sw dev environments, the install would have been nightmarish. For both platforms, installation pretty much requires knowledge of software development tools and practices, as well as more than a passing familiarity with Unix/Linux shells and environments. I can't imagine my 64 year-old sister in-law (a reasonably well educated and smart cookie with decent problem-solving skills) taking the time to learn how to use git, clang/gxx or even docker to install this "self hostable" stuff. That should be the target audience for such self hosted tools, not devs and other technical people. Taking the time to make one's application/platform easily installable/configurable (and building from git repos and/or Docker-compose aren't "easy" for non-technical folks) by non-technical end users could make a huge difference in this space. [0] https://matrix.org/docs/projects/server/synapse/ https://matrix.org/docs/projects/server/synapse/ [1] https://en.wikipedia.org/wiki/Diaspora_(social_network) https://en.wikipedia.org/wiki/Diaspora_(social_network)
- hsn915 5y ago
  I'd go a step further: programs aimed to make self-hosting easy should not even need a package manager. They should be self contained (statically linked) binaries. Luckily we have Go which makes this very easy to achieve, and to make things better, Go is designed for web servers. I believe we've had this ability for almost a decade, and still no one is harnessing it to make self-hosting easy and reliable. Further more, they should require absolultely zero configuration to get up and running. We've had SQLite for many years now, so it's easy to make a webserver that does not require a separate sql server to be installed and configured in order to get going. (There are also non-sql embedded data storage engines, many of them written in pure Go, eliminating the CGO problem). Ideally the user will download a program for their own operating system (say, windows). They will run this program, provide it with the ip and root password of their linux server which they rented from some provider, and this program will then upload the actual server program to the host machine and launch it.
  - Seirdy 5y ago
    Echoing this. All the services on my servers (Web, Gemini, Matrix, Fediverse servers and a CSP violations collector) are statically-linked binaries running in sandboxed chroots, with no access to the outside filesystem except a subdir of my data volume mounted into the chroot. Privs are limited to a defined list of acceptable syscalls and other limitations. I'm currently working on enforcing the use of this setup with SELinux policies and transitioning my OCSP fetching and session ticket key rotating scripts to statically linked binaries so I can just stick to one template shared across all services. It would have been much harder to pull this off if these services required large interpreters, adjacent daemons running, and complex orchestration. Given the amount of time I have, I might have just skipped the SELinux step.
    - BarbaPeru 5y ago
      I hope you are not saying this is a layperson doable setup. ;-)
    - hsn915 5y ago
      The reason I want things to be self contained is not for someone else to use it as a base upon which to build additional layers of complexity. That defeats the whole point.
ndiddy 5y ago
Laypeople don't know that systemd exists. They will install a webserver or something and the package manager will automatically install and enable its unit file.
- hotpotamus 5y ago
  You know, nothing is really ever that simple and this comment makes me realize that. You actually hit on a philosophical difference in package managers lol. Ubuntu (not sure about Debian) will install, enable, and start a package, But Red Hat only installs it, because they expect you to configure the service first.
  - ncphil 5y ago
    Which 90% of the time makes sense because if you want anything more than the barebones default config (which you usually do), that's best done before everything gets spun up. But I've worked with Ubuntu (and Debian) long enough that I now take for granted that some services are going to have to be downed for reconfig almost immediately after installation. The "auto start after install" practice rarely makes much difference in the final result. After over 25 years as a sysadmin I do wonder how non-experts navigate some of this stuff, what with the often incomplete doc and horribly uninformed (or just plain reckless) forum posts they have to work with. The best place to start is still æLeen Frisch's Essential System Administration (whose 1st ed is where I learned the sysadmin craft), but there really isn't much beyond it (unless you go the BSD route and so have the FreeBSD Handbook to lean on).
  - ddaalluu2 5y ago
    That is actually not true for the most part. RHEL-based distros have a vanilla config file, where Ubuntu yes does make some extra efforts to configure the packages in a sensible manner.
- Aeolun 5y ago
  Hence I have never cared about the difference. As long as the package installs and the service is enabled.
- 5y ago
lnxg33k1 5y ago
I think it has come the time where the society starts to advance without caring about laypeople, if some folks can learn it, if there is documentation, then we can just go on without caring about who doesn't know how to use it, because that's fixable. And I speak considering the German government who had to pull back from Linux because employee didn't know how to use it Let's start treating tech as the world treats everything else: Ignorance is not a justification
- prox 5y ago
  It is about expendable time. I mean it might take you a few hours or so do it, or even less. People working in other sectors, maybe with a family when they come home, do not have that skill or luxury. And speaking from experience, documentation is often greatly lacking. For example just today I had to thumb down a couple of google docs because it was riddled with inconsistencies and lacking crucial information. And that’s a company with near infinite money. And its like that for most software, with great docs an exception rather than a rule.
  - lnxg33k1 5y ago
    I don't agree with you, only for the fact that right now, in this age computers are everywhere, everything is digital, it is not luxury to learn how things work, it's survival, it's not expendable time, it's professional time
    - IggleSniggle 5y ago
      You could say the same thing about any number of fundamental disciplines: “chemistry is survival,” “roof making is survival” “SQL is survival.” The truth is, there’s only so much time, and we each must specialize. Software that decreases the need for broad reaching high-specialization is a public good, and software that increases the need for specialized knowledge across all economic activity is hurting productivity, whatever the bean counters may say.
    - asoneth 5y ago
      I have various friends who have made similar statements about food (everyone should cook meals for themselves), cars (everyone should do their own basic repairs and maintenance), homes (everyone should do their own basic home maintenance), keyboards (everyone should do basic soldering and learn a non-qwerty layout), accounting (everyone should have a budget and do their own taxes), gardening, fitness, investing, education, etc. The number of people who can learn all of the skills that someone in the world considers essential is small. The number of people who can do all those things while having a job, kids, and a working partner is smaller still. The rest of us have to focus on a proper subset. For me, every minute I waste learning how to configure my server is a minute I could have been playing Legos with my kids or riding my bike or sleeping.
fps_doug 5y ago
I think this discussion thread is basically people looking at this in different contexts. A lot of the replies seem to interpret your post as saying "systemd is more complicated than sysvinit was" which is most definitely not what you meant regarding your further replies in this thread. You seem to say "even systemd is too complicated for the layperson". I somewhat agree, if we assume someone totally not dealing with tech in any way on a daily basis, except for typical Office work. But the "in-betweeners"? They totally could. Like, not even Linux users, but curious tinkerers that fiddle aound with .ini files and registry settings to tweak their machines; do overclocking? They totally have what it takes to chew through a tutorial that tells you how to set up a Linux VPS with a couple services running. For the layperson that's a bus driver by day, not so much, most definitely, but I think no matter how simple you make setting this up, just having to maintain this and having to do something when the setup eventually has some unexpected bug a few years down the line is just too much.
- jethro_tell 5y ago
  To be fair, a bus driver probably isn't writing a self-hosted service anyway. So if there is an issue with the service init 3 years later, they will probably file a bug and let the maintainer handle it. And they wouldn't be parsing a bash script for a sysV-init if that broke either? SysV-init was to complex for the layman as well. Because gracefully starting and stopping system services with their dependency chains is generally too complex for the layman as well. There's this strange idea that laymen self-hosters are doing all this stuff and the choice of init system matters in the lease. They were going to run the command to start the service blindly regardless of which init system it was and if it breaks, they aren't going to really troubleshoot either one.
  - fps_doug 5y ago
    Sure, the bus driver was supposed to represent the other extreme. In reality, they probably wouldn't care no matter how simple the setup is. But the at-least-somewhat-curious non-tech person has probably better chances finding a problem with a systemd service than a sysvinit script, even if they just open a ticket in the end. The info they can provide is more likely to be useful with systemd, I'd argue.

GrayShade 5y ago

I swear, writing it as SystemD isa shibboleth of systemd haters.

kodah 5y ago
For the record, I actually like and use it. I'm just at work and didn't put much thought on how to spell it. I also didn't really expect someone to care that much in a general, high-level discussion.
cozzyd 5y ago
they are all in favor of SystemE
- bqmjjx0kac 5y ago
  More like SystemSh
  - cozzyd 5y ago
    SystemŞ?

spiffytech 5y ago

Technologists have a very skewed idea of what's complicated vs easy with computers. Things we think are absolutely trivial are often insurmountable hurdles for laypeople. (This can, of course, happen if you put a technologist outside their element, too)

teekert 5y ago

What lay person does anything with systemd though? I have all my services in a docker-compose.yaml... Sure, I remember the days before systemd, I remember upstart, Gentoo's rc.conf. I still think it's useful I can find my way trough the internals of a Linux box, but for me all that stuff is far in the past. This is how it goes nowadays: Install the system in 20 min, clone the infra as code, put the data back, start the infrastructure... Where does the init system still play a role?

0xdeadb00f 5y ago

I'm certainly not a layperson, but systemd frequently confuses me. 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?

bmn__ 5y ago
> it gets overwritten by package updates This doesn't happen. The package manager installs the new configuration under a different name so that you do not lose your changes and can merge them easily.
- johnny22 5y ago
  what they are saying is that they edited the file in /usr/lib , which definitely would get overwritten. You're supossed to copy it into /etc/systemd/ for the appropriate service type.
  - v_p_n_p_v 5y ago
    I think you all proved the point that this system is too complicated for anyone outside of a small group of professional IT people.
    - lmns 5y ago
      Are you implying that getting init script customisations overwritten by package managers isn't a problem with non-systemd init managers? I have lost track how often that happened with sysvinit, because the "logic" how to treat customisations was usually handled by the package manager and they messed it up regularly. systemd has a standard way to handle customisations. As long as you put everything you do in /etc/systemd/system, everything is fine. It's simple and works across distributions.

zepearl 5y ago

> Services depending in each other isn‘t complex or difficult to understand. 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.

hsn915 5y ago

Comments like yours are a great example of why Linux has a hard time being user friendly. You take something that's deeply technical but easy to understand for yourself, and somehow generalize it to everyone. "If it's easy for me, it is easy for everyone", without noticing that perhaps your expertise plays a big role in making it easy. 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).

klodolph 5y ago
Systemd is easy compared to init scripts. Maybe that’s the comparison point. I know that’s my comparison point, since I wrangled init scripts for a couple decades before systemd, and when systemd came out, suddenly it felt a million times easier to run services. > 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. I don’t think that’s a salvageable notion of “reliability”. I could bork Mac OS or Windows easily enough by editing text files, if I really wanted to.

takinola 5y ago

If you know what systemd is, you are, by definition, not a layperson.

Hendrikto 5y ago
End users would not need to know. They could just click the activate button in a GUI.

bavila 5y ago

> It has clean and logical abstractions, and consistency. Sorry, but an actual layperson would already be lost upon reaching the word "abstraction".

Hendrikto 5y ago
I am talking to technical people here. You would not expose that terminology to end users.

vineyardmike 5y ago

If someone says it’s complicated, then yes it’s complicated. It may not be complicated for you, but by definition someone finding it complicated makes it complicated.

rtpg 5y ago

I loved using LingonX on Mac, one of the things I'd really love to do is make that but for systemd stuff. 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).

friendzis 5y ago

> Services depending in each other isn‘t complex or difficult to understand. 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.