Laptop Mode Tools revisited due to a change in its functionality

The site statistics for this blog can be quite revealing. For example, over the last two or three months I noticed that my post How to prevent a USB mouse auto-suspending in Linux when a laptop’s power supply is disconnected has consistently been one of the most viewed. Given the problems I experienced with Laptop Mode Tools 1.65 (see my Gentoo Linux Forums post Bug in laptop-mode-tools-1.65? and Gentoo Linux Bugzilla Bug Report No. 520124), I was not entirely surprised. Thanks to fellow Gentoo Linux and Laptop Mode Tools user Ted Tanberry I learned that Version 1.65 had stopped using Laptop Mode Tools module usb-autosuspend, and started using Laptop Mode Tools module runtime-pm instead. At least that was the developer’s intention, but he had not implemented it correctly. The aforementioned Gentoo Linux bug report explains in detail the problem with Version 1.65.

The situation in my Gentoo Linux installation with laptop-mode-tools-1.64 installed, providing the functionality I desired, was as follows:

a. The precise package installed:

# eix -I laptop-mode-tools
[U] app-laptop/laptop-mode-tools
Available versions: 1.64 (~)1.65 (~)1.65-r1 (~)1.66 {+acpi apm bluetooth scsi}
Installed versions: 1.64(10:04:43 21/10/14)(acpi bluetooth -apm -scsi)
Homepage: http://www.samwel.tk/laptop_mode/
Description: Linux kernel laptop_mode user-space utilities

b. The auto-suspend state when the laptop PSU was connected:

# for d in /sys/bus/usb/devices/[0-9]* ; do if [[ -e $d/product ]] ; then echo -e "`basename $d`\t`cat $d/power/control`\t`cat $d/speed`\t`cat $d/product`" ; fi ; done
1-1.2 on 1.5 USB Laser Mouse
2-1.2 on 12 Fingerprint Sensor
2-1.3 on 480 USB 2.0 Camera

c. The contents of the file /lib64/udev/rules.d/99-laptop-mode.rules:

ACTION=="change", SUBSYSTEM=="power_supply", RUN+="lmt-udev auto"
ACTION=="add|remove", SUBSYSTEM=="machinecheck", RUN+="lmt-udev auto"
ACTION=="add|remove", SUBSYSTEM=="usb", RUN+="lmt-udev force modules=usb-autosuspend devices=%k"

d. The contents of file /etc/laptop-mode/conf.d/usb-autosuspend.conf:

#
# Configuration file for Laptop Mode Tools module usb-autosuspend.
#
# For more information, consult the laptop-mode.conf(8) manual page.
#
 
 
###############################################################################
# USB autosuspend settings
# ------------------------
#
# If you enable this setting, laptop mode tools will automatically enable the
# USB autosuspend feature for all devices.
#
# NOTE: Some USB devices claim they support autosuspend, but implement it in a
# broken way. This can mean keyboards losing keypresses, or optical mice turning
# their LED completely off. If you have a device that misbehaves, add its USB ID
# to the blacklist below and complain to your hardware vendor.
################################################################################
 
# Enable debug mode for this module
# Set to 1 if you want to debug this module
DEBUG=0
 
# Enable USB autosuspend feature?
# Set to 0 to disable
CONTROL_USB_AUTOSUSPEND="auto"
 
# Set this to use opt-in/whitelist instead of opt-out/blacklist for deciding
# which USB devices should be autosuspended.
# AUTOSUSPEND_USE_WHITELIST=0 means AUTOSUSPEND_*_BLACKLIST will be used.
# AUTOSUSPEND_USE_WHITELIST=1 means AUTOSUSPEND_*_WHITELIST will be used.
AUTOSUSPEND_USE_WHITELIST=0
 
# The list of USB IDs that should not use autosuspend. Use lsusb to find out the
# IDs of your USB devices.
# Example: AUTOSUSPEND_USBID_BLACKLIST="046d:c025 0123:abcd"
AUTOSUSPEND_USBID_BLACKLIST="046d:c052"
 
# The list of USB driver types that should not use autosuspend.  The driver
# type is given by "DRIVER=..." in a USB device's uevent file.
# Example: AUTOSUSPEND_USBID_BLACKLIST="usbhid usb-storage"
AUTOSUSPEND_USBTYPE_BLACKLIST=""
 
# The list of USB IDs that should use autosuspend. Use lsusb to find out the
# IDs of your USB devices.
# Example: AUTOSUSPEND_USBID_WHITELIST="046d:c025 0123:abcd"
AUTOSUSPEND_USBID_WHITELIST=""
 
# The list of USB driver types that should use autosuspend.  The driver
# type is given by "DRIVER=..." in a USB device's uevent file.
# Example: AUTOSUSPEND_USBTYPE_WHITELIST="usbhid usb-storage"
AUTOSUSPEND_USBTYPE_WHITELIST=""
 
# Trigger auto-suspension of the USB deivce under conditional circumstances
BATT_SUSPEND_USB=1
LM_AC_SUSPEND_USB=0
NOLM_AC_SUSPEND_USB=0
 
# USB Auto-Suspend timeout in seconds
# Number of seconds after which the USB devices should suspend
AUTOSUSPEND_TIMEOUT=2

Having experienced the problems with the buggy Laptop Mode Tools 1.65, I re-installed 1.64 and had been using that successfully until a week ago. Then I noticed that 1.66 had been released, so I installed it:

# emerge laptop-mode-tools
.
.
.
>>> Installing (1 of 1) app-laptop/laptop-mode-tools-1.66::gentoo
* To enable automatic power state event handling,
* e.g. enabling laptop_mode after unplugging the battery,
* both laptop_mode and the acpid daemon must be
* added to default runlevel:
* # rc-update add laptop_mode default
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

* GNU info directory index is up-to-date.

I would not have expected that ewarn message about adding laptop_mode to the default runlevel, as the ebuild is only supposed to display the warning if laptop_mode is not assigned to the default runlevel. But, sure enough, something had removed it:

# rc-update show -v | grep laptop
laptop_mode |
# rc-update show -v | grep acpi
acpid |      default

I don’t know what removed laptop_mode from the default runlevel. It was certainly assigned previously, as proved by Laptop Mode Tools 1.64 working as expected when I connected and disconnected the laptop’s PSU from the mains (see my earlier post). Anyway, I re-added it:

# rc-update add laptop_mode default
* service laptop_mode added to runlevel default

If you use systemd instead of OpenRC, instead of adding laptop_mode to the default runlevel you would need to use the following command:

# systemctl enable laptop_mode.service

Notice that the incorrect contents of 99-laptop-mode.rules and /etc/laptop-mode/laptop-mode.conf that were present in Laptop Mode Tools 1.65 have been fixed in 1.66:

# cat /lib64/udev/rules.d/99-laptop-mode.rules
ACTION=="change", SUBSYSTEM=="power_supply", RUN+="lmt-udev auto"
ACTION=="add|remove", SUBSYSTEM=="machinecheck", RUN+="lmt-udev auto force"
ACTION=="add|remove", SUBSYSTEM=="usb", RUN+="lmt-udev force modules=runtime-pm devices=%k"

# cat /etc/laptop-mode/laptop-mode.conf | grep usb-autosuspend
#

The ebuild for Laptop Mode Tools 1.66 did not delete the now-redundant file /etc/laptop-mode/conf.d/usb-autosuspend.conf but it is presumably ignored by 1.66 anyway.

From now on I must configure the contents of /etc/laptop-mode/conf.d/runtime-pm.conf instead. After installing Laptop Mode Tools 1.66 it contained the following:

#
# Configuration file for Laptop Mode Tools module runtime-pm
#
# For more information, consult the laptop-mode.conf(8) manual page.
#


###############################################################################
# Runtime Power Management Settings
# ---------------------------------
#
#__COMMENT If you enable this setting, laptop mode tools will automatically enable
#__COMMENT the Runtime Power Management feature for all devices.
#__COMMENT
#__COMMENT NOTE: Some devices claim they support autosuspend, but implement it in a
#__COMMENT broken way. This can mean keyboards losing keypresses, or optical mice
#__COMMENT turning their LED completely off. If you have a device that misbehaves,
#__COMMENT add its DEVICE ID to the blacklist section below and complain to your
#__COMMENT hardware / device driver contact
#
################################################################################

# Enable debug mode for this module
# Set to 1 if you want to debug this module
DEBUG=0

# Enable Runtime autosuspend feature?
# Set to 0 to disable
CONTROL_RUNTIME_AUTOSUSPEND=1

# Set this to use opt-in/whitelist instead of opt-out/blacklist for deciding
# which devices should be autosuspended.
# AUTOSUSPEND_USE_WHITELIST=0 means AUTOSUSPEND_*_BLACKLIST will be used.
# AUTOSUSPEND_USE_WHITELIST=1 means AUTOSUSPEND_*_WHITELIST will be used.
AUTOSUSPEND_USE_WHITELIST=0

# The list of Device IDs that should not use autosuspend. Use system commands or
# look into sysfs to find out the IDs of your devices.
# Example: AUTOSUSPEND_DEVID_BLACKLIST="046d:c025 0123:abcd"
AUTOSUSPEND_RUNTIME_DEVID_BLACKLIST=""

# The list of device driver types that should not use autosuspend.  The driver
# type is given by "DRIVER=..." in a device's uevent file.
# Example: AUTOSUSPEND_DEVID_BLACKLIST="usbhid usb-storage"
AUTOSUSPEND_RUNTIME_DEVTYPE_BLACKLIST=""

# The list of Device IDs that should use autosuspend. Use system commands or
# look into sysfs to find out the IDs of your devices.
# Example: AUTOSUSPEND_DEVID_WHITELIST="046d:c025 0123:abcd"
AUTOSUSPEND_RUNTIME_DEVID_WHITELIST=""

# The list of device driver types that should use autosuspend.  The driver
# type is given by "DRIVER=..." in a device's uevent file.
# Example: AUTOSUSPEND_DEVTYPE_WHITELIST="usbhid usb-storage"
AUTOSUSPEND_RUNTIME_DEVTYPE_WHITELIST=""

# Trigger auto-suspension of the deivce under conditional circumstances
# Warning: DO NOT CHANGE THESE DEFAUTLS UNLESS YOU KNOW
BATT_SUSPEND_RUNTIME=1
LM_AC_SUSPEND_RUNTIME=1
NOLM_AC_SUSPEND_RUNTIME=1

# Auto-Suspend timeout in seconds
# Number of seconds after which the USB devices should suspend
AUTOSUSPEND_TIMEOUT=2

So, in order to stop my laptop’s USB mouse, USB external keyboard and some internal USB devices from going to sleep when my laptop is only on battery power, I made the following change to a line in /etc/laptop-mode/conf.d/runtime-pm.conf:

# External keyboard at one office, internal Webcam, internal fingerprint sensor, Logitek NX50 notebook mouse
AUTOSUSPEND_RUNTIME_DEVID_BLACKLIST="03f0:0024 064e:a115 147e:1001 046d:c052"

My earlier post about Laptop Mode Tools explained one method for finding the device ID for each USB device, but the lsusb command can also be used:

# lsusb
Bus 002 Device 005: ID 03f0:0024 Hewlett-Packard KU-0316 Keyboard <---- External keyboard at one office
Bus 002 Device 004: ID 064e:a115 Suyin Corp. <---- Built-in Webcam
Bus 002 Device 003: ID 147e:1001 Upek TCS5B Fingerprint sensor <---- Built-in fingerprint sensor
Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 046d:c052 Logitech, Inc. <----Logitech NX50 notebook mouse
Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Although the Laptop Mode Tools usb-autosuspend module is supposed to be unused in 1.66, I edited /etc/laptop-mode/conf.d/usb-autosuspend.conf (which was not deleted by the 1.66 ebuild) and changed CONTROL_USB_AUTOSUSPEND="auto" to CONTROL_USB_AUTOSUSPEND="0" just to be on the safe side.

My thoughts on systemd

When I first read about systemd a few years ago, the main ‘marketing point’ seemed to be that Linux boots faster using it rather than SysVinit — see, for example, On to better booting. When I read that article back in September 2012, a paragraph caught my eye:

It looks like the crowd lining up behind systemd is growing fast. With Fedora, OpenSUSE, Mandiva, Arch, Debian, Gentoo, Frugalware — Did I forget anyone? And RedHat will probably be joining with the release of RedHat7. Ubuntu seems to be sticking with Upstart.

As a Gentoo user I was surprised to read that the distribution was ‘lining up behind systemd’ — systemd was not even mentioned in the Gentoo Handbook — so I started a thread in the Gentoo Forums enquiring whether there were plans to change the default init system from OpenRC to systemd: Gentoo ‘lining up behind systemd’?.

Revisiting that ITWorld article two years later, I notice the paragraph was subsequently changed, as it now reads:

It looks like the crowd lining up behind systemd is growing fast. With Fedora, OpenSUSE, Mandiva, Arch, Debian, Frugalware — Did I forget anyone? And RedHat will probably be joining with the release of RedHat7. Gentoo has its own next generation rc system called OpenRC, which competes with both systemd and upstart, but provides its users with the option of installing systemd. Ubuntu seems to be sticking with Upstart.

OpenRC works fine for me; I know how to use it and I do not particularly want to have to learn how to use another system when what I use now works perfectly well for my purposes. By no means do I begrudge others the use of systemd, as long as my freedom of choice is not curtailed. Each to his own, as the saying goes. But events over the past couple of years have left me wondering about my freedom to choose in the future, and indeed about the future form of the operating system itself.

Faster startup?

As I mentioned above, the main marketing point when I first read about systemd was its boot time. When I tried systemd in May 2013 on a 2009 Acer Aspire 5536-643G25Mn laptop (dual-core CPU; 3 GB RAM) — no match for today’s state-of-the-art hardware — the times to boot from the GRUB 2 menu to the DM login screen for a fully-updated 64-bit Sabayon Linux Xfce installation were as follows:

OpenRC with rc_parallel=”NO”	33 seconds
OpenRC with rc_parallel=”YES”	31 seconds
systemd	29 seconds

I posted the above timings in the Sabayon Linux Forums and the developer of the distribution responded:

speed improvements heavily depend on the CPU and I/O subsystem. In particular, systemd is able to leverage multi-core CPUs much better (because it spawns services in parallel). Spawning services in parallel also puts more pressure on the I/O subsystem, which means that if you have faster I/O (like with SSDs), the speed boost compared to OpenRC becomes quite relevant.

Indeed a few users of newer machines with 8 GB or more RAM and/or SSD drives wrote in the Sabayon Linux Forums that their boot times had almost been halved (e.g. from circa 40 seconds to circa 21 seconds). However, I expect the boot times for OpenRC and systemd would not be dramatically different from each other on any of my existing machines and, in any case, I’m not bothered about saving a few seconds in boot time on my machines (and I don’t reboot often either).

Nowadays one hears less mention of faster boot times from systemd proponents. For example, the author of the December 2011 article Here We Go Again, Another Linux Init: Intro to systemd mentioned ‘Faster Startups’ early on, whereas in a September 2014 article Understanding and Using Systemd, the same author states:

For whatever reason, it seems that the proponents of SysVInit replacements are obsessed with boot times. My systemd systems, like CentOS 7, don’t boot up all that much faster than the others. It’s not something I particularly care about in any case, since most boot speed measurements only measure reaching the login prompt, and not how long it takes for the system to completely start and be usable.

Erosion of choice?

A couple of Gentoo developers commented in the above-mentioned 2012 Gentoo Forums thread that adoption of systemd as the default init system in Gentoo would be extremely unlikely. Several posters pointed out that alternative init systems exist and Gentoo users could simply install an alternative if desired. However, I started to wonder about the long-term availability of choice when I began to see blog posts such as Red Hat Flag and, indeed, when I myself was affected by systemd’s subsumption of udev (see e.g. udev is doomed) earlier this year and, more recently, when a Gentoo developer had to create the package upower-pm-utils because systemd subsumed hibernate & suspend support from upower (UPower 0.99.0 was released to ~arch as of 2014-06-01).

Whatever one’s views on systemd, the impact on non-systemd users when systemd developers change something that previously worked fine is frustrating. Gentoo developers have been doing a good job working around such nugatory subsumptions, but it’s extra work for them and extra effort for the Gentoo user who doesn’t use systemd. I began to wonder how long this state of affairs could continue.

Another layer of abstraction?

Although my main laptop has Gentoo installed with OpenRC, on a couple of other machines I tinker with Sabayon Linux, which uses systemd. Sabayon Linux is pre-compiled Gentoo with an overlay and its own binary package manager, so there is some synergy in using the two distributions. Also, it is clear from several threads requesting help in the Gentoo Forums that a number of Gentoo users are migrating to systemd. In answering or just reading forum posts involving systemd, and in writing blog posts of my own explaining how to use systemd for certain tasks, in some cases it feels to me as if systemd sometimes adds a layer of abstraction that is not necessarily helpful. Two examples that spring to mind are given below.

1. The Gentoo Forums thread [SOLVED]I don’t understand transient hostnames in which a Gentoo user using systemd was trying to stop the hostname being changed when he connected to some networks:

   I’m running a systemd based system for the first time and I’m having an issue with my hostname. Basically, when I connect to (some) networks the network assigns me a transient hostname. This transient hostname seems to completely break everything with my desktop manager (KDM). I have to log out, and then log in with the new transient hostname (which is presumably assigned shortly after I log in and network manager connects to the network). Is this expected? I have set my hostname as described in the handbook and the systemd wiki page. How do I make my hostname *never* change based on dhcp crap?

   After I pointed out that it is possible to force a persistent hostname by specifying the hostname in NetworkManager.conf if NetworkManager is being used with either systemd or OpenRC, he wrote:

   My hostname is now written in 3 places (/etc/hosts, /etc/hostname, and /etc/NetworkManager/NetworkManager.conf). Oh, and I have some random executable (hostnamectl) sitting on my system doing a seemingly poor job of ‘controlling’ my hostname.

   Out of curiosity I then experimented with hostnamectl and compared the outcome with the outcome of setting the hostname in an installation that does not use systemd, and the results differed, so I’m not sure of the scope of hostnamectl.

2. Time (Arch Wiki)

   The hardware clock can be queried and set with the timedatectl command. To change the hardware clock time standard to localtime, use:

   # timedatectl set-local-rtc 1

   If you want to revert to the hardware clock being in UTC, do:

   # timedatectl set-local-rtc 0

   These will generate /etc/adjtime automatically and update the RTC accordingly; no further configuration is required.

   During kernel startup, at the point when the RTC driver is loaded, the system clock may be set from the hardware clock. Whether this occurs depends on the hardware platform, the version of the kernel and kernel build options. If this does occur, at this point in the boot sequence, the hardware clock time is assumed to be UTC and the value of /sys/class/rtc/rtcN/hctosys (N=0,1,2,..) will be set to 1.

   Later, the system clock is set again from the hardware clock by systemd, dependent on values in /etc/adjtime. Hence, having the hardware clock using localtime may cause some unexpected behavior during the boot sequence; e.g system time going backwards, which is always a bad idea (there is a lot more to it). To avoid it systemd (>215) will only synchronize back, if the hardware clock is set to UTC and keep the kernel uninformed about the local timezone. As a consequence timestamps on a FAT filesystem touched by the Linux system will be in UTC.

   Note: The use of timedatectl requires an active dbus. Therefore, it may not be possible to use this command under a chroot (such as during installation). In these cases, you can revert back to the hwclock command.

Swimming against the tide?

There have been a number of dissenting voices on the Internet. Some argue against systemd on technical grounds, others on philosophical grounds. Here are are few examples:

• boycott systemd
• You have your Windows in my Linux
• Systemd: The Biggest Fallacies

One of the few distributions bucking the trend is Void Linux, which has replaced systemd with runit as the default init system, with systemd becoming an option.

Slackware and Gentoo are two distributions that do not use systemd by default, although it is actually reasonably straightforward to switch to systemd in Gentoo. It seems one or two people are moving to Gentoo, or contemplating it, because systemd isn’t the default in Gentoo (see, for examples, Re: OT: Open letter to the Linux World and IgnorantGuru’s Hiatus).

Several threads in the Gentoo Forums contain prolonged discussions on systemd, and it is clear that some Gentoo users have strong reservations about systemd. As I write this, a poll in the Gentoo Forums shows only 13 per cent of respondents support the idea of Gentoo adopting systemd as the default init system. I suspect that users of binary-based distributions find this lack of enthusiasm odd, but I believe it is because Gentoo is a source-based distribution and its users are usually more familiar with Linux internals and more comfortable, more adept and more interested in getting ‘under the hood’ than are users of binary-based distributions. Gentoo is not quite Linux From Scratch, but Gentoo users build their installations almost from the ground up (Gentoo does not even have an installer application, for example). I believe that anything interfering with the current way of doing things, or adding a level of abstraction, is not of interest to many Gentoo users. On the other hand, I think users of binary-based distributions who just want to get something done in the quickest way possible are less likely to object.

The beginnings of a new OS?

systemd is not just an init system, it has grown into much more than that and continues to add functionality (referred to by some as ‘feature creep’). Below is the current list of functionality provided in systemd, and the list is growing.

init system, journal logging, login management, device management, temporary and volatile file management, binary format registration, backlight save/restore, rfkill save/restore, bootchart, read-ahead, encrypted storage setup, EFI/GPT partition discovery, virtual machine/container registration, minimal container management, hostname management, locale management, time management, random seed management, sysctl variable management, console management, network management, time synchronisation

I think more of the seasoned GNU/Linux users are waking up to the impact of what Lennart Poettering (the chief architect of systemd) and his fellow systemd ‘cabal’ (his word) members are doing. They are re-designing GNU/Linux from the ground up, and I don’t think it would be an exaggeration to call the end result ‘systemd/Linux’, a de facto new OS. Personally I’m not interested in using that, but I think the vast majority of existing users or newcomers to ‘Linux’ — to use the popular term for the OS — simply don’t care. As long as it works out-of-the-box, that’s all that matters to most people.

And as far as distribution developers are concerned, the status quo says it all: most have already switched their distributions to systemd or have committed to doing so in the future. I suspect it is because they see systemd as being easier to maintain, thus making their lives easier, and they also see systemd as being easier for their desktop users (and with a boot time closer to Windows 8/8.1 Fast Startup). Ultimately the systemd ‘cabal’ will effectively make the different package managers obsolete too, as the latest plan Revisiting How We Put Together Linux Systems shows.

In my opinion, the end result of the radical systemd redesign of the OS could be greater take-up of the OS on the desktop, but the distinction between distributions will lessen and many will cease to exist, as there will be little point choosing one over another. The greater commonality and the larger user base of systemd/Linux will attract more crackers than at present. In some respects the de facto new OS will be much more like Windows or Mac OS than the current GNU/Linux.

Widening the net?

In a Chromium OS discussion group thread earlier this year — The future of initsystem in Chromium OS — a systemd proponent (a Fedora developer?) offered to help the Chrome OS developers switch from Upstart to systemd, but the Chrome OS developers saw no reason to do so without proof of tangible benefits. I believe there is too much revenue at stake to risk switching an important component of the OS of a commercial product (Chromebooks) on a whim. With Chromebooks looking increasingly like the main threat to Microsoft’s hegemony on the desktop, I’m sure Google has no interest in jeopardising that without a very good reason.

The future?

The future seemed clear to me once Mark Shuttleworth announced Ubuntu would drop Upstart and adopt systemd (he made the announcement after Debian developers decided to adopt systemd). Given the number of Ubuntu users (I’ve seen figures in the tens of millions bandied about), I believe Ubuntu will be the making or breaking of systemd. In my opinion, as was the case with PulseAudio (another Lennart Poettering project) there will be a couple of choppy years with plenty of posts in the Ubuntu Forums seeking help, more bugs will be shaken out, and I believe the vast majority of Linux users will end up as accepting users of systemd. In some cases systemd does make configuration a little easier for a newcomer (see, for example, my post Configuring the Linux clock). Personally I find systemd no easier to use than what I use now; in some cases I find systemd more complicated than what I use now (e.g. OpenRC’s local.d). My concerns regarding abstraction, subsumption, loss of choice and the morphing of the OS into something closer to the Windows approach remain, although I can see that many people, including newcomers to Linux, would actually welcome those things. Ironically, although I used to get frustrated with the large number of Linux distributions and their differences, the implications of greater commonality now worry me from a security (predominantly cybercrime) point of view. I am satisfied and comfortable with the existing GNU/Linux tools, configuration files, modus operandi and OpenRC (which works with no problems whatsoever in my case), so I have no desire to migrate to systemd on my main machine running Gentoo Linux. I will also continue to tinker with Sabayon Linux, and thus with systemd, but it will be several years hence before this jury returns a verdict on systemd.