It’s Hack Week 9 at SUSE, and I’m working on a cracking project this time around. I’ve codenamed it ‘KLyDE’, for K Lightweight Desktop Environment, and it’s an effort to point KDE at the lightweight desktop market.  Surely some mistake, you say?  KDE and lightweight kan’t fit in the same sentence.  I think they can.

This project has been bouncing around my head for a couple of years now, starting on a train ride back from the KDE PIM meeting in Osnabrück in 2010, then I presented it at COSCUP 2012 in Taiwan last August. But work commitments and family always got in the way of completing/finishing it.  SUSE’s hack week gives me 40 hours to throw at it and this time I wasn’t going to tackle it alone, so I enlisted my bro(grammer)s Jos and Klaas.

As has been repeated on Planet KDE over the past decade, KDE is not intrinisically bloated.  At its core, it jumps through a lot of hoops for memory efficiency and speed, and is modular to a fault. But most packagings of KDE take a kitchen sink approach, and when you install your KDE distribution you get a full suite of desktop, applets and applications.  The other major criticism of KDE is that it is too configurable.  The KlyDE project applies KDE’s modularity and configurability to the challenge of making a lightweight desktop.  However, what I don’t want to do is a hatchet job where functionality is crudely chopped out of the desktop to fit some conception of light weight.

We’re approaching problem from 3 sides:

Minimal footprint

The first method of attacking this is by packaging. It involves factoring optional components of the KDE desktop out of the base installation into subpackages that the main packages only have weak dependencies upon, allowing a minimal installation without them.  This targets big lumps of ram/cpu usage and objects of user hatred like Nepomuk and Akonadi, but also smaller items like Activities and Attica (social desktop support) and non-core window decorations/styles/etc.  The actual KDE build includes everything; the optional components are always available, so those who do need one of them can just add the package and start using it.

The second approach is by configuration.  This allows different profiles of KDE desktop with the same installed packages.  We’ve collected sets of configs that represent these profiles, but I’m not entirely sure how to package this yet.  One way would be to ship default profiles as X sessions.  Another would be a first run wizard or KCModule so users can select profile and apply it to their configuration after login.

Simple config
Is a mixture of usability and perception.  A simplified configuration presents fewer choices and is therefore easier to understand.  It also looks faster and more lightweight, because people equate visual simplicity with efficiency.  This is incorrect, of course, but I’m not above exploiting this fallacy to give people what they want. For this aspect, we’re providing an alternate set of System Settings metadata to give it a cut down tree.  The full set remains available, if needed.

Fast startup

Is the most high-risk-for-reward effort.  It’s mostly a perception/first impression thing.  A working desktop shouldn’t need to be started up all the time.  But for people trying out KLyDE for the first time, a fast startup supports the claim to minimalism.  The interesting thing I note so far is that the package splitting and configuration in 1) makes very little different to startup time.  The optional components of KDE are already highly optimised to not affect startup time.  So I’m investigating alternate startup systems; refactoring startkde, Dantti’s systemk, Plasma Active’s startactive, and a systemd-managed startup.

Progress

The packaging effort is mostly done; we have packages in an Open Build Service project, that give you a bare Plasma Workspace when installed on top of a minimal X SUSE 12.3 installation with –no-recommends.

Jos has put a great effort into understanding System Settings and has produced a simple layout, I just need to complete my patch to allow it to use the alternative metadata scheme at runtime.  If we have time, we’ll also customise some KCMs to provide a simple way to control KDE’s theming.

I’ve been busy converting systemd, kdeinit and ksmserver into a native systemd startup by defining systemd unit files.  It’s a steep learning curve as it exposes a number of assumptions on both sides, but I’m getting there.  The unoptimised systemdkde.target starts up in 4s here, vs 6s for the same .kde4 started by startkde.  That might be due to legacy/fault tolerance parts of startkde being left out, so I won’t give more detailed numbers yet.

Next steps

You can see the state of the project on Trello. I’d like to see if there is a startup time  win by parallelizing kded and ksmserver starting modules and apps. I’d like to make an openSUSE pattern for existing installations, and an iso or a disk image for testers.  I’ve also submitted a talk on the subject for Akademy, so I’d like to work on that and get some real data to support this work.

Just a small quick note.

If you are using the nvidia proprietary drivers from our openSUSE repos. Take care of the following fact. By default the new drivers didn’t add your user to the video group.

Getting Gnome, kdm, kde, or other application running well you have to add your user to the video group.

YaST User & group management being your kindly Gui friend.
or use usermod

sudo usermod -A video yourusername

Happy 3D acceleration!

Just a quick note, I’m sharing my osc12 photo album at this addresse

Enjoy!

I finally will be able to attend osc 12, and I’m really looking forward to be there. I wouldn’t have miss that 4th conference, the first one outside of Germany.

Your VIP place is waiting you

I will go there with the Geeko car, and then will spend some time on the road Friday 19th October.

You can find my planned journey on this map.

I’ve still some place in the car, so if you want to join and are near one of the big place I will cross, just ping me back.

For the return, I’m sorry, I will left Prague only Saturday October 27th, due to the Postgresql europe conference.

You should also be there

Nota: it’s still a small car, so forget to bring your whole geek’s wardrobe

Don’t forget to bring your friends!

Changes for upcoming openSUSE

As a result of my previous 2 second post I have submitted few changes to openSUSE to be included in a next release.

1. purge-kernels.service patch has been accepted by our brave mkinitrd package maintainer
2. requested a split of mkinitrd setup script from splashy package, so users can freely remove the initrd integration without breaking resume et al
3. I opened feature 313851 to make NM the default network tool at least for laptops, because this expects a little more changes than add a package to laptop pattern

Run NetworkManager on demand

That is very uncommon user-case for *nix machines, but makes a perfect sense for consumer devices. My Amazon Kindle or today’s smartphone or tables works in the same way – device starts without a network connection and there’s a button or magic tap enabling it. On my laptop I already have such button – it is the Fn+F2 with a antenna symbol printed. This is the rfkill button turns my wlan card on and off.

So what I want is once I turn wifi on, NetworkManager should start and work. With systemd and it’s udev integration this is so simple, that I was not able to find a good howto for it. So here we are with a small howto for udev/systemd newbiew like me.

We need to know a sysfs name of wlan0 – simple find /sys/ -name 'wlan0' will say us all we need. Then udevadm info will tell you more

udevadm info --path=/sys/class/net/wlan0 --attribute-walk | less
...
  looking at device '/devices/pci0000:00/0000:00:1c.2/0000:01:00.0/net/wlan0':
    KERNEL=="wlan0"
    SUBSYSTEM=="net"
    DRIVER==""

That is all you need to know how to write a rule will match for all wlan cards.

# cat /etc/udev/rules.d/95-start-nm-on-wlan.rules
SUBSYSTEM=="net", NAME=="wlan?", TAG+="systemd", ACTION=="add", ENV{SYSTEMD_WANTS}="NetworkManager.service"

To explain it – SUBSYSTEM and NAME are taken from previous output and means that following rule matches for all devices in net subsystem named wlan-something. We should append tag systemd, because systemd sees tagged devices only. The ACTION=="add" says the rule will be evaluated only in case device will be added and the last part says to systemd which service should be started.

In case you will want to stop NM, the

SUBSYSTEM=="net", NAME=="wlan?", TAG+="systemd", ACTION=="remove", ENV{SYSTEMD_WANTS}="NetworkManager-stop.service"

# cat /etc/systemd/system/NetworkManager-stop.service
[Unit]
Description=Stops NetworkManager
Conflicts=NetworkManager.service

[Service]
ExecStart=/bin/true

WLAN cards

For onboard wlan cards following thing won’t work as they appear in a tree from early phase. Unfortunately I’ve found only one way how kernel exports the fact cable is plugged in and that’s changed /sys/class/net/eth0/carrier. But inotify does not work with a quantum-like fs like sysfs is. The trouble is values appears in time of read, but inotify react on writes, which never appear.

How much the removal of getting IP address from boot saved the time?

# systemd-analyze
Startup finished in 2719ms (kernel) + 4333ms (userspace) = 7052ms

which is about half of second.

Too much mounts in a parallel

The one thing surprised me was a long time until trivial mounts like debugfs were finished. The reason is that systemd (at least 44, recent version use generator+ .mount units) behaves differently to .mount units and things in /etc/fstab. In the first case, it executes the /bin/mount. Which means a lot of ld, stats, mmap, and the big delay of the system start.

So move things to fstab, or disable the systemd mount unit (I did that for sys-kernel-debug.mount and sys-kernel-security.mount). I already masked the remount-rootfs.mount, which calls /bin/mount -o remount /< only. That seems to me like a barrier for other mount units – iow this will be done as a last one. But who cares with a fast boot we have?

Way more changes

Then the systemd-modules-load.service delay a boot as it block sysinit.service, when basic boot ends. I read strace carefully, but it only load microcode_ctl module, but that took few seconds to be done. Thus I gently masked it.

The next change is backport from Factory package – this reduce the delay caused by all those tty devices to appear. Fortunately this will be part of next openSUSE as it is an upstream patch.

And as a last thing I wrote a simple xdm.service, instead of a big xdm init script. It will definitely need more love, but for me just works

cat /etc/systemd/system/xdm.service
[Unit]
Description=X Display Manager
After=dbus.socket

[Service]
Type=simple
ExecStart=/usr/bin/xdm -nodaemon
Restart=always

[Install]
WantedBy=graphical.target

Voilà!

#systemd-analyze
Startup finished in 2698ms (kernel) + 1513ms (userspace) = 4212ms

Using dracut

Because our brave systemd maintainer, Fréderic Crozat, chooses dracut as his hackweek project, I was curious if dracut can make some gain for me. I installed dracut and rebuilt and installed hardlink from his branches and try to investigate it. I would say the biggest advantage over mkinitrd is that dracut is configurable from command line. This is in a contrast with mkinitrd, where you have mostly no way how to exclude something – at least I did not find anything.

As Fréderic also pointed me, there is a --hostonly switch, which include only things needed for boot of current machine only. For instance dracut module kernel-modules will pull only things needed to mount rootfs (and if usrmount is included, then it will add things for /usr as well). Then I have excluded at least everything I can to have a working initramfs via -o, --nofsck and --strip. And that is the resulting time

# systemd-analyze
Startup finished in 726ms (kernel) + 1609ms (initramfs) + 1581ms (userspace) = 3917ms

Disabling way more things

As we are now versed in a looking at diagrams, there are still few ms we can save, even those changes are not sane . The first one follows the NetworkManager.service – now sshd.service delays the boot a lot, because it systemd-update-utmp-level.service waits on it’s finish. So let’s start it on demand

# cat /etc/udev/rules.d/95-start-nm-on-wlan.rules
SUBSYSTEM=="net", NAME=="wlan?", TAG+="systemd", ACTION=="add", ENV{SYSTEMD_WANTS}="NetworkManager.service sshd.service"

and disable it. Then mask all few remaining things – systemd-login.service, systemd-remount-api-vfs.service, systemd-user-session.service and rc-local.service. But only in case you are pretty sure what you are doing, because you might loose an important functionality, especially if you use a DE expected such things.

And that is the last time I will post

# systemd-analyze 
Startup finished in 726ms (kernel) + 1502ms (initramfs) + 1112ms (userspace) = 3341ms

With a kernel with SATA+ext support builtin, I would reach the two second goal – 1839ms. Of course on a system, which functionality was extremely cut down, but my goal was to boot as fast as possible. In reality, hunting of ms does not makes your feeling better a lot (until you will type systemd-analyze, of course)

This is the diagram of the really fast boot

Hi,

here’s a small summary of the 10th (coding) week. Last week I worked
mostly on the new fetcher code which I finally pushed into the git
repo. Apart from this I did some refactoring here and there.
The todo for this and the next week is to start with the new osc
user interface (that is the client code). As I already wrote in the
proposal the new osc client will be based on python’s argparse module
and the Jinja2 template engine.

Marcus