Archive for February, 2009

kdesvn-build 1.8

February 22nd 2009

It’s out. I’m sorry I forgot about the annoying cmake-options bug, otherwise it would have been out sooner.

Besides that bugfix the major change is that the branch, tag, and module-base-path options now do not add the module name for you when making up the final URL (for non-KDE modules), you need to do that yourself. The reason is that many modules are tagged or branched without ending in their module names now, so it was simply impossible without using override-url to check them out.

If you use kdesupport with kdesupport-for-4.2, you need to adjust your tag to read “kdesupport-for-4.2/kdesupport” now.

Posted by mpyne under KDE & Personal & kdesvn-build | No Comments »

.desktop file security

February 21st 2009

As most of you may have seen by now, foobar had made a post 10 days ago called “How to write a Linux virus in 5 easy steps.” That blog post was later covered on Slashdot and LWN, and describes the lack of security around .desktop launcher files. These .desktop files do lots of things, but one of their most prominent uses is in program launching.

Why are they needed? Well, they give a lot of extra metadata to executable programs, such as the icon to show, the friendly name, i18n translations, program working directory, whether a terminal-viewer should be launched in association, etc. Ever since their introduction, a .desktop file has been able to complete launching its associated program without being executable (that is, without have the +x bit set on the file for POSIX systems).

foobar makes a good point that in such a situation .desktop files are hardly any different than .vbs files in their effect if they were to be transported over email, and even if a .desktop file extension is not used, if the file “looks like” a .desktop file it will be handled as such. (For instance, on my KDE trunk desktop a .desktop file will be found out with a different extension or no extension, unless the fake extension is a known mimetype (like .jpg -> image/jpeg))

So this past week after some prompting by John Tapsell reminding us that we can’t drop the ball again I’ve been working on making .desktop files more secure. The issue is that we can’t simply require +x and see what happens, as even the installed menu icons in Kickoff are .desktop files, not to mention shortcuts on the Desktop and in the panel.

The alternative we hit upon in kde-core-devel was to allow .desktop file execution in the following cases:

  • If the .desktop file were owned by root (i.e. part of a standard system installation)
  • If the .desktop file was installed as part of the desktop environment (that is, it is from a known location for services, applications, and XDG-compliant applications. These correspond to the “services”, “apps”, and “xdgdata-apps” parameters to kde4-config --install). This allows for KDE installations to $HOME for instance.
  • Finally, having the file be executable by the user always allows the launcher to run.

Unfortunately this still leaves the problem of what to do with launchers on the desktop or in the panel. Going forward we will need to make such .desktop files executable when they’re created but users who are upgrading would all of a sudden lose their custom launchers if that was all we did.

So in addition to the lockdown code I’ve been working on a reliable means of giving the user the option of automatically “fixing” the .desktop file and continuing on with execution. Doing this would make the file executable, and add an appropriate #! header if one wasn’t already present. (The interpreter used for .desktop files is /usr/bin/env xdg-open).

This is an example of a dialog that would pop up for such a file (“mileage tracker.desktop”):

Dialog security popup example for launchers

The text isn’t set in stone yet (i.e. please suggest something better ;), I’m trying to make it descriptive enough to be useful without making the text so long as to simply lull the user into clicking “continue”.

One thing I haven’t done yet is to touch base with the XDG mailing lists to see if this requires revision to the specification (that way we don’t unintentionally break GNOME/Xfce/etc. apps on KDE, and don’t have ours broken). Mostly this was a matter of time — I already have little of it so it hasn’t quite percolated up in my priority list yet.

You can see my latest patches on the kde-core-devel mailing list. If you see any issues please don’t hesitate to email me or otherwise let me know sooner rather than later so we can either get them fixed or verify that it’s not an issue.

Posted by mpyne under Computing Troubles & KDE & Programming | 21 Comments »

Nuclear subs collide

February 16th 2009

I guess Slashdot has finally picked up on the collision between a British and French SSBN. Since submarining is my Real Job ™ I figured I’d try to disspell some of the inaccuracies I saw among the Slashdot comments.

I saw lots of comments regarding how extraordinarily low the probability “must be” for having two SSBNs collide in the Atlantic, therefore it must be some secret exercise, which I wanted to go into.

First off, SSBNs on patrol would not be able to just go anywhere in the Atlantic that they wanted to. Any missile system will have a set range, so depending on what country or countries they suspect they’d have to launch against, they’d at least have to be within some kind of minimum weapons range.

Further, there could be other criteria limiting their possible operating area. Maybe a country wants to keep their SSBNs within range of their maritime patrol aircraft so that there is air cover available to try and detect hostile SSNs looking for the SSBN. Maybe a country wants to keep their SSBN within a certain number of days of transit time to allow for timely changeout of SSBN in the event of mechanical failure or personnel casualty. There’s a lot of variables that could be put into the problem of determining a good operating area.

Given the fact that Britain and France are right next to each other it stands to reason that whatever operating areas they chose could be near each other or even intersecting. Unless the countries corresponded with each other to deconflict their operating areas they could unwittingly be having their SSBNs operate in the same waterspace.

France has been performing submerged strategic deterrance patrols since 1971, and Britain since 1968. That’s almost 40 years of submerged patrols going on and the fact that there’s been 1 collision in that time between countries which do not coordinate waterspace is frankly not that shocking.

The question then becomes how the submarines did not take action to avoid collision, since both were equipped with sonar. The answer lies in the fact that there are two major types of sonar, active and passive. Active sonar is the type of sonar you see in the Hollywood movies, where the submarine crew looks anxiously at the hull while it is being “pinged”. It’s actually counter-productive for a SSBN to use though, as it draws attention toward itself. Imagine a completely dark room with two people, and one turns on a flashlight. The person holding the flashlight is brilliantly obvious to the other person, but the person without a flashlight can still try to run out of range of the beam. Active sonar is more like an omni-directional light than a beam but in the context of avoiding detection at all costs it is still a no-go. So neither SSBN would have been using active sonar.

Passive sonar is the fallback, and is simply “putting an ear into the water” and listening for sounds. There are all manners of noise producers in the ocean. There is wave action, weather, biological activity, merchant traffic, normal background noise, etc. etc. When you keep in mind that both France and Britain have probably spent substantial sums of money designing, building, and maintaining a SSBN fleet that is nearly undetectable it doesn’t seem so surprising that passive sonar would have been ineffective at detection, not to mention tracking. There are other ways of trying to detect a submerged submarine but the common thread is you’d need to be close no matter what you do.

Given that there have been collisions between submerged submarines before (for instance, USS Tautog), even back when they were much noisier it’s not surprising per se that it would happen again.

The other major comment I read was the usual uninformed commentary over nuclear weaponry and/or propulsion. Many were concerned with the effects on either the warheads or the propulsion plant. I can’t speak to warhead design but the engineering problem of preventing an inadvertent detonation of an unarmed warhead is not exactly rocket science. The hard part was getting it to blow up in the first place! In addition the reactor plant (if it’s anything like ours at least) is probably going to be the most likely thing to work after a collision. Keep in mind they are designed to sustain battle damage from things like torpedoes and depth charges. The real contamination people are worried about is embedded inside the fuel plates in the reactor core. The reactor coolant itself is not nearly as large a concern. In fact, American nuclear-powered ships maintain a coolant discharge log (section 25.2.4) to record coolant discharges at sea.

Even if the nuclear plant were to have sprung a leak, it has to get through the submarine hull itself before it escapes to the environment (and in that situation the submarine is likely sunk anyways).

What would have happened in the event of the real catastrophe, that one or both submarines would have sunk? Same thing that happened to USS Thresher and USS Scorpion, the reactor plant would scram, and the decay heat cooling would be provided by the seawater flooding into the ship and reactor compartment as the submarine broke up while it was sinking. If contamination did leak it would be at the bottom of the ocean (the phrase “like peeing into the ocean” springs to mind).

The warheads themselves would sit inert in the ocean, undoutedly to be recovered at great expense (if feasible, at least). A US Air Force nuclear bomb was dropped into the Mediterranean Sea without blowing up in 1966 (three other bombs fell on Spain, two actually blew up without detonating the warhead). So the consequences would be severe but at the same time, a magic detonation just from going bump isn’t a plausible failure mode for the warheads.

So to sum up, this is a big deal, I’ll be interested to see what is publically released after the inquiry but there is no reason to be up in arms about warheads blowing up or reactor cores melting down or weird conspiracies between French and British SSBNs gone awry. (In fact, if the British and French had been doing an exercise it’s highly unlikely they would have collided, it’s very easy to say “you stay above 100m and I’ll stay below 200m” and thereby prevent the very possibility of collision.)

As an aside, if you think this collision was bad, then you must not be familiar with USS San Francisco, which ran into a mountain underwater at flank speed (and survived). And the reactor plant not only survived unscathed, but she managed to drag herself home under her own power.

Posted by mpyne under Navy & Personal | 7 Comments »

Google Chrome

February 15th 2009

So I guess that the upcoming Linux port of Google Chrome will be using the GTK+ toolkit.

Unfortunately the OSNews story I linked to didn’t bother to link to the email that they’re quoting so I only have their writeup of the explanation from Google engineer Ben Goodger to go off of. But it seems to me that Ben is making up explanations…

Update 1: OSNews has updated their story to add the email they’re referencing. Thanks, guys.

Regarding the question of why not Qt from the get-go instead of making essentially three different applications, he replies by more or less saying that using cross-platform toolkits doesn’t really offer anything except the illusion of native software, which makes the application end up “speaking with a foreign accent”. Now, that may be a reasonable issue he’s having. After all, he’s the Google engineer and I’m just the guy writing code in his spare time. But the same argument applies to his choice of GTK+, which is also a cross-platform toolkit. For the Linux/X11 platform both GTK+ and Qt are “native”. And Qt will, if you’re running under GNOME, default to a Clearlooks-alike style. And apparently, with Qt 4.5, it will default to GTK+ itself doing all the drawing. So that doesn’t seem to be a point against Qt, at least in relation to GTK+.

Ben also further claims that choosing Qt would limit the application to the subset of functionality between the 3 platforms chosen instead of allowing Chrome to use platform-specific features. It’s pretty much flatly false though, or else how does Qt Software manage to get their Windows XP style to work? I know that Ben and the rest of the brilliant guys at Google are able to figure out how to use #ifdef, so I figure the real reason is that they wouldn’t have wanted to clutter up their code with those (although even that can be easily minimized with proper design). Although not up to the level of our base X11 implementation, KDE on Windows is working. And that’s an entire desktop environment, one of the largest open code bases in the world, so I guess I don’t understand this argument either.

That was all of the arguments I saw against Qt, and neither was convincing. What seems more convincing to me is that other Google engineers apparently didn’t have the same impression of the problems with Qt, seeing as how Google Earth uses Qt.

I think what the real reason is, is that Ben Goodger likes GTK+ better, or is at least more familiar with it, and made the decision to use it. Which is fine, that’s his choice, and is probably borne out by his experience working with Netscape and working on the Firefox project. I just don’t see why he’s having to try to make up excuses after the fact.

Posted by mpyne under Personal | 25 Comments »

World of Goo… for Linux

February 14th 2009

It seems like the guys at 2D Boy, makers of World of Goo, have ported the game to Linux.

The interview I linked mentions a bit of the struggles involved in porting. PulseAudio was mentioned as an issue which apparently they were able to make work in the end. I wonder why OpenAL wasn’t used though. (Or if it was, why OpenAL was putting the audio through PulseAudio…). Latency isn’t really PulseAudio’s fault IMO, it’s a sound server when a game just needs access to the sound card.

As far as the game itself goes, I already own it on WiiWare so I probably won’t buy it again. But I can tell you it’s definitely worth $20. Like all puzzle games it can be a little frustrating at times. Luckily if you get fed up with a level you have a limited number of skips you can employ, and there are other features to may the game not antagonizing. So, it’s not like the bad old days where you’d work on a level for 20 minutes and then one stray click would cause you to have to start alllll over again.

Posted by mpyne under Personal | 3 Comments »

The RANDU pseudo-random number generator

February 6th 2009

On my homepage I have for awhile mentioned that I wanted to get my symposium project posted someday.

I’ve finally had a chance to touch up the code I used in the symposium and I’ll briefly mention here what this is all about.

In the late 60′s IBM developed a random number generator for its System/360 computers called RANDU. The algorithm was designed to be fast and have an easy implementation. Unfortunately it had a lot of deficiencies associated with it as well, including some glaring anomalies which are visible if you plot RANDU-generated points in 3 dimensions.

View of RANDU points looking like a uninteresting random distribution in a cube (click to enlarge)

This view of a RANDU-derived point distribution doesn’t look so bad. But if you rotate around the view a little bit, you’ll see this:

View of RANDU points looking like a set of planes (click to enlarge)

That doesn’t look very random at all. This type of testing is referred to as spectral testing, and it carries on to greater than 3 dimensions even (although it’s hard for us to visualize of course). Spectral testing is just one of a series of different tests that scholars use to determine how “random” psuedo-random number generators really are.

RANDU was bad in other ways too. Although it could output up to 2^32 or so different numbers it started repeating numbers long before that point (which makes the output not-very-random at all).

Anyways, this was the essence of my symposium project. It was a program I used to aid my demonstration, written in Qt 3 on Linux and then cross-compiled to Windows using a free (as in beer) Borland compiler running under Wine (I forgot what patch I used to eventually make it work). (The Qt 3 I used came with C++ GUI Programming with Qt 3 as a non-commercial license).

The program itself was derived from a series of programs I used in my Computer Graphics class (where we basically implemented 3-D primitives ourselves instead of with OpenGL — this was the first time I got to use OpenGL’s 3-D features), so that’s what the rotation and scale features are for (as in, I didn’t take them out).

As I mentioned, I ported the program to Qt 4. I used this as my opportunity to learn how to use the git source control program, which I’m liking more and more as we go. The final result is available from this link, with 3 random number generators, including RANDU.

I’ve fixed many stupid programming mistakes but a lot of the history is still evident in the code (such as scaling all the random numbers to 0-1000.0 arbitrarily. :))

Posted by mpyne under C++ & Personal & Programming | 2 Comments »

Could this be the dumbest Slashdot story ever?

February 6th 2009

Bold claim, I know. But according to this Slashdot story, Microsoft has a broken design for some Vista-specific tool because they allow XP Media Center users to download it.

I’d like to think that it made the front page of Slashdot just so we could collectively laugh at the submitter (the story is already tagged submitard as I write this). But sometimes I wonder…

Posted by mpyne under Personal | 3 Comments »

Another programming tidbit

February 4th 2009

Now that Super Bowl weekend is over (Go Steelers!) it’s time to get back to fixing bugs and typing up code. That brings me to my helpful tidbit for today.

A few JuK bugs have been related to this issue, and I just saw a second kdelibs bug today which I think is related to this (the actual bug is unimportant) so I think it’s important to get out the following message: QObjects do not free you up from having to write proper destructors.

Here’s a more detailed explanation of the problem. Let’s say you have a widget, which has a private d pointer. Your widget itself contains several sub widgets which are children of your widget. One or a few of these widgets rely on an object contained in your d-pointer. It may look something like this:

A simple class diagram

Of course, graphically illustrated the problem might seem obvious here, especially if you know how QObject’s destructor works: If you delete the d pointer while the View is still using it then you run the very real risk of a crash. This can occur if your destructor looks like this, for instance:

Widget::~Widget() {
  delete d;
}

After your ~Widget has run then your d pointer and its DataStore are no more, but your View and Button are still alive. This is usually OK, as the QObject destructor will delete them and there will be no memory leak. However, if anything happens to the View which would cause it to access the DataStore object before the program gets to that point, then you have a crash on your hands. The race window is very small here if you’re racing with an event handler for instance. The problem is a lot easier if View uses DataStore in its destructor since it will pretty much always crash there.

If DataStore had somehow been a child of View there wouldn’t have been an issue (since QObject deletes children first), but that unnecessarily fouls up the class design and besides, it’s usually either not possible or desirable. But when you have situations where you have children that depend on siblings for their functionality, you must delete them manually in your destructor or else the effectively random order that is chosen by QObject is what you’ll get, which can lead to hard-to-reproduce crashes. In this case, we would delete View before we deleted the d pointer. We don’t have to delete the Button manually since it does not depend on any of its siblings, although it doesn’t hurt either.

Posted by mpyne under C++ & KDE & Programming & Tutorial | 4 Comments »