wm161.net

The Future of Glovebox

The middle of last year, I started working on Glovebox, a rather ambitious project for a car computer environment.

One of the biggest choices I made was to write my own set of UI libraries on top of Qt to mirror the kind of integration that KDE has. This was mostly because I didn’t want to drag in the few hundred MB needed for Plasma.

Wow, that past me was an idiot. Lets all point and laugh.

Ever since Plasma got moved into kdelibs, I’ve been thinking on and off about building Glovebox on top of KDE. For some reason over the past few weeks I started thinking more seriously about it.

At any rate, I’ve decided to go ahead and do that. I’ve also thought about another good idea. I’ll allow Glovebox’s UI to run under an X server in addition to the original idea of using Qt Embedded’s framebuffer stuff.

So most of tonight will be spent hacking the build system and Launchpad into shape, followed by restructuring the page plugin system to use KParts.

Hello, planet!

So, uh, hi there. I’m new to the planet.

To get things started, I’m Trever, a 20 year old CS student from the good ‘ole US of A, which may or may not be true depending on your opinion of the united states. Your call. Anyways, I’ve been hacking on KDE on and off since 2007ish. The most I did was make a few patches for Amarok and just go bug hunting. Oh, and coding a lot of PHP. Apparently I’ve grown out of my PHP phase and moved on to bigger things with C++ and python. I’m one of the two people (the other one is Daniel) who work on KPackageKit, the KDE frontend to PackageKit. KPackageKit was the big reason I started hacking on KDE for real. It has also been rumored that I help work on the KDE bits for PolicyKit in fits (this rumor was started by me).

Cool, now that bit is out of the way. Now for something completely different, and really neat. I call it “Bubblemon”:

You can find it in playground/base/plasma/applets/bubblemon.

I’ve had the CPU plotters provided by the system-monitor plasmoid bundle, but I thought they were too boring, hard to see current usage at a glance, and I couldn’t really shrink them small enough. I think bubblemon addresses those shortcomings. Bubblemon is a glass sphere that fills up with some kind of goop depending on what it is monitoring. The cool thing is, the more full it is, the more it boils. Yes thats right, this is a cool animated plasmoid. It is guaranteed to wow your friends^[1]. The hotter it gets, the faster it boils with more bubbles.

In addition to monitoring your CPU usage, you can also monitor your memory usage. Soon, I’ll be adding temperature monitoring once I rework some of the internals (its all about plugins, man).

While writing this, I found a few possible bugs in plasma. I say possible, because I’ve been known to be an idiot sometimes. For instance, there’s this:

Putting it in the panel doesn’t seem to respect the plasmoid’s aspect ratio. I’m not entirely sure why this might be happening, as the battery plasmoid doesn’t have this problem, and I used it as reference for most of the code. I also haven’t updated my kdelibs with kdesvn-build since a month ago, so I’m not sure if it is fixed or not. Another issue I found was the lack of a plasma API to handle my animation. Bubblemon is forced to create its own QTimer, which is then connected to a slot that moves the bubbles and calls for a repaint every 40 ms, giving a 25fps animation. This gives plasma an ungodly number of wakeups per second. Not entirely sure if that can be helped though. However the methods that actually move and draw the bubbles take up 50% of my CPU (10 of which is system), which is unacceptable even on this dual core 2Ghz thinkpad.

The good news though, is that when my laptop goes on battery power, Applet::shouldConserveResources() returns true and bubbles are no longer bothered with, dropping CPU usage down to about 3%. If there’s any C++ gurus around who can figure out what is being such a resource hog, you’d be doing something pretty awesome for me. I’ve ran it through valgrind a few times, and it seems like most of the work is spent blending textures together in Qt. Later this week I might try 4.5 to see if that fixes anything.

¹ Not an actual guarantee.

My Atmel AVR

Last wednesday in my ASM and Systems Programming class we received our STK500 programming boards for use with our projects. Yesterday we were given some taste of how to program a board in Atmel ASM.

The ‘official’ way to download your program to an atmel board is to use their Windows-only AVR Studio. Boo!

Luckily, there is Linux software already available for this. AVRDUDE lets you communicate with the STK500 programmer to download code compiled into the Intel Hex format. Finding a compiler is a bit more difficult, but still pretty easy. There isn’t a compiler in the fedora repos, so I went searching and found avra. It is 100% compatible with the official AVR compiler.

As my first free time project, I made some leds count in binary:


;comment
.cseg
.org 0
.def count = r16
.def temp = r17
.equ PORTB = 0x18
.equ DDRB = 0x17
ldi temp,0xFF
out DDRB,temp
ldi count,0x00

lp:
out PORTB,count
inc count
rjmp lp


That was pretty thrilling for me, but I wanted more, so I made a pattern expand outwards:


;comment
.device ATmega16
.cseg
.org 0
.def output = r16
.def temp = r18
.equ PORTB = 0x18
.equ DDRB = 0x17
.equ LEFT = 0b11110000
.equ RIGHT = 0b00001111
.equ PATTERN = 0b00011000

ldi temp,0xFF
out DDRB,temp
ldi output,PATTERN

lp:
out PORTB,output
mov temp,output
andi output,LEFT
lsl output
andi temp,RIGHT
lsr temp
or output,temp
ldi temp,0
cpse temp,output
rjmp lp
ldi output,PATTERN
rjmp lp


And here’s the device in its blinking glory:

The State of Glovebox

First, I’ll show off the logo for Glovebox:

Second, Glovebox development has stalled a little bit over the last few weeks due to college starting up again for me. So, I’ll just give a quick overview over whats changed since I first announced the project.

Gloveui

Much like KDE’s libraries, Gloveui is the name for the base library I forsee all Glovebox components using. This will allow for super easy theming and other bits of consistency. As of now though, it only has an implementation of the Freedesktop icon and sound theme naming specifications, along with GIcon and GNotify classes.

A GIcon has a simple constructor. You pass it the fd.o icon name, and it uses the QIcon methods to load up images. Icons are still drawn using the basic QIconEngineV2, so it doesn’t always draw the proper size. Thats coming soon though.

The GNotify is a rough outline for a much more broad system. I soon home to have something similar to the galago-project implementation of the fd.o notification specification, where information bubbles can pop up on the display somehow. But for now, GNotify only does one thing: plays fd.o-named sounds. Since it is static, you just call GNotify::global()->sound("desktop-login"); to play the startup sound. GNotify uses Qt’s Phonon classes to accomplish this with minimal effort.

Launchpad Improvements

Over on the right is the current view of the Launchpad main window. Nothing too exciting to look at, I know, but there is now a fully-functional GPS data engine! And on the map page, I’ve implemented two handy widgets: A compass and a signal chart. The two widgets are independent of Glovebox, so any other Qt developer is welcome to use them. The only issue with them right now is the size hints aren’t working properly.

Coming Soon

With a full school schedule (class and work from 9-6 on a good day), I don’t have a whole lot of free time. I try to hack on Glovebox when I get a chance, and I’ve got a quick list of things I’m working on from time to time:

• Text-to-speech (via festival or flite) as part of GNotify
• Implement a new QIconEngineV2 to draw icons properly
• Improve hiding of the page bar (current method is drag it over to collapse)
• Proper copyright headers
• A KDE-esque plugin pattern
• A port of Plasma

That last item is a bit troublesome to me. A main feature of my Launchpad is to show a dashboard with widgets for the home page. Idealy, I’d like to implement this using Plasma. Unfortunately, that means I’d have to add KDELibs as a requirement. Right now, my plan of attack is to strip out all the KDE-specific code and replace it with Glovebox code.

Its bothering me though that I seem to be duplicating the efforts of KDELibs just to import one (awesome) feature (set). With all the recent work on getting Plasma to work great for embedded devices, it seems like I should just bite the bullet and link in KDELibs. I feel that goes against my biggest design goal for Glovebox, in that it should be small as possible and depend on as few libraries as possible.

So, lazyweb, any input on this problem?

Keeping your mythbackend alive

For my network, I’ve got two Mythtv machines. One is Saturn, the main recording backend. The other is Neptune, the supercharged media workhorse who has a frontend in addition to running my distributed DVD ripping, being part of a compile farm, holding all my music, and mysql databases.

Neither of the two are on a battery backup because I’m cheap, so when things go down, they don’t always come right back up. And sometimes Saturn’s mythbackend crashes. It happens.

So to prevent this, I added my mythtv-frontend user account to Saturn’s sudo list. Then I generated a ssh key and put it into the authorized_hosts file. Since all my accounts are managed with LDAP and /home is mounted over NFS, its really easy to syncronize both machines.

The final step is to change the ‘WOLBackendCommand’ setting in the database. The only sudo command mythtv-frontend can execute on Saturn is /etc/init.d/mythbackend restart. So I changed that setting to ssh saturn sudo /etc/init.d/mythbackend restart;sleep 5. The extra sleep allows for startup lag.

Now, if both machines go down, there isn’t a race condition between saturn waiting for neptune’s database to start before starting mythbackend. Once Neptune’s mythfrontend starts up it notices there isn’t a backend connection available. So it ssh’s into saturn, (re)starts the backend (It might be hanging, so thats why it restarts it), and waits politely for it to start.

Announcing: Glovebox, your in-car assistant!

For most of the summer, I spent my limited idle time thinking up what kind of big project I wanted to accomplish next, now that my MythTV system was ticking along just fine. My Hiveminder list had a few notable things in it: a beowulf cluster of as many free, discarded computers as I can find, a dorm computer that acts as a link between my dorm and home network, a networked coffee maker, and a car computer. Just to name a few crazy ideas.

All of those others would take too much effort, or have already been done before hundreds of times. The linux car computer hasn’t though. Searching google yields one result, “The Coolest Car in the World“. Really, its nicely done. But it could use some improvements. At a quick glance, most of the package seems hacked together using bits of MythTV, Gentoo, various other programs, and shell scripts. Even though it works, it is still very much a huge hack.

So I started my own project. A car computing environment. Much like a desktop environment such as KDE, or Gnome, Glovebox is a ‘desktop’ environment of sorts. It is based in Qt/Embedded Linux, which unfortunately restricts all GUIs to use that, but I feel the benefit of the lightweightness far outweighs anything gained by using a heavy X server.

The project is currently hosted by GitHub, and can be found on it’s page there. More details about the project can be found on that page as well. But for now, how about some screenshots, eh?

This first shot here shows Marble from the KDE project. In Qt/Embedded. As I said in yesterday’s post, I was planning on using it for some big upcoming project. Here it is! Right now, all the map does is sit there and look pretty. More like pretty awesome, am I right? Oh ho ho ho…

Since the Services concept in Launchpad (the main menu program) is based off of plasma’s DataEngine system, I figured it’d be a good idea to continue the tradition of using a clock as the whipping boy. The first Service I wrote was the time service, and the first page to use a service was the clock page. Once I add themes to the system, the clock will look a lot nicer.

Reinstalling GRUB

To add a few megs of space to my LiveDrive USB project, I repartitioned the drive in gparted, created some new LVM parititions, and then reinstalled the disk data by unpacking a tar archive I previously created. One crucial step I left out was telling my bootloader where everything went. Originally, my /boot partition was stored as the first partition. Somehow, I managed to make it the second partition (after my LVM), and now GRUB was all confuzzled.

To fix it, I tried running the command grub-install /dev/sdf. It failed saying it didn’t know which BIOS device corresponds to that linux device. The reason behind that is because on my host computer’s /boot partition, there is a file called /boot/grub/devices.map. In it is a cached mapping of BIOS devices to linux devices. Probing for devices takes a good bit of time, so it makes sense to cache it. This map file is only used by the command line version of GRUB, which recreates it when it doesn’t exist anyways. Renaming it let me progress a step further.

Now that GRUB sees the relation that /dev/sdf is my second BIOS disk (hd1), I tried messing around with grub-install again. It worked without complaint, but it still couldn’t boot. GRUB spit out a series of ‘GRUB’s to the console on boot, indicating some kind of horrible failure. Turns out, GRUB still thought my /boot was the first partition.

To finally fix this, I ran setup (hd1) (hd1,1). grub-install uses grub’s install command internally, but it uses it rather blindly. It assumes that the drive you give it is the same place where GRUB’s images are (those ’stage2′, ’stage1_5′, etc files). The setup command takes two arguments, and the second one is optional. The first argument indicates where you want to install the bootloader. I specified (hd1) to indicate I wanted it install in the MBR for my USB drive. The second argument indicates to grub where it can find its images and the menu.lst file. Remembering that partitions are 0-numbered, I told it to use the second disk and the second partition.

A few lines scroll by explaining exactly what commands it is running, then it should complete without failure. Once it did, my LiveDrive was bootable again.

Windows isn’t Insecure. It just has idiots.

Today’s slashdot article references a program built by NeoSmart called iReboot. NeoSmart says that they’ve manged to create a way to work around Windows Vista’s UAC system. Their method involves making a system daemon run at startup and then having a userspace program interact through standard interprocess communication. Yet somehow, they see this as a Vista security flaw.

Linux can do pretty much the same thing, yet people don’t point at it and say it is an insecure method. There already is an elevated privilege daemon running on a modern Linux system called HAL which lets regular users do things that only root should be able to do. Previously, the only way to reboot a system was to be root, who has the privilege to run /sbin/halt. Now, you send a message through the DBUS to HAL, who in turns calls halt, or more likely does a regular system call into the kernel.

The main difference between these two systems of rebooting into a different operating system is that DBUS was thought out to be secure from the start. DBUS relies on the concept of POSIX user accounts to make sure that only certain users or groups can access certain DBUS interfaces. But of course, DBUS was meant to be a generic interprocess communication system easier to use and much more capable than a homemade and likely platform-dependent system of unix sockets or even IPC signals. iReboot still uses the same principle, except that it isn’t as secure as DBUS. It doesn’t need to be, because there isn’t any security loss with a one- or two-user desktop.

As Raymond Chen says in his “When People ask for Security Holes as Features” series, some people are just stupid. They don’t understand the complications of how something like security works. They want silly things like asking the system for the user’s password while being blissfully naive. At the end of NeoSmart’s release post, the writer says that UAC’s separation of privileges just “gets in the way” of programmers who want to do simple things. Let’s face it, Unix-based operating systems have managed to deal with this ‘flaw’ for years. Through the efforts of ConsoleKit and DBUS, fine-grained granting of permissions has made ‘working around’ this issue a bit easier in recent times. The administrator just needs to specify which users can do what. No UAC dialogs, no need to enter the root password (unless the administrator desires it).

If NeoWin thinks this is a problem, they should have a careful look at any programming language in general. Just because it has a function to delete a file, does that mean that the language should remove that function because it could easily be abused?

How They Do It

Earlier today, BoingBoing posted a link to a list of how different people…you know, do it ;).

It took about an hour or two, but I created an AJAX version of the same list: http://wm161.net/labs/how-they-do-it/. People can add items to it and star good ones. Made me think that I should make some kind of AJAX library for PHP so I don’t have to duplicate the logic. Check the source to see what I mean. I don’t feel like cleaning up the code too much, but hey, it works, right?

My WPWrapper class

In my previous post, I mentioned that I had a really simple way of using my wordpress themes with regular PHP scripts. Now, according to the Codex, you are supposed to use this method:

include 'wp-blog-header.php';
get_header();
/* Do some code */
get_sidebar();
get_footer();

That works great and all, but from time to time you might change your theme to move your sidebar around or something. Now you’ve got a bunch of pages you need to update.

I’ve come up with a nifty solution that uses PHP’s output buffering callback system to catch whatever output happens and then stick it between wordpress’ get_* functions. The above code now becomes:

include 'wp-blog-header.php';
include 'WPWrapper.class.php';
WPWrapper::start()
/* Do some code */

Thanks to my commons system, I just need to do something like my documents page. Beautiful, innit?

For bonus points, read up on the API Documentation

The content of wm161.net by Trever Fischer is licensed under a Creative Commons Attribution 3.0 United States License unless noted otherwise.
See http://wm161.net/copyright for more details.