* Ralf Lang <lang@b1-systems.de> [2012-11-03 10:04]:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Am 03.11.2012 03:29, schrieb Cristian Rodríguez:

...

Hi:

I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5)

So it is now up for grabs.

that's all ;)

Can you estimate the effort needed to keep it running and the time frame until when people will start complaining why I bother the list with help requests for "old rubbish"?

at(1) is part of the posix utilities so it won't go away any time soon in favor of non-portable, proprietary tools such as systemd (or launchd timers which systemd is aping). -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

* Krzysztof Żelechowski <giecrilj@stegny.2a.pl> [2012-11-03 13:49]:

Dnia sobota, 3 listopada 2012 12:56:28 Guido Berhoerster pisze:

...

* Ralf Lang <lang@b1-systems.de> [2012-11-03 10:04]:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Am 03.11.2012 03:29, schrieb Cristian Rodríguez:

...

Hi:

I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5)

So it is now up for grabs.

that's all ;)

Can you estimate the effort needed to keep it running and the time frame until when people will start complaining why I bother the list with help requests for "old rubbish"?

at(1) is part of the posix utilities so it won't go away any time soon in favor of non-portable, proprietary tools such as systemd (or launchd timers which systemd is aping).

What do you mean by ’proprietary’ in this context? It usually means that the specification and implementation is under control of a single commercial entity that controls them for profit, like Adobe Flash or, to a smaller extent, Oracle Java. I doubt systemd is proprietary in that sense.

In the sense that implementation and specification (where it even exists and has any credible stability) are de-facto controlled by RedHat and are thus changeable at will. Combined with the overarching scope of reimplementing Apple's launchd and large parts of the lower-level userpace stack and the resulting dependencies of higher-level components, the costs of forking or swapping out systemd with alternative implementations become prohibitive for other entities/copetitors with less engineering resources. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

* Krzysztof Żelechowski <giecrilj@stegny.2a.pl> [2012-11-05 19:30]:

Dnia sobota, 3 listopada 2012 14:14:11 Guido Berhoerster pisze:

...

* Krzysztof Żelechowski <giecrilj@stegny.2a.pl> [2012-11-03 13:49]:

...

Dnia sobota, 3 listopada 2012 12:56:28 Guido Berhoerster pisze:

...

at(1) is part of the posix utilities so it won't go away any time soon in favor of non-portable, proprietary tools such as systemd (or launchd timers which systemd is aping).

What do you mean by ’proprietary’ in this context? It usually means that the specification and implementation is under control of a single commercial entity that controls them for profit, like Adobe Flash or, to a smaller extent, Oracle Java. I doubt systemd is proprietary in that sense.

In the sense that implementation and specification (where it even exists and has any credible stability) are de-facto controlled by RedHat and are thus changeable at will. Combined with the

Everything is either abandoned or de-facto controlled by somebody.

You are missing the point, the someone greatly matters and is in this case a single commercial entity whose decisions will reflect the needs for their products and their business interests. That is certainly their right by virtue of funding much of its development, it should however by noted that these decisions are not necessarily in the best interests or even detrimental to the interests of other projects and vendors. Init and udev are the most central and important pieces apart from the kernel and there is an ever increasing amount of previously loosely-coupled, separate userland components such as cron, atd, acpid, syslog, ConsoleKit, and now user sessions which are being sucked up into systemd. While it probably makes sense for RedHat to streamline and take control of or at least exert significant influence over this middle stack, it also represents a radical departure from the current Linux ecosystem where distros have a certain degree of flexibility in what and which components they include based on their specific needs and technical merit. Once they're in the systemd train they more or less have to take what gets handed down to them, that is what systemd depends on or replaces next, as getting off becomes increasingly costly, just as avoiding it altogether since RH seems to be eager on pushing dependencies up the stack. In the FOSS world competition or even the potential threat of a fork or alternative solution and users voting with their feet are important means of driving progress, pushing towards technically optimal solutions, and ensuring a degree of responsiveness to consumers. After systemd has gathered enough momentum, there is even less incentive to take the needs of from anyone but their own and their paying customers into account or to strive for technically optimal design. You can already see the symptoms of that reflected in design decisions, such as the offline updates feature designed around the deficiencies of RH's package management, the requirement to upgrade systemd and the kernel in lockstep, udev dropping support for installation in /lib, the inclusion of FSS in order to boost the academic career of developers family members and so on.

...

overarching scope of reimplementing Apple's launchd and large parts of the lower-level userpace stack and the resulting dependencies of higher-level components, the costs of forking or swapping out systemd with alternative implementations become prohibitive for other entities/copetitors with less engineering resources.

This means expensive, not proprietary.

Lets please move any further discussion to opensuse-offtopic or private since this is getting off topic here. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

El 03/11/12 08:56, Guido Berhoerster escribió:

at(1) is part of the posix utilities so it won't go away any time

Sure,I am not saying it will go away.. I am saying that I wont invest my resources on it. hence I ask for someone with interest in paleontology to take over. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Sun, Nov 04, 2012 at 04:40:27PM +0100, Christian Boltz wrote:

...

Am 03.11.2012 03:29, schrieb Cristian Rodríguez:

...

I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5) ... At the risk of scaring you away - one of the first things the future maintainer (you?) should do is an update for 12.2 because atd doesn't start at all (already fixed in the devel project) and the sysconfig options are ignored by the at.service file. See https://bugzilla.novell.com/show_bug.cgi?id=780259 for details.

Besides that, the changelog looks quite boring to me ;-)

(and: no, the fact that I fixed the at.service file does not mean that I'm volunteering to maintain the at package ;-)

Quite the opposite here... while I wouldn't mind maintaining atd, I certainly don't want to maintain a systemd service file. Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hello, Am Montag, 5. November 2012 schrieb Ralf Lang:

Am 04.11.2012 16:40, schrieb Christian Boltz:

...

Am Samstag, 3. November 2012 schrieb Ralf Lang:

...

Am 03.11.2012 03:29, schrieb Cristian Rodríguez: At the risk of scaring you away - one of the first things the future maintainer (you?) should do is an update for 12.2 because atd doesn't start at all (already fixed in the devel project) and the sysconfig options are ignored by the at.service file. See https://bugzilla.novell.com/show_bug.cgi?id=780259 for details.

I just fixed this - atd.service now contains: ExecStart=/bin/bash -c '[ -e /etc/sysconfig/atd ] && . /etc/sysconfig/atd; exec /usr/sbin/atd $${ATD_BATCH_INTERVAL:+-b $$ATD_BATCH_INTERVAL} $${ATD_LOADAVG:+-l $$ATD_LOADAVG}' (should I have added a comment "# looks ugly, but works"? ;-) See - request #142950 to Base:System - request #142949 for the 12.2 update but...

...

(and: no, the fact that I fixed the at.service file does not mean that I'm volunteering to maintain the at package ;-)

... this is still valid ;-)

I'll look at it and report back yes/no

Any news? ;-) Regards, Christian Boltz --

It is a pity that [Tumbleweed] fails to continue quickly after an openSUSE upgrade [...] A "pity"? That's a good one, you now owe me a beer for complaining :) [Erwin Van de Velde and Greg KH in opensuse-factory]

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

I don't think the above is in the spirit of systemd. Ideally atd would parse /etc/sysconfig/atd itself¹ and set it's defaults accordingly.

I think this remark shows very cleanly why so many *feel* that there is something wrong with the systemd concept. May be it has some merits over sysinit, but: It contradicts KISS. "atd" (or any other daemon) should do what it is designed for. If any init system wants to start it, it has to deal with "at", *not* the other way round. To me what you call "ideally" sounds just like a wrong way. Just an observation, 2c as usual, by no means a try to start another discussion about this topic. Detlef -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 27 of November 2012 11:21EN, Ludwig Nussel wrote:

The person decided to do it via shell hacks as it was quite common to do it that way back then. It's a good thing to get rid of such hacks and patch the features into daemon itself anyways, indepedent of whether or not systemd is used for booting.

As far as I can say from the proposed config, the features are actually implemented in atd and the "hacks" just translate sysconfig variables to command line parameters. Many init scripts do things like this as daemons rarely parse /etc/sysconfig themselves. Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Tuesday 27 November 2012, Ludwig Nussel wrote:

Michal Kubeček wrote:

...

On Tuesday 27 of November 2012 11:21EN, Ludwig Nussel wrote:

...

The person decided to do it via shell hacks as it was quite common to do it that way back then. It's a good thing to get rid of such hacks and patch the features into daemon itself anyways, indepedent of whether or not systemd is used for booting.

As far as I can say from the proposed config, the features are actually implemented in atd and the "hacks" just translate sysconfig variables to command line parameters. Many init scripts do things like this as daemons rarely parse /etc/sysconfig themselves.

So? We are talking about free software here. Add a few lines of C and they do. No need to add shell wrappers.

Hm, on the other hand this at package is a very good example how you can mess up a package by adding tons of "nice" patches so that it becomes really hard to follow upstream. Suse's at packages got not updates from upstream since 2005. Maybe one reason for this is that nobody wants to rebase (and test) all these existing patches. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

At Tue, 27 Nov 2012 13:38:38 +0100, Ludwig Nussel wrote:

Michal Kubeček wrote:

...

On Tuesday 27 of November 2012 11:21EN, Ludwig Nussel wrote:

...

The person decided to do it via shell hacks as it was quite common to do it that way back then. It's a good thing to get rid of such hacks and patch the features into daemon itself anyways, indepedent of whether or not systemd is used for booting.

As far as I can say from the proposed config, the features are actually implemented in atd and the "hacks" just translate sysconfig variables to command line parameters. Many init scripts do things like this as daemons rarely parse /etc/sysconfig themselves.

So? We are talking about free software here. Add a few lines of C and they do. No need to add shell wrappers.

True, but only if parsing (SUSE-specific) sysconfig variables is acceptable for the upstream, too. In other words, if such a patch won't be merged to the upstream, we'll need to carry over the patch forever. It'd be much more pain than maintaining an init shell script. (Of course, this is about packages where we do "follow upstream". For packages that carry already tons of our own patches, it doesn't matter :) Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

At Tue, 27 Nov 2012 16:33:57 +0100, Ludwig Nussel wrote:

Takashi Iwai wrote:

...

At Tue, 27 Nov 2012 13:38:38 +0100, Ludwig Nussel wrote:

...

Michal Kubeček wrote:

...

On Tuesday 27 of November 2012 11:21EN, Ludwig Nussel wrote:

...

The person decided to do it via shell hacks as it was quite common to do it that way back then. It's a good thing to get rid of such hacks and patch the features into daemon itself anyways, indepedent of whether or not systemd is used for booting.

As far as I can say from the proposed config, the features are actually implemented in atd and the "hacks" just translate sysconfig variables to command line parameters. Many init scripts do things like this as daemons rarely parse /etc/sysconfig themselves.

So? We are talking about free software here. Add a few lines of C and they do. No need to add shell wrappers.

True, but only if parsing (SUSE-specific) sysconfig variables is acceptable for the upstream, too. In other words, if such a patch won't be merged to the upstream, we'll need to carry over the patch forever. It'd be much more pain than maintaining an init shell script.

I don't agree. Whether or not such a patch would be openSUSE specific is also questionable. Looks like at least Fedora also wants to have atd parameters configurable. Maybe upstream would be open to accepting a patch for a global config file (in whatever format)? You will never find out if you don't even ask and keep writing shell wrappers.

Sure, I don't mean to stick *only* with the init shell script. It's broken for systemd, thus it must be fixed. No doubt about it. And the fix should be done together with the upstream at best indeed. Go ahead. However, a random patching in SUSE package can be rather a pain by itself alone. As mentioned, it's often harder to maintain unless accepted in the upstream. So, the key is the collaborative fix with the upstream. It might be a few lines of C code, but it needs lots of social tasks in addition. The background I write this is that, honestly speaking, I can hardly imagine that a SUSE-specific sysconfig is acceptable as a common infrastructure over all distros. If I were to get a patch from a Canonical guy to add a patch to parse Ubuntu's config file to any ALSA util programs, I'd reject it :) A typical and likely solution will be to introduce a new config file in the end, with a hope that the downstream will follow to change their tools like YaST for managing the new config file. This is a cleaner solution, but takes a long long way... Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

At Tue, 27 Nov 2012 17:03:00 +0100, Dominique Leuenberger a.k.a DimStar wrote:

Quoting Takashi Iwai <tiwai@suse.de>:

...

At Tue, 27 Nov 2012 16:33:57 +0100, Sure, I don't mean to stick *only* with the init shell script. It's broken for systemd, thus it must be fixed. No doubt about it. And the fix should be done together with the upstream at best indeed. Go ahead.

However, a random patching in SUSE package can be rather a pain by itself alone. As mentioned, it's often harder to maintain unless accepted in the upstream.

So, the key is the collaborative fix with the upstream. It might be a few lines of C code, but it needs lots of social tasks in addition.

The background I write this is that, honestly speaking, I can hardly imagine that a SUSE-specific sysconfig is acceptable as a common infrastructure over all distros. If I were to get a patch from a Canonical guy to add a patch to parse Ubuntu's config file to any ALSA util programs, I'd reject it :)

A typical and likely solution will be to introduce a new config file in the end, with a hope that the downstream will follow to change their tools like YaST for managing the new config file. This is a cleaner solution, but takes a long long way...

finally we're talking what it takes to be a packager / package maintainer... it's not about writing the .spec file (the syntax is not that difficult after all), but more aspects around it and a good contact / relation with upstream is very essential to be able to maintain the packages in long term.

Right. But don't forget that the whole story is not only about contacts with the upstream. For example, if a new config file scheme is introduced, it must be adapted by its management tools. This implies a contact with *internal* tool maintainers, too. And at best, involve these tool maintainers from the very beginning of the action. Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Christian Boltz wrote:

Am Dienstag, 27. November 2012 schrieb Ludwig Nussel:

...

Christian Boltz wrote:

...

Am Montag, 5. November 2012 schrieb Ralf Lang:

...

Am 04.11.2012 16:40, schrieb Christian Boltz: I just fixed this - atd.service now contains: ExecStart=/bin/bash -c '[ -e /etc/sysconfig/atd ] && . /etc/sysconfig/atd; exec /usr/sbin/atd $${ATD_BATCH_INTERVAL:+-b $$ATD_BATCH_INTERVAL} $${ATD_LOADAVG:+-l $$ATD_LOADAVG}'

(should I have added a comment "# looks ugly, but works"? ;-)

I don't think the above is in the spirit of systemd.

That's very visible when you look at the ExecStart line ;-) and is also the reason why I asked if I should have added the "looks ugly, but works" comment ;-)

The motivation behind this change was simple - fix the bug "settings in /etc/sysconfig/atd are ignored" (which was a regression by switching to a service file). I never said I like this solution, but it works ;-)

This is really a question of policy to me. Do we want to pollute .service files with such /bin/bash constructs? If the shell wrapper is inevitable it could be implemented in a regular file just as well (/usr/sbin/atd_systemd_wrapper or something like that). That would at least keep both the .service file and the script readable and avoids quoting issues. Or just keep the working init script and admit that the software isn't ready for the new world order yet. I wonder why the broken .service file was added to atd in the first place. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, Nov 28, 2012 at 11:00:46AM +0100, Ruediger Meier wrote:

On Wednesday 28 November 2012, Ludwig Nussel wrote:

...

I wonder why the broken .service file was added to atd in the first place.

Maybe because some packagers just accept everything which comes from 0pointer.de without thinking about it ...

Well that change probably came from here: Mon Dec 5 19:05:48 UTC 2011 - crrodriguez@opensuse.org - Support systemd. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

El 28/11/12 07:30, Ruediger Meier escribió:

On Wednesday 28 November 2012, Marcus Meissner wrote:

...

On Wed, Nov 28, 2012 at 11:00:46AM +0100, Ruediger Meier wrote:

...

On Wednesday 28 November 2012, Ludwig Nussel wrote:

...

I wonder why the broken .service file was added to atd in the first place.

Maybe because some packagers just accept everything which comes from 0pointer.de without thinking about it ...

Well that change probably came from here:

Mon Dec 5 19:05:48 UTC 2011 - crrodriguez@opensuse.org - Support systemd.

Yep, he just took a random service file from http://0pointer.de/public/systemd-units/atd.service and then accepted his own submit request ... https://build.opensuse.org/request/show/95490

The unit is correct, however our version of at is/was outdated and lacked of a needed command line flag. I missed that, my bad ;P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, 28 Nov 2012 11:30:39 +0100 Ruediger Meier <sweet_f_a@gmx.de> wrote: ...

Yep, he just took a random service file from http://0pointer.de/public/systemd-units/atd.service

http://0pointer.de/public/systemd-units.out-of-date/ :) -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Am 27.11.2012 20:22, schrieb Cristian Rodríguez:

El 27/11/12 06:48, Ludwig Nussel escribió:

...

I don't think the above is in the spirit of systemd. Ideally atd would parse /etc/sysconfig/atd itself¹ and set it's defaults accordingly. Using shell for this kind of things is one of the reasons why init scrips became such beasts.

The main issue here is the usage of this wonderful invention called sysconfig, which is really a hack for software whose authors were too lazy to include a basic configuration file. ;)

Now it has become entangled into the complete system and is very hard to get rid of :-|

...

[1] maybe we should have a common C library for that task

libHX already knows how to parse sysconfig files AFAIK.

Does debian actually have some scm for at or are just magically tarballs popping up at their ftp site? -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Am 27.11.2012 21:03, schrieb Cristian Rodríguez:

El 27/11/12 16:49, Ralf Lang (B1 Systems GmbH) escribió:

...

Does debian actually have some scm for at or are just magically tarballs popping up at their ftp site?

YEs, there is a git repo.

http://anonscm.debian.org/gitweb/?p=collab-maint/at.git

We recently upgraded factory at to debian's 3.1.13 plus suse related patches. After coarse testing, it seems like it doesn't break common use cases. Factory users please test any known edge cases so we can fix anything in time for release -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Cristian Rodríguez (crrodriguez@opensuse.org) wrote:

El 27/11/12 06:48, Ludwig Nussel escribió:

...

I don't think the above is in the spirit of systemd. Ideally atd would parse /etc/sysconfig/atd itself¹ and set it's defaults accordingly. Using shell for this kind of things is one of the reasons why init scrips became such beasts.

The main issue here is the usage of this wonderful invention called sysconfig, which is really a hack for software whose authors were too lazy to include a basic configuration file. ;)

I don't have any reasons for a biased opinion either way, but it seems to me that you could also argue that this kind of laziness is *good*, i.e. the authors were too lazy to reinvent a wheel, and that the consistent location and format of config files it results in is an advantage which can then be harnessed by things like yast. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

El 26/11/12 15:34, Christian Boltz escribió:

Hello,

Am Montag, 5. November 2012 schrieb Ralf Lang:

...

Am 04.11.2012 16:40, schrieb Christian Boltz:

...

Am Samstag, 3. November 2012 schrieb Ralf Lang:

...

Am 03.11.2012 03:29, schrieb Cristian Rodríguez: At the risk of scaring you away - one of the first things the future maintainer (you?) should do is an update for 12.2 because atd doesn't start at all (already fixed in the devel project) and the sysconfig options are ignored by the at.service file. See https://bugzilla.novell.com/show_bug.cgi?id=780259 for details.

I just fixed this - atd.service now contains: ExecStart=/bin/bash -c '[ -e /etc/sysconfig/atd ] && . /etc/sysconfig/atd; exec /usr/sbin/atd $${ATD_BATCH_INTERVAL:+-b $$ATD_BATCH_INTERVAL} $${ATD_LOADAVG:+-l $$ATD_LOADAVG}'

(should I have added a comment "# looks ugly, but works"? ;-)

See - request #142950 to Base:System - request #142949 for the 12.2 update

OK, I just now submitted a proper fix ;) created request id 143492 I rest my case with this thing though ;) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 29/11/12 07:38, Ruediger Meier wrote:

Apart from that I find it very ugly to introduce the libHX dependency just to parse 2 lines from a bash style sysconfig config file there are some issues with that patch.

We have shared libraries to use them and avoid reinventing parsers.

Command line arguments should override the config file and not the other way around.

The arguments from the config options should be parsed like the commandline ones inclusive error handling and not using atoi and atof. Config file should be mentioned in the man page.

Feel free to improve it, as the $SUBJECT says I will no longer spend time on this at thingy. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

El 29/11/12 09:50, Ruediger Meier escribió:

So your last action is breaking it again.

No, atd is supposed to be started from a systemd unit that the vast majority of users will not modify and instead will add the options to the sysconfig file.

My fix would be to just revert your patch.

I get it now, the idea is to complain and sabotage changes and not actually do anything constructive yourself. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Am 05.11.2012 14:28, schrieb Ralf Lang:

Am 04.11.2012 16:40, schrieb Christian Boltz:

...

Hello,

...

Am Samstag, 3. November 2012 schrieb Ralf Lang:

...

Am 03.11.2012 03:29, schrieb Cristian Rodríguez:

...

I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5)

So it is now up for grabs.

Can you estimate the effort needed to keep it running and the time frame until when people will start complaining why I bother the list with help requests for "old rubbish"?

If these are sane values, I might take over ;-)

...

At the risk of scaring you away - one of the first things the future maintainer (you?) should do is an update for 12.2 because atd doesn't start at all (already fixed in the devel project) and the sysconfig options are ignored by the at.service file. See https://bugzilla.novell.com/show_bug.cgi?id=780259 for details.

...

Besides that, the changelog looks quite boring to me ;-)

...

(and: no, the fact that I fixed the at.service file does not mean that I'm volunteering to maintain the at package ;-)

I'll look at it and report back yes/no

Request filed. https://build.opensuse.org/request/show/143267 -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

* Ralf Lang <lang@b1-systems.de> [2012-11-03 10:04]:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Am 03.11.2012 03:29, schrieb Cristian Rodríguez:

...

Hi:

I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5)

So it is now up for grabs.

that's all ;)

Can you estimate the effort needed to keep it running and the time frame until when people will start complaining why I bother the list with help requests for "old rubbish"?

at(1) is part of the posix utilities so it won't go away any time soon in favor of non-portable, proprietary tools such as systemd (or launchd timers which systemd is aping). -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

* Krzysztof Żelechowski <giecrilj@stegny.2a.pl> [2012-11-03 13:49]:

Dnia sobota, 3 listopada 2012 12:56:28 Guido Berhoerster pisze:

...

* Ralf Lang <lang@b1-systems.de> [2012-11-03 10:04]:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Am 03.11.2012 03:29, schrieb Cristian Rodríguez:

...

Hi:

I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5)

So it is now up for grabs.

that's all ;)

Can you estimate the effort needed to keep it running and the time frame until when people will start complaining why I bother the list with help requests for "old rubbish"?

at(1) is part of the posix utilities so it won't go away any time soon in favor of non-portable, proprietary tools such as systemd (or launchd timers which systemd is aping).

What do you mean by ’proprietary’ in this context? It usually means that the specification and implementation is under control of a single commercial entity that controls them for profit, like Adobe Flash or, to a smaller extent, Oracle Java. I doubt systemd is proprietary in that sense.

In the sense that implementation and specification (where it even exists and has any credible stability) are de-facto controlled by RedHat and are thus changeable at will. Combined with the overarching scope of reimplementing Apple's launchd and large parts of the lower-level userpace stack and the resulting dependencies of higher-level components, the costs of forking or swapping out systemd with alternative implementations become prohibitive for other entities/copetitors with less engineering resources. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

* Krzysztof Żelechowski <giecrilj@stegny.2a.pl> [2012-11-05 19:30]:

Dnia sobota, 3 listopada 2012 14:14:11 Guido Berhoerster pisze:

...

* Krzysztof Żelechowski <giecrilj@stegny.2a.pl> [2012-11-03 13:49]:

...

Dnia sobota, 3 listopada 2012 12:56:28 Guido Berhoerster pisze:

...

at(1) is part of the posix utilities so it won't go away any time soon in favor of non-portable, proprietary tools such as systemd (or launchd timers which systemd is aping).

What do you mean by ’proprietary’ in this context? It usually means that the specification and implementation is under control of a single commercial entity that controls them for profit, like Adobe Flash or, to a smaller extent, Oracle Java. I doubt systemd is proprietary in that sense.

In the sense that implementation and specification (where it even exists and has any credible stability) are de-facto controlled by RedHat and are thus changeable at will. Combined with the

Everything is either abandoned or de-facto controlled by somebody.

You are missing the point, the someone greatly matters and is in this case a single commercial entity whose decisions will reflect the needs for their products and their business interests. That is certainly their right by virtue of funding much of its development, it should however by noted that these decisions are not necessarily in the best interests or even detrimental to the interests of other projects and vendors. Init and udev are the most central and important pieces apart from the kernel and there is an ever increasing amount of previously loosely-coupled, separate userland components such as cron, atd, acpid, syslog, ConsoleKit, and now user sessions which are being sucked up into systemd. While it probably makes sense for RedHat to streamline and take control of or at least exert significant influence over this middle stack, it also represents a radical departure from the current Linux ecosystem where distros have a certain degree of flexibility in what and which components they include based on their specific needs and technical merit. Once they're in the systemd train they more or less have to take what gets handed down to them, that is what systemd depends on or replaces next, as getting off becomes increasingly costly, just as avoiding it altogether since RH seems to be eager on pushing dependencies up the stack. In the FOSS world competition or even the potential threat of a fork or alternative solution and users voting with their feet are important means of driving progress, pushing towards technically optimal solutions, and ensuring a degree of responsiveness to consumers. After systemd has gathered enough momentum, there is even less incentive to take the needs of from anyone but their own and their paying customers into account or to strive for technically optimal design. You can already see the symptoms of that reflected in design decisions, such as the offline updates feature designed around the deficiencies of RH's package management, the requirement to upgrade systemd and the kernel in lockstep, udev dropping support for installation in /lib, the inclusion of FSS in order to boost the academic career of developers family members and so on.

...

overarching scope of reimplementing Apple's launchd and large parts of the lower-level userpace stack and the resulting dependencies of higher-level components, the costs of forking or swapping out systemd with alternative implementations become prohibitive for other entities/copetitors with less engineering resources.

This means expensive, not proprietary.

Lets please move any further discussion to opensuse-offtopic or private since this is getting off topic here. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org