Re: Fedora 33 System-Wide Change proposal: swap on zram

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday, June 9, 2020 2:24:02 AM MST Kevin Kofler wrote:
> John M. Harris Jr wrote:
> 
> > I wonder if we could get that masked in Fedora Server and KDE Spin,
> > potentially along with homed, userdb, repart (Who in the world thought
> > this was a good idea?), resolved, networkd,
> > systemd-xdg-autostart-generator (you've got to be kidding with these
> > generators.. that's the DE's job, not the init system), systemd-sysusers,
> > systemd-growfs, and an ever growing list of absurd things thrown into an
> > init system.
> 
> 
> Are all those things enabled in Fedora by default? repart and growfs sound 
> particularly scary to me. How do they even decide what partitions they want
> to create or grow? I definitely do not want systemd to mess with my
> partitions, even if it does not delete anything!
> 
> 
> > These things are not discoverable at all. This stuff really needs to stop
> > trying to guess what the user/sysadmin wants to do.
> 
> 
> Yes, I think this is going too far lately. I think the first generation of 
> systemd modules, where the main idea was replacing ugly shell scripts with
> fast native C code, was a good idea, and systemd initially actually made
> things easier to configure (so I have never understood those systemd
> haters), but these days, the feature creep is adding complexity instead of
> removing it.

I completely agree. For example, I really like systemd as it is in RHEL7. Past 
that, it's an ever growing list of things that have nothing to do with the 
init system. Instead of being a fairly elegant init system, it's got more and 
more cruft thrown in on top.

Contrary to what is repeatedly claimed, these do still run even if there's no 
config, even if they don't do anything, which isn't the case. systemd-homed 
was mounting /home where it was explicitly listed as `noauto` last time I 
checked. See the output of `systemctl status systemd-homed` or `systemctl 
status systemd-repart`. What's even more wild is that you can't easily disable 
it. Even though it's supposed to be disabled ("vendor preset: disabled") it's 
actually built into systemd, as a static unit.

To quote Lennart on one of these, userdb specifically, "not sure I get this? 
why disable this at all? it's a tiny daemon, and shouldn't matter at all..."

> This reminds me more and more of that proprietary operating system which 
> does lots of complex and controversial things without asking you and where 
> you have to hunt down obscure registry keys in an attempt to hopefully stop
> it from doing those things.

Agreed on this as well, and that's making life hell for sysadmins and users 
alike.

-- 
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux