Re: Survey answers part 1: systemd has too many dependencies, …
Excerpts from Chow Loong Jin's message of 2013-06-12 11:06:54 -0700: On Wed, Jun 12, 2013 at 09:44:16AM -0700, Steve Langasek wrote: On Wed, Jun 12, 2013 at 04:40:22PM +0800, Chow Loong Jin wrote: Bitrot doesn't happen immediately, and even when it does happen, it will take time before its rate reaches an unmanageable state. Plenty of time to test a solution in the meantime I say. Basic autogeneration of sysvinit and upstart init scripts from systemd unit files perhaps? None of upstart jobs, systemd units, and init scripts are homologous to one another. You can't generate one set from another set without including additional metadata that's not being used by the native system you're writing for - which means you haven't actually solved the problem of leaving the users of the other systems with untested implementations. I get that converting between each of these formats perfectly is not possible due to them requiring different fields, but I was thinking that something that made educated guesses might work out in most cases. Unfortunately I think the models are just too different, and expect that it would only be useful as a developer tool. For a concrete example, if we assume systemd units are the base and using socket-based activation as the primary convention, you will have none of the information here about what events the upstart job should start on; and for init scripts, you'll have neither this information, nor information about how to track the processes (pidfiles, etc). Upstart these days has socket activation too. See upstart-socket-bridge(8). As for init scripts, well, er maybe we could use some xinetd-ish helper that handles the starting of socket-activated instead. And I reckon start-stop-daemon could benefit from some of the process tracking code that Upstart uses, which makes the pidfile one less issue to worry about. All three of these socket activation systems have different methods for getting the socket into the process. IMO this just represents more of the upstart vs. systemd pissing match, and is not fundamental. But suffice to say, the daemons have to support the init system's socket activation, and until the three are unified, this will not be automatically possible without added complexity. Remember that the appeal of upstart jobs or systemd units over init scripts is that we're removing *unnecessary complexity*. Once you've removed that complexity, you can't re-synthesize it from thin air in order to autogenerate init scripts; you have to maintain it somewhere. We could make a best-effort for common cases and require manual intervention for others. Some of the complexity can be inferred and dumped in wherever possible. Other information could be passed in via arguments to the converter. It doesn't always have to operate blindly without the maintainer's help. Anyway, my point is really that there's no use worrying about potential problems to the level of second-guessing what maintainers will or will not do if systemd becomes default. We'll just end up going round and round in circles, but then again I'm sure that's what some people want, as long as we don't switch away from $my_favourite_init, which just happens to be sysvinit at the moment. There is a point to worrying about wasting volunteer time though. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1371139039-sup-1...@fewbar.com
Re: Survey answers part 1: systemd has too many dependencies, …
On Sun, 09 Jun 2013 01:04:38 +0200, Michael Stapelberg stapelb...@debian.org wrote: since some people might not read planet debian, here is a link to my first blog post in a series of posts dealing with the results of the Debian systemd survey: http://people.debian.org/~stapelberg/2013/06/09/systemd-bloat.html Thanks for a remarkably unbiased view on the matter. I have to object against one part though: |While it is sad that those machines cannot profit from systemd, switching |to systemd as a default has no downside either: Debian continues to |support sysvinit for quite some time, so these machines will continue |to work even with upcoming Debian versions. I doubt this will happen. Once systemd is the default on Deban/GNU Linux, people will stop testing their init scripts, or they will even stop shipping init scripts, leaving the task of writing or testing init scripts to the non-Linux porters, which will of course decrease their quality since init scripts should be written and tested by people knowing the initted software very intimately. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1umfnj-0003ia...@swivel.zugschlus.de
Re: Survey answers part 1: systemd has too many dependencies, …
Hi Michael, On Tue, Jun 11, 2013 at 7:17 PM, Michael Stapelberg stapelb...@debian.orgwrote: Hi Ondřej, Ondřej Surý ond...@sury.org writes: and if I match this with the table at: http://people.debian.org/~stapelberg/docs/systemd-dependencies.html I get the result that you will _not_ compile systemd with: libselinux.so libpam.so libwrap.so libaudit.so libkmod.so because they are marked as optional in the table. I’m sorry that this is unclear. I updated the document, saying: Whether compiling systemd without this dependency is supported by upstream. This does not automatically mean that Debian choses to make these parts optional. Thanks, that makes the document and the goal of Debian maintainers much clearer. But, to be very clear, I certainly don’t see the need to strip down systemd in Debian for the general use case (including embedded devices and servers). That is energy which could be much better spent elsewhere. I concur. I still think you should also update the table with information if the library is actually used in PID 1 (or in forked process) as hmh suggested: It would be best to enhance http://people.debian.org/~stapelberg/docs/systemd-dependencies.html with information about what runs on PID 1, and what runs after fork() and how critical it is. O. -- Ondřej Surý ond...@sury.org
Re: Survey answers part 1: systemd has too many dependencies, …
On Wed, Jun 12, 2013 at 09:49:03AM +0200, Marc Haber wrote: [...] |While it is sad that those machines cannot profit from systemd, switching |to systemd as a default has no downside either: Debian continues to |support sysvinit for quite some time, so these machines will continue |to work even with upcoming Debian versions. I doubt this will happen. Once systemd is the default on Deban/GNU Linux, people will stop testing their init scripts, or they will even stop shipping init scripts, leaving the task of writing or testing init scripts to the non-Linux porters, which will of course decrease their quality since init scripts should be written and tested by people knowing the initted software very intimately. Bitrot doesn't happen immediately, and even when it does happen, it will take time before its rate reaches an unmanageable state. Plenty of time to test a solution in the meantime I say. Basic autogeneration of sysvinit and upstart init scripts from systemd unit files perhaps? Also, I don't think it takes that much to come up with a sane initscript for your regular daemon. Just program options, environment variables, pidfile, setuid user, and dependencies? The simplest root-run daemons might not even need any of those. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: Survey answers part 1: systemd has too many dependencies, …
Le 12/06/2013 09:49, Marc Haber a écrit : On Sun, 09 Jun 2013 01:04:38 +0200, Michael Stapelberg stapelb...@debian.org wrote: since some people might not read planet debian, here is a link to my first blog post in a series of posts dealing with the results of the Debian systemd survey: http://people.debian.org/~stapelberg/2013/06/09/systemd-bloat.html Thanks for a remarkably unbiased view on the matter. I have to object against one part though: |While it is sad that those machines cannot profit from systemd, switching |to systemd as a default has no downside either: Debian continues to |support sysvinit for quite some time, so these machines will continue |to work even with upcoming Debian versions. I doubt this will happen. Once systemd is the default on Deban/GNU Linux, people will stop testing their init scripts, or they will even stop shipping init scripts, leaving the task of writing or testing init scripts to the non-Linux porters, which will of course decrease their quality since init scripts should be written and tested by people knowing the initted software very intimately. However, the set of machines not able to switch to systemd and needing complicated init scripts is probably quite small. And the init scripts won't suddenly deteriorate. And I suspect that all suspicious cases will receive bugs, and then patches, and that maintainers will integrate these patches. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: Survey answers part 1: systemd has too many dependencies, …
Hi Ondřej, Ondřej Surý ond...@sury.org writes: I still think you should also update the table with information if the library is actually used in PID 1 (or in forked process) as hmh suggested: It would be best to enhance http://people.debian.org/~stapelberg/docs/systemd-dependencies.html with information about what runs on PID 1, and what runs after fork() and how critical it is. I don’t understand what you mean by this. The table — as published — already differentiates between PID 1 (section 2 of the document) and all other binaries (section 3 of the document). Anything not listed in section 2 is not required in PID 1. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/x6txl3xpfi@midna.zekjur.net
Re: Survey answers part 1: systemd has too many dependencies, …
On Wed, Jun 12, 2013 at 04:40:22PM +0800, Chow Loong Jin wrote: Bitrot doesn't happen immediately, and even when it does happen, it will take time before its rate reaches an unmanageable state. Plenty of time to test a solution in the meantime I say. Basic autogeneration of sysvinit and upstart init scripts from systemd unit files perhaps? None of upstart jobs, systemd units, and init scripts are homologous to one another. You can't generate one set from another set without including additional metadata that's not being used by the native system you're writing for - which means you haven't actually solved the problem of leaving the users of the other systems with untested implementations. For a concrete example, if we assume systemd units are the base and using socket-based activation as the primary convention, you will have none of the information here about what events the upstart job should start on; and for init scripts, you'll have neither this information, nor information about how to track the processes (pidfiles, etc). Remember that the appeal of upstart jobs or systemd units over init scripts is that we're removing *unnecessary complexity*. Once you've removed that complexity, you can't re-synthesize it from thin air in order to autogenerate init scripts; you have to maintain it somewhere. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Survey answers part 1: systemd has too many dependencies, …
Michael Stapelberg wrote: Ondřej Surý ond...@sury.org writes: I still think you should also update the table with information if the library is actually used in PID 1 (or in forked process) as hmh suggested: It would be best to enhance http://people.debian.org/~stapelberg/docs/systemd-dependencies.html with information about what runs on PID 1, and what runs after fork() and how critical it is. I don’t understand what you mean by this. The table — as published — already differentiates between PID 1 (section 2 of the document) and all other binaries (section 3 of the document). Anything not listed in section 2 is not required in PID 1. I think what he meant is that section 2 lists libpam.so.0 as a dependency, even though PAM is not run in PID 1. So from the table it is not obvious that libpam is NOT a dependency of the core systemd daemon in the sense that faulty PAM modules would make PID 1 crash etc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1371058452.18948.40.camel@glyph.nonexistent.invalid
Re: Survey answers part 1: systemd has too many dependencies, …
On Wed, Jun 12, 2013 at 09:44:16AM -0700, Steve Langasek wrote: On Wed, Jun 12, 2013 at 04:40:22PM +0800, Chow Loong Jin wrote: Bitrot doesn't happen immediately, and even when it does happen, it will take time before its rate reaches an unmanageable state. Plenty of time to test a solution in the meantime I say. Basic autogeneration of sysvinit and upstart init scripts from systemd unit files perhaps? None of upstart jobs, systemd units, and init scripts are homologous to one another. You can't generate one set from another set without including additional metadata that's not being used by the native system you're writing for - which means you haven't actually solved the problem of leaving the users of the other systems with untested implementations. I get that converting between each of these formats perfectly is not possible due to them requiring different fields, but I was thinking that something that made educated guesses might work out in most cases. For a concrete example, if we assume systemd units are the base and using socket-based activation as the primary convention, you will have none of the information here about what events the upstart job should start on; and for init scripts, you'll have neither this information, nor information about how to track the processes (pidfiles, etc). Upstart these days has socket activation too. See upstart-socket-bridge(8). As for init scripts, well, er maybe we could use some xinetd-ish helper that handles the starting of socket-activated instead. And I reckon start-stop-daemon could benefit from some of the process tracking code that Upstart uses, which makes the pidfile one less issue to worry about. Remember that the appeal of upstart jobs or systemd units over init scripts is that we're removing *unnecessary complexity*. Once you've removed that complexity, you can't re-synthesize it from thin air in order to autogenerate init scripts; you have to maintain it somewhere. We could make a best-effort for common cases and require manual intervention for others. Some of the complexity can be inferred and dumped in wherever possible. Other information could be passed in via arguments to the converter. It doesn't always have to operate blindly without the maintainer's help. Anyway, my point is really that there's no use worrying about potential problems to the level of second-guessing what maintainers will or will not do if systemd becomes default. We'll just end up going round and round in circles, but then again I'm sure that's what some people want, as long as we don't switch away from $my_favourite_init, which just happens to be sysvinit at the moment. -- Kind regards, Loong Jin signature.asc Description: Digital signature
Re: Survey answers part 1: systemd has too many dependencies, …
On Wed, Jun 12, 2013 at 7:34 PM, Uoti Urpala uoti.urp...@pp1.inet.fiwrote: Michael Stapelberg wrote: Ondřej Surý ond...@sury.org writes: I still think you should also update the table with information if the library is actually used in PID 1 (or in forked process) as hmh suggested: It would be best to enhance http://people.debian.org/~stapelberg/docs/systemd-dependencies.htmlwith information about what runs on PID 1, and what runs after fork() and how critical it is. I don’t understand what you mean by this. The table — as published — already differentiates between PID 1 (section 2 of the document) and all other binaries (section 3 of the document). Anything not listed in section 2 is not required in PID 1. I think what he meant is that section 2 lists libpam.so.0 as a dependency, even though PAM is not run in PID 1. So from the table it is not obvious that libpam is NOT a dependency of the core systemd daemon in the sense that faulty PAM modules would make PID 1 crash etc. Exactly, thanks for rewording me. O. -- Ondřej Surý ond...@sury.org
Re: Survey answers part 1: systemd has too many dependencies, …
On Tue, Jun 11, 2013 at 7:36 AM, Tollef Fog Heen tfh...@err.no wrote: ]] Thomas Goirand If what you say above is right (I have no opinion on that yet, I just trust what you say), then this renders the systemd is modular argument completely useless, because practically, the user wont be able to choose. Which is why I was asking specifically Michael about this, since he raised the fact that systemd is modular and components can be disabled. The primary point about the modularity is to limit what happens in init itself, not to have optional modules if it can be avoided. So my original question to Michael remains: what component should be activated by default, which one could be optional, and how can these options be enabled or disabled. I've heard about journald. which seems controversial (I also don't have any option about it myself yet). Could this one be optional, and not activated by default for example? What are the systemd maintainers opinion about it? I believe I already answered this, so I'm not sure why you're asking again. Tollef, it is still unclear to me as well. You said: I'd like to align with upstream here (and in general): If upstream says a component is optional, that's a configuration I'd in general want to support. If upstream says a component is not optional, well, then I'm unlikely to go to the effort of making it optional. and if I match this with the table at: http://people.debian.org/~stapelberg/docs/systemd-dependencies.html I get the result that you will _not_ compile systemd with: libselinux.so libpam.so libwrap.so libaudit.so libkmod.so because they are marked as optional in the table. Is that true or not? I am quite lost, because wheezy systemd package has these dependencies: Depends: libacl1 (= 2.2.51-8), libaudit0 (= 1.7.13), libc6 (= 2.11), libcap2 (= 2.10), libcryptsetup4 (= 2:1.4), libdbus-1-3 (= 1.1.1), libkmod2 (= 5~), liblzma5 (= 5.1.1alpha+20120614), libpam0g (= 0.99.7.1), libselinux1 (= 2.0.65), libsystemd-daemon0 (= 31), libsystemd-id128-0 (= 38), libsystemd-journal0 (= 38), libsystemd-login0 (= 38), libudev0 (= 172), libwrap0 (= 7.6-4~), util-linux (= 2.19.1-2), initscripts (= 2.88dsf-17), udev And this list include all of them. So either the webpage optional means a different thing than upstream optional or the future-to-be PID1 package will not include these dependencies. Can you please clarify? O. -- Ondřej Surý ond...@sury.org
Re: Survey answers part 1: systemd has too many dependencies, …
]] Ondřej Surý Tollef, it is still unclear to me as well. Ok, I'll try to be clearer then. You said: I'd like to align with upstream here (and in general): If upstream says a component is optional, that's a configuration I'd in general want to support. If upstream says a component is not optional, well, then I'm unlikely to go to the effort of making it optional. and if I match this with the table at: http://people.debian.org/~stapelberg/docs/systemd-dependencies.html I get the result that you will _not_ compile systemd with: libselinux.so libpam.so libwrap.so libaudit.so libkmod.so because they are marked as optional in the table. Is that true or not? I am quite lost, because wheezy systemd package has these dependencies: We'll compile with all compile-time options enabled, as per what's normal for Debian packages. Any run-time optional components we'll keep optional, but likely enabled by default. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3m10zna@qurzaw.varnish-software.com
Re: Survey answers part 1: systemd has too many dependencies, …
Hi Ondřej, Ondřej Surý ond...@sury.org writes: and if I match this with the table at: http://people.debian.org/~stapelberg/docs/systemd-dependencies.html I get the result that you will _not_ compile systemd with: libselinux.so libpam.so libwrap.so libaudit.so libkmod.so because they are marked as optional in the table. I’m sorry that this is unclear. I updated the document, saying: Whether compiling systemd without this dependency is supported by upstream. This does not automatically mean that Debian choses to make these parts optional. To further expand on this: It was my impression that people thought systemd had _hard_ dependencies on many parts when that actually isn’t true. In particular, this was used as an argument against using systemd on embedded devices. While I happily use systemd on devices such as the Raspberry Pi, I can understand that other people might have stricter constraints on binary sizes. Therefore, they could recompile the systemd package if they can live without a few features. In case demand is high enough and there is somebody who volunteers to maintain such a package, we would be open to talk about having a systemd-light package which is specfically targeted on such devices. It’d probably make sense to maintain this as part of one of the embedded spins we have, e.g. Emdebian — but I am not very familiar with those and their current state. But, to be very clear, I certainly don’t see the need to strip down systemd in Debian for the general use case (including embedded devices and servers). That is energy which could be much better spent elsewhere. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/x68v2gzhw8@midna.zekjur.net
Re: Survey answers part 1: systemd has too many dependencies, …
On Sun, Jun 9, 2013 at 2:46 PM, Vincent Bernat ber...@debian.org wrote: ❦ 9 juin 2013 11:45 CEST, Bjørn Mork bj...@mork.no : You do of course not have to agree. This is my personal opinion only. But I believe it is useful to read Jamie Zawinski's view on screensavers and toolkit library dependencies, and try to figure out how that can be relevant to systemd and external dependencies: http://www.jwz.org/xscreensaver/toolkits.html systemd does not rely on a toolkit. So, most of the arguments listed by Jamie do not hold. I suppose that you are mostly worried by libdbus since other libraries are already used in other critical daemons. Personally I would be more worried about libpam and it's ability to load random pam modules into a memory, and we have a plenty of them. $ apt-cache search ^libpam- | wc -l 61 Do you have idea how would a buggy PAM module affect PID 1? O. -- Ondřej Surý ond...@sury.org
Re: Survey answers part 1: systemd has too many dependencies, …
Le 2013-06-10 10:18, Ondřej Surý a écrit : systemd does not rely on a toolkit. So, most of the arguments listed by Jamie do not hold. I suppose that you are mostly worried by libdbus since other libraries are already used in other critical daemons. Personally I would be more worried about libpam and it's ability to load random pam modules into a memory, and we have a plenty of them. $ apt-cache search ^libpam- | wc -l 61 Do you have idea how would a buggy PAM module affect PID 1? No PAM module is executed in PID 1. All PAM code is executed after forking a child process and only for jobs requiring PAM explicitly. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/d3c9d21655f1100453e9bc528d4c0...@luffy.cx
Re: Survey answers part 1: systemd has too many dependencies, …
On Mon, Jun 10, 2013 at 12:22 PM, Vincent Bernat ber...@luffy.cx wrote: Le 2013-06-10 10:18, Ondřej Surý a écrit : systemd does not rely on a toolkit. So, most of the arguments listed by Jamie do not hold. I suppose that you are mostly worried by libdbus since other libraries are already used in other critical daemons. Personally I would be more worried about libpam and it's ability to load random pam modules into a memory, and we have a plenty of them. $ apt-cache search ^libpam- | wc -l 61 Do you have idea how would a buggy PAM module affect PID 1? No PAM module is executed in PID 1. All PAM code is executed after forking a child process and only for jobs requiring PAM explicitly. The document with library dependencies at http://people.debian.org/~stapelberg/docs/systemd-dependencies.html kind of misses this information. It might be good to add this kind of information to that document. Ondrej -- Ondřej Surý ond...@sury.org
Re: Survey answers part 1: systemd has too many dependencies, …
On Mon, 10 Jun 2013, Thomas Goirand wrote: On 06/10/2013 03:21 AM, Michael Stapelberg wrote: Thomas Goirand z...@debian.org writes: In this blog post, you tell that it's possible not to use all the components of systemd. Then, the immediate question that pops to my mind: what are *your* intentions then, in Debian (or, said in another way, what would you like to do if you where the only one to decide)? Would you like to remove some components, or keep them all by default? I don’t understand the intention behind that question. Could you clarify so that I can give a proper answer please? Let's say you decide. Let's say you set systemd by default in Debian. Then which component would you install, and activate by default? Which component will you make only installable if the user decides to do it actively (for example using apt-get install)? That is an uninteresting option. There is no way we can afford to have two different sets of features for PID 1 under the same name in Debian without it causing support trouble we don't need. So, please assume that every optional PID 1 feature of systemd will be compiled in, and that only stuff that can be disabled at runtime might be disabled. It would be best to enhance http://people.debian.org/~stapelberg/docs/systemd-dependencies.html with information about what runs on PID 1, and what runs after fork() and how critical it is. Also, it is extremely important to track down the full library dependency chain for the systemd executable that runs as PID 1, and include any library initialization code found in the entire chain in the analysis, otherwise the analysis will be too incomplete to base any decisions on. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130610182334.gb28...@khazad-dum.debian.net
Re: Survey answers part 1: systemd has too many dependencies, …
On 06/11/2013 02:23 AM, Henrique de Moraes Holschuh wrote: On Mon, 10 Jun 2013, Thomas Goirand wrote: On 06/10/2013 03:21 AM, Michael Stapelberg wrote: Thomas Goirand z...@debian.org writes: In this blog post, you tell that it's possible not to use all the components of systemd. Then, the immediate question that pops to my mind: what are *your* intentions then, in Debian (or, said in another way, what would you like to do if you where the only one to decide)? Would you like to remove some components, or keep them all by default? I don’t understand the intention behind that question. Could you clarify so that I can give a proper answer please? Let's say you decide. Let's say you set systemd by default in Debian. Then which component would you install, and activate by default? Which component will you make only installable if the user decides to do it actively (for example using apt-get install)? That is an uninteresting option. There is no way we can afford to have two different sets of features for PID 1 under the same name in Debian without it causing support trouble we don't need. So, please assume that every optional PID 1 feature of systemd will be compiled in, and that only stuff that can be disabled at runtime might be disabled. If what you say above is right (I have no opinion on that yet, I just trust what you say), then this renders the systemd is modular argument completely useless, because practically, the user wont be able to choose. Which is why I was asking specifically Michael about this, since he raised the fact that systemd is modular and components can be disabled. So my original question to Michael remains: what component should be activated by default, which one could be optional, and how can these options be enabled or disabled. I've heard about journald. which seems controversial (I also don't have any option about it myself yet). Could this one be optional, and not activated by default for example? What are the systemd maintainers opinion about it? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b69a6e.6030...@debian.org
Re: Survey answers part 1: systemd has too many dependencies, …
Thomas Goirand wrote: On 06/11/2013 02:23 AM, Henrique de Moraes Holschuh wrote: On Mon, 10 Jun 2013, Thomas Goirand wrote: Then which component would you install, and activate by default? Which component will you make only installable if the user decides to do it actively (for example using apt-get install)? That is an uninteresting option. There is no way we can afford to have two different sets of features for PID 1 under the same name in Debian without it causing support trouble we don't need. So, please assume that every optional PID 1 feature of systemd will be compiled in, and that only stuff that can be disabled at runtime might be disabled. If what you say above is right (I have no opinion on that yet, I just trust what you say), then this renders the systemd is modular argument completely useless, because practically, the user wont be able to choose. Which is why I was asking specifically Michael about this, since he raised the fact that systemd is modular and components can be disabled. As I understand it, the point about modularity was brought up to clarify misunderstandings about systemd architecture, not to suggest that the Debian setup should give users the ability turn arbitrary things on or off just for the sake of having more choices to make. Some people apparently had various misunderstandings about systemd bloat, up to believing that it would have a huge collection of varying functionality in PID 1. The systemd is modular argument shows what's wrong with this bloat view. It still works even if Debian maintainers decide to use all the modules. Your user won't be able to choose would be relevant if the complaint had been that systemd doesn't provide Gentoo users enough switches to turn on or off, but apparently that was not a common complaint in the survey. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370925376.18948.33.camel@glyph.nonexistent.invalid
Re: Survey answers part 1: systemd has too many dependencies, …
]] Thomas Goirand If what you say above is right (I have no opinion on that yet, I just trust what you say), then this renders the systemd is modular argument completely useless, because practically, the user wont be able to choose. Which is why I was asking specifically Michael about this, since he raised the fact that systemd is modular and components can be disabled. The primary point about the modularity is to limit what happens in init itself, not to have optional modules if it can be avoided. So my original question to Michael remains: what component should be activated by default, which one could be optional, and how can these options be enabled or disabled. I've heard about journald. which seems controversial (I also don't have any option about it myself yet). Could this one be optional, and not activated by default for example? What are the systemd maintainers opinion about it? I believe I already answered this, so I'm not sure why you're asking again. -- Tollef Fog Heen, with his systemd maintainer hat on UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87li6hqkdv@xoog.err.no
Re: Survey answers part 1: systemd has too many dependencies, …
Michael Stapelberg stapelb...@debian.org writes: since some people might not read planet debian, here is a link to my first blog post in a series of posts dealing with the results of the Debian systemd survey: http://people.debian.org/~stapelberg/2013/06/09/systemd-bloat.html I was hoping you would cover my reason why I fear the too many dependencies: external dependencies obfuscates what code is part of pid 1 and what is not. Some (most?) of the external projects you depend on are probably not developed with this use case in mind, and hence are not suitable for being used like this. This is not a critisism of the externel libraries. There is quite a difference between writing code which can exit and writing code which cannot. No sane person will attempt to do the latter unless strictly required. You claim that the systemd code using these dependencies is simple, and I have no reason do doubt that. But you ignore the fact that you make the external code part of systemd. That code also needs to be audited as if it were an integral part of systemd. You could just write a libpid1 and a 5 line application using that library. It should be obvious that auditing the 5 line application would be unsufficient. The point is that it is not obvious that all these external dependencies are suited for use by systemd, and that the responsibility for ensuring that they are lies with the systemd project. Not with the external projects. I understand that there are lots of developers having a hard time understanding that there is a difference between - desktop application depending on libfoo, and - criticial (securitywise, stabilitywise, other) application depending on libfoo You do of course not have to agree. This is my personal opinion only. But I believe it is useful to read Jamie Zawinski's view on screensavers and toolkit library dependencies, and try to figure out how that can be relevant to systemd and external dependencies: http://www.jwz.org/xscreensaver/toolkits.html Using a library in a critical application will make any harmless library bug into a critical bug. Are the maintainters of those dependencies really ready to handle that? This is the primary reason why the list of dependencies terrifies me. Not any of the four reasons you list, which, although valid, are only minor issues which could be outweighed by advantages offered by the dependency. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zjuzwrb9@nemi.mork.no
Re: Survey answers part 1: systemd has too many dependencies, …
Hi Bjørn, Thanks for your well-put mail. As far as I understand it, your concern is that libraries might exit() (either due to actually calling exit() or due to having a bug) and therefore take pid 1 with them. I am sure that the systemd developers are very aware of this fact. They even published libabc, a collection of best practices for libraries: https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git/tree/README …which explicitly lists your concern: Never call exit(), abort(), be very careful with assert() - Always return error codes. - Libraries need to be safe for usage in critical processes that need to recover from errors instead of getting killed (think PID 1!). Looking at the pid 1 dependency list¹, my gut feeling is that these libraries are very mature and well-tested. Of course, that is not a guarantee and I have not personally audited them. Furthermore, you can never entirely rule out bugs. Then again, you can always fix bugs :). In conclusion, I don’t worry about this at all. systemd, in my experience, is very stable. This includes code which is pulled in by third-party libraries. ① http://people.debian.org/~stapelberg/docs/systemd-dependencies.html, section 2 (“systemd(1) itself: PID 1”) -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/x67gi31tc1@midna.zekjur.net
Re: Survey answers part 1: systemd has too many dependencies, …
❦ 9 juin 2013 11:45 CEST, Bjørn Mork bj...@mork.no : You do of course not have to agree. This is my personal opinion only. But I believe it is useful to read Jamie Zawinski's view on screensavers and toolkit library dependencies, and try to figure out how that can be relevant to systemd and external dependencies: http://www.jwz.org/xscreensaver/toolkits.html systemd does not rely on a toolkit. So, most of the arguments listed by Jamie do not hold. I suppose that you are mostly worried by libdbus since other libraries are already used in other critical daemons. However, note that: - D-Bus is not a new project, it is now 10 years old - security is a primary concern for dbus - there are a lot of unit tests covering dbus code - memory allocation failure is also tested and crashing on that is considered as a bug - systemd uses dbus to avoid to introduce a new (buggy) RPC mechanism Moreover, I am not aware of critics against D-Bus code quality. The coding practice is modern and seems safe. -- Use statement labels that mean something. - The Elements of Programming Style (Kernighan Plauger) pgpQcccnbw8R5.pgp Description: PGP signature
Re: Survey answers part 1: systemd has too many dependencies, …
On 06/09/2013 07:04 AM, Michael Stapelberg wrote: Hi, since some people might not read planet debian, here is a link to my first blog post in a series of posts dealing with the results of the Debian systemd survey: http://people.debian.org/~stapelberg/2013/06/09/systemd-bloat.html In this blog post, you tell that it's possible not to use all the components of systemd. Then, the immediate question that pops to my mind: what are *your* intentions then, in Debian (or, said in another way, what would you like to do if you where the only one to decide)? Would you like to remove some components, or keep them all by default? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b4ac5a.4050...@debian.org
Re: Survey answers part 1: systemd has too many dependencies, …
Hi Thomas, Thomas Goirand z...@debian.org writes: In this blog post, you tell that it's possible not to use all the components of systemd. Then, the immediate question that pops to my mind: what are *your* intentions then, in Debian (or, said in another way, what would you like to do if you where the only one to decide)? Would you like to remove some components, or keep them all by default? I don’t understand the intention behind that question. Could you clarify so that I can give a proper answer please? -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/x6mwqzytsa@midna.zekjur.net
Re: Survey answers part 1: systemd has too many dependencies, …
On 10 June 2013 07:21, Michael Stapelberg stapelb...@debian.org wrote: Hi Thomas, Thomas Goirand z...@debian.org writes: In this blog post, you tell that it's possible not to use all the components of systemd. Then, the immediate question that pops to my mind: what are *your* intentions then, in Debian (or, said in another way, what would you like to do if you where the only one to decide)? Would you like to remove some components, or keep them all by default? I don’t understand the intention behind that question. Could you clarify so that I can give a proper answer please? I think Thomas is saying that the question of 'systemd for Debian' is a specific deployment case; the answer of 'you can choose which components of systemd to use' is an abstract answer. What components would still be choosable in 'systemd for Debian', not systemd generically. I must admit, I find it an interesting question too :) -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj3hoz2t3h1tbmkovucyj09vtrairts3upr+u1xjk7eqmuk...@mail.gmail.com
Re: Survey answers part 1: systemd has too many dependencies, …
]] Robert Collins On 10 June 2013 07:21, Michael Stapelberg stapelb...@debian.org wrote: Hi Thomas, Thomas Goirand z...@debian.org writes: In this blog post, you tell that it's possible not to use all the components of systemd. Then, the immediate question that pops to my mind: what are *your* intentions then, in Debian (or, said in another way, what would you like to do if you where the only one to decide)? Would you like to remove some components, or keep them all by default? I don’t understand the intention behind that question. Could you clarify so that I can give a proper answer please? I think Thomas is saying that the question of 'systemd for Debian' is a specific deployment case; the answer of 'you can choose which components of systemd to use' is an abstract answer. What components would still be choosable in 'systemd for Debian', not systemd generically. I'd like to align with upstream here (and in general): If upstream says a component is optional, that's a configuration I'd in general want to support. If upstream says a component is not optional, well, then I'm unlikely to go to the effort of making it optional. I am in general not fond of optional components, they make for more variations and harder debugging. (There are of course situations where the tradeoff goes the other way, but everything else being equal, I prefer a system with fewer parts and fewer optional parts.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m21u8bdnnl@rahvafeir.err.no
Re: Survey answers part 1: systemd has too many dependencies, …
On 06/10/2013 03:21 AM, Michael Stapelberg wrote: Hi Thomas, Thomas Goirand z...@debian.org writes: In this blog post, you tell that it's possible not to use all the components of systemd. Then, the immediate question that pops to my mind: what are *your* intentions then, in Debian (or, said in another way, what would you like to do if you where the only one to decide)? Would you like to remove some components, or keep them all by default? I don’t understand the intention behind that question. Could you clarify so that I can give a proper answer please? Let's say you decide. Let's say you set systemd by default in Debian. Then which component would you install, and activate by default? Which component will you make only installable if the user decides to do it actively (for example using apt-get install)? Which (installed by default) component will be able to be turned off by our users without breaking the whole thing, or removing features which makes the life with systemd difficult (I'm not sure if there's things like that, just trying to understand)? How would the user unable/disable such components: apt-get remove/purge/install ? Edit /etc/default/systemd ? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51b53989.8030...@debian.org
Survey answers part 1: systemd has too many dependencies, …
Hi, since some people might not read planet debian, here is a link to my first blog post in a series of posts dealing with the results of the Debian systemd survey: http://people.debian.org/~stapelberg/2013/06/09/systemd-bloat.html -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/x6fvws19x5@midna.zekjur.net
Re: Survey answers part 1: systemd has too many dependencies, …
Please note that I am not advocating for or against systemd, but... With regards complexity and whether it is intrinsic or not, Rich Hickey puts forward a more rigorous definition of complexity, and how it is sometimes in tension with easiness... http://www.infoq.com/presentations/Simple-Made-Easy-QCon-London-2012 I would love it if someone were to analyze systemd with/in that framework. -Rob On 9 June 2013 11:04, Michael Stapelberg stapelb...@debian.org wrote: Hi, since some people might not read planet debian, here is a link to my first blog post in a series of posts dealing with the results of the Debian systemd survey: http://people.debian.org/~stapelberg/2013/06/09/systemd-bloat.html -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/x6fvws19x5@midna.zekjur.net -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Cloud Services -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj3hoz1ztkmwkbffc4ubhwpdxvh1-c22bf1xfdvpkrrty8u...@mail.gmail.com
