Date: Sun, 09 Feb 2020 10:09:25 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Josh Aas <josh@kflag.net> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, 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: <202002091809.019I9P9D051984@slippy.cwsent.com> In-Reply-To: <CAJzSF_77peGakgSQXKoVF3x03ZaSRND2tAkaJNe-TG1TC8Fr1Q@mail.gmail.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> <CAJzSF_5dEhnEx5wKGyJ6NrjyJtSiscH9EDrZH-y9EFnE1kN25w@mail.gmail.com> <202002091605.019G5Csj051412@slippy.cwsent.com> <CAJzSF_77peGakgSQXKoVF3x03ZaSRND2tAkaJNe-TG1TC8Fr1Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <CAJzSF_77peGakgSQXKoVF3x03ZaSRND2tAkaJNe-TG1TC8Fr1Q@mail.gmail.c om> , Josh Aas writes: > I understand that some other operating systems have integrated atrun > into cron, but that's not, in and of itself, a reason for FreeBSD to > do it. Other operating systems do lots of things not worth copying in > FreeBSD. I'm curious to hear if there are actual technical reasons > that it's worthwhile for FreeBSD to do it. Because at(1) and batch(1) are immensely useful everyday tools. > > Even if such integration advantages do exist, they might rest on the > assumption that at/atrun is worth keeping in base in the first place. Of course they are worth keeping. I haven't heard a good reason to remove them. > >From what you and others have said, maybe at/atrun doesn't deserve > "basic functionality" status you're ascribing to it. I don't know, I'm > not an expert on this, but it's a perspective that seems worth > considering. In an earlier email you said "People generally have no > idea what they do and people are unwilling to chance using them or > learning something new..." That doesn't sound like a description of > "basic functionality" that necessarily needs to be a part of a base > operating system. It explains why people are unwilling to use tools they've never used before. > > Vi is a very heavily used program, which many people appreciate being > available in base. I'm not advocating removal of vi. I'm drawing parallels, real life examples from $JOB. > That is not the case for "at." It's something a > small minority of people appreciate, but nonetheless, I agree that > they should have access to it. Do we really know that it's a small minority of people? How do you know that? I come from the position of having used the tools for 25 or more years. You come from the position of never having used or > Sounds to me like a great candidate for > inclusion in ports. Pkgbase will resolve this. You pick and choose what you want. I've advocated for pkgbase for a while. You can choose whether to install the cron in pkgbase, use one of the many cron-like tools in ports, or a collection of scripts. > I imagine the default position should be that > things are not in base unless there's a strong argument for it, not > the other way around. That's the point of pkgbase. Packages in base would have the status as ports, just like any Linux distro. You pick and choose what you want and packages would be grouped like they are in an anaconda install. > Does FreeBSD have a set of written guidelines > for what makes something appropriate for inclusion in the base system? Like many organizations (like $JOB) much of this isn't written down, like it should be. Just like $JOB it can be gleaned from mail archives. This is obviously not ideal because it's open to debate and subjective interpretation. This might be a good idea then again maybe not. If we take the justice system as an example, we can either codify things to death (like some jurisdictions do) or we codify less and base our decisions on precedence. This can be argued both ways. I think we do more of the latter here. My vote would be to base our cron on NetBSD or OpenBSD. Make cron, crontab, and at/batch build options and pkgbase packages. Additionally, a dialog to allow users to pick and choose which options to enable/disable to configure src.conf, similar to sysrc(8), might be compromise. As you don't use at(1) but other people do doesn't automatically suggest or require the removal of the tool. You're trying to convince us to remove a useful tool, the onus is on you to build a good case for removal. I haven't seen good business case in your arguments so far? -- 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. > > On Sun, Feb 9, 2020 at 11:05 AM Cy Schubert <Cy.Schubert@cschubert.com> wrote > : > > > > In message <CAJzSF_5dEhnEx5wKGyJ6NrjyJtSiscH9EDrZH-y9EFnE1kN25w@mail.gmail. > c > > om> > > , Josh Aas writes: > > > 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. > > > > That is not a compromise. The functionality has been in cron in Solaris, > > AIX, HP-UX, DG/UX, Tru64, and now NetBSD for years, in some cases decades. > > Why such a reluctance to maintain basic functionality because it is either > > not understood or you never use it? > > > > Atrun should be integrated into cron, where all other major UNIX and > > UNIX-like systems have the function. However when we implement pkgbase > > crond(8), crontab(1), and at(1)/batch(1) should be three separate packages, > > like Linux distros do. crond(8) could be installed by default whereas > > crontab(1) and at(1)/batch(1) would not. > > > > Moving at(1) and batch(1) to ports would be tantamount to putting vi in > > ports because, well, nano is an easier to use editor. (Yes, we did that at > > $JOB on our RHEL servers for a while because vi is too hard for most people > > to use, it used up valuable space, and only installed it if a customer > > specifically requested it. That policy is no more but that it was makes my > > point. We now install vim and nano.) You get my point. The fact that some > > people don't understand a utility and don't have the time or patience to > > learn it (yes, we're all busy, like at $JOB, and taking time out to learn > > something, like at $JOB, has a cost) doesn't mean it's not useful. > > > > Coming from a SunOS, Solaris, HP-UX, DG/UX, Tru64 background, at(1) and > > batch(1) are a basic function of cron, even if some in the Linux community > > feel they're not. > > > > > > -- > > 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. > > > > > > > > > > > > > > > > > > > -- > Josh Aas > (215) 206-2020
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202002091809.019I9P9D051984>