> Well, that's really the point. The one you're using is one of the (4? 5?) > other zram implementations. It seems a bit more straightforward than the > systemd one for sure. The zram-generator is probably more straightforward (with literally less layers of indirection) than what the zram package provides. I would assume that a generator is also the more idiomatic (and efficient) solution as far as systemd is concerned and I wouldn't mind migrating to that if it looked feature-complete and had decent documentation. There is no manual page[1], only a slightly confusing README that hints at simplicity and incompleteness. I don't see the zram-generator as systemd magic nobody knows about like you claimed. Sure, it's not implemented as a shell script and I'd need to read its source code to understand what it does given the current lack of documentation (which is a shame considering how systemd documentation is often top notch) but as far as the zram package goes I eventually run into the same situation with zramctl. If this thread's initiative converges all implementations towards zram-generator [2] and moves the project forward, then I'm in. Currently it's a mere rust experiment to me, and by that I don't want to downplay it, but it's not mature. Dridi [1] like most rust programs I have used so far [2] shouldn't it be called systemd-zram-generator? _______________________________________________ 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
