UWSM Aims To Be A Universal Wayland Session Manager

[spicfoo]

Yes, and I can call it whatever I like. Since I’m a Wayland user who cannot run this software, I’ll choose to express my opinion that it isn’t universal. And I don’t need your approval for that any more than you need mine.

Sure you are welcome to complain all you want about a free and open source software noone is forcing you to use.

[spicfoo]

Maybe actually reading the comment in full rather than skim would help you understand what I said.

I understood you just fine. I highlighted all the ways exactly in which you did seem to mind after declaring that you don't.

[J.King]

By the way, my distro of choice, Trisquel, uses systemd, so I'm not even a hater, I'm a begrudging user of the slowest booting of all modern init systems.

I've never understood why systemd being not-as-fast at booting a system would bother someone. I boot my machine about once a week, and it takes about thirty seconds, much of which is the firmware booting. Shutting down takes about five seconds. I've never felt it needed to be faster. I certainly wouldn't want to lose all the convenience of systemd for faster booting.

[cend]

TODO: Adapt for elogind. Apparantly there is still reasonable amount of maintenance and rebasing, so porting won't be too hard. It's not like eudev where Gentoo switching to systemd-udevd (with a convoluted build process, which I contributed to) left the former to die.

[cend]

I've never understood why systemd being not-as-fast at booting a system would bother someone. I boot my machine about once a week, and it takes about thirty seconds, much of which is the firmware booting. Shutting down takes about five seconds. I've never felt it needed to be faster. I certainly wouldn't want to lose all the convenience of systemd for faster booting.

OpenRC without parallel rc actually seems slower to boot up and shut down than when I just switched to systemd (which is quite easy on Gentoo)...

(Lost all my startup daemon configurations in the process, but setting up services is as easy as it was.)

[andyprough]

I've never understood why systemd being not-as-fast at booting a system would bother someone. I boot my machine about once a week

Some people boot more often. Some people boot a lot more often. So, it can be an issue.

[access]

On all machines I have access to the firmware and other pre-kernel stuff is whats takes a lot of time. When it gets to systemd it just flashes by. Slowest deps in the systemd boot chain on my work laptop is waiting for dockerd to start and network.

# systemd-analyze && systemd-analyze critical-chain
Startup finished in 14.499s (firmware) + 6.190s (loader) + 13.746s (kernel) + 6.083s (userspace) = 40.520s
graphical.target reached after 6.038s in userspace.
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @6.038s
└─multi-user.target @6.038s
  └─docker.service @2.823s +3.214s
    └─network-online.target @2.822s
      └─NetworkManager-wait-online.service @2.529s +292ms
        └─NetworkManager.service @2.097s +397ms
          └─network-pre.target @2.065s
            └─firewalld.service @1.834s +230ms
              └─polkit.service @1.734s +91ms
                └─basic.target @1.692s
                  └─dbus-broker.service @1.666s +23ms
                    └─dbus.socket @1.633s
                      └─sysinit.target @1.611s
                        └─systemd-resolved.service @1.515s +95ms
                          └─systemd-tmpfiles-setup.service @1.480s +27ms
                            └─local-fs.target @1.474s
                              └─boot-efi.mount @1.449s +25ms
                                └─boot.mount @542ms +247ms
                                  └─dev-nvme0n1p2.device @534ms

Some time spent unlocking LUKS in the kernel measurement