On Monday, June 29, 2020 12:58:30 AM MST Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Jun 28, 2020 at 01:32:41PM -0700, John M. Harris Jr wrote: *snip* > > - Mask/disable systemd-homed > > > Doesn't do anything unless you create some users with homectl.
There's no reason for it to be there, wasting resources. > > - Mask/disable systemd-userdb > > > That's just a proxy service to provide user records as json. On its > own it doesn't really do much. That's awful, and the above applies there as well. > > - Mask/disable systemd-sysusers > > > Well, various packages make use of systemd-sysusers so if you disable > systemd-sysusers, they won't get a user created and will likely not > work. Also doesn't do anything if there's no configuration. But knock > yourself out. I don't think that's the case, since that Change required that `useradd` (or was it `adduser`?) be used. It'd be worth a try to remove the systemd bloat. > > - Mask/disable systemd-repart > > > Doesn't do anything unless you provide a configuration file. So it has no reason to be there. > > - Mask/disable systemd-resolved > > > That's trivially disabled. The Change page lists a few mechanisms. It's one of the many things in this list. Each one may be "trivially disabled", but it all adds up. > > - Mask/disable systemd-networkd > > > Doesn't do anything unless you provide configuration files. And, so, it shouldn't be there, wasting resources. > > - Mask/disable systemd-timesyncd > > > Chrony is the default choice in Fedora, so until you uninstall chrony > and enable timesyncd, you're safe. Same as above, it's unnecessary bloat. > > - Disable systemd-xdg-autostart-generator > > > That's a mechanism for gnome and kde to spawn apps. Right now it's not > used yet, but it might in the future... I guess your best bet is not > to use gnome or kde. TWM would be a safe choice ;) systemd has no place doing the DE's job. That's why I have a DE, instead of systemdOS. :) > > - Remove the privacy anti-feature of using Google DNS when none are > > configured > > In general people seem to prefer to have a functional network without > manual configuration. So we want to pick *some* default. Google DNS > seems to be not better or worse than other major providers. But if > you'd rather prefer to have no DNS if none is configured, it's still a > one line config to "fix" the issue. Generally, if there are no configured servers, people expect that.. there are no DNS servers in use. That's how it should be. I don't expect the system to outright subvert my intentions to run off to Google, and I'm sure others don't either. See the systemd-resolved Change "proposal" thread for more information on that. > > - Disable fstrim.timer > > - Disable EarlyOOM > > - Not set a default EDITOR > > > All those are trivially done with a single command or one-line file. That'd be the purpose of the Spin, so that users don't have to keep track of all of the things that need to be fixed. > > - Have no modular repos by default > > > This one will soon be trivially done with a single command. Yes, and that'll make it all the more simple to add it as an excluded package in the Spin's kickstart! ;) > > - Not use btrfs or XFS as the default filesystem > > > Pick a different default when installing... Hey, that's my line! Seriously though, that wasn't really a fair thing for me to write. At the time, I was of the attitude of "I don't really care if it breaks users' systems", and to "let those folks make a mockery of Fedora with that default". Sure, folks who are in the know will pick their own partitioning scheme and filesystems of choice. However, that doesn't solve the UX of a new user. > > From this list, I know it might look like I'm calling out systemd. Well, > > that's just because it's become so bloated. > > > I'd say "useful", but that's just words. Anyway, each of the items on > this list can be easily disabled. I guess you could provide a simple rpm > in a copr repo somewhere that does this. I don't see why it'd need to be copr, I actually like mattdm's suggestion above. Some of these may need a bit more consideration, such as sysusers, but it'd have a lot of value to Fedora users. -- John M. Harris, Jr. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
