[arch-general] Change Arch's default crond

[C Anthony Risinger]

On Thu, Apr 21, 2011 at 2:33 PM, Ionut Biru <ibiru at archlinux.org> wrote:
> On 04/21/2011 02:18 PM, Heiko Baums wrote:
>>
>> Am Thu, 21 Apr 2011 08:48:04 +0200
>> schrieb Sven-Hendrik Haase<sh at lutzhaase.com>:
>>
>>> I second this suggestion. cronie upstream isn't dead at all. cronie
>>> is a drop-in unlike fcron which was favored earlier.
>>
>> Is it such a drop-in like the new dcron when dcron upstream was adopted
>> by this Arch user?
>>
>> Better look at the features and the use cases (don't only think of some
>> 24/7 servers, but also think of the desktop users) and not at some small
>> differences in the crontab syntax. It's definitely not such a big work
>> to re-adjust a few crontab entries if this is necessary at all. And this
>> work has to be done only once and can probably be done with sed.
>>
>
> i think you are not understanding the process.
>
> if cronie is moved in core, it won't have a replaces=dcron. Only new
> installations will get cronie by default instead of dcron.

personally i can't stand crons at all; IME they are usually used for
hack job workarounds to other problems, and i avoid them at all costs,
preferring boundary triggers or other event-based activation points.
crons tend to end up forgotten and separated from other application
logic.

while i totally agree that a new one is needed if the current one has
such fundamental problems, i'm with the guy that says systemd will
obsolete it anyways.  as far as i'm concerned, `cron` and `init` are
the same program, differing only by _when_ they run stuff.  the power
and flexibility of systemd and it's configuration provide for
unprecedented precision and control over your timed executions.  let's
make a smarter Arch ... init/cron are not smart.

just the other day i had to tweak a debian sqeeze system (which uses
upstart btw) and the LSB scripts + half-baked dependency system was
rather painful IMO, and it made me appreciate the systemd readability
even more ... Arch may end up being the only distro that cares about
sysvinit :-(

not trying to derail the conversation, i just think it's relevant ... when i:

# tree /etc/systemd

i get a nice neat view of what my system will do at boot time, or any
other time.  i haven't had a chance to try it yet, but i believe each
user could potentially have their own ~/unit directory, and systemd
could run stuff from there too.

C Anthony