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.
]]>
I’ve just spent 15 minutes going through my Open Build Service home:wstephenson project, deleting unfinished works in progress, finished branches that were never deleted, inherited repositories in branched projects that aren’t relevant to the tweaks I’m making, and I think I’ve saved about 100 repositories for the OBS scheduler to recalculate and look at publishing.
Time for you to spring clean too?
]]>Now fast forward to 2013 and we’re seeing the same happen to GNOME. No longer the standard desktop, but still with significant suction among Ubuntu users, GNOME is neatly herded on to the reservation and congratulated on its wise decision. Now look to your Kubuntu colleagues to see how that is going to work out for you down the road. PS: If Mark promises to install GNOME Ubuntu, don’t believe him for a second. He has an office by now full of desktop computers representing official flavours that he never turns on. Sound familiar?
]]>To use Skype with openSUSE 12.3, you need to download the Skype package for openSUSE. If you’re using a 64 bit machine/install, like most of us nowadays, you also need some 32 bit compatibility packages, included with openSUSE.
- Download Skype from http://www.skype.com/en/download-skype/skype-for-linux/
- Select openSUSE 12.1 32 bit (the most recent openSUSE version for which they offer Skype at time of writing) and save the package
- As root,
zypper in skype-4.1.0.20-suse.i586.rpm alsa-plugins-pulse-32bit
to install the package, its 32 bit requirements, and the 32 bit ALSA plugin for PulseAudio it also needs, but doesn’t/can’t specify automatically.
Happy calling.
]]>
Shimano has just released its electronic shifting system for Alfine internally geared hubs. In mechanical Alfine, the gear cable pull is translated into rotation and gear selection by a detachable unit that sits on the end of the hub. Alfine Di2 SEIS replaces this with a MU-S705 motor unit controlled by an electronic brake lever. But it also introduces a new hub (SG-S705). I wondered whether the motor unit can be retrofitted to existing hubs, as I have the original Alfine 11 (SG-S700) on my Genesis Day One, and I’m not completely happy with the Versa drop bar brake lever integrated shifter*.
So I mailed Paul Lange, Shimano’s German distributor, to ask. The answer I got is that the SG-S700 hub can not be used with the Di2 components, because it has a return spring for upshifts, whereas SG-S705 does not since the gear selection in both directions is actively performed by the motor. If you put a MU-S705 motor unit on an SG-S700 it would be working against the return spring.
As far as I understood it, there is a spring in the SM-S700 cable end unit – I didn’t know there is also one in the hub itself, but I’ll check next time I have the wheel out. Until then, my dreams of perfect drop bar shifting are just that, because at 400 quid SRP the hub is a big investment. Maybe Shimano will take pity on me and make a mechanical STI…
* Mostly because there is no little cam decoupling the upshift lever from the cable spool inside the Versa shifter, so sometimes it shifts up several gears at once.
]]>Get them now at http://download.opensuse.org/repositories/KDE:/Release:/48/openSUSE_12.1/.
The repository for openSUSE 11.4 is being created at the time of writing at http://download.opensuse.org/repositories/KDE:/Release:/48/openSUSE_11.4
Users who already have the KDE:Release:48 registered in YaST need only zypper up or upgrade with YaST.
As always, have a lot of fun and report bugs!
]]>Read more at my platform page. Then go and vote!
]]>The reason is that I upload photos to Facebook using KDE’s shared uploader and this has fallen victim to the whims of FB’s purge of its app biosphere. Unless the original developer can convince them that the app is not spammy, offering a bad experience or having the wrong attitude, the app, my photos (all archived elsewhere of course), but most importantly, all the kind comments from my friends and contacts that represent FB’s only value, get sent to the farm.
This is what you get when you trust one company with stuff you care about. Will. ]]>
I was just hanging in the #active channel, watching my KDE chums make their new touchscreen interface (video), when somebody complained that shared-desktop-ontologies does not yet contain the latest release needed by KDE git master. And instead of updating the package myself, I suggested they just BURP:
- Branch,
- Update,
- Request,
- the Package
And by doing so we all get the latest versions in the devel project and soon in Tumbleweed and openSUSE Factory. So ambassadors, boosters and motivated contributors know how to do that right? Now you can use this glib little acronym to persuade friends and colleagues to do the same.
Happy BURPing!
]]>