Bobulate

It’s been ages since I wrote (or complained) about Sun Ray Server Software (SRSS) on OpenSolaris in combination with KDE4. That was because I wasn’t using it and my Sun Ray terminal sat idle. But a bit of house-rearranging has made the device useful again, and I spent an hour futzing with it today to get things working again.

SRSS is a bit complicated — it’s officially delivered only for Solaris 10 and it exists separately from the client devices, so just because you have a Sun Ray doesn’t mean you can do anything with it. Certainly there’s issues on OpenSolaris (or OpenIndiana). I seem to have 4.2 running — it’s a bit unclear whether there’s a version 5 available, and last time I blogged about SRSS it was enthusing about the new addition of Porter-Duff compositing, which made the Plasma Desktop beautiful on the thin client again.

A good official(-ish?) source of information on SRSS is the sun-rays.org wiki which has a section on getting this stuff to work on OSOL as well. Plus notes for build 134 or later, which is what KDE4 requires. Two blog entries I found very helpful were Chris Gerhard about build 130 and later and the Grey Blog on 2009.06. Both point out some tweaking that’s needed to get gdm to like the thin client — otherwise it starts on the thin client and stops about 60 milliseconds later.

After adding the requires symlinks and font paths, gdm starts up normally.

From there, I can now display KDE4 on my FullHD TV downstairs while the server hums gently in the attic. It’s nice to be able to move around in the house and have the desktop available everywhere. Session resume is also supported, so if I switch off the Sun Ray and switch on again later, my desktop is there.

Another benefit of having a desktop available in the living room is that it enables pair programming when random developers stop over, but that’s a topic for another time.

Since Allen pointed out that the KDE PIM team had released another 4.4 version, we’ve bumped the KDEPIM version available for OpenSolaris through our KDE 4.5 series specfile repository. PIM hasn’t done a 4.5 release as such, concentrating on 4.6 and a full Akonadi-based release, so it’s good to see updates and bugfixes going on nonetheless.

You can build the software using the specfiles — we have not uploaded newer packages. That will have to wait until we’ve done a little more research into how to best serve up packages (as more people are using them now, we’re hitting various performance issues in the way we do things).

Dear Lazyweb,

My brother lives in Addis Ababa. This means I sometimes get cool stuff (like coffee straight from the highlands) and sometimes rather incomprehensible parcels in the mail. In this case, I have a sachet of "Raw Tikur Azmude" and a bag of very interestingly colored beans. See photo. Since my Amharic just isn’t what it needs to be — and I still have Hausa on the list of things to do above learning Amharic — I’m at a loss as to what to do with this. So anyone with some Ethiopian cooking hints, please drop me a note.

Love in International cooking,

[ade]

Q: how many different STL implementations are there available on OpenSolaris?
A: at least five by my count: Cstd, stlport4, stlport5, stdcxx4 (either as package from Oracle or from our KDE4-Solaris packages) and g++.
Q: can you mix and match them?
A: only if you like interesting segfaults. Take ‘Hello World’ and compile as follows: CC -lstdcxx4 hello.cc. Ignore the (dire and in this case serious) linker warnings. See program. Run program. Run, program, run! See program dump core right on the new carpet. Bad program. The crash happens inside the static constructors of one of the two libraries as it calls methods in the other one which has a very different idea of how things work. LD_DEBUG=libs might help you spot this. Compare also CC -library=no%Cstd -lstdcxx4 -lCstd versus CC -library=no%Cstd -lCstd -lstdcxx4 (the former crashes, the latter doesn’t, for some reason).
Q: so why is this a problem?
A: plugins make this a problem. If you load a plugin (i.e. dlopen() a shared object) which uses a different C++ STL library from the one you’re already linked to, then you hit the problem described above:
Q: so how can that happen?
A: different parts of an OpenSolaris system are built with different C++ STLs. This is a historical problem; at some point there were plans to slowly migrate all the desktop-relevant stuff to stdcxx4 (that’s the Apache STL, by the way).but it’s a big effort and takes time. One component that is still built against Cstd is Firefox. So all the Firefox plugins that are written in C++ or that use system components in C++, link to Cstd. Like, for instance, libtotem plugins.
Q: so just don’t load them, right?
A: how do you identify “them” then? In Qt 4.7.0 the demo browser (WebKit based) goes and loads all the Firefox plugins, pretty much on startup. And that crashes in a slow and strange way — it dlopen()s a libtotem plugin, loads in libCstd, runs the initializers on libCstd and boom. It’s probably related to the order in which the libraries are loaded. In any case, we don’t know beforehand what libraries a given plugin uses nor can we say what plugins there are.

If you like, you can pretend this was a conversation between Legolas and Haldir and not a run-in to looking at library files in ELF format.

So, having established that plugin loading can kill a Qt application in a gory fashion and that it happens in practice, the KDE4-Solaris team (a kind of Fellowship of the Ring, committed to binding themselves in the darkness that is OSOL) went looking for a solution. With /usr/bin/dump -Lv you can get a listing of dynamic items in an ELF object, including the libraries it’s going to load (e.g. grep for NEEDED). We decided that a likely place to insert a check was in QLibrary::load_sys(), which has some code to search for libraries and also already has some checks in place for strange platforms. So we had in mind something like bool is_library_acceptable(const char *filename) which would do the necessary check. If the library that’s about to be loaded uses Cstd, then don’t load it at all and return failure. That way, we avoid the mysterious crashes caused by STL incompatibility.

When mucking about with ELF files, the obvious resource to use is libelf. However, the libelf available on OpenSolaris is incompatible with largefile support. Why? Because it uses off_t in some structures instead of a 64-bit offset which could accomodate but 32- (non-largefile) and 64-bit (largefile) offsets. It does have the decency to #error out.

I suppose gelf would have been a solution. But thinking about the problem of finding which libraries are NEEDED by a loadable object, I came up with the following algorithm (which applies regardless of which ELF reading approach I’m using):

• Read the ELF header
• Find the ELF .dynamic section.
• Scan the .dynamic section for NEEDED tags, look them up in the .dynstr section.
• Bail out if libCstd.so is mentioned.

The precise details — sizes of headers, layouts of structures — depends on whether it’s a 32-bit or a 64-bit ELF file, but the alogrithm remains the same.

I initially coded this in C, with macros. (Bear with me here — I realize now that I tend to iterate over my own code as I understand the problem and solution space better, so I often start with something horrible that gets improved later). Then the code ended up looking like this:

#define ALGORITHM_STEP(d0,d1) \
  /* a step using values from d0 and d1 */
if (is32) { 32bit_t d0,d1; ALGORITHM_STEP(d0,d1); }
else { 64bit_t d0,d1; ALGORITHM_STEP(d0,d1); }

Ugh. From there I went to C++ and template functions. Each macro became a template, but I could also put the types in there, albeit a little awkwardly:

template <typename t0, typename t1> ALGORITHM_STEP() 
{ t0 d0; t1 d1; /* a step using values from d0 and d1 */ }
if (is32) { ALGORITHM_STEP<32bit_t0,32bit_t1>() } 
else { ALGORITHM_STEP<64bit_t0, 64bit_t1>() }

Feel free to go “Ugh” again, especially if you’re an experienced C++ template hacker. Oddly enough, I haven’t written much in the way of neat template code, just usually debugged what others have done. So by now my program was a bunch of template functions and then a main function with a sequence of if (is32) {} statements to string together those template functions. I could actually collapse it down to just one if() statement, but then the template would have 8 or 9 parameters and it’d be even more ugly than it already is.

From here I remembered non-type template parameters and specializations. It came down to this: define a template class with an integer parameter that can be specialized to hold the 32- or 64-bit types that I need. This looked like so:

template <int> class elftype;
template<> elftype<32> {
  typedef 32bit_t0 t0; typedef 32bit_t1 t1; } ;
template<> elftype<64> {
  typedef 64bit_t0 t0; typedef 64bit_t1 t1; } ;

Not much change in the program itself, except that instead of writing 32bit_t0 I’d write elftype<32>::t0. But this specialization approach applies to the functions themselves, too, and they became:

template<int n> ALGORITHM_STEP() {
  elftype<n>::t0 d0; elftype<n>::t1 d1;
  /* actual algorithm step */ } ;

Now it makes sense to collapse the whole thing into a single function parameterized by 32- or 64-bits, and then the main function I was looking for becomes something like this:

/* read ELF header */
if (is32) { return is_library_acceptable<32>(); }
else { return is_library_acceptable<64>(); }

The algorithm needs to be written only once, it’s specialized for the two cases, the types are neatly squirreled away in their respective class templates. Although functionally it’s no different from the original C version, I find it much more satisfying — for one thing, it’s extensible in a way that wouldn’t be easy with macros (say if there’s a 48-bit ELF format).

And the original purpose, of checking whether a plugin is usable before loading it? We’ve got that patched in for the next package release of Qt 4.7.0 on OpenSolaris, and the demo browser won’t crash anymore (but it won’t play whatever libtotem supports, either).

Since Qt 4.7, the QString class has gained a constructor. It used to have QString(const char *), QString(const QChar *, int) and a bunch of others. Now it has QString(const QChar *) as well. This constructor works with 0-terminated QChar sequences, like char * does. A useful addition, except that it makes certain other code constructions newly ambiguous.

Consider code that uses 0 as a pointer; this is now ambiguous because that might be a const char * or a const QChar *. There’s code in KDE where 0 is used in places for QStrings, and this used to work, like class A { public: A() : a(0) {} ; QString a; } ; You don’t always see it that obviously; for instance, there’s arrays of structs with a terminating null struct — a real C-ism. It becomes ambiguous with a QString member: struct { int, int, QString } foo[] = { …, { 0,0,0 } } . For some reason we hit these more clearly in Solaris (OpenIndiana, that is), and we’ve started to fix them. The simple fix is to use QString() to mean an empty string (QString::null? damn I’m oldschool).

One more reason to look forward to nullptr (didn’t mpyne or MarcM mention that recently?).

Lots of links and interesting tidbits come my way. Most are KDE related, sometimes computer science. I thought I’d clear up my backlog of items for once.

• Kunal Deo pointed me to an article on cross-desktop development,
• UPnP got a little attention (as DLNA) at the Register which is timely due to the release of the KDE UPnP IOSlave.
• Stef Bon approached me with a cool mechanism to mount all kinds of stuff through FUSE. It reminds me a bit of libferris.
• Naheed Nenshi is now mayor of Calgary. Probably the last time I spoke to him it was about D&D and I was 14, but spiffy nonetheless.

Some folks have asked me what I think of the Nokia N900. Blog posts like that by Dinesh or Ben prodded me, but what worked best was spotting an N900 in the wild. See, I know KDE and Qt developers have this device. Nokia kindly ensures that we have access. But does it get used by anyone else? The Register (a UK IT publication I like to read) is ferociously anti-Nokia, so I rarely read any good news. Combine that with decidedly poor availability of the N900 in the Netherlands — none of the telco’s carried it — and it’s felt rather lonely with one. The device I’m using is one of those handed out at the Maemo summit in Amsterdam. I didn’t attend, but someone who did passed the device on to me.

Now, I’m not necessarily a smartphone user. I tend to move from home to office by train, don’t have lots of "road warrior" in me, and I can stand being offline for, say, an hour while moving between one location and another. I love the Nokia 6300 form factor. Small, sturdy, makes phone calls and is a nice mp3 player as well. In a pinch it can even load up buienradar.nl or another website. That said, I may as well start with what I perceive to be the downsides of the device — which should be no surprise here. Size and battery life. The thing is heavy, which makes longer phone calls a drag. it lasts two, maybe three days on a charge if it sees little use and doesn’t hook up to a wifi hotspot — the latter is a real drain. Compare to the week I get with the 6300 or three weeks with a 2310 (again, I’m not a heavy phone user, so standby time is actually most important to me).

Software-wise there are a few annoyances (setting a ringtone is much harder than it needs to be) but I really appreciate the openness of the platform. Debian packages? Pre-built VM for development? SSH out of the box? An XTerm? Ticks all the boxes for me. IRC over SSH to irssi running on a server is just what I always do — hasn’t anyone built Quassel for this device yet? Software updates are a little slow, but I appreciate it that it also flags updates for third-party apps. I have an early release of KDEPIM-Mobile installed, which needs an update, and there’s Marble too.

The keyboard is nice as long as you’re not using emacs. All in all I’d say the N900 is the smallest laptop I’ve ever owned — and it makes calls, too.

Thanks to lots of comments on my previous blog post about color schemes, I’ve made things Moar Pink. If you’re not yet ready to destroy that color, here’s the start of the (pink) art.

Icons have been pinkified — where you can see that some are resistant like the battery and SELinux — a little more harmony has been created between the colors. Notice that the icons do become a little monochrome like this (or is it bichrome?) because the color nuances are smashed flat with a pink hammer. I’ve also added a custom Konqueror stylesheet to keep things pink when visited websites don’t have anything set. There’s still some uncomfortable blue in links (also in Blogilo) and message counts (KMail). And of course KMail still has the blue swoosh while switching folders — I can’t see that that is configurable anywhere.

Olaf points out that there was work done on system-color-settings compatible color schemes for some applications. That’s definitely something to keep in mind.

Now, this exercise isn’t just about being horrifyingly pink. I came up with a few usage scenarios where easy-to-do global appearance updates are interesting:

• Distribution branding. I know, most ditro’s do this by hand already. But having a good checklist of where to look and what to modify would make it easier on them. Plus, you could then publish, say, the Fedora look and make it easy to install onto any KDE desktop installation.
• "Hey, your desktop is cool, can I have that?"
• Quick user switching.
• Activity customization.
• Environment-aware computing. When you move your laptop outside, the color scheme changes and everything becomes higher-contrast and more sharply defined. Like the n900’s keyboard lights up in the dark, but now for wallpapers and color schemes.
• Pretending that your video cable is damaged so that one color drops out.

I so need to start a TechBase article on colorizing and global appearance customization.

Alas, Frederik’s master plan has not seen a whole lot of progress. I wanted to go down that path a little as well — that has everything to do with sitting next to Lydia for a day of not-always-exciting meetings. She challenged me to make my desktop as horrifyingly pink as possible. That would be useful if I had to plug in my laptop to give a presentation: the color scheme would shock everyone awake.

So, clear challenge. Now how do you make your desktop as pink as possible. KDE is terrifically configurable, but that doesn’t mean it’s simple to configure it. Here are my notes in KDE 4.4.5 (Fedora 13). To some extent it’s intended to show where additional polishing might be applied to make KDE more consistent. And overall it will show that for an overall appearance manager we need something more — or something else — than we have right now.

Wallpaper: right click the background of the desktop, pick Desktop Activity Settings. That’s the only configuration item there. It opens a Desktop Settings – Plasma Workspace dialog. Pick Wallpaper. Click Get New Wallpapers. There’s a search bar in the resulting dialog. I tried searching for unicorns first, but the right search term is "Sugarcoma Bunny". Click install and then select that wallpaper, click OK. The dialog goes away and the first step (over one million pixels) in pinkness has been made.

Colors: start System Settings, pick the Appearance module. The title now changes to Style (because that’s the selected item on the left). Go down one item, to Colors. Pick the tab Scheme. Click Get New Schemes. (This Hot New Stuff is really darn useful). Once again there’s a search bar, use "pink". You could pick either Ruphy’s "So pink that it hurts my teeth" or Fregl’s "Fluffy." I think the "hurts my teeth" theme is a little better, but it still needs a little tweaking.

This is where futzing with color schemes gets a little complicated. There is a tremendous number of settings to deal with, and I’m not really sure what all of them do. (Here’s a bit of history related to color display in the scheme list).

Switch to the Colors tab (in the Colors item). From the drop-down box, select Window. Click the button next to Normal Background. Pick a better color. I used #FBBCFF. OK the color dialog, then click apply. For reference, we’re in System Settings – Appearance – Colors – Colors – Window. Five selection levels deep. You might want to Save Scheme to keep these custom settings around, too.

Icons: there doesn’t seem to be a very pink icon set. I skipped this bit for now.

Windows: if you stick with the Oxygen window decoration, there are some additional colors to set. The window shadows are colored as well, and in a pink desktop, you should have pink shadows. I changed the windowdrop-down shadow to use #FBBCFF; the active window glow uses #FF37C7 and outer color #FFC0FF.

Other appearance items: to be truly pervasively pink, we would need a pink splash screen and emoticon set as well. Switch to the Splash Screen item. Click Get New Themes. For some reason this dialog is different from the ones used earlier. It’s titled Get Hot New Stuff and labeled internally with System Settings Add-On Installer. There’s probably some string not being passed to a constructor there to make the labels more meaningful. Note to self: check same dialogs in KDE 4.5.2, then file a bug report if necessary. Searching for "pink", "bunny" and "fluffy" didn’t yield anything, so we’ll have to leave the splash for now; same for emoticons.

[[ By now the desktop is pretty darn pink. But let’s start two applications to see how far the colors go. ]]

Konsole: start Konsole, go to Settings -> Edit Current Profile. Select the Appearance tab. Notice the extremely cool way color schemes slide in, but there’s no quick way to import a color scheme. The New button gives you basically a bunch of color selectors; there’s no Hot New Stuff here, nor a quick way to import settings. It’s not clear to me how to export the settings either — I’ll file a wishlist item there.

It’s straightforward to set up light and dark pink (or purple) as foreground and background colors, but the other available colors are a bit problematic. I use irssi in screen a lot, and the blue and yellow that it uses was a bit jarring. Since I don’t use any other colors in konsole, I just picked a bunch of settings to colorize things in a nice way for my specific use. KDE 4.5 note: seems that the menus have changed a little, and you need to go through the settings dialog.

Kate: the other application I use a lot is Kate, and it uses its own color schemes. Go to Settings->Configure Kate and then under Editor Component / Fonts & Colors you can mess with the colors. Again, no clear way to export a scheme or use Hot New Stuff to get new ones. Here again there’s a huge number of colors to set up (which might explain why there’s only two color schemes by default). I took a quick route to setting up a pink scheme and changed only the four text background colors: normal, selected, current and bookmark = ( #FFBBFD, #FF7DCB, #F8E0F4, #FF39F9). The current line is perhaps a bit greyish, but that does make it easy to spot. I haven’t touched any of the syntax highlighting.

Other UI elements: text input and some other backgrounds still aren’t pinkish, but white. I may have missed something in the color scheme control module. Similarly alternating colors in lists aren’t pink and pink, but still while and blueish.

Plasma Theme: many Plasma themes are dark-ish. For this color scheme, you really want the desktop background to shine through. I tried the Glassified theme but struggled to get it to be transparent. I suspect XRender problems on this laptop. In any case, to change this: System Settings -> Appearance -> Style. Select tab "Workspace". Here you can pick themes. The obvious theme would be the original Fluffy Bunny, but it has gone missing again. I ended up with the Atelier theme — click Get New Themes, then search for that name. Install, apply, done.

After all this configuration, the desktop looks like the screenshot here. There’s still some disconcerting bits of white there — the open documents list in Kate in particular. But let’s take a step back and summarize where changes needed to be made to achieve the goal of "make it pink".

Wallpaper, system color scheme, icon set, emoticons, window deco settings and colors, konsole color scheme, kate color scheme, plasma theme. Less than half of these support Hot New Stuff. They are in several different locations, different KCM’s, require manual configuration in applications.

Now suppose that one of my new friends from Ljubljana were to come over and ask if they can make their desktop look like mine (o horrors!). It strikes me that it would be useful to have a new collection (or meta-HNS) setting that is called "Overall Appearance" or something like that that would apply a theme, wallpaper, color scheme, etc. etc. in one go — including Konsole and Kate’s default schemes. Then the idea of "share my desktop look" can come to fruition. Or have I just missed something obvious to do that already?

I recently mentioned that Plasma Desktop and KDE applications 4.5.2 was building. It’s done now and the repository has been put up on solaris.bionicmutton.org. This uses a Linux port of pkg.depotd, rather crudely hacked together by myself. That should ease up some package downloading issues.

So, users of KDE4 on OpenSolaris and OpenIndiana, it’s time to update. Remember to file bugs at bugs.kde.org with the OS set to Solaris, and drop by #kde4-solaris on Freenode.

PS. There was an article up on a Dutch website with “5 best things Oracle did for Open Source” and one of them was “Kill OpenSolaris”. Hm. PPS. Konqueror does crash on Flash games sites, somewhere in kjs. On the plus side, DrKonqui now produces nice stack traces with dbx.

Now that the october updates for all the software shipped by the KDE community — that is, Plasma Desktop and the applications — has been released, it’s time to bump versions, etc. and kick off a bunch of builds. This follows the tried-and-true approach of replacing the version number (i.e. it now reads ‘%define kde_src_ver 4.5.2’), running make, waiting for the pkgbuild tool to report failures, fix, rinse, repeat. Usually the things we fix are just new or removed files. In this release, for instance, KHelpCenter has a new documentationnotfound/ directory and some files there.

During this period, our so-called stable (-450) repository is not stable. Fixes to the packages get pushed as and when they are found. Once the builds are stable (i.e. a few of us have managed to get everything to build), then Hajma kicks off a clean build on our build server, waits about six hours for that to finish, then uploads the whole darn thing to the actual binary IPS package server. And then people can update as they like.

I won’t vouch for the stability of updating. We usually take the ‘pkg uninstall -r hier-kde4-deps ; pkg install KDEconsolidation’ route, which is also known as ‘log into JDS, rip out all of KDE, install a new one’. One day we hope to look at that more closely.

Our IPS package server runs in OpenSolaris in a VirtualBox on an OpenSuSE machine. There’s issues with networking in that setup; I’m a little hazy on the details but it means that downloads often crap out. There’s 1226 TCP connections in FIN_WAIT2 state right now. That’s also a sign that people are actually using Plasma desktop and KDE applications on OpenSolaris and OpenIndiana. Apparently folks are overrunning the OI IRC channel asking what’s wrong with our package server — ask in #kde4-solaris, folks.

Since the server setup has been giving us some problems, I cloned the pkg source code repository from Oracle and now have a copy available in our Mercurial repository. The purpose of the clone is to hammer the system into shape so it can run on Linux. It seems Onno M. has done something similar, to the point of producing packages of same via the OpenSuSE build service. In any case, the idea is to drop the VM and additional OS from the equation and make pkg.depotd serve packages directly from Linux. This needs some testing, but I imagine we will be switching over for serving up 4.5.2.

Finally Michael will be able to install KDE software without a week’s worth of disconnects.

[[ While I typed this story, I built the KDEsdk, KDEtoys and KDEutils packages; changes here reflect the renaming of kdesvn-build to kdesrc-build. KDEtoys has no changes, and KDEutils incorporated one of our patches from 4.5.1, so there was a patch to remove. ]]

Two last tidbits: I managed to utterly break my OSOL VBox, so I now do builds on OpenIndiana virtually and on physical hardware running OSOL. Packages are produced in OSOL b.134 and work unmodified on OI b.147 and later. The -460 repository is in the throes of a massive cleanup since the range of supported platforms has shrunk recently: it’s either Solaris10 (untested except by the hardiest of souls) or OSOL b.134 or OpenIndiana, pkgtool 1.3.102 or later. That means cleaning up tons of cruft and special-cases. Once that’s done, there looks to be a bump to Boost (to 1.44) and some Qt mucking about.