On Wed, Apr 10, 2019 at 8:54 PM Japheth Cleaver <cleaver@xxxxxxxxxxxxxx> 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. I was not suggesting cron had a short fall. > >> The last thing I'd want to have to deal with is solving for a missing > >> /etc/cron.* because someone forgot to click a checkbox somewhere or > >> didn't call it out in kickstart. > > Yes, but I also don't want to deal with a security fix in cron when I > > didn't want it to begin with. Adding software the user doesn't want > > to have it as assumed for other users is always a trade-off. > > True, but - as written elsewhere - that can be taken to a logical > extreme, both via removal of simple, auditable utilities and shell > scripts, and eventual giant replacements. I don't consider the evolution of replacements to be inherently bad. They may not meet your use case, but they may meet the use case of the Fedora Workstation core target audience. If we build a workstation that tries to be all things for all people, it is often not great for everyone. I am advocating that we tighten our scope for our deliverables and allow for differentation in them instead of trying to be all things for all people. regards, bex -- Brian (bex) Exelbierd | bexelbie@xxxxxxxxxx | bex@xxxxxxxxx Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
