KDE4 on OpenSolaris

I installed KDE (3 at the time) the first time on Solaris 10 quite some years ago – and have been a fan ever since. I’ve been using KDE as my main desktop environment on the Sparc desktops I had; one of them is currently still my main "window" (via vnc) into my development work within the Oracle corporate network. To be a little more specific, that version (3.5.7) was compiled for Solaris by Stefan Teleman even before he joined Sun, hooray for him. With a little effort, I believe that version can still be found on the net somewhere.

What I like most about KDE is its flexibility; here are some examples (with KDE4, see below for some more on that) (click on the pictures to be shown a larger version):

selecting mouse actions in root  window1) I can decide which mouse button does what when pressed in the root window.

In the screen shot on the left, the window in the bottom left is the menu to let me change the settings, and the one to its right (bottom middle of the screen) is the pop-up menu of windows, sorted by virtual desktop (workspace), that I set the "press middle button" activity to show. Gnome offers nothing in this way unless you start fiddling with replacing the window manager or the code.

The switch to version 4 (around early 2008) changed a lot of things and,
as far as I can tell, completely broke compilation on Solaris. A
dedicated team of people have been working on porting KDE4 to Solaris
and the Sun Studio compilers (other projects are sticking to gcc/g++, which is fine, but makes integration with the rest of Solaris harder – I won’t go into this discussion here ;-), and I’m very happy to say that in its
current form I find KDE4 a more than satisfactory replacement for gnome,
and with the availablility from an IPS repository, installation is as
easy as ‘pkg install’ (well almost – see below for links ;-). I even have it on my laptop (a lenovo T60p) now,
although it (the laptop) is a little challenged by all the graphic effects and – due
to the ATI graphics chip support on OpenSolaris – doesn’t support all
the whiz-bang KDE is capable of when the adapter is fully supported.

2) If you look closely, you’ll see another example within this first example: it’s a gimp window holding a screen shot of the window switcher that I configured for the "alt-tab" action (it’s the Flip Switch, if I’m not mistaken, found in System Settings -> Desktop -> Desktop effects -> all effects). What I can’t show in a single picture: whenever I use this method of switching between windows, I get the most recent one first, so even if I selected the current window by pressing alt-tab several times, I can get back to what I was doing before with a single alt-tab. This is useful eg. when someone pings me in xchat (which happens fairly frequently since I work from home).

all windows on one screen3) I can configure KDE to show me all open windows (with live content) across all virtual desktops and I can then select the window I’m interested in (picture on the right). The highlighted window is the one I was working on last, so if I accidentally activate this feature (in my case by moving the mouse into one of the screen corners – this is configurable too, of course πŸ˜‰ it’s not too hard to "find my way back" to resume what I was doing.

It may be a little hard to see that I have two panels configured, one at the bottom of the screen that has the pager (virtual desktop selector) and holds icons for all the open windows, and one on the left side of the screen where I keep icons for things like firefox, my vnc client invocation, etc. I’ve found this separation convenient (I try to avoid icons sitting "on" my desktop, they’re always covered by something else).

KDE offers all the usual bells and whistles too, of course – the background image, for example, is my own, and was quite easy to set up.

Of course, a lot of this is eye-candy, but the main thing for me is ease-of use. I’ve described three seperate methods of window selection, and I find I use all of them (plus "click the icon") at different times. Whenever I have to use gnome these days, I feel restricted.

There are still bugs to be shaken out (eg: akonadi crashes every time I start KDE, and for some strange reason the working directory for applications I start from KDE is set to $HOME/Documents (but I can configure that per application – not convenient, but works – try that on gnome!), which breaks tons of assumptions about "home" (this is not Solaris-specific, btw)), but on the whole I’m very happy with this piece of software.

If you want to try it (and please do!), I’d encourage you to subscribe to kde-discuss@opensolaris.org; most importantly, announcements of new versions are made there (as of today, http://solaris.bionicmutton.org:10004/ is the publisher for kdedev-ips, but the port currently changes for every new revision), and any trouble people may have with them. Please go to http://techbase.kde.org/Projects/KDE_on_Solaris  for a general overview of the KDE4 on Solaris project, and to http://techbase.kde.org/Projects/KDE_on_Solaris/OpenSolaris  for how to install KDE (and build, if you’re so inclined – developers are welcome, as I understand it) on an OpenSolaris machine

Correction: going through my old email I realised I mixed up KDE versions and their authors: while the initial version I used was compiled by Stefan Teleman (or perhaps I even compiled them myself – can’t remember, it’s that long ago!), that was 3.4.3  (instructions here), whereas the 3.5.7 bits as I’ve been using for quite a few years now (since 2007, IIRC) were built by Michael Lindig, look here). Sorry about the mix-up.

Posted in Sun | 3 Comments

myth about regular password change busted

Here, finally, a piece by one of the leading experts in computer security, Gene Spafford, about where the "need" to regularly change your password came from, and why it won’t help much:


two highlights:

"In summary, forcing periodic password changes given today’s resources is
unlikely to significantly reduce the overall threat"


"This is DESPITE the fact that any reasonable analysis shows that a
monthly password change has little or no end impact on improving

Posted in miscellany | Leave a comment

ILB finally pushed!

Last week, project ILB was finally pushed to the main Solaris (nevada) repository; even though I haven’t been a full member of the project team for a few months (not because of ILB’s fault, btw), I do take pride in this piece of work, and congratulations to the remaining team members, above all Sangeeta, who hung on during the last few nerve-wracking weeks.

The bits will appear on opensolaris.org with build 128.

See the wiki for more details.

Posted in miscellany | 1 Comment

Virtualbox Guest extension surprise

A lot has happened since I wrote last — among other things, I’m now with the MySQL organisation in the Enterprise Tools team, and one challenge this group is facing is the multitude of platforms being supported.

I needed to test a bug that to all appearences I had introduced, that was only manifesting itself on Linux; since (Open)Solaris is all I had at the time on the machines I use, and I couldn’t find a ready-made box running Linux, I had two choices: (re-)install a test box somewhere in the lab or use Virtualbox. I decided to go with the latter, especially as I could choose from quite a few canned OS images for Virtualbox here.

I selected a Ubuntu 64-bit image; download and installation on the lab machine went well, and I had it up & running after a fairly short time. One of the notices that Virtualbox showed me when it booted the Ubuntu VM was something about "mouse integration" being present. I hadn’t seen that active before, so I was pleasantly surprised that I didn’t have to press the host key every time I wanted to "escape" from the VM, as it were.

A few minutes after logging in the first time, the update manager told me it had some updates ready, did I want them? I said "yes" and let it do its work, including "reboot" at the end. To my dismay, when the VM came back up, there was no mouse integration — I had to go back to the old behaviour of pressing the host key… I had selected "don’t display this warning again" sometime earlier, and initially thought that that may have been the (unexpected) cause.

As it turns out, selecting "install guest additions" from the devices menu and then running the appropriate script got mouse integration back.

Posted in miscellany | Leave a comment

how to merge your project gate with Nevada … and what not to do.

I recently made my first attempt to merge our project gate with then-current bits from the Nevada gate; a change I wanted to benefit from had just been put back, and I was eager to get the bits.

Here’s what I should have done:

  • creat a clone of the project gate (ilb-merge-clone) (we were based off of build 107 at the time)
  • reparent to onnv-clone
  • hg pull -u (this got us bits from build 111)
  • hg merge
  • hg commit
  • create webrevs vs. the project gate and vs. Nevada, inspect.
  • hg reparent to our opensolaris gate
  • hg push (to the project gate on opensolaris.org)

If I’d done it this way, all would have been fine. And I did, except for one step: before the last ‘push’, I did something I shouldn’t have: I issued a ‘hg recommit’. If you’re groaning now, there’s probably no news for you in the rest of this piece ;-). If not, here’s a little detail:

Whenever a change to the source is done (eg. a minor milestone or the fix for a bug), you can do ‘hg commit’ to document this in the your repository. Such an action is also reversible with hg-means; so it makes sense to commit fairly often. Note: commit doesn’t change anything in the parent repository, rather, the change in the code is communicated to your working repository. That way, you accumulate several commits before pushing them to the parent repository (or "putting back" in teamware-speak).

When you compare your work with the repository you’re planning to push this to, hg uses this history to find out which files actually changed and compare those that did.

Normally, when you want to push an incremental set of changes to your project gate, it’s sufficient for these changes to appear as one changeset in the project history (esp if you’re planning to integrate with Nevada anyway at a later point in time, where all those changes will again be collapsed into a single change-set). ‘hg recommit’ collapses all changes into one.

What was different in my situation: by pulling bits from onnv-clone, I’d imported Nevada’s change-set history. Unless we’d been planning to integrate our project with Nevada right away (ie before (m)any more changes to Nevada), this history would have been essential for future merges.

By removing this history, I made that step very painful – I essentially declared all changes that Nevada had introduced since we’d started our project gate, and which I’d now incorporated into our gate, as "our" changes (and not as Nevada changes we just synced up with), so every future comparison with Nevada would not only show our project work as changed, but everything that had changed in Nevada since we’d created our gate.

Lesson learned: just because something makes sense in one set of circumstances, it does not necessarily do so when the circumstances change – even if the change is minimal.

I finally got Nevada history back into our repository with a lot of help from Mark J Nelson (and that was not trivial!), and if you want to buy him a beer the next time you see him, you’re more than welcome to πŸ™‚

Posted in Sun | 2 Comments

looking at laptop screens

I recently had the chance to try a Toshiba Tecra M10 with OpenSolaris for a while; the idea was to find out whether I preferred it to my current one (a lenovo T60p) – its main advantage over the lenovo being that OpenSolaris supports suspend & resume, which the lenovo does not (due to its ATI graphics adapter).

I finally didn’t keep it – the M10’s screen resolution (1440×900) is less than the lenovo’s (1680×1050), and for me the difference made the difference.

Since then, I’ve started looking around at the laptop market, more out of idle curiosity than anything else, and I came to realise that many vendors whose pages I looked at don’t tell you up front about the screen resolution, but only about screen size – am I the only one who’s interested in resolution?

Posted in miscellany | 1 Comment

ILB: Design questions on import, export and (persistent) config

here follows the text of an email that I just sent out to ilb-dev@opensolaris.org; if you feel inclined to respond, please do so on the same alias so the discussion can stay in one place. thx.

We need to nail down the semantics and the broad design of "ilbadm export"
and "ilbadm import" (note, this diverges from the spec as it’s currently
posted, where we still talk about import-rules etc. This has been simplified).

In addition, there’s what we have come to call "persistent configuration",
which is conceptually an extension of ilbd, basically a copy of ildb’s
running configuration that persists across start/stop of ilbd (and reboot
of the server). (this has nothing to do with "session persistence", btw)

We have been investigating how closely these are related and what impact
this has; here’s some points that we seek understanding and your input on:

* import/export: the initial requirement was to have a means to take the
current configuration of the load balancer ("ilbadm export <file>"),
transport it to another machine by whatever means and re-apply ("ilbadm
import <file>") it there.

Q1: Would people agree that this requirement makes sense?

Q1a: if yes, would you agree that the format we use here is of secondary
concern, ie. private?

Since we already have a parser in place for the CLI, it was suggested to
use that format for import/export (initially, anyway) to avoid having to
duplicate effort.

Q1b: does the above cause concern for anyone?

* persistent config: this was initially planned to be completely invisible
to users/admins, and exclusively maintained by ilbd. (As I understood it,)
this configuration file would be updated with every change the admin made
via ilbadm that was not explicitly designated temporary. Whenever ilbd
starts, it was supposed to clear all rules from the kernel (in case it, the
daemon, had died unexpectedly), re-read the persistent config and apply all
that to the kernel (ie all rules).

There is also discussion of a different usage model, namely, requiring
explicit admin action ("commit") to cause the running configuration to be
saved in the persistent config file. (There seems to be precedent for that
in the industry, but I couldn’t find a reference right now)

There are tradeoffs for both models.

Q2: which of the above models (explicit commit vs implicit update) do you
think is more appropriate for us?

The argument that "we already have a parser for CLI" also seems attractive
here, so we’re toying with the idea of using the same syntax we use for
import/export for persistent config as well; since SMF handles ilbd
restart, it would be easy to add an invocation of "ilbadm read-config" (or
sth. to indicate that persistent config is meant) to the service’s start

Q3: since persistent configuration is viewed as a private component of the
ilb framework, is it be acceptable from a privilege/authorisation POV to
expose any interaction with it via ilbadm?

If we went with "commit" model outlined above, a suitable subcommand could
be added to ilbadm, which would presumably perform the actual update to the
persistent config file (in line with the "we already have …" argument).
This would have maybe even more severe implications than Q3 indicates, as
ilbadm would be *writing* persistent config.

Q4: would this cause security considerations?

TIA for your (timely πŸ˜‰ thoughts.

Posted in Sun | Leave a comment