On Wed, Apr 6, 2011 at 4:29 PM, Heiko Baums <lists@xxxxxxxxxxxxxxx> wrote: > Am Wed, 6 Apr 2011 15:30:26 -0600 > schrieb Thomas S Hatch <thatch45@xxxxxxxxx>: > > > dcron and fcron are not under active development, > > fcron is under active development. It's just feature complete and > therefore not developed anymore, but bugs are still fixed if they > occur. So don't mix it up with a "dead" project. I guess dcron most > likely can be assumed to be dead. > > > cronie is > > cronie is small - 0.20MB installed > > cronie is developed by Red Hat - it is not going anywhere and we have > > a guaranteed upgrade path > > What does that mean? Look at the size and you can see that it can't be > as feature rich as fcron. > > > As far as I can tell cronie has no deps beyond glibc and pam > > cronie has /etc/cron.d support > > cronie has configurable anacron support via an anacrontab config file > > But you need a separate anacrontab. So it's the same as having > installed a cron and a separate anacron. With fcron you just need one > cron daemon which has anacron features integrated. This means you don't > need to have a separate anacrontab. So you don't need to decide if a > task needs to be run by cron or by anacron. You just can add every task > into one single crontab resp. fcrontab and just put &bootrun at the > beginning of the line as Thomas already explained. This means that this > task is run at the desired time if the system is up and the cron is > running, and if not then this task is automagically run as soon as fcron > is started the next time and that very reliably. > > So this is much easier and much more flexible than a separate > cron/anacron solution. > > That's why fcron is still the best. > > And neither /etc/cron.d support nor the fact that cronie is developed by > Redhat is an argument in my opinion. > > /etc/cron.d can easily be moved > to /etc/cron.{hourly,daily,weekly,monthly} or to fcrontab. > So /etc/cron.d is not needed. So this is not an argument in my opinion. > I guess this transition takes about 5 to 10 minutes maximum if at all. > > > cronie extends the original vixie cron package so the syntax, core > > feature set, etc are stable > > cronie implements advanced security hooks as well and can integrate > > with SELINUX (I am saving the "include SELINUX support in base for a > > latter date") > > Well, is SELinux really a default? Does SELinux run on Arch at all? Is > this really an argument regarding the decision which cron shall be the > default. > > As said before, the question is not having removed every other cron > from the repos. The question is about the default cron. > > Most people who are regularly discussing this topic here on the mailing > list tend to fcron for a lot of good reasons. > > And the few people who really need /etc/cron.d or SELinux support - I'm > not sure if fcron is not able to run with SELinux - can easily install > another cron daemon. > > dcron was just kept as the default, because the formerly dead project > was adopted by an Arch user who said, that he wants do keep developing > it and to fixing the bugs. As already said the most important bug wasn't > fixed in a year. And in the meantime it was nothing heard from this > Arch user anymore. So it can be assumed dead in my opinion. > > > At the outset I think that cronie looks to be the most viable option, > > but merits further investigation. > > I definitely still vote for fcron for reason which have been explained > many times here on the list - not only by me. > > Alternatively it can be done as it is already done with the boot > manager in AIF that every cron is listed in the package list so that > the user can decide which one to install or AIF brings a separate > dialog which asks the user which cron daemon to install with a small > or a bit more detailed description of the daemons. > > Heiko > All I said what that cronie merits investigation, and that there are good reasons to investigate. Also, the size of a package != feature set. The argument that Red Hat develops it is only a plus in that is ensures ongoing development of the project of provisions to migrate to something else in the future, just because Red Hat develops something is not alone a viable reason to use it over other things, but it is a topic for consideration when making a decision. All I want is a good decision to be made and have a crond that is not buggy. Therefore I think that it is foolish not to present the available options in an accurate light.