Date: Sun, 9 Feb 2020 15:32:21 -0500 From: Josh Aas <josh@kflag.net> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: freebsd-arch@freebsd.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, "N.J. Mann" <njm@njm.me.uk> Subject: Re: updating cron and atrun Message-ID: <CAJzSF_5dEhnEx5wKGyJ6NrjyJtSiscH9EDrZH-y9EFnE1kN25w@mail.gmail.com> In-Reply-To: <202002091350.019DoZrf084564@slippy.cwsent.com> References: <CAJzSF_7N4A-_6LfjivWRirNkTHv3ANWu%2BBX6g1UOKqdYmDZZNA@mail.gmail.com> <6701.1581190231@critter.freebsd.dk> <97A66670F59C9C626B5090E3@triton.njm.me.uk> <8967.1581243035@critter.freebsd.dk> <55C50689-6DA8-4D44-92BB-72C38B54AC96@cschubert.com> <202002091350.019DoZrf084564@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
There seems to be a real question here about the value of at/atrun. Maybe a good compromise is to move that functionality to ports instead of the base system. If we integrate the functionality into cron then we're basically stuck with it in core. All functionality adds complexity, and complexity adds maintenance cost and risk. Sometimes that's totally worth it, but I don't think it's clear that saddling FreeBSD base with at/atrun because we integrated it with cron for unclear reasons is necessarily a good idea. On Sun, Feb 9, 2020 at 8:50 AM Cy Schubert <Cy.Schubert@cschubert.com> wrote: > > In message <55C50689-6DA8-4D44-92BB-72C38B54AC96@cschubert.com>, Cy > Schubert wr > ites: > > On February 9, 2020 2:10:35 AM PST, Poul-Henning Kamp <phk@phk.freebsd.dk> wr > > ote: > > >-------- > > >In message <97A66670F59C9C626B5090E3@triton.njm.me.uk>, "N.J. Mann" > > >writes: > > >>Hi, > > >> > > >>On Saturday, February 08, 2020 19:30:31 +0000 Poul-Henning Kamp wrote: > > >>> > > >>> Thanks for looking into this. > > >>> > > >>> Is at(1) something people actually use these days, or should it be > > >>> disabled by default ? > > >> > > >>I do. I use it to run various homebrew scripts in response to > > >external > > >>events. I needed a delay (sometime minutes, sometimes hours) between > > >>the event and the response and at(1) was a perfect fit. > > > > > >Right, it is absolutely useful to have, if you need it, and it should > > >not be removed. > > > > > >But if, as I suspect, the vast majority of FreeBSD pointlessly add > > >288 lines to /var/log/cron every day, without anybody ever using the > > >at(1) > > >command, maybe we should disable it to save power and disk-wear ? > > > > I use at at(1) and batch(1) all the time, on FreeBSD and other platforms. Mos > > t people I know, professionally, don't know about these commands. They add th > > e 288 lines to cron every day. They're not interested when I explain to them > > a better way to do it. What's worse, at $JOB, at(1) and batch(1) have been un > > installed on Linux (while they remain on the other platforms) because the sen > > ior Linux person (who left our employ three weeks ago) felt people didn't und > > erstand the utilities and, they could add anything to cron for a day if they > > wanted. > > > > The idea of removing at(1) and batch(1) is not new. People generally have no > > idea what they do and people are unwilling to chance using them or learning s > > omething new because they're busy working. That's my experience. > > Looking at the wiki page, integration of atrun into cron as NetBSD has > done, is obvious. Solaris, HP-UX and every other platform I've used (which > is no longer produced today) have had the atrun functionality performed by > cron itself. This is a no brainer. > > > -- > Cheers, > Cy Schubert <Cy.Schubert@cschubert.com> > FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" -- Josh Aas (215) 206-2020
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJzSF_5dEhnEx5wKGyJ6NrjyJtSiscH9EDrZH-y9EFnE1kN25w>