Re: Debian systemd survey
On 2013-05-30 13:59:09 -0700, Russ Allbery wrote: Also, determining which flags to pass to the daemon from some other configuration file, which is a common use of /etc/default files, is a hack to work around the fact that an init script is not really user-editable. We therefore move the parts that we expect users to change into a separate, simpler configuration file to avoid making them brave the dangers of the init script and deal with lots of dpkg configuration file prompts when we fix bugs in the init script. But with a systemd or upstart configuration file, it becomes reasonable to have the user just edit that file directly to pass different parameters to the daemon, since the configuration file is already as simple, in many cases, as the /etc/default file was. Most config files are not really user-editable under Debian. I mean: they can be editable, but there are serious drawbacks during upgrades. Indeed most often the user has the choice between installing the new version (but his local changes are lost) and keeping the old version (but he doesn't benefit from new features, and worse, the old version of the config file is not guaranteed to work well with the new version of the package). The user can also start a shell to do the merge on his side, but this may take time... So, splitting config files is a way to avoid that, not in all cases but in most cases (this is not specific to sysvinit, apparently just a consequence of the old wishlist bug 32877, from 1999!). Aren't systemd and upstart config files affected by this problem? -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20130602121521.ga17...@xvii.vinc17.org
Re: Debian systemd survey
On 02/06/13 13:15, Vincent Lefevre wrote: Most config files are not really user-editable under Debian. ... So, splitting config files is a way to avoid that, not in all cases but in most cases (this is not specific to sysvinit, apparently just a consequence of the old wishlist bug 32877, from 1999!). Aren't systemd and upstart config files affected by this problem? The current upstream systemd has an include mechanism by which the unit in /etc can say copy all keys from the upstream version in /lib, then set Foo=bar, and also a mechanism by which individual keys in a unit can be overridden by a separate file in a .d directory corresponding to that unit. I think the older version currently in Debian has the former, but not the latter. I don't know about Upstart. If it doesn't have an equivalent of that systemd feature, I'm sure one could be added. S -- 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/51ab73d4.2050...@debian.org
Re: Debian systemd survey
Vincent Lefevre vinc...@vinc17.net writes: Most config files are not really user-editable under Debian. I mean: they can be editable, but there are serious drawbacks during upgrades. Indeed most often the user has the choice between installing the new version (but his local changes are lost) and keeping the old version (but he doesn't benefit from new features, and worse, the old version of the config file is not guaranteed to work well with the new version of the package). The user can also start a shell to do the merge on his side, but this may take time... So, splitting config files is a way to avoid that, not in all cases but in most cases (this is not specific to sysvinit, apparently just a consequence of the old wishlist bug 32877, from 1999!). Aren't systemd and upstart config files affected by this problem? They are somewhat, but it's much less bad because they're so simple. You don't have to write nearly as much there, and if you design them carefully, you can reduce even that complexity. My impression so far is that systemd has taken this even farther than upstart, but I've not done an exhaustive comparison. As a result, the config files look rather a lot like /etc/default files, and are amenable to a similar merge process: look at each setting, since there's only a handful, and think about which setting you want. For example, here's the complete systemd file for rsyncd: [Unit] Description=fast remote file copy program daemon ConditionPathExists=/etc/rsyncd.conf [Service] ExecStart=/usr/bin/rsync --daemon --no-detach [Install] WantedBy=multi-user.target There's really no reason to have something like an /etc/default setting for that, the way there is for the rsyncd init script. You can just edit that directly (well, it's systemd, so you have to copy it into /etc and make a new version and then won't know if anything about the default changes -- a truly awful design, but that's another argument). Now, rsyncd is one of the simplest init scripts, and more complicated services aren't quite that nice. But they stay surprisingly simple. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/8761xwjvob@windlord.stanford.edu
Re: Debian systemd survey
Hi Russ, Am 02.06.2013 18:59, schrieb Russ Allbery: For example, here's the complete systemd file for rsyncd: [Unit] Description=fast remote file copy program daemon ConditionPathExists=/etc/rsyncd.conf [Service] ExecStart=/usr/bin/rsync --daemon --no-detach [Install] WantedBy=multi-user.target There's really no reason to have something like an /etc/default setting for that, the way there is for the rsyncd init script. You can just edit that directly (well, it's systemd, so you have to copy it into /etc and make a new version and then won't know if anything about the default changes -- a truly awful design, but that's another argument). You do not necessarily have to copy the whole file. You can override/amend the .service file by using a foo.service.d/*.conf snippet. Say you just want to change the ExecStart line, you can do the following: echo ExecStart=/usr/bin/rsync --daemon --my-funky-param /etc/systemd/system/rsync.service.d/my-override.conf This mechanism is not yet in v44, but a newer version of systemd will be uploaded to unstable soonish having this feature. As for noticing upstream default changes: There is a tool called systemd-delta, which can notify you about such differences. That all said, I think one has to treat .service files more like application ressource files. Having to change them should be the exception rather then the norm. E.g., I see the need being able to modify /etc/rsyslog.conf, but /etc/init.d/rsyslog (and therefore rsyslog.service) not so much. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Debian systemd survey
Russ Allbery wrote: There's really no reason to have something like an /etc/default setting for that, the way there is for the rsyncd init script. You can just edit that directly (well, it's systemd, so you have to copy it into /etc and make a new version and then won't know if anything about the default changes -- a truly awful design, but that's another argument). You don't necessarily need to copy the file into /etc to change something. Depending on the change, it may be more appropriate to create a new file using .include for the old file and then overriding only one particular setting. Telling people to blindly copy everything is bad advice IMO - if you have even the settings you _don't_ want to override in the /etc file, then merging is necessary on upgrades if you still want to follow changes to those default settings. Whether there are notifications from the packaging system when package upgrades change the default file has nothing to do with systemd design. That's up to the Debian packaging. Tollef Fog Heen just said in a post yesterday it's quite likely we'll go with an approach that uses ucf and does notify on update-with-changes. Of course rsync has another maintainer who might or might not choose the same behavior, and obviously he hasn't enabled any notifications at the moment. But if you disagree with that, blaming the design of upstream systemd is not the right target. -- 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/1370196033.3628.343.camel@glyph.nonexistent.invalid
Re: Debian systemd survey
Michael Biebl bi...@debian.org writes: Am 02.06.2013 18:59, schrieb Russ Allbery: There's really no reason to have something like an /etc/default setting for that, the way there is for the rsyncd init script. You can just edit that directly (well, it's systemd, so you have to copy it into /etc and make a new version and then won't know if anything about the default changes -- a truly awful design, but that's another argument). You do not necessarily have to copy the whole file. You can override/amend the .service file by using a foo.service.d/*.conf snippet. That doesn't really help -- it's exactly changes to ExecStart that I want to be informed of by dpkg. Suppose that I modify the systemd file to add an additional command-line flag, and the package maintainer separately changes the systemd file to add a different command-line flag. When I upgrade the package, I really want both flags. dpkg will at least warn me that this happened and show me a diff, and I can then make the obvious change. With the systemd configuration strategy, this change is completely hidden to me. There are many daemons in Debian that are configured with a variety of command-line options in the package and that the end user will want to customize with other command-line options without losing the ones provided by the package maintainer. This is a very common use case, and one that we frequently handle poorly and awkwardly with /etc/default files right now and could handle much better with upstart or systemd, except that systemd's configuration handling shoots itself in the foot. As for noticing upstream default changes: There is a tool called systemd-delta, which can notify you about such differences. Does it do the proper comparison? I don't want to just be informed that my version is different from the default version: I know that. I want to know if the package file has changed since I based my version on it. This is exactly the behavior that we get right now from dpkg configuration file handling. (Ideally, I also want to know *how* it's changed so that I get a full three-way merge behavior, but that's a harder problem, and only ucf sort of does that. I wouldn't expect the change in init system to try to tackle that problem, although of course it would be nice.) That all said, I think one has to treat .service files more like application ressource files. Having to change them should be the exception rather then the norm. E.g., I see the need being able to modify /etc/rsyslog.conf, but /etc/init.d/rsyslog (and therefore rsyslog.service) not so much. No, I strongly disagree. This defeats one of the primary gains from moving to upstart or systemd as I've described at some length in this thread. One of the points is to get *away* from this broken situation where the daemon initialization file is an uneditable blob. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87li6sidt1@windlord.stanford.edu
Re: Debian systemd survey
]] Russ Allbery There's really no reason to have something like an /etc/default setting for that, the way there is for the rsyncd init script. You can just edit that directly (well, it's systemd, so you have to copy it into /etc and make a new version and then won't know if anything about the default changes -- a truly awful design, but that's another argument). .. and to work around that, we're likely to tell people to use ucf for the files, so you will get notification on updates. (Or you can use the .include syntax as smcv wrote about.) -- 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/878v2swerb@xoog.err.no
Re: Debian systemd survey
On 03/06/2013 00:33, Simon McVittie wrote: [...] The current upstream systemd has an include mechanism by which the unit in /etc can say copy all keys from the upstream version in /lib, then set Foo=bar, and also a mechanism by which individual keys in a unit can be overridden by a separate file in a .d directory corresponding to that unit. I think the older version currently in Debian has the former, but not the latter. I don't know about Upstart. If it doesn't have an equivalent of that systemd feature, I'm sure one could be added. If it's just overriding statements in an init script, a .override file can be dumped into /etc/init. From init(5): · Files ending in .override are called override files. If an override file is present, the stanzas it contains take precedence over those equivalently named stanzas in the corresponding configuration file contents for a particular job. The main use for override files is to modify how a job will run without having to modify its configuration file directly. See the section Override File Handling below for further details. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: Debian systemd survey
Tollef Fog Heen tfh...@err.no writes: ]] Russ Allbery There's really no reason to have something like an /etc/default setting for that, the way there is for the rsyncd init script. You can just edit that directly (well, it's systemd, so you have to copy it into /etc and make a new version and then won't know if anything about the default changes -- a truly awful design, but that's another argument). .. and to work around that, we're likely to tell people to use ucf for the files, so you will get notification on updates. (Or you can use the .include syntax as smcv wrote about.) Yeah, I should be clear that this is certainly something we can fix. It's not intrinsic to the systemd software itself, only in the design of the default configuration behavior. The software itself supports both configuration models, which actually makes it more flexible than designs that only support one configuration model. Also, to be fair, there are some advantages to having a canonical and working version of the configuration kept outside of configuration space where it won't be modified and is available as a fallback in various situations. There have been times when I've wanted that for other Debian configuration files. With some new tool development, we could do better than dpkg does with straight /etc/default files. The syntax is so much simpler that we could, for instance, eventually develop quite intelligent three-way merge tools. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87li6sgutv@windlord.stanford.edu
Re: Debian systemd survey
On 2013-06-02 11:10:34 -0700, Russ Allbery wrote: Michael Biebl bi...@debian.org writes: Am 02.06.2013 18:59, schrieb Russ Allbery: There's really no reason to have something like an /etc/default setting for that, the way there is for the rsyncd init script. You can just edit that directly (well, it's systemd, so you have to copy it into /etc and make a new version and then won't know if anything about the default changes -- a truly awful design, but that's another argument). You do not necessarily have to copy the whole file. You can override/amend the .service file by using a foo.service.d/*.conf snippet. That doesn't really help -- it's exactly changes to ExecStart that I want to be informed of by dpkg. Agreed. To give an example, /lib/systemd/system/wpa_supplicant.service currently contains: ExecStart=/sbin/wpa_supplicant -u -s -O /var/run/wpa_supplicant What if the user wants his own ExecStart line, do does something like the above? echo ExecStart=/sbin/wpa_supplicant -u -s -O /var/run/wpa_supplicant -foo /etc/systemd/system/wpa_supplicant.service But if the /var/run symlink disappears some time in the future, or if wpa_supplicant is moved to /usr/sbin (something that may happen), the /lib/systemd/system/wpa_supplicant.service file would have been updated, but the user wouldn't necessarily be aware of such a change. I hope the user isn't required to write config files that can dynamically update themselves from new /lib/... files. :) -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20130602205105.ga15...@xvii.vinc17.org
Re: Debian systemd survey
On Thu, 30 May 2013 13:59:09 -0700, Russ Allbery r...@debian.org wrote: Marc Haber mh+debian-de...@zugschlus.de writes: Russ Allbery r...@debian.org wrote: Get rid of some of that complexity because it is pointless (you'll find that much of it is working around inadequacies in sysvinit). Explain. For example, all the PID file handling is working around the inability to determine via better mechanisms whether or not the daemon is running. Much of the logic for changing users can be eliminated in favor of a declarative syntax. Various logic for determining whether the daemon is installed can be handled via a better syntax or by having the base unit file not be a configuration file (I prefer the upstart approach here, personally). Also, determining which flags to pass to the daemon from some other configuration file, which is a common use of /etc/default files, is a hack to work around the fact that an init script is not really user-editable. We therefore move the parts that we expect users to change into a separate, simpler configuration file to avoid making them brave the dangers of the init script and deal with lots of dpkg configuration file prompts when we fix bugs in the init script. But with a systemd or upstart configuration file, it becomes reasonable to have the user just edit that file directly to pass different parameters to the daemon, since the configuration file is already as simple, in many cases, as the /etc/default file was. Agreed. Get rid of more of it by building a static configuration from the dynamic configuration when it changes, where appropriate. So you are seriously suggesting to add an inotify trigger on the conf.d directory instead of building the configuration right before it is needed? Could you please find a better way of asking questions than putting a bunch of words in someone else's mouth that you clearly find absurd? I'm going to try that. When the source of the configuration is debconf, we know exactly when it changes and don't need anything like inotify to know when to rebuild it. Disagreed, one can change a debconf-generated file manually, thanks to the debconf-is-not-a-registry mantra and the demand that a debconfed package needs to read in its configuration before presenting the debconf questions. 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/e1uin12-0001cu...@swivel.zugschlus.de
Re: Debian systemd survey
Marc Haber mh+debian-de...@zugschlus.de writes: Russ Allbery r...@debian.org wrote: When the source of the configuration is debconf, we know exactly when it changes and don't need anything like inotify to know when to rebuild it. Disagreed, one can change a debconf-generated file manually, thanks to the debconf-is-not-a-registry mantra and the demand that a debconfed package needs to read in its configuration before presenting the debconf questions. Correct, which is why I went on to address exactly that question in the rest of the message to which you are responding. Because the upstart and systemd configuration is much more easily parsable and suitable for use directly as a configuration file due to much simpler structure than init scripts, we can use it as the repository for configuration data and parse it in the maintainer scripts to preserve that behavior. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/8738t3jfiy@windlord.stanford.edu
Re: Debian systemd survey
Le mercredi 29 mai 2013 à 21:43 +0200, Marc Haber a écrit : That is one of my concerns: Once Debian GNU/Linux has systemd as default, noone will an longer provide init scripts, let alone tested init scripts, which will severely hurt non-Linux kernels in Debian. While entirely true, I think it demonstrates we are lacking adequate support for non-Linux kernels, and it should not prevent us from improving the init system for Linux. The current init scripts are not tested on non-Linux. The current *packages* are not tested on non-Linux. Most of the current packages appear completely dysfunctional once someone actually tries them on non-Linux – and this almost never happens because these architectures don’t have real testing/unstable users. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1369908317.5185.182.camel@pi0307572
Re: Debian systemd survey
On Wed, 29 May 2013 13:10:57 -0700, Russ Allbery r...@debian.org wrote: Using an imperative language for a descriptive purpose is a bad mismatch of tools and has been ever since the practical effect of init scripts has become fairly standardized. Some init scripts in Debian build dynamic configuration before the daemon is started. It has grown to be an important part of conffile and configuration management for software that cannot by itself read its configuration in snippets from a foo.conf.d directory. I am not sure how we would handle that in a descriptive approach. It has once been suggested by people to use wrappers around the daemon and to call that wrapper from the job description, but that strikes me as _much_ more ugly than having an init script. Greetings Ma old conservative sneg rc -- -- !! 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/e1uhzwx-0008dh...@swivel.zugschlus.de
Re: Debian systemd survey
On 30/05/13 11:19, Marc Haber wrote:
On Wed, 29 May 2013 13:10:57 -0700, Russ Allbery r...@debian.org
wrote:
Using an imperative language for a descriptive purpose is a bad mismatch
of tools and has been ever since the practical effect of init scripts has
become fairly standardized.
Some init scripts in Debian build dynamic configuration before the
daemon is started. It has grown to be an important part of conffile
and configuration management for software that cannot by itself read
its configuration in snippets from a foo.conf.d directory.
I am not sure how we would handle that in a descriptive approach.
My preferred answer is give the daemon better configuration handling,
so you can get maximum benefit from having a declarative init, but if
that isn't an option:
systemd:
ExecStartPre=/usr/share/myservice/hack-up-the-config.sh
ExecStart=/usr/sbin/myservice
Upstart:
pre-start script
# entirely untested, but [1] suggests that this might be right?
/usr/share/myservice/hack-up-the-config.sh || { stop; exit 0; }
end script
script
/usr/sbin/myservice
end script
Or keep using a legacy sysvinit script (they'll have to remain supported
for quite some time, at least in runlevels 2-5, for LSB if nothing
else), or wrap the daemon in a shell script that does some initial setup
and eventually exec()s the real daemon (like openarena-server).
Perhaps your favourite package can't derive much/any benefit from a more
declarative init, but I would guess that 90%+ do. That's still a
significant reduction in the number of lines of shell script boilerplate
in the distribution :-)
S
[1]
http://upstart.ubuntu.com/cookbook/#stop-a-job-from-running-if-a-pre-start-condition-fails
--
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/51a738eb.9040...@debian.org
Re: Debian systemd survey
Marc Haber mh+debian-de...@zugschlus.de writes: Russ Allbery r...@debian.org wrote: Using an imperative language for a descriptive purpose is a bad mismatch of tools and has been ever since the practical effect of init scripts has become fairly standardized. Some init scripts in Debian build dynamic configuration before the daemon is started. It has grown to be an important part of conffile and configuration management for software that cannot by itself read its configuration in snippets from a foo.conf.d directory. I am not sure how we would handle that in a descriptive approach. Get rid of some of that complexity because it is pointless (you'll find that much of it is working around inadequacies in sysvinit). Get rid of more of it by building a static configuration from the dynamic configuration when it changes, where appropriate. For the rest, escape out to an imperative language to do that work. Something that upstart certainly supports, and that I believe systemd does as well. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87sj14cw3q@windlord.stanford.edu
Re: Debian systemd survey
On Thu, 30 May 2013 12:32:59 +0100, Simon McVittie s...@debian.org
wrote:
On 30/05/13 11:19, Marc Haber wrote:
On Wed, 29 May 2013 13:10:57 -0700, Russ Allbery r...@debian.org
wrote:
Using an imperative language for a descriptive purpose is a bad mismatch
of tools and has been ever since the practical effect of init scripts has
become fairly standardized.
Some init scripts in Debian build dynamic configuration before the
daemon is started. It has grown to be an important part of conffile
and configuration management for software that cannot by itself read
its configuration in snippets from a foo.conf.d directory.
I am not sure how we would handle that in a descriptive approach.
My preferred answer is give the daemon better configuration handling,
so you can get maximum benefit from having a declarative init, but if
that isn't an option:
That is often not an option. In my case, for example, it's skills. I
would not dare to write configuration handling code in C code that is
destined to run as root, while I don't have much issues in writing
such code in perl or even in shell. otoh, I maintain quite some daemon
packages that have their code written in C.
Additionally, this this traditionally written daemon does not work
nicely with systemd, so change the daemon instead of making systemd
behave as if it was destined for Unixoid OSses attitude is a big
topic for systemd opponents.
systemd:
ExecStartPre=/usr/share/myservice/hack-up-the-config.sh
ExecStart=/usr/sbin/myservice
Can the hack-up-the-config.sh give an error message that is shown to
the user? Can it abort the daemon start? How would systemd handle this
case if it is configured to make sure the daemon is always running?
Upstart:
pre-start script
# entirely untested, but [1] suggests that this might be right?
/usr/share/myservice/hack-up-the-config.sh || { stop; exit 0; }
end script
script
/usr/sbin/myservice
end script
Ugly. Same questions apply.
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/e1ui5co-0004w0...@swivel.zugschlus.de
Re: Debian systemd survey
On Wed, May 22, 2013 at 08:35:52PM +0200, John Paul Adrian Glaubitz wrote: Please leave the FUD at the door. Writing upstart jobs is not difficult; while there are some gotchas currently with process lifecycle (which will be fixed soon), there is also very complete documentation (for these issues, and generally). systemd's unit files are still way simpler than upstart job files since these are just more or less a simple set of instructions to give systemd some hints on how to deal with the targets and services, it actually does most of the work automatically without the need of scripts at all (which are obviously still required for upstart). That's patently false. Upstart does not *require* scripts. It *supports* scripts, out of a recognition that C is not always the language of choice for implementation. This enables upstart jobs to do things like providing compatibility with existing, shell-based /etc/default/* files than packages are already using for daemon configuration; it enables rapid prototyping and more flexible customization and iteration of upstart jobs for debugging and development (because unlike the systemd developers, the upstart developers aren't trying to sell anyone a bill of goods about how their existing units are perfect and nothing will ever need to be patched downstream). But there is nothing in upstart that requires the use of scripts; anything that's done using 'script' in an upstart job could equally be done with 'exec', or could be built into a C daemon. The fact that a set of typical startup operations are handled in upstart by scripts is a design choice to not hard-code such policy into pid 1. This does not in any way speak to the complexity of the job file or unit file syntax. But this is ground that you and I have covered before, so I'm disappointed to see this claim being repeated. https://lists.debian.org/debian-devel/2012/02/msg00896.html -- 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: Debian systemd survey
On Thu, May 30, 2013 at 12:32:59PM +0100, Simon McVittie wrote:
On 30/05/13 11:19, Marc Haber wrote:
On Wed, 29 May 2013 13:10:57 -0700, Russ Allbery r...@debian.org
wrote:
Using an imperative language for a descriptive purpose is a bad mismatch
of tools and has been ever since the practical effect of init scripts has
become fairly standardized.
Some init scripts in Debian build dynamic configuration before the
daemon is started. It has grown to be an important part of conffile
and configuration management for software that cannot by itself read
its configuration in snippets from a foo.conf.d directory.
I am not sure how we would handle that in a descriptive approach.
My preferred answer is give the daemon better configuration handling,
so you can get maximum benefit from having a declarative init, but if
that isn't an option:
systemd:
ExecStartPre=/usr/share/myservice/hack-up-the-config.sh
ExecStart=/usr/sbin/myservice
Upstart:
pre-start script
# entirely untested, but [1] suggests that this might be right?
/usr/share/myservice/hack-up-the-config.sh || { stop; exit 0; }
end script
script
/usr/sbin/myservice
end script
While you could do it this way, I think it would be better to do this:
pre-start exec /usr/share/myservice/hack-up-the-config.sh
exec /usr/sbin/myservice
No need to use 'script' if you're just running a single command (that just
forks a shell uselessly). And for a pre-start that's not expected to fail
in the normal case, there's no need to worry about a clean stop of the job
from the pre-start; the only difference this makes is to whether upstart
tries repeatedly to start the job and hits the respawn limit, or whether the
job is stopped immediately when there's a failure. So that's a trade-off
between a little bit of extra log spam, vs. spawning an extra shell.
Or keep using a legacy sysvinit script (they'll have to remain supported
for quite some time, at least in runlevels 2-5, for LSB if nothing
else), or wrap the daemon in a shell script that does some initial setup
and eventually exec()s the real daemon (like openarena-server).
Yes. A lot of the people expressing concern about being forced to migrate
to non-sysvinit seem to be overlooking the fact that both upstart and
systemd provide backwards-compatibility for sysvinit scripts. So changing
the default init comes with no obligation on maintainers to write
configuration files for the new thing before they're convinced of its
utility.
--
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: Debian systemd survey
On Thu, May 30, 2013 at 09:38:40AM -0700, Steve Langasek wrote: development (because unlike the systemd developers, the upstart developers aren't trying to sell anyone a bill of goods about how their existing units are perfect and nothing will ever need to be patched downstream). But there Seems nicer to strive to never have differences in conf files. Then they can be part of upstream instead of yet another file that will differ between distributions. I have not noticed that these systemd files differ between distributions though. Care to show this? -- Regards, Olav -- 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/20130530191258.gb25...@bkor.dhs.org
Re: Debian systemd survey
On Thu, May 30, 2013 at 09:12:58PM +0200, Olav Vitters wrote: On Thu, May 30, 2013 at 09:38:40AM -0700, Steve Langasek wrote: development (because unlike the systemd developers, the upstart developers aren't trying to sell anyone a bill of goods about how their existing units are perfect and nothing will ever need to be patched downstream). But there Seems nicer to strive to never have differences in conf files. Then they can be part of upstream instead of yet another file that will differ between distributions. I have not noticed that these systemd files differ between distributions though. Care to show this? It's not a question of whether they *do* differ between distributions; it's a question of whether they *will* differ at some future point. The utopian vision painted by systemd upstream is colored by the fact that they only actually have to support Fedora and Red Hat, not a range of distributions; so having systemd units upstream works just fine *for them* as the only ones who are actually leveraging them heavily to date, but that's not at all proof that they will not need to be modified downstream. But, well, here's an example of people already managing to propose non-portable systemd units upstream - non-portable for reasons as absurd as a hard-coded path. https://lists.samba.org/archive/samba-technical/2013-February/090369.html -- 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: Debian systemd survey
On Thu, 30 May 2013 08:42:49 -0700, Russ Allbery r...@debian.org wrote: Get rid of some of that complexity because it is pointless (you'll find that much of it is working around inadequacies in sysvinit). Explain. Get rid of more of it by building a static configuration from the dynamic configuration when it changes, where appropriate. So you are seriously suggesting to add an inotify trigger on the conf.d directory instead of building the configuration right before it is needed? 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/e1ui9n5-0005x1...@swivel.zugschlus.de
Re: Debian systemd survey
Marc Haber mh+debian-de...@zugschlus.de writes: Russ Allbery r...@debian.org wrote: Get rid of some of that complexity because it is pointless (you'll find that much of it is working around inadequacies in sysvinit). Explain. For example, all the PID file handling is working around the inability to determine via better mechanisms whether or not the daemon is running. Much of the logic for changing users can be eliminated in favor of a declarative syntax. Various logic for determining whether the daemon is installed can be handled via a better syntax or by having the base unit file not be a configuration file (I prefer the upstart approach here, personally). Also, determining which flags to pass to the daemon from some other configuration file, which is a common use of /etc/default files, is a hack to work around the fact that an init script is not really user-editable. We therefore move the parts that we expect users to change into a separate, simpler configuration file to avoid making them brave the dangers of the init script and deal with lots of dpkg configuration file prompts when we fix bugs in the init script. But with a systemd or upstart configuration file, it becomes reasonable to have the user just edit that file directly to pass different parameters to the daemon, since the configuration file is already as simple, in many cases, as the /etc/default file was. Get rid of more of it by building a static configuration from the dynamic configuration when it changes, where appropriate. So you are seriously suggesting to add an inotify trigger on the conf.d directory instead of building the configuration right before it is needed? Could you please find a better way of asking questions than putting a bunch of words in someone else's mouth that you clearly find absurd? It puts the conversation on a very uncomfortable footing and leaves me feeling like your goal is to discredit other participants in the conversation rather than understand what they were trying to say. I was thinking of cases where the /etc/default file or some similar configuration file is managed by debconf, such as with one of my packages (openafs-client). In those cases, systemd or upstart allows removing several levels of indirection and just generating the configuration file for the init system directly, instead of having an init script that loads configuration from another configuration file managed by debconf. In particular, both upstart and systemd configuration files can be fairly easily read by maintainer scripts, allowing us to preserve user settings that were made manually on the system, a requirement for configuration files. This is much harder to do with init scripts, which accounts for another chunk of the separation of init script and startup configuration. When the source of the configuration is debconf, we know exactly when it changes and don't need anything like inotify to know when to rebuild it. And if the output of that configuration file is an init system configuration that is also user-editable (which init scripts really aren't), that allows us to also support direct user edits of the underlying configuration without any additional complexity. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/871u8oxjz6@windlord.stanford.edu
Re: Debian systemd survey
On May 28, 2013, at 11:49 PM, Marc Haber mh+debian-de...@zugschlus.de wrote: On Sat, 25 May 2013 11:27:36 -0700, Russ Allbery r...@debian.org wrote: (The shading of meaning between those two options could be clearer. I took it as a measure of enthusiasm and personally answered I welcome systemd in Debian because, regardless of whether it becomes the default, I'm happy to provide systemd unit files for my packages. If Upstart makes it into Debian, good luck running (responsible, reliable) servers: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/669481 http://marc.merlins.org/perso/linux/2012-03.html#Ditched-Ubuntu-and-Switched-Laptop-to-Back-to-Debian-64bit Dependency based init already works well, to replace it with a hive of bugs does not make sense. OpenRC is the only one which claims to be reverse compatible, if this is true then OpenRC should be the focus. -- Mark -- 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/626d6289-00e6-4fda-95d7-94373c852...@syminet.com
Re: Debian systemd survey
On Fri, May 31, 2013 at 5:11 AM, Mark Symonds wrote: If Upstart makes it into Debian Upstart is already in Debian. Dependency based init already works well, to replace it with a hive of bugs does not make sense. OpenRC is the only one which claims to be reverse compatible, if this is true then OpenRC should be the focus. OpenRC is not (yet) compatible with LSB dependency information, which we use in Debian. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6GrpFC-KFsE93nEu4uh=xagze2fuq3tvzmdncdznqj...@mail.gmail.com
Re: Debian systemd survey
On Fri, 24 May 2013 09:09:32 -0700, Steve Langasek vor...@debian.org wrote: On Fri, May 24, 2013 at 08:40:19AM +0200, Marc Haber wrote: On Thu, 23 May 2013 12:50:00 -0700, Steve Langasek vor...@debian.org wrote: Also worth noting: ~/systemd$ find . -name '*.c' | grep -vE 'tests|test/|intl/|udev/' \ | xargs wc -l | tail -n1 149081 total $ find . -name '*.c' | grep -vE 'tests|test/|intl/|udev/' | xargs wc -l \ | tail -n1 31282 total $ Yep, systemd has a larger community of contributors... and weighs in at nearly 5 times the code base. Granted, those 110KLOC may save almost as much lines of code in init scripts. No, this is not the case. Upstart jobs are short, simple, and lacking in shell boilerplate, just as systemd units are. So you were comparing systemd to upstart? Sorry, that was not clear to me. Does upstart support non-linux kernels? Grüße 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/e1uha9p-0003ft...@swivel.zugschlus.de
Re: Debian systemd survey
On Sat, 25 May 2013 11:27:36 -0700, Russ Allbery r...@debian.org wrote: (The shading of meaning between those two options could be clearer. I took it as a measure of enthusiasm and personally answered I welcome systemd in Debian because, regardless of whether it becomes the default, I'm happy to provide systemd unit files for my packages. Would you also be happy to test and support both systemd unit files _and_ init scripts? 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/e1uhacm-0003kj...@swivel.zugschlus.de
Re: Debian systemd survey
Marc Haber mh+debian-de...@zugschlus.de writes: Russ Allbery r...@debian.org wrote: (The shading of meaning between those two options could be clearer. I took it as a measure of enthusiasm and personally answered I welcome systemd in Debian because, regardless of whether it becomes the default, I'm happy to provide systemd unit files for my packages. Would you also be happy to test and support both systemd unit files _and_ init scripts? I'm happy to provide both, integrate patches, etc., although I think init scripts are awful and my level of personal motivation to work on init scripts compared to anything else (whether it be systemd or upstart or whatever else someone might invent) is quite low. I expect that as soon as we have a fully supported init system in Debian that supports a sane daemon configuration syntax instead of a mass of unreadable shell code, I will switch all of my systems to it and never look back. Therefore, I can't promise testing of init scripts going forward, but I'm certainly not going to stand in the way of anyone who wants to maintain them and contribute improvements. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/8738t5n3yg@windlord.stanford.edu
Re: Debian systemd survey
On Wed, 29 May 2013 09:30:47 -0700, Russ Allbery r...@debian.org wrote: Marc Haber mh+debian-de...@zugschlus.de writes: Would you also be happy to test and support both systemd unit files _and_ init scripts? I'm happy to provide both, integrate patches, etc., although I think init scripts are awful and my level of personal motivation to work on init scripts compared to anything else (whether it be systemd or upstart or whatever else someone might invent) is quite low. That is one of my concerns: Once Debian GNU/Linux has systemd as default, noone will an longer provide init scripts, let alone tested init scripts, which will severely hurt non-Linux kernels in Debian. 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/e1uhmhj-0001bk...@swivel.zugschlus.de
Re: Debian systemd survey
Marc Haber mh+debian-de...@zugschlus.de writes: Russ Allbery r...@debian.org wrote: I'm happy to provide both, integrate patches, etc., although I think init scripts are awful and my level of personal motivation to work on init scripts compared to anything else (whether it be systemd or upstart or whatever else someone might invent) is quite low. That is one of my concerns: Once Debian GNU/Linux has systemd as default, noone will an longer provide init scripts, let alone tested init scripts, which will severely hurt non-Linux kernels in Debian. Yes, that's one of the risks of not managing to port one of the other init systems to non-Linux kernels. We are, in general, not going to get people to work on things they don't want to work on, and init scripts are awful and long-overdue for being replaced. I think some of the burden is going to have to be born by the Debian porters for platforms for which there's currently nothing better available, whether by porting something better, developing some conversion process for one of the other formats, or maintaining the init scripts in other packages and submitting patches. I will promise to review and integrate such patches promptly, similar to how I've tried to review and integrate patches for Hurd support. Using an imperative language for a descriptive purpose is a bad mismatch of tools and has been ever since the practical effect of init scripts has become fairly standardized. We need to switch to a descriptive language; we will gain huge maintainability benefits and will have far fewer bugs of the type that have plagued init scripts for decades: bad shell error handling, incorrect handling of unusual cases involving half-stopped daemons, inconsistent PID handling, stopping unrelated binaries with the same executable name, and so on, all of which are avoidable but only if you're very careful and know what you're doing or get lucky when translating opaque and obscure templates. I definitely do *not* agree with breaking systems that use shell init scripts proactively, but shell init scripts are so inferior to any descriptive replacement that I agree with you they're likely to bitrot if left solely to the maintenance of the average Debian packager, who will probably quickly embrace something easier to maintain and stop paying attention to them. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87fvx54kdq@windlord.stanford.edu
Re: Debian systemd survey
What are the results Michael? ken. On Mon, May 20, 2013 at 5:19 PM, Michael Stapelberg stapelb...@debian.org wrote: Hello, In the past, we have had multiple heated discussions involving systemd. We (the pkg-systemd-maintainers team) would like to better understand why some people dislike systemd. Therefore, we have created a survey, which you can find at http://survey.zekjur.net/index.php/391182 Please only submit your feedback to the survey and not this thread, we are not particularly interested in yet another systemd discussion at this point. The deadline for participating in that survey is 7 days from now, that is 2013-05-26 23:59:00 UTC. Please participate only if you consider yourself an active member of the Debian community (for example participating in the debian-devel mailing list, maintaining packages, etc.). Of course, we will publish the results after the survey ends. Thanks! Best regards, the Debian systemd maintainers -- 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/x6mwrp7hfq@midna.zekjur.net -- 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/CAGf7y=qpkn7ypktdr9zgejjkiep3tkvgqkf6mxfhmjtz0qc...@mail.gmail.com
Re: Debian systemd survey
Ken Barber k...@bob.sh writes: What are the results Michael? He posted them to debian-devel, but also: http://people.debian.org/~stapelberg//2013/05/27/systemd-survey-results.html -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87li6xp9yp@windlord.stanford.edu
Re: using upstart in Debian [was, Re: Debian systemd survey]
❦ 24 mai 2013 12:29 CEST, Dmitrijs Ledkovs x...@debian.org : The best way to run daemons under upstart is in foreground, then correct PID is tracked and the complete stdout/stderr is properly collected and stored in /var/log/upstart/$job.log (even early boot output). The best way to run a daemon under upstart is by using expect stop. This is the one thing I think upstart is better than systemd. This is really easy to implement in most daemons (one line of code). Notifying systemd is not really complex but this cannot be done in one line or without an external dependency. -- Keep it right when you make it faster. - The Elements of Programming Style (Kernighan Plauger) pgpYq0WcJ9yDs.pgp Description: PGP signature
Re: Debian systemd survey
Michael Stapelberg wrote: In the past, we have had multiple heated discussions involving systemd. We (the pkg-systemd-maintainers team) would like to better understand why some people dislike systemd. Therefore, we have created a survey, which you can find at http://survey.zekjur.net/index.php/391182 Please only submit your feedback to the survey and not this thread, we are not particularly interested in yet another systemd discussion at this point. The wording of one of the questions in the survey is problematic. What is your general sentiment towards having systemd in Debian (not necessarily as default)? Choose one of the following answers [ ] I welcome systemd in Debian, everything is fine [ ] I am not sure yet [ ] I don't care [ ] I don't want systemd in Debian I realize the words (not necessarily as default) are included in the question. But that is only parenthetical. I personally don't mind having options available that I do not use. But I don't think this question is worded to account for this. If I respond that I welcome systemd in Debian (as an option for others to use) does that mean this will count as a vote toward having systemd as a default? If I respond that I don't want systemd in Debian (as a default) will that count as a vote that systemd should not be available in Debian as an option for others? Bob signature.asc Description: Digital signature
Re: Debian systemd survey
Bob Proulx b...@proulx.com writes: The wording of one of the questions in the survey is problematic. What is your general sentiment towards having systemd in Debian (not necessarily as default)? Choose one of the following answers [ ] I welcome systemd in Debian, everything is fine [ ] I am not sure yet [ ] I don't care [ ] I don't want systemd in Debian I realize the words (not necessarily as default) are included in the question. But that is only parenthetical. I personally don't mind having options available that I do not use. But I don't think this question is worded to account for this. If I respond that I welcome systemd in Debian (as an option for others to use) does that mean this will count as a vote toward having systemd as a default? The very next question is about whether you want systemd to be the default, so I don't think that would be a reasonable interpretation of the survey results. If I respond that I don't want systemd in Debian (as a default) will that count as a vote that systemd should not be available in Debian as an option for others? That's not an available option. The option says I don't want systemd in Debian without the parenthetical, which in context would mean that you don't want the packages to be in Debian at all. The next question offers a place to say that you don't want systemd to be the default. If your position is that you're happy to have systemd be available in Debian but you don't want it to be the default, I would answer either I welcome systemd in Debian, everything is fine or I don't care to this question and No to the next question. That seemed mostly straightforward to me, but of course YMMV. (The shading of meaning between those two options could be clearer. I took it as a measure of enthusiasm and personally answered I welcome systemd in Debian because, regardless of whether it becomes the default, I'm happy to provide systemd unit files for my packages. If I were planning on ignoring it completely, I would have answered I don't care.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87mwri6hk7@windlord.stanford.edu
Re: Debian systemd survey
On 05/24/2013 01:20 AM, brian m. carlson wrote: rsyslog is priority important and is the default syslog implementation in Debian. It's also the default in Fedora. I think we can be confident that it gets lots of real-world use. I am fully aware of that. I was mainly talking about the other logging daemons which most of them I haven't even heard of before. It's a bit unfair to use these for statistics, they simply don't play any important role. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/519efeb8.3080...@physik.fu-berlin.de
Re: Debian systemd survey
On 05/24/2013 01:15 AM, brian m. carlson wrote: I can use only parts of coreutils if I desire. The same is true for systemd. Ubuntu is using parts of systemd without actually using the daemon itself. Also, coreutils does not start services on startup that I do not need. Aeh, what the heck are you comparing here? My cat also doesn't fly and my hamster doesn't play the guitar. coreutils doesn't start services because it isn't an init daemon. However, what systemd actually does as compared to all other init systems, it only starts the services you actually need. It won't start ssh, for example, unless someone needs it. upstart, on the other hand, starts ssh once the other services it depends on are present (unless they changed that design aspect in more recent versions of upstart), even though you actually don't need ssh right now. It just starts it because its dependencies are fulfilled, while systemd actually starts ssh once a process or a target explicitly requires it. Thus, upstart actually turns the dependency chain upside down which is actually one of the main reason the systemd developers started from scratch instead of jumping the upstart band wagon. It's an inherent design issue in upstart. systemd, on the other hand, has spawned systemd-journald, which I do not want or need, which is autorestarted, and which cannot be stopped with service. Since I am not using its functionality, there is no point in having the service running. rsyslog is very capable. You can use systemd without the journal, it's optional. And, btw, it's not rsyslog which is broken but the fact that logging the way syslog does is quite a mess. There is no syntax convention for any logging whatsoever so you will have to come up with scripts to parse syslog for every single daemon that you want to watch. The systemd journal, OTOH, uses a defined format for the logging entries which means you can easily search your logs for any events matching a certain daemon and severity type of event and so on. It's much more powerful. Also, traditionally init has been limited to starting and stopping groups of services. It has not been involved in logging, session management, seat management, hotkey handling, or suspend and resume, except perhaps to start and stop the services which perform those functions. However well-intentioned, systemd does a lot more than init traditionally has, and definitely encroaches into areas that were not traditionally init-related. The Unix Way is to use separate processes for separate tasks. Traditionally, TVs and monitors used CRTs and discrete parts as components. We are therefore not allowed to improve the design and use LC displays and integrated circuits. Please stop treating the The Unix Way as the ultimate design concept which already has reached perfection and must not get unchanged for eternity. Did you, in fact know, that even the creators of the original Unix concept weren't quite happy with the design and actually replaced Unix with something called Plan 9? Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/519f02b0.7000...@physik.fu-berlin.de
Re: Debian systemd survey
On Fri, 2013-05-24 at 04:21 +0800, Thomas Goirand wrote: On 05/23/2013 03:15 PM, Lucas Nussbaum wrote: I have the (possibly wrong) impression that OpenRC is less advanced technically than systemd and upstart, and lacks many of their advantages For example, according to https://bugs.gentoo.org/show_bug.cgi?id=391945 which is linked from http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems, parallel boot does not work due to problems in dependency handling. I don't think that taking any random bug (which is a can, not always) is fair. I also understand that OpenRC does not replace sysvinit, but instead is an additional layer on top of it (for example, sysvinit stays PID 1). I believe that is a very strong thing in *favor* of OpenRC. What is the status of packaging OpenRC for Debian? Is there a group doing that, is help needed? -- 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/1369376389.27914.20.ca...@g3620.my.own.domain
Re: Debian systemd survey
On Thu, 23 May 2013 23:18:04 +0200, Josselin Mouette j...@debian.org wrote: Le jeudi 23 mai 2013 à 22:06 +0200, Marc Haber a écrit : Yes, systemd trying to replace so much of traditional UNIX tools at once and so blatantly breaking the One job one tool principle that has made our platform so successful is one major part of the acceptance issues that systemd has in Debian. I’d bother answering to that, but Lennart already did. Myth #1: http://0pointer.de/blog/projects/the-biggest-myths.html Systemd is just as much monolithic as, say, coreutils. Having read Lennart's ramblings, I did not say that systemd is monolithic. 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/e1uflvb-0006bu...@swivel.zugschlus.de
Re: Debian systemd survey
On Thu, 23 May 2013 12:50:00 -0700, Steve Langasek vor...@debian.org wrote: Also worth noting: ~/systemd$ find . -name '*.c' | grep -vE 'tests|test/|intl/|udev/' \ | xargs wc -l | tail -n1 149081 total $ find . -name '*.c' | grep -vE 'tests|test/|intl/|udev/' | xargs wc -l \ | tail -n1 31282 total $ Yep, systemd has a larger community of contributors... and weighs in at nearly 5 times the code base. Granted, those 110KLOC may save almost as much lines of code in init scripts. 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/e1uflfn-0006i1...@swivel.zugschlus.de
Re: using upstart in Debian [was, Re: Debian systemd survey]
Steve Langasek vorlon at debian.org writes: Sorry you ran into trouble with upstart. Not a DD, just a happy Debian user, hope you'll excuse me, but on the topic of Upstart, I have some technical comments on why, surprisingly, I think it may not be mature enough yet. A couple of years ago I was doing emergency consultancy work for a company using Red Hat and upstart. The dev dude there was really on top of new tech and had made Upstart scripts for starting his Python web apps (which I thought was a great idea, this was back when Upstart looked like THE alternative to sysvinit). However, when debugging it, we had some weird lock-ups from Upstart, basically you'd ask Upstart for the status of the job and it would lock up really hard (IIRC Ctrl-C wouldn't work). After much swearing, it wasn’t immediately obvious why Upstart would be the culprit, I found this (at the time) old bug: https://bugs.launchpad.net/upstart/+bug/406397 Upstart couldn't track the forks going on inside a started process reliably. As one commenter notes: “I’m wondering why this bug has a importance of “low”, as it renders using upstart for many daemons (including apache, postfix and others) as impossible.” This bug doesn't appear to be fixed yet. So unfortunately, I don't think Upstart is ready for handling a server boot with native job files. I had a look at the apache2 packages for Ubuntu raring, and there’s a sysvinit file, but no Upstart job. I'm telling you the whole story here to explain that this isn't just a minor problem for packages shipped with the distribution, it's also a potentially big problem for ISVs. Also on technical merits although more philosophically, with Upstart you're expressing yourself in an event-based DSL rather than writing configuration files. It's pretty generic. But unfortunately, that means it's also not entirely straightforward, and, I believe, easier to get wrong. Scott had some explaining blog posts before he left Canonical that I still find confusing (from the POV of just getting a job file done): http://netsplit.com/2010/12/20/events-are-like-methods/ http://netsplit.com/2010/12/03/event-matching-in-upstart/ Lennart Poettering wrote in his initial blog posts on systemd about why he thought this fundamental model of Upstart wasn't entirely spot on, and while I thought this might have been NIH BS at the time I've later come to the conclusion that he's probably right. Taking as much confusing logic as possible out of the job files does seem like a win. Ole -- 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/loom.20130523t110151-...@post.gmane.org
Re: Debian systemd survey
On Fri, May 24, 2013 at 03:22:12AM +0200, Matthias Klumpp wrote: 2013/5/24 brian m. carlson sand...@crustytoothpaste.net: Gentlemen, This is well-worn territory on -devel. Please bear in mind the OP's wish not to open this can of worms again. -- 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/20130524080744.GA20095@debian
Re: Debian systemd survey
On Fri, May 24, 2013 at 04:07:06AM +0800, Thomas Goirand wrote: On 05/23/2013 03:55 PM, John Paul Adrian Glaubitz wrote: How on earth does that contradict with the fact that 40%, i.e. the minority of all contributions are done by the original author. 40% still means that 60% of the code comes from other people and those are 145 contributors according to ohloh [1]. It's not this way. Last time I checked, there was another upstream doing about 30% of the work. You keep moving the goal posts! I don't see why this even matters. I guess you don't think systemd's development community is healthy, whereas John does. I doubt either of you is going to convince the other, so why not respect the OP and leave it there? -- 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/20130524081525.GB20095@debian
Re: Debian systemd survey
On Fri, May 24, 2013 at 03:22:12AM +0200, Matthias Klumpp wrote: Ubuntu carries patches downstream to make logind work without systemd but with upstart instead, but I don't think that doing that is a sane solution. Various GNOME code incorrectly checked for systemd-as-init before using logind. The two can be used separately. Canonical/Ubuntu sent various patches to fix this assumption. Those patches should be in latest GNOME 3.8.x (that was the plan). -- Regards, Olav -- 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/20130524081552.gb24...@bkor.dhs.org
Re: Debian systemd survey
If On Thu, May 23, 2013 at 12:50:00PM -0700, Steve Langasek wrote: A large number of contributors to an *init system* is not something that should be a goal in and of itself Then Furthermore, the statistics for systemd are themselves a distortion isn't really relevant here, let's please not open a can of worms counting contributors and contributions every which way. -- 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/20130524081825.GC20095@debian
Re: Debian systemd survey
On Fri, May 24, 2013 at 04:07:06AM +0800, Thomas Goirand wrote: I'm still not convinced. Don't trust the lies from Lennart, the git clone tells the truth: As a mostly lurker, I think there was already a request to be a bit more polite on this mailing list. The is a big difference between someone being wrong or having a wrong impression and saying that a person is lying all the time. Suggesting lying is not polite IMO. -- Regards, Olav -- 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/20130524080608.ga24...@bkor.dhs.org
Re: using upstart in Debian [was, Re: Debian systemd survey]
On 05/22/2013 06:19 PM, Steve Langasek wrote: On Wed, May 22, 2013 at 03:39:00PM +0200, Bernd Schubert wrote: On 05/22/2013 04:50 AM, Uoti Urpala wrote: Lucas Nussbaum wrote: I went through the various init systems threads again during the last few days. My understanding of the consensus so far is the following: - Both systemd and upstart bring many useful features, and are a clear improvement over sysvinit. Yes, both are an improvement over sysvinit. Hrmm, I have not tested systemd yet, but personally I'm not conviced about the advantages of upstart: - Stops booting *somtimes*, does not provide any information why. I didn't report a bug yet as an almost black screen won't help in any way how to figure out why it stopped. Already that stops without any further information why and where is a sufficiently big design issue, imho. (Btw, in the mean time I belive this issue is related to /etc/mtab, but I'm not sure yet.). Sorry you ran into trouble with upstart. Probably related to /etc/fstab, rather than /etc/mtab... Due to incomplete upstart integration of plymouth in Debian at present, if there are problems in /etc/fstab, mountall won't Well, actually this happens on 2 ubuntu systems. always be able to display any prompt to the user asking what to do (cf. http://web.dodds.net/~vorlon/wiki/blog/Plymouth_is_not_a_bootsplash/). I really meant mtab. After the issue appeared last time again and didn't go away on reboots, I booted into recovery shell and noticed that 'mount -a' didn't do anything. Remouting / rw, deleting /etc/mtab solved it, also on reboots. I now linked /proc/self/mtab to /etc/mtab and that solved it. Might not be an upstart bug at all, but I'm mainly complaining here that upstart does not provide any way to figure out what it is currently waiting for. Just opening a shell after some time and writing something like waiting on XXX to proceed with ... probably would be sufficient. Without any logs, screen output and no way to investigate it just gives the feeling that one now needs to re-install the system, similar to another famous OS . Whereas sysvinit would eventually give up on trying to mount filesystems in /etc/fstab if they were missing at boot and continue booting without them, upstart takes the design decision that this is an error that the admin needs to deal with directly. This ensures that the system always boots reliably in the face of slow disks, which become more of a problem now that your init system is so fast that it can boot before your hardware has been probed. Feel free to file a bug report against the upstart package (with a copy of your /etc/fstab attached) so we can look at this further. - Updating/install programs in a chroot fails with weird messages that those programs (afaik for example X) cannot connect to upstart. Well, it is a chroot, what does it expect? This is bug #685779, which will be fixed in the next upload of sysvinit to unstable. - Personally I'm using unionfs-fuse as very first init script to mount /etc and /var and others on my development systems. So no need to modify an initrams, but a very simple approach and controllable using a boot script. But specifying a script to be run *before* anything else is not possible (yet?). I'm skeptical of the value of such a design in place of just using an initramfs, but the 'friendly-recovery' package in Ubuntu gives an example of to do this. You create an upstart job that's 'start on real-startup-event', runs your necessary pre-setup, and at the end calls 'initctl emit startup' to call into the rest of the boot sequence; then you pass '--startup-event=real-startup-event' to init on the kernel commandline. Thanks, going to look into this. I also need to work on unionfs-fuse to properly work from an initramfs. The issue is just missing time for either of both... I also just wanted to point out that upstart is some way a regression. Thanks, Bernd -- 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/519f2d5e.2010...@fastmail.fm
Re: Debian systemd survey
Steve Langasek vor...@debian.org writes: On Thu, May 23, 2013 at 09:11:55AM +0200, Gergely Nagy wrote: Also, post-raring, systemd is available in Ubuntu aswell, and in some cases, you can check for systemd at runtime, needing no modification to the package *at all*. What's available in Ubuntu are the systemd dbus services, the libraries, and a little-known daemon called 'udev'. The systemd init is *not* in Ubuntu and there are no plans to change that. Those are enough to cover quite a bit of software well enough to not need Ubuntu-specific patches. -- |8] -- 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/87k3mobugf.fsf@algernon.balabit
Re: Debian systemd survey
Adam Borowski kilob...@angband.pl writes: On Thu, May 23, 2013 at 09:55:41AM +0200, John Paul Adrian Glaubitz wrote: On 05/23/2013 06:56 AM, Thomas Goirand wrote: As you may know, systemd is developed by a large amount of contributors How on earth does that contradict with the fact that 40%, i.e. the minority of all contributions are done by the original author. 40% still means that 60% of the code comes from other people and those are 145 contributors according to ohloh [1]. OpenRC has 19 [2], upstart has even only 7 [3] contributors. So, yeah, systemd is definitely the project which has the largest amount of contributors which was exactly my point. Did you include the stats for all projects systemd wants to replace as well? FWIW, systemd does *not* want to replace your traditional syslog. Parts of it, yes, but not all of it. So counting those projects in would be a mistake. -- |8] -- 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/87fvxcbu9q.fsf@algernon.balabit
Re: Debian systemd survey
On 2013-05-24 02:16, brian m. carlson wrote: Yes, systemd uses separate processes, but they are not independent. They cannot be independently turned off. If I decide I do not want the journal features, however useful others might think they are, I should not have to resort to chmod and dpkg-statoverride to keep them from running. Let them be optional features which the core systemd can be used without. Well, one central feature for debugging is that systemctl status $foo.service gives you the output (stdout/stderr) of that service. This seems to be realized using journald. So that's one case where a feature is realized by a helper binary (it is not in */bin, but in a lib directory). I guess that the syslog-related features can be turned off using journald.conf. Kind regards Philipp Kern -- 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/57f947876efb9a8429d5b2f19b2a1...@hub.kern.lc
Re: using upstart in Debian [was, Re: Debian systemd survey]
On 23 May 2013 10:37, Ole Laursen o...@hardworking.dk wrote: Steve Langasek vorlon at debian.org writes: Sorry you ran into trouble with upstart. Not a DD, just a happy Debian user, hope you'll excuse me, but on the topic of Upstart, I have some technical comments on why, surprisingly, I think it may not be mature enough yet. A couple of years ago I was doing emergency consultancy work for a company using Red Hat and upstart. The dev dude there was really on top of new tech and had made Upstart scripts for starting his Python web apps (which I thought was a great idea, this was back when Upstart looked like THE alternative to sysvinit). However, when debugging it, we had some weird lock-ups from Upstart, basically you'd ask Upstart for the status of the job and it would lock up really hard (IIRC Ctrl-C wouldn't work). After much swearing, it wasn’t immediately obvious why Upstart would be the culprit, I found this (at the time) old bug: https://bugs.launchpad.net/upstart/+bug/406397 Upstart couldn't track the forks going on inside a started process reliably. As one commenter notes: “I’m wondering why this bug has a importance of “low”, as it renders using upstart for many daemons (including apache, postfix and others) as impossible.” This bug doesn't appear to be fixed yet. So unfortunately, I don't think Upstart is ready for handling a server boot with native job files. I had a look at the apache2 packages for Ubuntu raring, and there’s a sysvinit file, but no Upstart job. I'm telling you the whole story here to explain that this isn't just a minor problem for packages shipped with the distribution, it's also a potentially big problem for ISVs. Yes, it's a real bug and as clearly stated in the bug report comments above it is due to using ptrace to count/track forks. The best way to run daemons under upstart is in foreground, then correct PID is tracked and the complete stdout/stderr is properly collected and stored in /var/log/upstart/$job.log (even early boot output). How to establish fork counts the consequences of getting it wrong are well documented in the upstart cookbook (see below). As far as I understand (correct me if I am wrong), systemd instead of counting/tracking forks uses cgroups to keep track of the started processes. Also on technical merits although more philosophically, with Upstart you're expressing yourself in an event-based DSL rather than writing configuration files. It's pretty generic. But unfortunately, that means it's also not entirely straightforward, and, I believe, easier to get wrong. Scott had some explaining blog posts before he left Canonical that I still find confusing (from the POV of just getting a job file done): http://netsplit.com/2010/12/20/events-are-like-methods/ http://netsplit.com/2010/12/03/event-matching-in-upstart/ Since those blog posts were published a coprehensive documentation book was written and is constantly kept up to date. http://upstart.ubuntu.com/cookbook/ It actually guides explains upstart concepts in a coherent and straight-forward manner with a very large section of examples on how to achieve various goals tasks. Lennart Poettering wrote in his initial blog posts on systemd about why he thought this fundamental model of Upstart wasn't entirely spot on, and while I thought this might have been NIH BS at the time I've later come to the conclusion that he's probably right. Taking as much confusing logic as possible out of the job files does seem like a win. Blog posts are interesting to read, but at times I'd like to look up reference manuals which are more than bear minimal man pages. Whilst systemd ships manpages, the website has either incorrectly formatted wiki-pages and/or eventual links to lennart's blog posts. Where is systemd's documentation? Regards, Dmitrijs. -- 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/canbhluhbgvwkp8tsgicgmq2zermb61idbjgwd6261euohqn...@mail.gmail.com
Re: using upstart in Debian [was, Re: Debian systemd survey]
On Fri, May 24, 2013 at 11:29:27AM +0100, Dmitrijs Ledkovs wrote: Blog posts are interesting to read, but at times I'd like to look up reference manuals which are more than bear minimal man pages. Whilst systemd ships manpages, the website has either incorrectly formatted wiki-pages and/or eventual links to lennart's blog posts. Where is systemd's documentation? Could you point out where the systemd documentation or website is lacking? Then I'll send the information to systemd-devel. IMO the documentation of systemd is really good. As said by someone else, the systemd version in Debian is not the latest so please look at the latest version. In any case, looking forward to your reply. -- Regards, Olav -- 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/20130524110640.gc24...@bkor.dhs.org
Re: using upstart in Debian [was, Re: Debian systemd survey]
On 24/05/13 11:29, Dmitrijs Ledkovs wrote: As far as I understand (correct me if I am wrong), systemd instead of counting/tracking forks uses cgroups to keep track of the started processes. systemd uses cgroups to track which processes are part of this service?, which means the services may be configured to do traditional Unix daemonization (double-fork), or remain in the foreground, whichever is easier. One advantage of leaving the services forking is that some daemons effectively use the fork() as a signal that they are ready for use (because the point at which they fork and go to the background is the point at which their sysvinit-style init script would exit). For a simple daemon that doesn't fork, init can't necessarily tell when it's actually ready, which can be a problem when doing aggressive parallelization. systemd has several ways to tell that a service is ready, configured with the [Service] Type key in the .service file: the service could fork when it's ready (Type=forking), it could take a D-Bus name when it's ready (Type=dbus), or it could use the systemd-specific sd_notify(3) to tell systemd explicitly (Type=notify). For services that don't do any of those (Type=simple), it can only assume that the service is instantly ready: that's OK when using socket activation, but usually not otherwise. S -- 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/519f4f03.8060...@debian.org
Re: Debian systemd survey
Matthias Urlichs wrote: Steve McIntyre st...@einval.com writes: Matthias wrote: Please also keep in mind that many upstream projects ship systemd service files. Therefore, most of the systemd work is already done too. Most? Really? Do you have stats for that? Given the fact that sysvinit scripts are supported by systemd out-of-the-box, the basic work is already done. So why would you need any stats? That wasn't what was claimed, nor what I asked. -- Steve McIntyre, Cambridge, UK.st...@einval.com It's actually quite entertaining to watch ag129 prop his foot up on the desk so he can get a better aim. [ seen in ucam.chat ] -- 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/e1uftco-000803...@mail.einval.com
Re: Debian systemd survey
On Fri, May 24, 2013 at 08:40:19AM +0200, Marc Haber wrote: On Thu, 23 May 2013 12:50:00 -0700, Steve Langasek vor...@debian.org wrote: Also worth noting: ~/systemd$ find . -name '*.c' | grep -vE 'tests|test/|intl/|udev/' \ | xargs wc -l | tail -n1 149081 total $ find . -name '*.c' | grep -vE 'tests|test/|intl/|udev/' | xargs wc -l \ | tail -n1 31282 total $ Yep, systemd has a larger community of contributors... and weighs in at nearly 5 times the code base. Granted, those 110KLOC may save almost as much lines of code in init scripts. No, this is not the case. Upstart jobs are short, simple, and lacking in shell boilerplate, just as systemd units are. -- 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: using upstart in Debian [was, Re: Debian systemd survey]
Dmitrijs Ledkovs xnox at debian.org writes: Also on technical merits although more philosophically, with Upstart you're expressing yourself in an event-based DSL rather than writing configuration files. It's pretty generic. But unfortunately, that means it's also not entirely straightforward, and, I believe, easier to get wrong. Scott had some explaining blog posts before he left Canonical that I still find confusing (from the POV of just getting a job file done): http://netsplit.com/2010/12/20/events-are-like-methods/ http://netsplit.com/2010/12/03/event-matching-in-upstart/ Since those blog posts were published a coprehensive documentation book was written and is constantly kept up to date. I think you misunderstood me. I was not questioning the documentation here, I was questioning some of the fundamental design choices that Scott's blog posts exposed. While the Upstart team has obviously done good work on documentation, I guess fixing mistakes in the architecture after the fact is going to be hard, if it's even on the radar. Ole -- 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/loom.20130524t181806-...@post.gmane.org
Re: using upstart in Debian [was, Re: Debian systemd survey]
On Fri, May 24, 2013 at 12:29:07PM +0100, Simon McVittie wrote: On 24/05/13 11:29, Dmitrijs Ledkovs wrote: As far as I understand (correct me if I am wrong), systemd instead of counting/tracking forks uses cgroups to keep track of the started processes. systemd uses cgroups to track which processes are part of this service?, which means the services may be configured to do traditional Unix daemonization (double-fork), or remain in the foreground, whichever is easier. One advantage of leaving the services forking is that some daemons effectively use the fork() as a signal that they are ready for use (because the point at which they fork and go to the background is the point at which their sysvinit-style init script would exit). For a simple daemon that doesn't fork, init can't necessarily tell when it's actually ready, which can be a problem when doing aggressive parallelization. Definitely. This is why upstart offers the 'expect fork' and 'expect daemon' options in the first place, and why this limitation in using fork/daemon is important for us to fix. -- 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: Debian systemd survey
On 05/24/2013 04:15 PM, Jonathan Dowland wrote: On Fri, May 24, 2013 at 04:07:06AM +0800, Thomas Goirand wrote: On 05/23/2013 03:55 PM, John Paul Adrian Glaubitz wrote: How on earth does that contradict with the fact that 40%, i.e. the minority of all contributions are done by the original author. 40% still means that 60% of the code comes from other people and those are 145 contributors according to ohloh [1]. It's not this way. Last time I checked, there was another upstream doing about 30% of the work. You keep moving the goal posts! Probably I didn't express myself correctly. Let me try again. First don't take me wrong. It is my view the number of authors in a given project isn't an indication at all of the quality of the said project at all. But... John Paul Adrian Glaubitz wrote: Don't you really have any other good argument to bring up against systemd other than you dislike *one* of the systemd developers? That is making the false impression that Lennart is just one developer out of many, and that therefore we shouldn't care. That isn't truth, he is clearly the main author and by far, and *we should* care. But that's not it. Also, from this page: http://0pointer.de/blog/projects/the-biggest-myths.html [citation] 27 - Myth: systemd is a Red-Hat-only project, is private property of some smart-ass developers, who use it to push their views to the world. Not true. Currently, there are 16 hackers with commit powers to the systemd git tree. Of these 16 only six are employed by Red Hat. The 10 others are folks from ArchLinux, from Debian, from Intel, even from Canonical, Mandriva, Pantheon and a number of community folks with full commit rights. And they frequently commit big stuff, major changes. [/citation] Olav Vitters is right. I shouldn't have call it lies, this is inappropriate and impolite. But maybe one could call it propaganda, seeing the git stats that I posted. What disturbs me a lot, is that what I wrote above is very easy to check, and there is no controversy possible, but other facts of the myth page have also been repeated here, for which I can't say the same thing. Then I wonder how many of these facts are also distorted reality, repeated without any further checks. It worries me that we are having an important discussion with the view of upstream as argumentation, and that some statements will simply never be checked. Steve wrote to begin with: Sure; obviously the right thing to do is to instead take stuff from GNOME and freedesktop.org without regard to integration with our existing system, because if Lennart says it's right it must be so. I agree with what is above. I don't want to just take any random piece of code from Lennart, just because he said it's the latest awesome thing, especially when it's touching every bits of my system. I doubt either of you is going to convince the other, so why not respect the OP and leave it there? I don't understand the OP's post in the first place. What did he need to know that wasn't discussed before? Also, this thread was highly predictable, with or without the OP's post, sooner or later. IMO, the fact that his message sparked the fight^Wdiscussion again isn't relevant. 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/519fd301.40...@debian.org
Re: Debian systemd survey
Thomas Goirand z...@debian.org writes: I don't understand the OP's post in the first place. What did he need to know that wasn't discussed before? The opinions of all the people who have opinions but are uninterested in wading through huge threads to express them, don't read debian-devel at all (the call for survey responses was also sent to Planet Debian), or have been driven away from any discussion of this topic on debian-devel by the hostile, aggressive, confrontational, and nasty tone the participants inevitably take every time it comes up. In other words, it was an attempt to get feedback from a wider variety of people in a structured form, rather than unstructured opinions from only the most vocal and aggressive. Whether it will be successful or useful is another question, but it's certainly *understandable*. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/874nds842r@windlord.stanford.edu
Re: Debian systemd survey
Thomas Goirand z...@debian.org writes: On 05/23/2013 01:45 AM, Josselin Mouette wrote: I understand it will be a pain for Ubuntu if Debian picks a different init system. I don’t think this is relevant for the discussion, though. It might be very relevant for many of us that our package works on *both* Debian and Ubuntu (and other derivative, including those who derive from Ubuntu, like for example Mint) without too much modifications. Some of my packages already incorporate some upstart script for that reason. As someone who packages software that has explicit systemd supporting bits and pieces, which needs to be turned off on Ubuntu (at least pre-raring Ubuntu), I'd like to note that doing this is *simple*. Ubuntu have been patching out the systemd support from the syslog-ng package anyway, doing the same myself for my own packaging was trivial. I needed to make two modifications: remove libsystemd-daemon-dev from build-depends, and not install the unit files. In the future, when there'll be a dh_* tool to do the latter, I will need to do even less. Also, post-raring, systemd is available in Ubuntu aswell, and in some cases, you can check for systemd at runtime, needing no modification to the package *at all*. -- |8] -- 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/87sj1eb26c.fsf@algernon.balabit
Re: Debian systemd survey
On 23/05/13 at 12:28 +0800, Thomas Goirand wrote: On 05/22/2013 04:53 AM, Lucas Nussbaum wrote: - Neither systemd nor upstart are likely to be ported to kfreebsd soon, as they both rely on many Linux-specific features and interfaces. Though it should be easy enough to port OpenRC to kFreeBSD and Hurd, once it completes its support for the current init.d scripts. You completely forgot that option. The only thing that worries me is the cgroup thing, but probably it should be possible to fallback to .pid files in such case (in an automated way). I have the (possibly wrong) impression that OpenRC is less advanced technically than systemd and upstart, and lacks many of their advantages For example, according to https://bugs.gentoo.org/show_bug.cgi?id=391945 which is linked from http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems, parallel boot does not work due to problems in dependency handling. I also understand that OpenRC does not replace sysvinit, but instead is an additional layer on top of it (for example, sysvinit stays PID 1). Also, you wrote: On 14/05/13 at 17:54 +0800, Thomas Goirand wrote: I do think that restarting crashed daemons is a nice feature, yes. Though I believe OpenRC has this feature too (I have no time to check for that fact right now, but I think I remember reading it somewhere). According to http://wiki.gentoo.org/wiki/Comparison_of_init_systems, OpenRC does not have this feature (No in Keeping daemons alive). I'm not saying that OpenRC should be excluded right now. I'm open to be proven wrong. :) And actually, I'd recommend that once you are reasonably sure that OpenRC is a viable alternative, you follow the same path as for other init systems (policy support, explore how it can co-exist in the archive, explore how we could transition to it, etc.) Lucas signature.asc Description: Digital signature
Re: Debian systemd survey
Lucas Nussbaum lu...@debian.org writes: - there are 300+ upstart job files ready to be imported from Ubuntu FWIW, there are a similar (if not more) number of systemd service files we can look at and import from: Fedora, openSUSE, Arch and possibly a few others too. (This I find to be a great strength of systemd by the way: it is (or is becoming) the default on not only one, but multiple unrelated distributions.) -- |8] -- 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/87obc2b1t8.fsf@algernon.balabit
Re: Debian systemd survey
On 05/23/2013 06:56 AM, Thomas Goirand wrote: * As you may know, systemd is developed by a large amount of contributors. If you are tired of seeing the same arguments, Personal insults is something you call arguments? You have a weird method of discussion ... don't post things which have already been debunked as well. You are doing the very same thing that you are complaining about: I already posted in this list the git log stats, and Lennart owns more than 40% of all the commits. So no, Lennart is not just *one* of the systemd developers, he's the main one, and by far. You didn't debunk anything, you're interpreting statements wrong and obviously don't know your math. Please re-read what I said, which is As you may know, systemd is developed by a large amount of contributors How on earth does that contradict with the fact that 40%, i.e. the minority of all contributions are done by the original author. 40% still means that 60% of the code comes from other people and those are 145 contributors according to ohloh [1]. OpenRC has 19 [2], upstart has even only 7 [3] contributors. So, yeah, systemd is definitely the project which has the largest amount of contributors which was exactly my point. Adrian [1] http://www.ohloh.net/p/systemd [2] http://www.ohloh.net/p/openrc [3] http://www.ohloh.net/p/upstart -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/519dcb7d.9010...@physik.fu-berlin.de
Re: Debian systemd survey
On Thu, May 23, 2013 at 09:55:41AM +0200, John Paul Adrian Glaubitz wrote: On 05/23/2013 06:56 AM, Thomas Goirand wrote: As you may know, systemd is developed by a large amount of contributors How on earth does that contradict with the fact that 40%, i.e. the minority of all contributions are done by the original author. 40% still means that 60% of the code comes from other people and those are 145 contributors according to ohloh [1]. OpenRC has 19 [2], upstart has even only 7 [3] contributors. So, yeah, systemd is definitely the project which has the largest amount of contributors which was exactly my point. Did you include the stats for all projects systemd wants to replace as well? For just one piece: * busybox-syslogd * dsyslog * inetutils-syslogd * rsyslog * socklog-run * syslog-ng-core -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- 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/20130523094359.ga9...@angband.pl
Re: Debian systemd survey
Le jeudi 23 mai 2013 à 11:43 +0200, Adam Borowski a écrit : Did you include the stats for all projects systemd wants to replace as well? For just one piece: * busybox-syslogd * dsyslog * inetutils-syslogd * rsyslog * socklog-run * syslog-ng-core For the Xth time (with X becoming rather large now): systemd does not replace syslog. It complements it with new features. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1369308569.12592.205.camel@pi0307572
Re: Debian systemd survey
On 05/23/2013 11:43 AM, Adam Borowski wrote: Did you include the stats for all projects systemd wants to replace as well? For just one piece: * busybox-syslogd * dsyslog * inetutils-syslogd * rsyslog * socklog-run * syslog-ng-core Well, how many of these are actually used in the real world? Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/519e0751.4000...@physik.fu-berlin.de
Re: Debian systemd survey
Le mercredi 22 mai 2013 à 15:05 -0700, Steve Langasek a écrit : There certainly have been cases of fd.o changes being dropped into Debian without dealing with the integration questions. mime - .desktop is a prime example of this. .desktop is clearly far superior - but that doesn't mean it's ok to drop the existing stuff on the floor. This is a perfect example of how hard it is to make Debian as a whole evolve. We have kept the old mime-support entries for a long time, until just a handful of widespread packages remained to use them, based on the promise that one day, mime-support would use desktop entries. Yet it took provocative measures, such as removing widely used entries, to make it finally happen for real, because otherwise there was no incentive on the people who were interested to make it happen. So if your comment is a fair critique of upstart proponents, then mine is an equally fair critique of systemd proponents. I’m not criticizing the fact that upstart comes from Ubuntu. I disagree with the idea of having Ubuntu as the sole origin of innovation in the project. It gives bad habits to both Debian and Ubuntu if the natural thing to do to make things happen in Debian is to make them happen in Ubuntu first. For a comparable innovation, I’m thankful to Canonical for making multiarch happen, but the fact that we have waited for Ubuntu to make it happen is the symptom of a Debian problem that needs solving. I'd be happy to hear you expand on how you think systemd integrates better with the existing system in Debian. I certainly don't see that this is the case - particularly when the systemd dbus services, which people have told me are so essential a component of the GNOME desktop going forward, had no tested backend that integrated with the Debian locations for system-level config files until I provided one for Ubuntu. I don’t think FHS compliance is often a big problem. It is important to us, but usually it does not take a lot of patching to fix it, even for very FHS-unfriendly upstreams. On the other hand, being able to re-use most of our existing init scripts, with zero to little modification, is a big advantage of systemd. The fact that the unit file syntax is purely declarative also makes it easier to interface with the existing, such as generating init files from service files. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1369311463.12592.258.camel@pi0307572
Re: Debian systemd survey
Josselin Mouette writes (Re: Debian systemd survey): Le mercredi 22 mai 2013 à 15:05 -0700, Steve Langasek a écrit : There certainly have been cases of fd.o changes being dropped into Debian without dealing with the integration questions. mime - .desktop is a prime example of this. .desktop is clearly far superior - but that doesn't mean it's ok to drop the existing stuff on the floor. This is a perfect example of how hard it is to make Debian as a whole evolve. We have kept the old mime-support entries for a long time, until just a handful of widespread packages remained to use them, based on the promise that one day, mime-support would use desktop entries. Yet it took provocative measures, such as removing widely used entries, to make it finally happen for real, because otherwise there was no incentive on the people who were interested to make it happen. I see this quite differently. The problem was that you didn't want to do the work required to transition properly, and instead decided to try to bounce everyone into dropping the old machinery entirely. Indeed that's why you were overruled by the Technical Committee, who clearly don't agree with your interpretation of the situation. Ian. -- 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/20894.5018.847071.278...@chiark.greenend.org.uk
Re: Debian systemd survey
On Thu, 23 May 2013 14:17:43 +0200 Josselin Mouette j...@debian.org wrote: So if your comment is a fair critique of upstart proponents, then mine is an equally fair critique of systemd proponents. I’m not criticizing the fact that upstart comes from Ubuntu. I disagree with the idea of having Ubuntu as the sole origin of innovation in the project. It gives bad habits to both Debian and Ubuntu if the natural thing to do to make things happen in Debian is to make them happen in Ubuntu first. For a comparable innovation, I’m thankful to Canonical for making multiarch happen, but the fact that we have waited for Ubuntu to make it happen is the symptom of a Debian problem that needs solving. Multi-Arch in Debian could have moved faster but Debian has a more complex use-case for Multi-Arch than Ubuntu and was in freeze longer. Innovation involves making mistakes and fixing things quickly - some of that comes from having repositories to which uploads can be made quickly and independently of processes not directly involved with that particular development path, e.g. transitions in unrelated packages, release freeze when the development path is not yet stable etc. Debian is moving in a direction which can fix these problems by making archives accessible in a way which does not have to affect everyone else. Making (or allowing for) mistakes in a large project is too disruptive to allow in the main flow of the project. We need sandboxes which are more than just a few local chroots and I'm very glad to see that this is being implemented. Debian has a reputation for stability and reliable releases. Innovations like this should be able to ease the release process, keep Debian releases just as stable as before and make things easier for those who do want to drive innovative ideas within Debian itself. There's no need to think that all future innovation will be constrained by previous Debian workflows. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpbw0OMtEQBW.pgp Description: PGP signature
Re: Debian systemd survey
On Wed, May 22, 2013 at 09:22:22PM +0200, Martin Wuertele wrote: Actually it's just a response to the ongoing insulting by joss to variouse participants on mailinglists. As usual he has a way of mailing that i find disgusting. I don't find yours to be much better. You know why many projects are adopting many technologies that are developed by RedHat people? It's because RedHat is an excellent upstream and they are one of the largest contributors to the whole Linux software stack, be it the kernel or anything above. In many projects yes, in some no. Current kernel development, tough an understandable way to compete with Oracle, is not as cooperative as it was. There are more projects than kernel patches, though. And they argued that they contribute to upstream, which is true, although the backport situation is nothing to be proud of, I agree. There are a bunch of projects started by RedHat (not in private as systemd) that are useful to the community. See http://et.redhat.com/ for instance. Actually in ubuntu happened a lot of multiarch development before it ended up in debian. And we still need to cope with the problems Ubuntu didn't have by design. ;-) Actually that is not true. With some projects they both do a good job while with others they suck, it depends mainly on the actual persons involved. As with RedHat, I guess. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Debian systemd survey
On Thu, May 23, 2013 at 09:11:55AM +0200, Gergely Nagy wrote: Also, post-raring, systemd is available in Ubuntu aswell, and in some cases, you can check for systemd at runtime, needing no modification to the package *at all*. What's available in Ubuntu are the systemd dbus services, the libraries, and a little-known daemon called 'udev'. The systemd init is *not* in Ubuntu and there are no plans to change that. -- 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: Debian systemd survey
On May 23, 2013, at 02:17 PM, Josselin Mouette wrote: I’m not criticizing the fact that upstart comes from Ubuntu. I disagree with the idea of having Ubuntu as the sole origin of innovation in the project. It gives bad habits to both Debian and Ubuntu if the natural thing to do to make things happen in Debian is to make them happen in Ubuntu first. For a comparable innovation, I’m thankful to Canonical for making multiarch happen, but the fact that we have waited for Ubuntu to make it happen is the symptom of a Debian problem that needs solving. I don't think it's necessarily a bad thing for Debian and Ubuntu to have this kind of symbiotic relationship. Maybe from a Debian point of view, it shouldn't be necessary, but given the current realities of differing release schedules, goals, focus, and resources, where such an arrangement exists, I think it can - and should - be used for mutual benefit. This of course requires good coordination between the parties involved in both distributions, and motivated people in both camps that want to strengthen collaboration. Of course, some folks will only have feet in one or the other, and that's fine too. Some recent examples include transitions we've seen in the Python world. The push for dh_python2, the push for Python 3 support, and the transition to newer versions of the interpreter are all great examples (IMHO) where Debian and Ubuntu worked together to come to some semblance of consensus, and where Ubuntu, by benefit of its timed release schedule was able to be more aggressive in adopting some of those transitions. It was also able to experience and alleviate some of the pain first too. But this was *always* done with the goal of ensuring those changes would get pushed back into Debian when the time was right. In such cases, the assistance, insight, expertise, resources, and feedback of experienced Debian developers was crucial. It's usually (but not always) easier to get changes that appear in Debian first, migrated into Ubuntu. IME, it's often harder to get changes from Ubuntu into Debian. I think there's ample opportunity to help make this barrier lower on both sides of the pond. Some of the hurdles include: - Team based vs. individual maintainership. In Ubuntu, no one person (or group of people) maintains any package. There's a strong sense of team for maintaining packages. This has an advantage in that important updates need not block on availability, workload, vacations, etc. of individual maintainers (not that it can't block on other reasons). In Debian, teams like PAPT and DPMT do help with this. - Membership differences. I am currently sitting on the Ubuntu Developer Membership Board, and I am in the final stages of my DD application. Applying for DD was way more thorough than achieving core-dev in Ubuntu. Now, this may or may not be a good thing, but one of the key things that the DMB is addressing is how to streamline approval for DDs. It should be fairly clear that a DD has the requisite technical expertise to package things for Ubuntu, so the initial interaction with the DMB can (mostly) accept that as a given, and thus explore other requirements of Ubuntu membership. Hopefully (and I'd like to hear if otherwise) this means that a DD who wants to also contribute to Ubuntu, should be able to get the needed permissions fairly quickly and easily. In Debian, it would be nice if the process were made easier, or more inviting for Ubuntu developers[1]. - Tool mismatches. I just wish it were easier to build packages for both Debian and Ubuntu, but the tools chains are sufficiently different that it's difficult to switch your (well, *my* ;) brain into Debian mode from Ubuntu mode and vice versa. Part of it is dealing with Ubuntu Distribute Development (UDD), which I'm very comfortable with, and which gives me a source-full checkout of a package (debian/ + unpacked upstream) all managed in a DVCS branch. I can grab the source for any version of any package on any release of Ubuntu (and actually, Debian too!) through Launchpad[2], so it's easy to make a change, do merges from Debian or upstream, build it locally, test it, and upload it. I personally find the Debian tools (svn instead of a dvcs, debian/ only directory) harder to deal with, but maybe that's just me. I've said before that as much as I dislike git, if Debian had something like UDD+bzr but git based and more interoperable with quilt packages, I'd use it. Also, I do think that Ubuntu's source-only uploads are a win. PPAs are nice too, as are the new -proposed pocket for the in-development release. - All is not roses in Ubuntu-land though. When uploads to Debian are delayed (e.g. because of release freezes), then Ubuntu can get ahead of Debian in ways that are more difficult to untangle. Ubuntu's auto-import from Debian gets blocked whenever a package has an -NubuntuM version number. These take
Re: Debian systemd survey
* Philipp Kern pk...@debian.org [2013-05-23 15:39]: On Wed, May 22, 2013 at 09:22:22PM +0200, Martin Wuertele wrote: Actually it's just a response to the ongoing insulting by joss to variouse participants on mailinglists. As usual he has a way of mailing that i find disgusting. I don't find yours to be much better. True, I should have followed George Carlins advice and not argued. -- 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/20130523162913.gh13...@anguilla.debian.or.at
Re: Debian systemd survey
On Wed, 22 May 2013 19:40:57 +0200, Matthias Klumpp matth...@tenstral.net wrote: Please also keep in mind that many upstream projects ship systemd service files. Therefore, most of the systemd work is already done too. Are those any better than init scripts shipped by upstream? How many Debian packages use upstream init scripts verbatim? 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/e1ufyyy-0003pj...@swivel.zugschlus.de
Re: Debian systemd survey
On Thu, May 23, 2013 at 07:07:16PM +0200, Marc Haber wrote: Please also keep in mind that many upstream projects ship systemd service files. Therefore, most of the systemd work is already done too. Are those any better than init scripts shipped by upstream? How many Debian packages use upstream init scripts verbatim? That's one of the most important problems with sysvinit. -- WBR, wRAR signature.asc Description: Digital signature
Re: Debian systemd survey
2013/5/23 Marc Haber mh+debian-de...@zugschlus.de: On Wed, 22 May 2013 19:40:57 +0200, Matthias Klumpp matth...@tenstral.net wrote: Please also keep in mind that many upstream projects ship systemd service files. Therefore, most of the systemd work is already done too. Are those any better than init scripts shipped by upstream? How many Debian packages use upstream init scripts verbatim? One of the great goals of systemd is to unify init-scripts on all Linux systems. The systemd unit files are entirely declarative and work the same way on all Linux distributions (I recently spoke with Mageia, Fedora and OpenSUSE people about how well this works - very well so far :) ) And that is the reason why they can be shipped upstream. If some tweaking is needed, the changes can even be upstreamed again, so everyone benefits from the changes. Cheers, Matthias P.S: @all: Please keep in mind that systemd is not just an init system, but contains many other buiĺding blocks to create an operating system, e.g. journald to create better syslogs (it forwards messages to traditional syslog, so no worries about binary stuff), logind as replacement for ConsoleKit and to finally get multiseat support working again, hostnamectl, udev and many other tools daemons which make it much nicer to administer a system and to abstract differences between distributions (which makes writing applications (for Linux) so much better...). -- 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/caknhny-xm8bxgf5dsmzfnzr7ncp86b_gqjjmcxigvf_fule...@mail.gmail.com
Re: Debian systemd survey
On Thu, May 23, 2013 at 09:55:41AM +0200, John Paul Adrian Glaubitz wrote: don't post things which have already been debunked as well. You are doing the very same thing that you are complaining about: I already posted in this list the git log stats, and Lennart owns more than 40% of all the commits. So no, Lennart is not just *one* of the systemd developers, he's the main one, and by far. You didn't debunk anything, you're interpreting statements wrong and obviously don't know your math. Please re-read what I said, which is As you may know, systemd is developed by a large amount of contributors How on earth does that contradict with the fact that 40%, i.e. the minority of all contributions are done by the original author. 40% still means that 60% of the code comes from other people and those are 145 contributors according to ohloh [1]. So, yeah, systemd is definitely the project which has the largest amount of contributors which was exactly my point. The problem isn't that your statements are false, it's that they're twisted propaganda. A large number of contributors to an *init system* is not something that should be a goal in and of itself. There's a certain level of sustainability that we should be concerned about meeting; but that doesn't require a community of hundreds of committers. Feel free to check how many committers sysvinit has had over the past decade - we're pushing to move away from sysvinit not because it didn't have enough committers, but because we believe a new architecture is needed. Furthermore, the statistics for systemd are themselves a distortion. The only reason Lennart shows up as being responsible for a minority of the code in systemd is because systemd gobbled up udev whole. If we look at line count rather than number of commits (which I would argue is a better measure), and exclude the udev code, we get: $ find . -name '*.c'|grep -v udev | xargs -n1 git blame --line-porcelain \ | sed -n 's/^author //p' | sort | uniq -c | sort -rn | head -n1 120124 Lennart Poettering $ find . -name '*.c'|grep -v udev | xargs wc -l | tail -n1 153404 total $ And even then, that includes dbus services and other things not related to the init daemon. 78% is not a minority. But this isn't the statistic that gets trotted out by people advocating for systemd; instead, they always cherry-pick the statistics that paint it in the most favorable light. Because systemd advocates are not trying to win on technology, they're trying to win on marketing. Also worth noting: ~/systemd$ find . -name '*.c' | grep -vE 'tests|test/|intl/|udev/' \ | xargs wc -l | tail -n1 149081 total $ find . -name '*.c' | grep -vE 'tests|test/|intl/|udev/' | xargs wc -l \ | tail -n1 31282 total $ Yep, systemd has a larger community of contributors... and weighs in at nearly 5 times the code base. Which of these is the more important attribute for an init, I wonder? Disclaimer: this comparison will catch files that are not part of init. Feel free to slice and dice this differently to make the case that systemd init is not bloated... and publish your methodology so we can be sure to check how many committers that section of the code actually has. OpenRC has 19 [2], upstart has even only 7 [3] contributors. [1] http://www.ohloh.net/p/systemd [2] http://www.ohloh.net/p/openrc [3] http://www.ohloh.net/p/upstart Ohloh statistics are of dubious value. Counting contributors to upstart using a more direct method shows me 17 committers - small but not miniscule, and not a mark of an unsustainable project. I'm not going to bother generating stats showing who's contributed how many lines to this, because I don't think that's actually the useful metric - I just object to people claiming this high ground for systemd when it's not materially true. Feel free to run these stats yourself if you wish. -- 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: Debian systemd survey
On Thu, 23 May 2013 19:34:09 +0200, Matthias Klumpp matth...@tenstral.net wrote: P.S: @all: Please keep in mind that systemd is not just an init system, but contains many other bui?ding blocks to create an operating system, e.g. journald to create better syslogs (it forwards messages to traditional syslog, so no worries about binary stuff), logind as replacement for ConsoleKit and to finally get multiseat support working again, hostnamectl, udev and many other tools daemons which make it much nicer to administer a system and to abstract differences between distributions (which makes writing applications (for Linux) so much better...). Yes, systemd trying to replace so much of traditional UNIX tools at once and so blatantly breaking the One job one tool principle that has made our platform so successful is one major part of the acceptance issues that systemd has in Debian. 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/e1ufbmf-0003xz...@swivel.zugschlus.de
Re: Debian systemd survey
On 05/23/2013 03:55 PM, John Paul Adrian Glaubitz wrote: On 05/23/2013 06:56 AM, Thomas Goirand wrote: * As you may know, systemd is developed by a large amount of contributors. If you are tired of seeing the same arguments, Personal insults is something you call arguments? You have a weird method of discussion ... Sorry, that is probably badly translated from French. I meant as argumentation, or discussion point. I'm not sure if you got it now. There was nothing about insults or anything like this. How on earth does that contradict with the fact that 40%, i.e. the minority of all contributions are done by the original author. 40% still means that 60% of the code comes from other people and those are 145 contributors according to ohloh [1]. It's not this way. Last time I checked, there was another upstream doing about 30% of the work. The rest of is probably small patches contributed here and there. Run The facts are that there's no big community working on Systemd. There's 2 main authors, and a crowd sending smaller (tiny?) contributions. OpenRC has 19 [2], upstart has even only 7 [3] contributors. So, yeah, systemd is definitely the project which has the largest amount of contributors which was exactly my point. I'm still not convinced. Don't trust the lies from Lennart, the git clone tells the truth: 4528 Lennart Poettering lenn...@poettering.net 3291 Kay Sievers k...@vrfy.org 676 Greg KH g...@kroah.com 541 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl 274 Michal Schmidt mschm...@redhat.com 190 Martin Pitt martinp...@gnome.org 171 Harald Hoyer har...@redhat.com There is no other contributor that has done more than 100 patches. If you count people who contributed even a single patch, there's in total 421 contributors (but that is not the point, is it?). (just did a git pull before running the stats...) BTW, why did you make me repeat myself? Couldn't you search in the list archive? And in what way is this a technical argumentation to choose a init system? What are you trying to prove here? 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/519e76ea.2080...@debian.org
Re: Debian systemd survey
On 05/23/2013 03:15 PM, Lucas Nussbaum wrote: I have the (possibly wrong) impression that OpenRC is less advanced technically than systemd and upstart, and lacks many of their advantages For example, according to https://bugs.gentoo.org/show_bug.cgi?id=391945 which is linked from http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems, parallel boot does not work due to problems in dependency handling. I don't think that taking any random bug (which is a can, not always) is fair. I also understand that OpenRC does not replace sysvinit, but instead is an additional layer on top of it (for example, sysvinit stays PID 1). I believe that is a very strong thing in *favor* of OpenRC. Why on earth do you need to reimplement the PID 1 for booting your system? It works very well, and doesn't need to be changed and over-engineered. All the logic is done away from it, in its child PIDs, because PID 1 is a very dangerous place to hack (if it crashes, your whole system is dead). I'm not saying that OpenRC should be excluded right now. I'm open to be proven wrong. :) And actually, I'd recommend that once you are reasonably sure that OpenRC is a viable alternative, you follow the same path as for other init systems (policy support, explore how it can co-exist in the archive, explore how we could transition to it, etc.) Actually, I believe that OpenRC transition should be one of the most smooth of all the init systems, once the port to Debian is done, and when the support for existing LSB header is tackled (we already have some script in both python and perl to handle automatic conversion of the LSB header). Meaning that we could simply replace sysvrc with OpenRC, have all the nice added features (cgroups, nicer headers than LSB headers, tiny small init scripts), and still continue to have the possibility to keep large, bulky init scripts, if that is your thing. They all coexist together, you just decide what you wish to implement. What I like the most with it is that it is very, very simple, and easy to hack. I think I wrote too much already. I would prefer to be able it does rather than it could. 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/519e7a67.7080...@debian.org
Re: Debian systemd survey
On Thu 23 May 2013 12:50:00 Steve Langasek wrote: 78% is not a minority. But this isn't the statistic that gets trotted out by people advocating for systemd; instead, they always cherry-pick the statistics that paint it in the most favorable light. Because systemd advocates are not trying to win on technology, they're trying to win on marketing. …and politics. – Jubal -- Somewhere, just out of sight, the unicorns are gathering. -- 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/1723455.LqBqR2euQA@metatron
Re: Debian systemd survey
Le jeudi 23 mai 2013 à 22:06 +0200, Marc Haber a écrit : Yes, systemd trying to replace so much of traditional UNIX tools at once and so blatantly breaking the One job one tool principle that has made our platform so successful is one major part of the acceptance issues that systemd has in Debian. I’d bother answering to that, but Lennart already did. Myth #1: http://0pointer.de/blog/projects/the-biggest-myths.html Systemd is just as much monolithic as, say, coreutils. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1369343884.10252.5.camel@tomoyo
Re: Debian systemd survey
On Thu, May 23, 2013 at 11:18:04PM +0200, Josselin Mouette wrote: Le jeudi 23 mai 2013 à 22:06 +0200, Marc Haber a écrit : Yes, systemd trying to replace so much of traditional UNIX tools at once and so blatantly breaking the One job one tool principle that has made our platform so successful is one major part of the acceptance issues that systemd has in Debian. I’d bother answering to that, but Lennart already did. Myth #1: http://0pointer.de/blog/projects/the-biggest-myths.html Systemd is just as much monolithic as, say, coreutils. I can use only parts of coreutils if I desire. Also, coreutils does not start services on startup that I do not need. systemd, on the other hand, has spawned systemd-journald, which I do not want or need, which is autorestarted, and which cannot be stopped with service. Since I am not using its functionality, there is no point in having the service running. rsyslog is very capable. Also, traditionally init has been limited to starting and stopping groups of services. It has not been involved in logging, session management, seat management, hotkey handling, or suspend and resume, except perhaps to start and stop the services which perform those functions. However well-intentioned, systemd does a lot more than init traditionally has, and definitely encroaches into areas that were not traditionally init-related. The Unix Way is to use separate processes for separate tasks. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Debian systemd survey
On Thu, May 23, 2013 at 02:10:57PM +0200, John Paul Adrian Glaubitz wrote: On 05/23/2013 11:43 AM, Adam Borowski wrote: Did you include the stats for all projects systemd wants to replace as well? For just one piece: * busybox-syslogd * dsyslog * inetutils-syslogd * rsyslog * socklog-run * syslog-ng-core Well, how many of these are actually used in the real world? rsyslog is priority important and is the default syslog implementation in Debian. It's also the default in Fedora. I think we can be confident that it gets lots of real-world use. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Debian systemd survey
2013/5/24 brian m. carlson sand...@crustytoothpaste.net: On Thu, May 23, 2013 at 11:18:04PM +0200, Josselin Mouette wrote: Le jeudi 23 mai 2013 à 22:06 +0200, Marc Haber a écrit : Yes, systemd trying to replace so much of traditional UNIX tools at once and so blatantly breaking the One job one tool principle that has made our platform so successful is one major part of the acceptance issues that systemd has in Debian. I’d bother answering to that, but Lennart already did. Myth #1: http://0pointer.de/blog/projects/the-biggest-myths.html Systemd is just as much monolithic as, say, coreutils. I can use only parts of coreutils if I desire. Also, coreutils does not start services on startup that I do not need. systemd, on the other hand, has spawned systemd-journald, which I do not want or need, which is autorestarted, and which cannot be stopped with service. Since I am not using its functionality, there is no point in having the service running. rsyslog is very capable. Also, traditionally init has been limited to starting and stopping groups of services. It has not been involved in logging, session management, seat management, hotkey handling, or suspend and resume, except perhaps to start and stop the services which perform those functions. However well-intentioned, systemd does a lot more than init traditionally has, and definitely encroaches into areas that were not traditionally init-related. The Unix Way is to use separate processes for separate tasks. ...and this is what systemd does! It's not like we have an event-logger, hotkey-handling and seat-management all in pid0. It is all nicely split into separate processes. The journal is mainly used to produce structured logs and to log the early boot process (which I find *very* nice, it helped me a lot already!), but you can turn it's functionality off[1]. There will be a reason why it cannot be removed completely too. I think it is valid to see systemd as a compilation of basic tools for a Linux system, which also includes an init-system. Cheers, Matthias [1] http://www.freedesktop.org/software/systemd/man/journald.conf.html -- 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/caknhny8o9oejylxe5uzbjychooevsoncztxanddpvqfqv32...@mail.gmail.com
Re: Debian systemd survey
On Fri, May 24, 2013 at 01:45:46AM +0200, Matthias Klumpp wrote: 2013/5/24 brian m. carlson sand...@crustytoothpaste.net: The Unix Way is to use separate processes for separate tasks. ...and this is what systemd does! It's not like we have an event-logger, hotkey-handling and seat-management all in pid0. It is all nicely split into separate processes. The journal is mainly used to produce structured logs and to log the early boot process (which I find *very* nice, it helped me a lot already!), but you can turn it's functionality off[1]. Yes, systemd uses separate processes, but they are not independent. They cannot be independently turned off. If I decide I do not want the journal features, however useful others might think they are, I should not have to resort to chmod and dpkg-statoverride to keep them from running. Let them be optional features which the core systemd can be used without. There will be a reason why it cannot be removed completely too. I think it is valid to see systemd as a compilation of basic tools for a Linux system, which also includes an init-system. The problem is that it would be great as just an init system. I love it as an init system: it boots very, very fast and shuts down very, very fast. But that's all I want it to do: be an init system. I *have* a syslog daemon. I *have* tools to handle hotkeys. It should be a great init system, and (at least be able to be configured to be) *absolutely nothing else*: one small, limited process with PID 1. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Debian systemd survey
2013/5/24 brian m. carlson sand...@crustytoothpaste.net: On Fri, May 24, 2013 at 01:45:46AM +0200, Matthias Klumpp wrote: 2013/5/24 brian m. carlson sand...@crustytoothpaste.net: The Unix Way is to use separate processes for separate tasks. ...and this is what systemd does! It's not like we have an event-logger, hotkey-handling and seat-management all in pid0. It is all nicely split into separate processes. The journal is mainly used to produce structured logs and to log the early boot process (which I find *very* nice, it helped me a lot already!), but you can turn it's functionality off[1]. Yes, systemd uses separate processes, but they are not independent. They cannot be independently turned off. If I decide I do not want the journal features, however useful others might think they are, I should not have to resort to chmod and dpkg-statoverride to keep them from running. Let them be optional features which the core systemd can be used without. I will ask about the journal reasoning, but most of the other tools are usable without systemd (like hostnamed, systemd-detect-virt, systemd-tmpfiles, systemd-udevd, ...). There are some, like logind, which use systemd internals to (e.g. here make multiseat possible). Ubuntu carries patches downstream to make logind work without systemd but with upstart instead, but I don't think that doing that is a sane solution. There will be a reason why it cannot be removed completely too. I think it is valid to see systemd as a compilation of basic tools for a Linux system, which also includes an init-system. The problem is that it would be great as just an init system. I love it as an init system: it boots very, very fast and shuts down very, very fast. But that's all I want it to do: be an init system. I *have* a syslog daemon. I *have* tools to handle hotkeys. It should be a great init system, and (at least be able to be configured to be) *absolutely nothing else*: one small, limited process with PID 1. One of the goals of systemd is to unify all the different solutions available on Linux to handle stuff the same way or to at least define stable interfaces for application developers and administrators to use. This is also a reason why it is at Freedesktop ;-) (but mainly because fd.o provides vendor- and project-independent code hosting).I like systemd *especially* for providing these interfaces as cross-distro interoperability, but I understand if some people don't welcome it. Regarding tools, depending on the packaging, it should be possible to replace most of them or use different implementations. Systemd is very modular in that regard. Also, systemd spawns one process with minimal dependencies and less code - most of the other features are stored in separate binaries, which may or may not exist. This modularity is proven by Ubuntu, which manages to ship the systemd services in an extra package to provide interfaces to logind (although I don't like this approach, it is great to have most of the interfaces available on Ubuntu too now). Cheers, Matthias -- 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/CAKNHny-Yx7yjbt6GT936MQ9ybJubeUh33CW5GKogB=8rebi...@mail.gmail.com
Re: Debian systemd survey
Steve Langasek vor...@debian.org writes: [...] by people advocating for systemd; instead, they always cherry-pick the statistics that paint it in the most favorable light. Because systemd advocates are not trying to win on technology, they're trying to win on marketing. Please don't make such generalizations. They make the rest of your points look a lot weaker than they probably are. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- 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/87ppwhcg5n@vostro.rath.org
Re: Debian systemd survey
On 22/05/13 at 05:50 +0300, Uoti Urpala wrote: Lucas Nussbaum wrote: I went through the various init systems threads again during the last few days. My understanding of the consensus so far is the following: - Both systemd and upstart bring many useful features, and are a clear improvement over sysvinit. Yes, both are an improvement over sysvinit. It is not clear which one of systemd or upstart is the best on the technical level. Many of the differences have grounds in differences of philosophy, which can easily be seen as pros or cons. I think this is false, both as a description of fact and as a description of claimed consensus view. Systemd has advanced significantly further than upstart, and this is more a technical reality than a matter of opinion like something such as preferred GUI behavior; this is better compared to whether Linux or MINIX was a more promising platform for future development in the 1990s. There is a lack of consensus, rather than a consensus that it's a matter of opinion or philosophy with no clear technical arguments. We can argue for a long time about which one is technically better. The result of that discussion does not matter much (since you are invoking Linux vs MINIX, look at Hurd vs Linux). If I were you, I would be very worried about the risk that the decision will be taken not by looking at which one is the best, but by looking at which one is de-facto supported in Debian. In that area, systemd is very late, since: - AFAIK nobody has started the effort to document things in policy - there are 300+ upstart job files ready to be imported from Ubuntu So, please work on: - policy support - outlining how systemd and sysvinit can properly co-exist in the archive (this is required in any case for the duration of the transition) - outlining how the transition could be achieved, eased, and tracked Lucas -- 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/20130522061634.ga25...@xanadu.blop.info
Re: Debian systemd survey
On 05/21/2013 10:53 PM, Lucas Nussbaum wrote: - Neither systemd nor upstart are likely to be ported to kfreebsd soon, as they both rely on many Linux-specific features and interfaces. What about launchd? Wouldn't it be possible to port that to Debian/kFreeBSD? It's designed to run in a BSD userland, after all. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/519c7077.5040...@physik.fu-berlin.de
Re: Debian systemd survey
John Paul Adrian Glaubitz glaubitz at physik.fu-berlin.de writes: On 05/21/2013 10:53 PM, Lucas Nussbaum wrote: - Neither systemd nor upstart are likely to be ported to kfreebsd soon, as they both rely on many Linux-specific features and interfaces. And this is one more reason to continue supporting sysvinit with file-rc and sysv-rc: having a unique system across kernels. What about launchd? Wouldn't it be possible to port that to Debian/kFreeBSD? It's designed to run in a BSD userland, after all. Debian GNU/kFreeBSD has GNU userland, not BSD userland. That’s why it’s named like that. bye, //mirabilos -- 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/loom.20130522t100014-...@post.gmane.org
Re: Debian systemd survey
Uoti Urpala wrote: A related point which I think is very important is the effect of Debian's decision on the larger community. Having Linux distributions permanently split in systemd and upstart camps would have major costs for the overall Linux community. Actually, in the EU this is called antitrust and considered a good thing for a âmarketâ, also increasing innovation by open competition. Systemd is already guaranteed to live, Yeah, in a proprietary RedHat world⦠could easily switch to. Maintaining and extending such a split between distros should be seen as a big negative, regardless of how upstart No, it should be seen as a bit *positive*, for the aforementioned reason as well as for reasons already seen on the list. IMO essentially irrelevant distractions such as effects on marginal systems like kFreeBSD shouldn't be brought up at all. Like it or not, but kFreeBSD *is* now part of the ecosystem. And I still think internal consistency is something desirable, so sysvinit should stay the default, with other init systems (yes this does include OpenRC) available for these who want to use it. As Debian, we have two different problems: 1. We need to decide which init systems we want to support, and how. 2. We need to decide which init system should be the default. We will have a GR about that. I don't think it's at all obvious that it would make sense to support more than systemd Debian is the Universal Operating System, not GNOME OS. If you want to develop GNOME OS, please do it as a Derivate or Blend, or something entirely separate. Really, reading this makes Rogerâs (IIRC) suggestion of removing it entirely all that more enticing⦠fit-for-use maintenance of all three systems sounds like a rather costly I see it like with new ports: if a new init system wants to be supported, they should help the package maintainers along in providing support, while the individual package maintainers should be gently encouraged to actually include said patches. And sysvinit is still the gold standard. (I personally like BSD stuff more, but from what Debian provides itâs the least evil or rather the one most people can agree to work with.) bye, //mirabilos -- 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/knhv7i$3vs$1...@ger.gmane.org
Re: Debian systemd survey
]] Lucas Nussbaum If I were you, I would be very worried about the risk that the decision will be taken not by looking at which one is the best, but by looking at which one is de-facto supported in Debian. In that area, systemd is very late, since: - AFAIK nobody has started the effort to document things in policy - there are 300+ upstart job files ready to be imported from Ubuntu So, please work on: - policy support - outlining how systemd and sysvinit can properly co-exist in the archive (this is required in any case for the duration of the transition) - outlining how the transition could be achieved, eased, and tracked We're going to respond to those once the time period for the survey is up. Until then, could we please not be having this discussion? Thanks, -- 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/87ehczrz8n@qurzaw.varnish-software.com
Re: Debian systemd survey
Le mercredi 22 mai 2013 à 08:16 +0200, Lucas Nussbaum a écrit : - there are 300+ upstart job files ready to be imported from Ubuntu When you compare the time it takes to write an upstart job file or a systemd unit file, to the time it takes to proprely test it, I don’t think this argument makes any sense. If the only things we do for improving the distribution are to take stuff from Ubuntu because, well, it’s here, we might as well stop developing anything at all. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1369226754.12592.96.camel@pi0307572
Re: Debian systemd survey
On May 21, Lucas Nussbaum lu...@debian.org wrote: We don't need to select a single init system at this point, and it would As the maintainer of a package which is strongly tied to the init system, I disagree. Then, something I failed to find in the discussion was a discussion of how sysvinit / systemd / upstart could co-exist (not on a single system, but in the archive). I suggest that this is related to my first point. I understand that systemd replaces some parts of initscripts, could also replace syslog, etc. How do systemd supporters see that working in practice? What kind of feature duplication between init sytems should be expected? How much does it increase the maintenance effort? I am not strictly a systemd supporter but more like a modern init system supporter, and the duplication, increased mainteinance overhead and lack of QA are the reasons why I do not want to support multiple init systems in my packages and I do not think that Debian should either as a project. Is it realistic to dream about a generator that would automate the generation of sysvinit scripts, systemd .service files, and upstart job files for a majority of our packages (the easy ones)? The easy ones can continue using sysvinit scripts for a while, since they can coexist with both upstart and systemd configurations. (Maybe better in the systemd case.) -- ciao, Marco signature.asc Description: Digital signature
Re: Debian systemd survey
On 05/22/2013 04:50 AM, Uoti Urpala wrote: Lucas Nussbaum wrote: I went through the various init systems threads again during the last few days. My understanding of the consensus so far is the following: - Both systemd and upstart bring many useful features, and are a clear improvement over sysvinit. Yes, both are an improvement over sysvinit. Hrmm, I have not tested systemd yet, but personally I'm not conviced about the advantages of upstart: - Stops booting *somtimes*, does not provide any information why. I didn't report a bug yet as an almost black screen won't help in any way how to figure out why it stopped. Already that stops without any further information why and where is a sufficiently big design issue, imho. (Btw, in the mean time I belive this issue is related to /etc/mtab, but I'm not sure yet.). - Updating/install programs in a chroot fails with weird messages that those programs (afaik for example X) cannot connect to upstart. Well, it is a chroot, what does it expect? - Personally I'm using unionfs-fuse as very first init script to mount /etc and /var and others on my development systems. So no need to modify an initrams, but a very simple approach and controllable using a boot script. But specifying a script to be run *before* anything else is not possible (yet?). Bernd -- 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/519cca74.9030...@aakef.fastmail.fm
Re: Debian systemd survey
Hi! On Wed, 2013-05-22 at 09:15:03 +0200, John Paul Adrian Glaubitz wrote: On 05/21/2013 10:53 PM, Lucas Nussbaum wrote: - Neither systemd nor upstart are likely to be ported to kfreebsd soon, as they both rely on many Linux-specific features and interfaces. What about launchd? Wouldn't it be possible to port that to Debian/kFreeBSD? It's designed to run in a BSD userland, after all. launchd relies heavily on Mach and Apple specific interfaces, and while there was a GSOC to port it to FreeBSD, funnily enough, in the end it might be easier to port it to GNU/Hurd! :) Also last I checked the upstream svn repo had not seen any update in a while, which might mean upstream practices might not be optimal. Thanks, Guillem -- 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/20130522135758.ga25...@gaara.hadrons.org
Re: Debian systemd survey
On 22/05/13 at 14:45 +0200, Josselin Mouette wrote: Le mercredi 22 mai 2013 à 08:16 +0200, Lucas Nussbaum a écrit : - there are 300+ upstart job files ready to be imported from Ubuntu When you compare the time it takes to write an upstart job file or a systemd unit file, to the time it takes to proprely test it, I don’t think this argument makes any sense. If the only things we do for improving the distribution are to take stuff from Ubuntu because, well, it’s here, we might as well stop developing anything at all. Note that if it's there, and Ubuntu uses upstart, it has probably been tested. I was not suggesting that we blindly import upstart job files from Ubuntu, but a basis to start from is better than no basis at all. (I can see how my phrasing was a bit confusing -- sorry about that) Lucas -- 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/20130522154811.ga25...@xanadu.blop.info
using upstart in Debian [was, Re: Debian systemd survey]
On Wed, May 22, 2013 at 03:39:00PM +0200, Bernd Schubert wrote: On 05/22/2013 04:50 AM, Uoti Urpala wrote: Lucas Nussbaum wrote: I went through the various init systems threads again during the last few days. My understanding of the consensus so far is the following: - Both systemd and upstart bring many useful features, and are a clear improvement over sysvinit. Yes, both are an improvement over sysvinit. Hrmm, I have not tested systemd yet, but personally I'm not conviced about the advantages of upstart: - Stops booting *somtimes*, does not provide any information why. I didn't report a bug yet as an almost black screen won't help in any way how to figure out why it stopped. Already that stops without any further information why and where is a sufficiently big design issue, imho. (Btw, in the mean time I belive this issue is related to /etc/mtab, but I'm not sure yet.). Sorry you ran into trouble with upstart. Probably related to /etc/fstab, rather than /etc/mtab... Due to incomplete upstart integration of plymouth in Debian at present, if there are problems in /etc/fstab, mountall won't always be able to display any prompt to the user asking what to do (cf. http://web.dodds.net/~vorlon/wiki/blog/Plymouth_is_not_a_bootsplash/). Whereas sysvinit would eventually give up on trying to mount filesystems in /etc/fstab if they were missing at boot and continue booting without them, upstart takes the design decision that this is an error that the admin needs to deal with directly. This ensures that the system always boots reliably in the face of slow disks, which become more of a problem now that your init system is so fast that it can boot before your hardware has been probed. Feel free to file a bug report against the upstart package (with a copy of your /etc/fstab attached) so we can look at this further. - Updating/install programs in a chroot fails with weird messages that those programs (afaik for example X) cannot connect to upstart. Well, it is a chroot, what does it expect? This is bug #685779, which will be fixed in the next upload of sysvinit to unstable. - Personally I'm using unionfs-fuse as very first init script to mount /etc and /var and others on my development systems. So no need to modify an initrams, but a very simple approach and controllable using a boot script. But specifying a script to be run *before* anything else is not possible (yet?). I'm skeptical of the value of such a design in place of just using an initramfs, but the 'friendly-recovery' package in Ubuntu gives an example of to do this. You create an upstart job that's 'start on real-startup-event', runs your necessary pre-setup, and at the end calls 'initctl emit startup' to call into the rest of the boot sequence; then you pass '--startup-event=real-startup-event' to init on the kernel commandline. -- 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: Debian systemd survey
On Wed, May 22, 2013 at 02:45:54PM +0200, Josselin Mouette wrote: Le mercredi 22 mai 2013 à 08:16 +0200, Lucas Nussbaum a écrit : - there are 300+ upstart job files ready to be imported from Ubuntu When you compare the time it takes to write an upstart job file or a systemd unit file, to the time it takes to proprely test it, I don’t think this argument makes any sense. Please leave the FUD at the door. Writing upstart jobs is not difficult; while there are some gotchas currently with process lifecycle (which will be fixed soon), there is also very complete documentation (for these issues, and generally). http://upstart.ubuntu.com/cookbook/ If the only things we do for improving the distribution are to take stuff from Ubuntu because, well, it’s here, we might as well stop developing anything at all. Sure; obviously the right thing to do is to instead take stuff from GNOME and freedesktop.org without regard to integration with our existing system, because if Lennart says it's right it must be so. -- 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
