8 ms·

Portable systemd services

75 points by cheiVia0 10y ago

dkarapetyan 10y ago
Isn't ubuntu snap already doing all this? The competing standards I don't think help in this regard. Now to make a "portable service" I will need to make sure whatever I do can be used as a snap and a systemd portable service. Why is it so hard to settle on a standard when it comes to this stuff? The same confusion exists when it comes to rpm and deb packaging formats. At the end of the day both do the same thing and yet to deliver software to redhat and debian systems you have to double your packaging effort.
- mateuszf 10y ago
  Because systemd is more popular and cross distros.
- derefr 10y ago
  The RPM/Deb split, at this point, isn't so much about packaging formats, as it is about dependency graphs. Even if the two distro "families" of Redhat and Debian shared a common packaging format, a package would still have to be built—or at least specified—twice for them, because each family would still have its own set of deps that are factored out in incompatible ways to the deps of the other family. (For example, in Debian land, if your package wants to declare a dependency on OpenSSL, that might mean a package dependency on any of 'openssl', 'libssl1.0.0', 'libssl1.0.0-dbg', or 'libssl-dev'. RHEL et al do not have an isomorphic set of packages that these dependencies could be mapped to.)
  - vbernat 10y ago
    This is already the case for SuSE and Redhat. Package names are different, RPM macros are different. Doing a package that works for both is gruesome. Also, at the time of SysV, you had to use two different init scripts.
- wmf 10y ago
  Presumably portable services will work on Ubuntu so you could skip the snap. There will never be agreement on standards that are used as strategic weapons in developer mindshare turf wars between companies using monopoly-or-die-trying business models.
- niemeyer 10y ago
  Such competing efforts are actually a form of non-voluntary collaboration. rpm and deb (and apt, yum, synaptic, ...) have significantly evolved together along the years, looking at each other. This happens all the time, and is happening again here.. the snap format and snapd evolve based on previous knowledge, and it's no surprise that the linked LWN article seems quite inspired by snaps (I'm biased as a snapd designer/developer). Let it come.. we'll be watching and picking up the good ideas too. And working hard to make sure snaps continue to win on merit, rather than lack of competition.
m3rc 10y ago
I used to spend time arguing with people on the internet about how systemd was an actually very useful tool but I never changed any minds and didn't help myself any. Now I just wait and watch for new helpful things it does to show up and I live a much happier life.
- throwaway98237 10y ago
  Not trolling. Not at all.
- badsock 10y ago
  I almost think there should be a divorce. Call it systemdOS and be done with it. At that point every service it subsumes will be seen as a step closer to the obvious end-goal rather than a point of contention. And the other OS can be something like the Gnome2 fork MATE. It's not a technical thing, it's cultural. The two sides are playing tug-of-war with the same OS, and systemd's winning, but maybe it would be better to have a positive culture around the changes they're making instead of always having people dragging on the rope. Some forks have been good in the past - EGCS/GCC for example.
  - SwellJoe 10y ago
    > Call it systemdOS and be done with it. Every major Linux distro has chosen systemd as their future. I think that means whoever wants something different needs to change their name, rather than every major Linux distro changing theirs. Just as the Gnome 2 fans chose a new name for their future based on that lineage.
    - badsock 10y ago
      Fair enough. It just seems like it might be useful to have a symbolic split of some kind, where people choose a camp instead of trying to pull in both directions. Naming can do that.
      - SwellJoe 10y ago
AceJohnny2 10y ago
Tangentially, glad to see Jon finally put up a signup banner for non-subscribers :) (see discussion 3 months ago: https://news.ycombinator.com/item?id=12224408 https://news.ycombinator.com/item?id=12224408)
Karlozkiller 10y ago
This should surely stop the critics from saying systemd is doing too much and is bloatful. No, but seriously I understand the reason why you'd want this, but what stops systemd from being divided into smaller modules? Like the Linux I'm used to.
- SwellJoe 10y ago
  systemd is modular, and is divided into many components. There are several dozen binaries in a systemd package. Where do you believe the lines should be drawn differently?
  - Karlozkiller 10y ago
    What I did mean was that at least from my understanding of it, you get systemd, and then you have all of systemd, unable to replace one part of systemd with some other package to handle that specific task. One of the features I would like to see for example is less binary logging and this journalctl madness. Binary logging makes it harder for me to plug in other programs to parse the logs or whatever I want to do. So what I would like to see is modularity in the sense where I can choose to run systemd as an init system, and something not-systemd for logging, or for scheduling or whatever.
    - SwellJoe 10y ago
      On the logging question, does the ForwardToSyslog option not do what you'd like? Most components can be replaced (the journal isn't one of them, AFAIK, but most others can, and the journal can be configured to send things to a plain text log). Personally, I don't find the binary log to be that problematic. It is taking some getting used to, of course. 20+ years of muscle memory for grepping and awking and cutting text log files is hard to overcome, but the amount of help the system provides is nicer. It's better documented and better at guiding the user than the old way, IMHO. Which brings to mind something I like about systemd becoming standard that rarely gets discussed, I think: It brings a level of consistency that some other UNIX systems have had for a long time; the BSDs, for instance, have the feeling of all of the pieces having been designed to work together. Linux has never had that feeling; but with systemd, a large amount of Linux real estate now feels that way. The documentation correctly references other components docs. The way various components work together is reasonably documented because they were built at roughly the same time by roughly the same people (or at least people who interacted during the design), so the interfaces are clearly delineated. That's cool, I think. So, sure, I'm having to learn new stuff every time I interact with systemd, and that's frustrating. I know Linux like the back of my hand, so when I find myself having to read the docs for even simple stuff, I get grumpy. But, I get over it. It's gonna be fine, and we'll all get through this learning curve.
sandGorgon 10y ago
It's very interesting how the whole article (and Lennart) shies away from even uttering "package manager" and instead talks about containers. This is fundamentally an implementation of Lennart's blog post - http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu.... That article used the words "We want an efficient way that allows vendors to package their software " ... which was followed by a storm of angry systemd-is-the-borg-it-needs-to-die tweets and articles. Even on HN - the response to this article seems fairly muted... although it is a bigger political issue than even init systems. I wonder what the response would have been to "systemd introduces new portable packaging format"
- oblio 10y ago
  If no one will say it, I will: it's stupid that we have multiple package managers and package formats. There's no fundamental technical reason Linux couldn't have just 1 extensible package format and 1 extensible package manager. All the reasons for the split are social ("I like A"), political ("we want to be able to control A") or historical ("A came first, we built our house on A, we can't abandon A").
  - qznc 10y ago
    Why do have so many programming languages? Because they fulfill different needs. C and Python are used for different things. Yet, there is overlap, which creates a constant tension. When do you rewrite your Python module into C for better performance? Likewise, different packaging formats exist for different needs. Docker and Ubuntu Snap are for different needs, yet they overlap. Systemd did initially not care about packaging and containers. Yet, there is an overlap, like "How to do logging?". Docker and Systemd both grow and overlap more and more.
    - oblio 10y ago
      We're talking about different things here. deb/rpm serve the same role. yum/apt ditto. We have gratuitous differences which could have been prevented with a better design. See for example even the mess in the rpm world where a SUSE rpm may or may not work on Red Hat.
hardwaresofton 10y ago
Excited to see where this goes. After some recent issues with running docker on arch (vague devicemapper issues, inability to stop containers properly), and my newfound love for systemd using it from day to day on my personal computer (writing unit files is pretty darn easy), I've actually been seriously considering going back to writing applications that just get run as processes, and managed by something other than me. If my understanding is right, the industry went: CGI -> processes -> VMs -> containers I'm thinking of going back to step 2.
qwertyuiop924 10y ago
I'm sorry, but I can't keep a straight face hearing the phrase "portable systemd." I don't care what init system you run, but if you're writing userland software (GNOME, for one), than what init system I run is none of your damn business. For that matter, ideally you'd at least try to support the *BSDs. As much as Systemd is the borg, I could at least live with that. I cannot live with the fact that systemd maintainers continue to say that having high-level userland software link to libsystemd is viable and acceptable. I cannot live with the fact that systemd continues to violate widely-accepted defaults for no reason (kill all processes on logout? really?). I cannot live with the fact that Lennart has widely stated that you should ignore POSIX and that all systems other than Linux don't matter.
- progman 10y ago
  > high-level userland software link to libsystemd is viable and acceptable This is a direct violation of the KISS principle which made Unix and Linux so great. Not only do they want to intertwine user software with system software, now they even want an additional layer of abstraction on the _system_ level! I think we need a counter strategy against the aggressive takeover of the Linux land before it is too late. I have nothing against people who love systemd. If they want it they should use it. But any Linux user should also have the option to get rid of systemd _completely_ if it turns out to be a failure. Init systems and system services should be as replacable as desktop environments! Only if systemd is aiming to be "portable" like that than I can live in peace with it.
  - qwertyuiop924 10y ago
    >I think we need a counter strategy The Gentoo folks, as well as many of us Arch users, are with you. Gentoo in particular has been aggressively forking and maintaining patch sets for any of the software that has succumbed to the cancer (the *kits, various desktop software, DBUS, GNOME, and most notably udev. Although if they weren't needed for some pieces of software I use, I'd gladly chuck 90% of that stuff). So yeah, if you want to help, that's where to contribute your effort.
    - 10y ago

75 points by cheiVia0 10y ago

Isn't ubuntu snap already doing all this? The competing standards I don't think help in this regard. Now to make a "portable service" I will need to make sure whatever I do can be used as a snap and a systemd portable service. Why is it so hard to settle on a standard when it comes to this stuff? The same confusion exists when it comes to rpm and deb packaging formats. At the end of the day both do the same thing and yet to deliver software to redhat and debian systems you have to double your packaging effort.

mateuszf 10y ago
Because systemd is more popular and cross distros.
derefr 10y ago
The RPM/Deb split, at this point, isn't so much about packaging formats, as it is about dependency graphs. Even if the two distro "families" of Redhat and Debian shared a common packaging format, a package would still have to be built—or at least specified—twice for them, because each family would still have its own set of deps that are factored out in incompatible ways to the deps of the other family. (For example, in Debian land, if your package wants to declare a dependency on OpenSSL, that might mean a package dependency on any of 'openssl', 'libssl1.0.0', 'libssl1.0.0-dbg', or 'libssl-dev'. RHEL et al do not have an isomorphic set of packages that these dependencies could be mapped to.)
- vbernat 10y ago
  This is already the case for SuSE and Redhat. Package names are different, RPM macros are different. Doing a package that works for both is gruesome. Also, at the time of SysV, you had to use two different init scripts.
wmf 10y ago
Presumably portable services will work on Ubuntu so you could skip the snap. There will never be agreement on standards that are used as strategic weapons in developer mindshare turf wars between companies using monopoly-or-die-trying business models.
niemeyer 10y ago
Such competing efforts are actually a form of non-voluntary collaboration. rpm and deb (and apt, yum, synaptic, ...) have significantly evolved together along the years, looking at each other. This happens all the time, and is happening again here.. the snap format and snapd evolve based on previous knowledge, and it's no surprise that the linked LWN article seems quite inspired by snaps (I'm biased as a snapd designer/developer). Let it come.. we'll be watching and picking up the good ideas too. And working hard to make sure snaps continue to win on merit, rather than lack of competition.

m3rc 10y ago

I used to spend time arguing with people on the internet about how systemd was an actually very useful tool but I never changed any minds and didn't help myself any. Now I just wait and watch for new helpful things it does to show up and I live a much happier life.

throwaway98237 10y ago
Not trolling. Not at all.
badsock 10y ago
I almost think there should be a divorce. Call it systemdOS and be done with it. At that point every service it subsumes will be seen as a step closer to the obvious end-goal rather than a point of contention. And the other OS can be something like the Gnome2 fork MATE. It's not a technical thing, it's cultural. The two sides are playing tug-of-war with the same OS, and systemd's winning, but maybe it would be better to have a positive culture around the changes they're making instead of always having people dragging on the rope. Some forks have been good in the past - EGCS/GCC for example.
- SwellJoe 10y ago
  > Call it systemdOS and be done with it. Every major Linux distro has chosen systemd as their future. I think that means whoever wants something different needs to change their name, rather than every major Linux distro changing theirs. Just as the Gnome 2 fans chose a new name for their future based on that lineage.
  - badsock 10y ago
    Fair enough. It just seems like it might be useful to have a symbolic split of some kind, where people choose a camp instead of trying to pull in both directions. Naming can do that.
    - SwellJoe 10y ago

AceJohnny2 10y ago

Tangentially, glad to see Jon finally put up a signup banner for non-subscribers :) (see discussion 3 months ago: https://news.ycombinator.com/item?id=12224408 https://news.ycombinator.com/item?id=12224408)

Karlozkiller 10y ago

This should surely stop the critics from saying systemd is doing too much and is bloatful. No, but seriously I understand the reason why you'd want this, but what stops systemd from being divided into smaller modules? Like the Linux I'm used to.

SwellJoe 10y ago
systemd is modular, and is divided into many components. There are several dozen binaries in a systemd package. Where do you believe the lines should be drawn differently?
- Karlozkiller 10y ago
  What I did mean was that at least from my understanding of it, you get systemd, and then you have all of systemd, unable to replace one part of systemd with some other package to handle that specific task. One of the features I would like to see for example is less binary logging and this journalctl madness. Binary logging makes it harder for me to plug in other programs to parse the logs or whatever I want to do. So what I would like to see is modularity in the sense where I can choose to run systemd as an init system, and something not-systemd for logging, or for scheduling or whatever.
  - SwellJoe 10y ago
    On the logging question, does the ForwardToSyslog option not do what you'd like? Most components can be replaced (the journal isn't one of them, AFAIK, but most others can, and the journal can be configured to send things to a plain text log). Personally, I don't find the binary log to be that problematic. It is taking some getting used to, of course. 20+ years of muscle memory for grepping and awking and cutting text log files is hard to overcome, but the amount of help the system provides is nicer. It's better documented and better at guiding the user than the old way, IMHO. Which brings to mind something I like about systemd becoming standard that rarely gets discussed, I think: It brings a level of consistency that some other UNIX systems have had for a long time; the BSDs, for instance, have the feeling of all of the pieces having been designed to work together. Linux has never had that feeling; but with systemd, a large amount of Linux real estate now feels that way. The documentation correctly references other components docs. The way various components work together is reasonably documented because they were built at roughly the same time by roughly the same people (or at least people who interacted during the design), so the interfaces are clearly delineated. That's cool, I think. So, sure, I'm having to learn new stuff every time I interact with systemd, and that's frustrating. I know Linux like the back of my hand, so when I find myself having to read the docs for even simple stuff, I get grumpy. But, I get over it. It's gonna be fine, and we'll all get through this learning curve.

sandGorgon 10y ago

It's very interesting how the whole article (and Lennart) shies away from even uttering "package manager" and instead talks about containers. This is fundamentally an implementation of Lennart's blog post - http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html http://0pointer.net/blog/revisiting-how-we-put-together-linu.... That article used the words "We want an efficient way that allows vendors to package their software " ... which was followed by a storm of angry systemd-is-the-borg-it-needs-to-die tweets and articles. Even on HN - the response to this article seems fairly muted... although it is a bigger political issue than even init systems. I wonder what the response would have been to "systemd introduces new portable packaging format"

oblio 10y ago
If no one will say it, I will: it's stupid that we have multiple package managers and package formats. There's no fundamental technical reason Linux couldn't have just 1 extensible package format and 1 extensible package manager. All the reasons for the split are social ("I like A"), political ("we want to be able to control A") or historical ("A came first, we built our house on A, we can't abandon A").
- qznc 10y ago
  Why do have so many programming languages? Because they fulfill different needs. C and Python are used for different things. Yet, there is overlap, which creates a constant tension. When do you rewrite your Python module into C for better performance? Likewise, different packaging formats exist for different needs. Docker and Ubuntu Snap are for different needs, yet they overlap. Systemd did initially not care about packaging and containers. Yet, there is an overlap, like "How to do logging?". Docker and Systemd both grow and overlap more and more.
  - oblio 10y ago
    We're talking about different things here. deb/rpm serve the same role. yum/apt ditto. We have gratuitous differences which could have been prevented with a better design. See for example even the mess in the rpm world where a SUSE rpm may or may not work on Red Hat.

hardwaresofton 10y ago

Excited to see where this goes. After some recent issues with running docker on arch (vague devicemapper issues, inability to stop containers properly), and my newfound love for systemd using it from day to day on my personal computer (writing unit files is pretty darn easy), I've actually been seriously considering going back to writing applications that just get run as processes, and managed by something other than me. If my understanding is right, the industry went: CGI -> processes -> VMs -> containers I'm thinking of going back to step 2.

qwertyuiop924 10y ago

I'm sorry, but I can't keep a straight face hearing the phrase "portable systemd." I don't care what init system you run, but if you're writing userland software (GNOME, for one), than what init system I run is none of your damn business. For that matter, ideally you'd at least try to support the *BSDs. As much as Systemd is the borg, I could at least live with that. I cannot live with the fact that systemd maintainers continue to say that having high-level userland software link to libsystemd is viable and acceptable. I cannot live with the fact that systemd continues to violate widely-accepted defaults for no reason (kill all processes on logout? really?). I cannot live with the fact that Lennart has widely stated that you should ignore POSIX and that all systems other than Linux don't matter.

progman 10y ago
> high-level userland software link to libsystemd is viable and acceptable This is a direct violation of the KISS principle which made Unix and Linux so great. Not only do they want to intertwine user software with system software, now they even want an additional layer of abstraction on the _system_ level! I think we need a counter strategy against the aggressive takeover of the Linux land before it is too late. I have nothing against people who love systemd. If they want it they should use it. But any Linux user should also have the option to get rid of systemd _completely_ if it turns out to be a failure. Init systems and system services should be as replacable as desktop environments! Only if systemd is aiming to be "portable" like that than I can live in peace with it.
- qwertyuiop924 10y ago
  >I think we need a counter strategy The Gentoo folks, as well as many of us Arch users, are with you. Gentoo in particular has been aggressively forking and maintaining patch sets for any of the software that has succumbed to the cancer (the *kits, various desktop software, DBUS, GNOME, and most notably udev. Although if they weren't needed for some pieces of software I use, I'd gladly chuck 90% of that stuff). So yeah, if you want to help, that's where to contribute your effort.
  - 10y ago