My share of shower insights: power to the artists!

KDE4 has made revolutionary changes in UI architecture, there is no doubt about that. But I can't shake the feeling that, while you can certainly see big advantages this brings to applications, all those KDE4 pillars aren't leveraged nearly as much as could be, in principle, possible.

Take Plasma, for example. The decoupling of logic and presentation into engines and plasmoids is perhaps the most powerful single idea implemented there. But what I see as the greatest opportunity it creates is left untaken: the decoupling makes it possible, in principle, for the artists to design plasmoids entirely by themselves.

Indeed, the simplest Plasma applets do nothing that couldn't be trivially designed graphically: see my own RSIBreak plasmoid (a simplistic prototype yet, sorry) for example. Yet, we still have the situation that the presentation logic is written in a programming language; even if it isn't C++ but something more human-friendly, such as Ruby or Python (having said that, I have yet to see a single useful plasmoid written in one of those) it still leaves out many if not most of the people that could design them on the mercy of developers, who often have more interesting things to do than code trivial UI handling code.

Even the more complicated applets, see the clock for example (you can't talk about Plasma without mentioning the clocks, can you?), could be done entirely in a language designers already know (even if not directly)—SVG. SVG is expressive enough to do every operation that is currently done in C++ code of analog clock plasmoid. But how to program graphically what operations map to which inputs? Why, telling by showing, of course:

[a comic of telling by showing]

The problem with current architecture is that we cannot easily modify SVG tree programatically, so we end up with having to use two languages to describe the interface: SVG for the static parts and C++/whatever for the dynamic behaviour and coupling with the engine. But, IMHO, most plasmoids' presentation could be described just by a smart mapping from engine data to SVG properties.

So, what do we need? What is teh masterplan? Well, first we have to have a framework in place—that's the easy part. First of all, we need a widget that is able to draw an SVG tree that we can modify. Then we need to devise language to describe mapping of inputs to SVG transformation—I'm pretty sure that existing SVG infrastructure for animation is well adaptable to that task. After that, it's just a matter of wrapping the mutable SVG widget with another one that draws the graphic transformed according to the transformation given input data.

The harder part would be making the "tell by showing" interface for the artists—but even without that, this approach has a whole host of benefits. Making a new plasmoid (using an existing data engine) would be just a matter of drawing it and coupling it to the inputs using a description—not programming—language.

This would enable theme designers to alter widgets' look completely—they would no longer be constrained by whatever design the programmer had in mind while writing the code; so that, for example, one theme could show, say, CPU temperature as a bar, while another could use VU-like meters, all that without changing a single line of code—without any additional code at all, in fact!

I'll confess that I'm largely inspired in this idea by Bret Victor whose paper Magic Ink: Information Software and the Graphical Interface I have once read and which sits in my head since and transpires to my consciousness from time to time. You should really read it in its entirety—it's full of innovative, revolutionary ideas and I feel that, with KDE4, for the first time in the history of computer user interfaces, implementing those ideas is finally feasible.


Skipping to merge install phase in Paludis

Don't you hate it when building a lengthy package succeeds, installs all right into the image, only to fail for some trivial reason (like out of disk space) when merging into the filesystem? In portage you could just use the ebuild(1) command to short-circuit it right to merge. It's not that easy with Paludis, unfortunately.

But worry not, undocumented environment variables to the rescue! The SKIP_FUNCTIONS environment variable allows you to force paludis not to execute some phases of the install action. The magic combo is SKIP_FUNCTIONS="init killold setup saveenv unpack compile install". It fails on loadenv just before postrm for some reason (probably because we barred it from saveenv, but there seems to be no way to skip one saveenv and not another), but by that point the package is already merged.

But really, they ought to make it easier to do such tricks (or at least document the freakin' variable). I can only imagine how hard it must be to debug ebuilds with paludis... Or maybe there is something I don't know about?


Really nice system administration console

When you're like me, you don't like your CPU cycles waste — and if you're using Gentoo, you like to be constantly merging something in the background. The problem is that the CPU and IO load really can be a major PITA, rendering the machine essentially unusable to do any real work when compilation is running.

Luckily, Linux kernel offer a great deal of flexibility when it comes to scheduling and prioritizing processes. And using that, I hereby present you The Really Nice SysAdmin Console:

alias suscreen="sudo screen -drU || sudo nice -n19 ionice -c3 chrt -b 0 su - -c 'screen -U'"

What this code does, is to:

  • try to attach to an existing root screen (won't work for more than one, sorry),
  • in case that fails (ie. no screen running) it sets up a root login screen, scheduled on
    • lowest nice priority,
    • idle io priority class,
    • BATCH scheduler class.

Maybe chrt -b 0 and nice -n19 are a bit redundant, but you're never too sure. The bottom line is — you can have your compilation running in that screen and it doesn't go in the way with whatever you do; when need be, it just yields any CPU and IO to higher-class (ie. your) processes. So you can have your cake and eat it too.


Hardware hacking or how I learned to love the DRM

[a photo of the device]My friend, roommate and/or wife (pick two) has a Sony Network Walkman NW-E507. Quite nice piece of hardware in and of itself—gotta love the shiny bright OLED (or whatever) display.

It has only one forthcoming, and a huge one at that. Designed from grounds-up with DRM in mind, it seems that the only way to upload music is to use Sony SonicStage software; it converts files to ATRAC3 (supposedly the only format the device can play), encrypts them and only after such preparation (and adding to a proprietary-binary-formatted directory files) they could be played back. Quite amazingly odd, if you ask me—especially given it's a USB Storage device.

What's worse, the software is only available for Windows and doesn't seem to work in wine at all. (appdb.winehq says someone succeeded in running it, but I have no patience trying different wines and crazy config files + dlls mix and match. Sorry.) This is quite a major headache, as recently I've convinced her to switch to Ubuntu (and now we're running a 100% windows-free household) and now she's effectively unable to use the player (well, only as a really cool looking portable radio).

After some googling, there seemed there is no way to drive it with linux. But then again, it seems to semiofficially support playing MP3 files—but they have to be encrypted, too. Looking deeper, I've found mlsony—an open-source plugin for winamp allowing to upload and download mp3s to the Walkman. It is written in rather clean C++, so it wouldn't be hard to port.

Now, what's cool is that it seems they have succeeded in reverse-engineering the encryption format; alas, the plugin needs a key, and to get the device key, you have to run another proprietary Sony program.

As it wouldn't work in wine either, I've had a choice: either going through hell of installing (or downloading a VM, anyways) and running windows just to get those fricking 16 bytes, or reverse engineering the app. Obviously the latter seemed more fun, so that's just what I've done.

After some fun with freeIDA, assembly and WINAPI (thank you ReactOS for a clean reference and clean header files!) I've finally revealed that getting the key is a piece of cake. Everything that needs to be done is to send special SCSI commands to the device; first to authorize you, and then to read the key.

You can even do that from command line. Just make sure you have sg3-utils and xxdinstalled and just do
echo 00 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | xxd -r -p | sg_raw -s 20 /dev/sg2 a3 00 00 00 00 00 00 bc 00 14 30 00; sg_raw -r 18 -o sonydid /dev/sg2 a4 00 00 00 00 00 00 bc 00 12 3f 00; cat sonydid | tail -c16 > key

There, you have your device key in the key file! Just be sure to substitute your walkman device for /dev/sg2.

(Keep in mind that I have not tested the key yet; I have disassembled the validation procedure of the Sony software, and the string I've obtained seems all right. If you need to know, the magic value is 03 01 01 00 00 00.)