On Thu, 11 Apr 2019 12:30:11 +0200 "Brian (bex) Exelbierd" <bexel...@redhat.com> wrote:
> To: Japheth Cleaver <clea...@terabithia.org> > CC: Development discussions related to Fedora > <devel@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 > <devel@lists.fedoraproject.org> > > On Wed, Apr 10, 2019 at 8:54 PM Japheth Cleaver > <clea...@terabithia.org> wrote: > > > > 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: > > https://bugzilla.redhat.com/show_bug.cgi?id=1409920 > > 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 Security) capable. 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 currently does. -Steve _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
