On Thu, 11 Apr 2019 12:30:11 +0200
"Brian (bex) Exelbierd" <bexelbie(a)redhat.com> wrote:
To: Japheth Cleaver <cleaver(a)terabithia.org>
CC: Development discussions related to Fedora
<devel(a)lists.fedoraproject.org> Subject: Re: Can we maybe reduce the
set of packages we install by default a bit? Date: Thu, 11 Apr 2019
12:30:11 +0200 Reply-To: Development discussions related to Fedora
On Wed, Apr 10, 2019 at 8:54 PM Japheth Cleaver
> Reducing the Minimal size is, in general, good, but it's possible
> to go too far, and I think that's the case with low-level, *nix
> wide tools like this. I'm reminded of the time someone thought tar
> needed to go too:
My interest, and the way I read the OP was not about minimal size,
directly. In this case, it sounds like we have adopted a tool,
systemd, that replaces another tool, cron. We can debate the
completeness of the replacement, etc, but it is also valid to question
why we ship both as default installed.
Extending this, tar is a reasonable thing to install on all systems
today. That might not be true tomorrow. I encourage Fedora to be
willing to explore these questions and make opinionated decisions.
> > Lastly, taking a position on some of this, for example, removing
> > cron, is a form of opinionation that calls back to our roots of
> > innovating in the OS space. We would be saying, we recognize
> > this is the way we did things X years ago, but there are new ways
> > and processes and we see value in those. If we can't remove
> > these things, then we are being a good distribution by pointing
> > out where solutions that claim to fix something have fallen short
> > so that those upstreams can make decisions about what to do.
> But what, exactly, has cron fallen short in?
In this case, I was trying to communicate that if systemd, which seems
to want to replace cron, can't meet all the use cases, we should be
reporting those that we find in the distro. That lets the systemd
upstream decide if it is in scope or not and make changes as needed.
From a security point, we'd want the equivalent of cron.allow,
cron.deny. We'd need the pam stack to run just as it did for cron which
means it needs to be privileged and switch to the user account so that
it can correctly recreate the user environment, optionally do auditing
as needed (just like cronie), and it would need to be MLS (Multi-level
If it did all these things, I could see ditching cron. I also have not
looked into the systemd timers to see if or how much of this it