6 ms·

systemd unit files are text files, not binary blobs. And it is much easier to grok a unit file than a 500 line init script.

waynesonfire 5y ago
At what cost? Thats not the enirety of systemds complexity curve. Your systemd unit file is backed by pages and pages of docs that must be comprehended to understand and hack on. Unix developers have all they need from the script. Furthermore, its all in context of existing unix concepts and thus your unix experiance is paying dividends.
- NikolaeVarius 5y ago
  How dare a system have "checks notes" have too much documentation describing how it works.
  - astrange 5y ago
    FreeBSD has a lot of documentation, which is something people like about it. I think it actually shows a problem, which is that BSD is designed for all your machines to be special snowflakes with individual names, edited config files, etc instead of being mass managed declaratively. So you need to know how to do everything because you’re the one doing it.
    - Datagenerator 5y ago
      Our research company hosts 15 PB of data on what we call Single System Imaged FreeBSD with ZFS. All systems pull the complete OS from one managed rsync repo during production hours. Doing this for ten years, never ever any problems. Config files are included using the hostname to differentiate between servers. Adding servers doesn't add manual labor, it's the borg type of setup which handles it all.
    - ybloviator 5y ago
      This is nonsense. Please educate yourself a bit on systems automation in general if you think this is the case.
      - astrange 5y ago
        Is there an automation for "before updating ports, you need to read every single entry in UPDATING in case one of them has a command you need to run after"? Why is there a chapter on custom kernels under "common tasks" that assumes you're going to have a C compiler and kernel source on your machine and want to installkernel on that same machine?
        deleted 5y ago
        [deleted]
- ybloviator 5y ago
  The unsaid thing here is Linux is largely not used by sysadmin/unix types. Devops has driven this bloat so that people new to the field can just not have to learn any fundamentals about the OS they're building their tools on. For rapid "move fast and break things" VC nonsense, this is a great match. For efficiency, correctness, and long-term maintainability and security, it's a nightmare.
- crazy_hombre 5y ago
  Now you're just exaggerating. Are you really saying spending 5-10 mins skimming through a couple of man pages is that hard? Are you saying that a lot of documentation is a bad thing? (I thought FreeBSD fans liked to harp about their handbook..) And besides, there are already hundreds of systemd unit files on your system that you can easily copy and make relevant changes for your own services. Not having to deal with finicky shell features is a major advantage IMO.
  - waynesonfire 5y ago
    I think the disconnect we're having is your inability to perceive complexity. And I don't blame you, it's not easy to quantify. I suggest you start with, Out of the Tar Pit by Ben Moseley. I'm not knocking on documentation, it's a vital property that I consider when adopting new technology. What I'm saying is that systemds documentation currency (if you accept my metaphor) is spent on covering its accidental complexity and it's voluminous. If you disagree with me, that's fine. This is just my experience as a linux user that's had to deal with systemd. If your claim is that systemd man pages are well written documentation then I think you're exaggerating and I'll wager you've relied on stackoverflow examples or tutorial blogs to solve your systemd issues--because I have. The reason for this is because the number of concepts and abstractions that you have to piece together to solve your problem is massive. But yeah, it's just a 5 line Unit file. I prefer strawberry kool-aid, thanks.
    - crazy_hombre 5y ago
      I genuinely don't see what's so complex about a service unit file. It's a simple INI file that has multiple sections that describes the service, tells what command to run and specifies any dependencies. It's literally the same thing that init scripts do except in a much more concise and efficient manner. And as I said before, there's a ton of systemd service unit files on any Linux system that you can take a look at and use as inspiration for your own services. Taking a little time to learn the ways of systemd is not a huge burdensome task like you're making it seem to be. I don't see why you think everyone should conflate systemd with complexity. And about the voluminous documentation, well man pages are supposed to be comprehensive and cover every single aspect of the tools being described. They're not there to just be an intro to systemd for new users and administrators. If you want something like that, look no further than the "systemd for Administrators" series of articles written by the systemd author himself. https://github.com/shibumi/systemd-for-administrators/blob/master/systemd-handbook.pdf https://github.com/shibumi/systemd-for-administrators/blob/m....
trasz 5y ago
But they only provide fixed functionality, while shell scripts allow for practically unlimited customization. As for 500 lines - take a look at proper rc scripts, eg the ones in FreeBSD. They are mostly declarative; it’s nothing like Linux’ sysv scripts, which were in some ways already obsolete when first introduced (runlevels? In ‘90s, seriously?)
- lordgroff 5y ago
  Yeah, this conversation seems a bit like people arguing past each other. But it's a result of the fact that the story on Linux was stuck for so long (e.g., sysvinit on Debian, Upstart with some sharp edged hacks on Ubuntu). Systemd as the solution seems to have sucked out all the air out of the room: either it's great and people are idiots, or it's the worst thing on the planet and people using it are sheep.
  - passthejoe 5y ago
    Yes. Exactly.
- crazy_hombre 5y ago
  If you need extra customization capabilities, just run a shell script via the ExecStart= parameter and boom, you have all the power of systemd and the shell combined.
  - Spivak 5y ago
    You can even do one better since systemd can natively run rc scripts. If you're on a systemd based distro peak at /etc/init.d. You can even manage services with /etc/init.d and the service command. The amount of effort systemd went through to make existing software work is genuinely heroic.
- matthewmacleod 5y ago
  But they only provide fixed functionality, while shell scripts allow for practically unlimited customization. This is the exact opposite of a good thing.
ybloviator 5y ago
If your BSD init script is 500 lines long, you've done something horribly wrong.

waynesonfire 5y ago

At what cost? Thats not the enirety of systemds complexity curve. Your systemd unit file is backed by pages and pages of docs that must be comprehended to understand and hack on. Unix developers have all they need from the script. Furthermore, its all in context of existing unix concepts and thus your unix experiance is paying dividends.

NikolaeVarius 5y ago
How dare a system have "checks notes" have too much documentation describing how it works.
- astrange 5y ago
  FreeBSD has a lot of documentation, which is something people like about it. I think it actually shows a problem, which is that BSD is designed for all your machines to be special snowflakes with individual names, edited config files, etc instead of being mass managed declaratively. So you need to know how to do everything because you’re the one doing it.
  - Datagenerator 5y ago
    Our research company hosts 15 PB of data on what we call Single System Imaged FreeBSD with ZFS. All systems pull the complete OS from one managed rsync repo during production hours. Doing this for ten years, never ever any problems. Config files are included using the hostname to differentiate between servers. Adding servers doesn't add manual labor, it's the borg type of setup which handles it all.
  - ybloviator 5y ago
    This is nonsense. Please educate yourself a bit on systems automation in general if you think this is the case.
    - astrange 5y ago
      Is there an automation for "before updating ports, you need to read every single entry in UPDATING in case one of them has a command you need to run after"? Why is there a chapter on custom kernels under "common tasks" that assumes you're going to have a C compiler and kernel source on your machine and want to installkernel on that same machine?
      - deleted 5y ago
        [deleted]
ybloviator 5y ago
The unsaid thing here is Linux is largely not used by sysadmin/unix types. Devops has driven this bloat so that people new to the field can just not have to learn any fundamentals about the OS they're building their tools on. For rapid "move fast and break things" VC nonsense, this is a great match. For efficiency, correctness, and long-term maintainability and security, it's a nightmare.
crazy_hombre 5y ago
Now you're just exaggerating. Are you really saying spending 5-10 mins skimming through a couple of man pages is that hard? Are you saying that a lot of documentation is a bad thing? (I thought FreeBSD fans liked to harp about their handbook..) And besides, there are already hundreds of systemd unit files on your system that you can easily copy and make relevant changes for your own services. Not having to deal with finicky shell features is a major advantage IMO.
- waynesonfire 5y ago
  I think the disconnect we're having is your inability to perceive complexity. And I don't blame you, it's not easy to quantify. I suggest you start with, Out of the Tar Pit by Ben Moseley. I'm not knocking on documentation, it's a vital property that I consider when adopting new technology. What I'm saying is that systemds documentation currency (if you accept my metaphor) is spent on covering its accidental complexity and it's voluminous. If you disagree with me, that's fine. This is just my experience as a linux user that's had to deal with systemd. If your claim is that systemd man pages are well written documentation then I think you're exaggerating and I'll wager you've relied on stackoverflow examples or tutorial blogs to solve your systemd issues--because I have. The reason for this is because the number of concepts and abstractions that you have to piece together to solve your problem is massive. But yeah, it's just a 5 line Unit file. I prefer strawberry kool-aid, thanks.
  - crazy_hombre 5y ago
    I genuinely don't see what's so complex about a service unit file. It's a simple INI file that has multiple sections that describes the service, tells what command to run and specifies any dependencies. It's literally the same thing that init scripts do except in a much more concise and efficient manner. And as I said before, there's a ton of systemd service unit files on any Linux system that you can take a look at and use as inspiration for your own services. Taking a little time to learn the ways of systemd is not a huge burdensome task like you're making it seem to be. I don't see why you think everyone should conflate systemd with complexity. And about the voluminous documentation, well man pages are supposed to be comprehensive and cover every single aspect of the tools being described. They're not there to just be an intro to systemd for new users and administrators. If you want something like that, look no further than the "systemd for Administrators" series of articles written by the systemd author himself. https://github.com/shibumi/systemd-for-administrators/blob/master/systemd-handbook.pdf https://github.com/shibumi/systemd-for-administrators/blob/m....

trasz 5y ago

But they only provide fixed functionality, while shell scripts allow for practically unlimited customization. As for 500 lines - take a look at proper rc scripts, eg the ones in FreeBSD. They are mostly declarative; it’s nothing like Linux’ sysv scripts, which were in some ways already obsolete when first introduced (runlevels? In ‘90s, seriously?)

lordgroff 5y ago
Yeah, this conversation seems a bit like people arguing past each other. But it's a result of the fact that the story on Linux was stuck for so long (e.g., sysvinit on Debian, Upstart with some sharp edged hacks on Ubuntu). Systemd as the solution seems to have sucked out all the air out of the room: either it's great and people are idiots, or it's the worst thing on the planet and people using it are sheep.
- passthejoe 5y ago
  Yes. Exactly.
crazy_hombre 5y ago
If you need extra customization capabilities, just run a shell script via the ExecStart= parameter and boom, you have all the power of systemd and the shell combined.
- Spivak 5y ago
  You can even do one better since systemd can natively run rc scripts. If you're on a systemd based distro peak at /etc/init.d. You can even manage services with /etc/init.d and the service command. The amount of effort systemd went through to make existing software work is genuinely heroic.
matthewmacleod 5y ago
But they only provide fixed functionality, while shell scripts allow for practically unlimited customization. This is the exact opposite of a good thing.

ybloviator 5y ago

If your BSD init script is 500 lines long, you've done something horribly wrong.