Here's the 12th installment of posts highlighting key new features of the upcoming v256 release of systemd.
Putting a PC to sleep is complicated business and there are different mechanisms available to achieve this on Linux. Broadly speaking there is suspend-to-ram and suspend-to-disk, as well as combinations of this: one where we suspend to both, and one where we first suspend-to-ram and then later change to suspend-to-disk, if we have slept for a long time, or the battery is running empty.
Which types of sleep are available depends on various parameters. On functionality of the hardware, on security settings, on available swap space and more.
systemd exposes all four modes listed above via high D-Bus calls in systemd-logind, and via systemctl commands. Desktop UIs so far were expected to figure out which of the methods to use, and maybe implement a fallback scheme. This is less than ideal, in particular as inhibitor schemes would trigger multiple times…
…if fallbacks are necessary.
With v256 we did something about this: there's now a new D-Bus call and systemctl command, which we just called "sleep". It's supposed to abstract this mess away, and just get the job done, according to what is available, and based on system-level configuration in /etc/systemd/sleep.conf if needed.
This relieves tools and desktops to bother what precisely to when suspending, and just make the system "sleep" and let the lower layers of the stack then figure…
…out what to precisely do.
Hence, in your mind, please rewire "systemctl suspend" to now become "systemctl sleep".
And that's all for now. Stay tuned for installment Nr. 13.
@pid_eins could you elaborate to this noob?
Basically, "sleep mode" on Linux is a mess. As Lennart said, there are 4 modes available. So far it's been up to the desktop environment or end-user to figure out what works or not. But that gives a pretty bad user experience, since you need to battle what's possible or not. And some environments disables feature which could work for you, but doesn't work for the majority of their users - so you, who could get a better user experience does not get that because of lots other users would get an even worse user experience.
"systemctl sleep" is a new feature, which figures out the best approach for you your system when you call it. This functionality is also available via a DBus API which desktop environments can use directly as well¹. Thus ideally giving a much better user experience for all users.
So Lennart is just asking all who uses or implements the "systemctl suspend" feature today to switch to use "systemctl sleep" - to give more end-users a better user experience.
¹ The systemctl command is effectively just a tool which calls DBus APIs provided by the systemd service stack. And that's the same API desktop environments and other tools can interact with as well.
@pid_eins it is good to see the continuing progress in my favorite #FreeSoftware operating system, Arch systemd/gnu/linux!
@pid_eins the urge to make an “eep” alias for it is real
@pid_eins I've wondered for quite a while how systemd uses version numbers. When do you increase version number? Does it happen at a fixed interval?
@dinfuehr we increase the version number when we do a new release.