On Friday, June 5, 2020 12:03:03 PM MST Chris Murphy wrote: > On Fri, Jun 5, 2020 at 11:47 AM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> > wrote: > > > > > > On Thursday, June 4, 2020 11:54:37 PM MST Kevin Kofler wrote: > > > > > > Also -1 to adding something to the core system that is written in a > > > language for which we do not even have dynamic linking support. Or > > > even real static linking support, as opposed to packaging libraries as > > > source code.> > > > > Kevin Kofler > > > > > > > > Agreed. Besides, GNOME already has this enabled, right? It's definitely > > not right for servers, as I brought up the last time this was thrown > > around. > > In discussions with both cloud and server folks, their use cases often > do not even create disk-based swap at all. A small swap-on-zram > provides all the benefits of inactive anonymous page eviction, > including reducing reclaim of file pages, without the black hole > performance problems of swap-on-drive. > > So yes it's well suited for these cases and the proposal does include > them. If they wish to be left out, that's up to those working groups. > It's possible to make sure /etc/systemd/zram-generator is not present. That doesn't seem to reflect reality. If you download the Server image right now, and go with its automatic partitioning scheme generation, it'll give you a swap partition on LVM. This is correct for most servers, not necessarily the LVM part, but having swap on disk. It really seems like this is wrong for most of Fedora, but that individual parts, such as Fedora GNOME or IoT, should be left to make the decision for themselves, without affecting the rest. -- John M. Harris, Jr. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx