Skip to content

Archive

Category: F/OSS

When Ubuntu 10.04 was released it represented the most modern incarnation of Canonical’s premier Linux desktop distribution. However not all things were better in this release. For myself I immediately noticed a problem while trying to install the gnustep-devel development libraries for GNUstep and Objective-C. I was greeted with this oh so lovely error message:

Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming.
The following information may help resolve the situation:

The following packages have unmet dependencies:
gnustep-devel: Depends: gorm.app but it is not installable
E: Broken packages

So essentially I was left with the following choice: install the missing Gorm.app package from the repository (which wasn’t there) or don’t install gnustep-devel. Thankfully it was pointed out to me that I could perhaps see if the package still existed in the Debian repository instead. So off to http://www.debian.org/distrib/packages I went and after a quick search I found what I was looking for! I recalled reading somewhere that Ubuntu synchronizes with Debian testing (A.K.A. squeeze) at the start of every round of development, so I figured that would be the best package to grab. A short download and install later Gorm.app was finally on my system. With the dependencies now met it was a breeze to install the rest of the development files using a simple

sudo apt-get install gnustep-devel

And there you have it. By installing a single package from the Debian repository you too can get around the problem. For reference I have also filed a bug report with Ubuntu at Launchpad here.

As some of you already know, I am a big fan of the KDE desktop environment (or KDE Workspaces or whatever they’re calling it these days). In my search to reach Linux KDE perfection I have tested out a number of different distributions. First there was Fedora, which I happily ran throughout the length of the experiment. Once that was finished I attempted to install and try both Kubuntu and openSUSE. Unfortunately I was unable to do so after openSUSE decided not to play nice. However my search did not stop there, and once the community edition was ready I jumped over to Linux Mint KDE CE. Finally I decided to once again try openSUSE, this time installing from a USB drive. This somehow resolved all of my installation issues.

Now that I have tried out quite a few of the most popular distributions I figured I would write a little bit to tell you fine people my thoughts on each, and why I will be sticking with openSUSE for the near future.

Fedora 11

  • KDE Version: 4.2 – 4.3
  • Pros: very secure, not too many modifications of the KDE source, cutting edge
  • Cons: could have really used some more modifications of the base KDE packages in order to better integrate GTK+, Bluetooth problems, not always stable
  • Thoughts:

    I have written at length about my experiences with Fedora during this experiment. Without re-writing everything again here let me simply say this: Fedora is primarily a GNOME distribution and I could never shake the feeling that KDE got the left-over treatment.

Kubuntu

  • KDE Version: 4.3
  • Pros: very easy to use, nice integration of GTK+ and GNOME notifications, access to Ubuntu support
  • Cons: the hardware drivers application (jockey) simply did not work, very bad sound issues, Firefox could not handle opening file types
  • Thoughts:

    When I first installed Kubuntu I was thrilled. Ah, this must be what it’s like to use a real KDE distribution, I thought. Everything seemed smoother and far more integrated then it did in Fedora. For example: OpenOffice.org had a KDE theme and it’s file browser actually used the native KDE one. Furthermore the notification system was awesome. Now instead of a GNOME application, like Pidgin, generating GNOME notifications, it instead integrated right into the standard KDE equivalent.

    Then the problems started to show up. Oh I’ll just download this torrent file and… hmm Firefox doesn’t seem to know what to do with it. Why can’t I set the file type options inside of Firefox for torrents? Why doesn’t it use the system defaults? Then the sound issues came. YouTube stopped putting out audio all together and all of my attempts to fix it were futile. Maybe it’s just my hardware but Kubuntu just could not handle multimedia at all.

    While Kubuntu is definitely one of the better KDE experiences it is by no means problem free.

Linux Mint KDE CE

  • KDE Version: 4.3
  • Pros: excellent package manager, easy to use
  • Cons: sound issues, WiFi issues, is this actually a KDE desktop? there are so many GTK+ applications in it…
  • Thoughts:

    After hearing much praise for Linux Mint I decided to give the newly released KDE community edition a go. I must say at first I was very impressed. The package manager was far superior to KPackageKit and even included things like user ratings and comments. It also came bundled with many tools and applications designed specifically for Linux Mint. Sadly very few of these were re-written in Qt and so I was forced to deal with GTK+ skinning almost everywhere.

    Sound issues similar to those in Kubuntu (maybe it’s something in the shared source?) started to crop up almost immediately. Again YouTube just did not work no matter how much I tried to fix it. Finally the WiFi connection was very poor, often disconnected on what seemed like a specific interval.

    While I think this distribution has a lot going for it I can only suggest the GNOME desktop for those who want to give it a try. The KDE version just does not seem polished enough to be recommended for someone looking for the ultimate KDE distribution.

openSUSE

  • KDE Version: 4.3
  • Pros: very responsive, a lot of streamlined tweaks, rock solid WiFi, excellent audio
  • Cons: slower to boot, uses quite a bit of RAM, too much green :P
  • Thoughts:

    Installing openSUSE seemed like an awful idea. After reading all of the complaints that both Phil and Dave had written over the course of the experiment I have to admit I was a little hesitant. However, I am very happy I decided to try it anyway; openSUSE is an excellent KDE distribution.

    Everything about it, from the desktop to the little helpful wizards, all seem to be designed with one purpose in mind: make openSUSE the easiest, or at the very least most straightforward, distribution possible. YaST, often a major source of hate from my fellow Guinea Pigs, does indeed have some quirks. However I honestly think that it is a very good tool, and something that streamlines many administrative tasks. Want SAMBA network sharing? Just open up YaST and click on the wizard. Want restricted codecs? Just hop on over to openSUSE-Community and download the ymp file (think of it like a Windows exe).

    My time with openSUSE so far has been wonderful. My network card seems to actually get better range then ever before, if that’s even possible. My battery life is good and my sound just plain works without any additional effort. If I had one complaint it would be with the amount of RAM the distribution uses. After a quick reboot it takes up a very small amount, around ~350MB or so. However after a couple of hours of general use the RAM often grows to about 1-1.5GB, which is far more than I have seen with the other distributions. Thankfully I have 4GB of RAM so I’m not too worried. I wonder if it has something to do with the fact that I am running the x64 version and not the x86 version. Perhaps it assumes I have at least 4GB of RAM for choosing the newer architecture.

    Whatever the case may be I think I have finally found what I consider to be the very best KDE Linux distribution. Obviously your results may vary but I look forward to hearing what you think.

This piece was cross-posted over at The Linux Experiment.

I have been meaning to write up a short post about this for a while, but thanks to the start of a new school term I have been a bit busy.

If you have seen the security news in the last month or so you will know that RSA-768, a 768bit or 232 decimal digit asymmetric key, has been broken (factored). This has important security repercussions for all of us because it is these public key algorithms like RSA, or ElGamal, that guard our online transactions, and e-mail conversations.

So just how much should we be worrying about this newest ‘break’?

When it comes to public key cryptography it is important to remember that their security is essentially in our inability to factor them quickly. The only real way that public key cryptography could be considered broken is if we find a way to drastically increase our ability to factor massive prime numbers. Thankfully that time is still far away. In fact after digging into the news articles a little more it quickly became obvious that the feat of factoring a 768bit key, while incredibly difficult, was inevitable.

So what now?

Nothing. Currently the most popular asymmetric key size in use is 1024bit, which represents a work load increase of over 1000 times when compared to RSA-768. Still afraid? Check out the list of RSA challenges that have been issued over the years and just how few have actually be ‘broken’.

In choosing my current PGP/GPG public key I decided to go with a 2048bit one, which, according to all accounts, will be safe for years to come. As always, I recommend checking out this site for the most up to date key length recommendations from the world’s foremost cryptography experts.

There you have it

With the knowledge that you’re online transactions are still perfectly safe you have nothing to worry about.

For reference, the currently recommended key lengths for asymmetric encryption algorithms, like RSA, are 1976bit (BSI recommendation for use after 2016), 2048bit (NSA recommendation for current and future use), and 2432 (ECRYPT II recommendation for protection until at least 2030).

I honestly don’t remember how I came across this awesome project but I am certainly glad I did! XMLVM is a software toolchain which is designed to take cross-compilation to a whole new level. Rather than just offer OS portability, XMLVM is able to actually offer OS, hardware and programming language portability.

Here’s how it works: you write a program in a programming language of your choice, say .NET. Once compiled you send it through the first step of XMLVM which analyzes the produced CIL and creates an XML document out of it. It would end up looking like something similar to this:

<clr:ldc type=”int” value=”2″/>
<clr:rem/>

Next this XML document is fed through what XMLVM calls the data-flow analysis (DFA). Basically you can think of DFA as a pseudo-language that simply describes the operations that the program is trying to perform. Once in this form the code is considered portable. XMLVM then lets you pick a target, for example the Java JVM, and automates the conversion of the DFA to an XML representation of the java byte code. From there it’s an easy conversion back to true java byte code.

Now think about this in practical terms for a second. That means that you can write a program in a .NET language (C#), and have it automatically ported and compiled to Java. Expand on this a bit and consider that you can write the same program in any language and have it converted to any other language. Currently the XMLVM offers a lot of other cool options as well and has actually been designed a lot with mobile devices in mind. Now you can write a program once and have it automatically converted to Objective-C, to run on the iPhone, and to Java to run on Android.

I really hope that this project continues to improve and I will certainly be watching it closely. It is still very early in development but from what I have seen it is simply brilliant.

Well, at least for now. Check out the site to see what everyone thought about the experiment as a whole.

Check it out here: The Linux Experiment

That’s right an update to your favourite hash verification program! :P

This update includes a few new features that some of you might find useful. It also includes help documentation which walks you through how to use it!

New Features

  • Menu strip for even easier use
  • Export features allows you to automatically write all of the hashes to a single file
  • About dialog that provides information about the program
  • Help documentation

Requirements:

  • All platforms: .NET 2.0+ / Mono, a graphical display
  • *nix platforms: WinForms (identified as System.Windows.Forms)

As always the binary only package contains just the executable, whereas the all package contains the source code as well.

Binary Only Package All Package
File name: hash_verifier_0_2_0_0_binary.zip hash_verifier_0_2_0_0_all.zip
File hashes: Download Here
GPG signature: Download Here Download Here
Screenshots: Screenshot 1 Screenshot 2
License: (LGPL) View Here
Version: 0.2.0.0
File size: 171.5KB 530.1KB
File download: Download Here Download Here

Some of you may remember an old Windows program of mine called Hash Verifier. It was a graphical utility that allowed people to generate hashes of their files, and then compare those to known hashes, ensuring that their files had not been corrupted. Well in recent months my foray into the world of Linux has finally taken me into the realm of programming on that platform. Being primarily a .NET developer on Windows I have found the Mono project on Linux to be an absolute breath of fresh air.

“Monkey” project

The Mono project is an open source implementation of Microsoft’s .NET common language runtime and a C# compiler. On Linux the easiest way to program in a Mono language is within the project’s own integrated development environment called MonoDevelop.

C is a sharp language

C# is a very powerful programming language that falls somewhere between C and Java in terms of syntax. While my experience with C# has been limited in the past, I was easily able to pick it up quickly thanks to my background in both C and Java, as well as fellow .NET language Visual Basic.

The challenge

Digging up an old .NET project of mine, Hash Verifier, I decided to challenge myself to port the application to Mono. In order to do this I needed to accomplish the following:

  • The original application ran on Microsoft’s .NET on the Windows platform. The new application must run on both .NET on Windows and Mono on supported platforms.
  • The original application was written in Visual Basic. The new application must be written in C#.
  • The original application has a GUI powered by the native Windows.Forms. The new application needs to have a GUI that works in a similar way on all platforms.
  • The new application must be able to fully re-create all of the old application’s features and functions.

Porting = easy

I must say that porting this old application to C#/Mono was a relatively straightforward task. Although I had plenty of GUI toolkits to choose from I ended up sticking with the existing Windows.Forms. Once I had decided on using Windows.Forms as the basis for my GUI (WinForms is a free and open source implementation for non-Windows users!) I set out to create my new application. I was literally able to open the old Visual Basic GUI designer file, copy the code into my Mono workspace, change the syntax to C# and voila it worked!

In fact the only tricky part was trying to figure out a compatibility issue that .NET/Mono 2.0 seem to have with the new Windows Presentation Foundation (WPF). I’ll save you the gory details but basically drag and drop functionality would not work. I eventually rectified this issue by including a compiler flag telling .NET/Mono to execute the form in single thread apartments mode. You can see where I did this in my code by looking right above my static main function:

[STAThreadAttribute]
public static void Main()
{

}

Final result

With the application complete I must say I am impressed. Crafting and running applications for Mono is extraordinarily simple to do, seems very powerful, and the application itself only takes up a couple of MiB to run. In the future I definitely plan on doing more of this type of development now that I am using different operating systems every day.

Hash Verifier

If you are still using the old version of Hash Verifier, or if you would just like to try it out you can download the new Hash Verifier in two different ways. The package marked binary only contains just the program itself and the relevant documentation. The package marked all contains both the program, documentation as well as the source code.

Requirements:

  • All platforms: .NET 2.0+ / Mono, a graphical display
  • *nix platforms: WinForms (identified as System.Windows.Forms)
Binary Only Package All Package
File name: hash_verifier_0_1_0_0_binary.zip hash_verifier_0_1_0_0_all.zip
File hashes: Download Here
GPG signature: Download Here Download Here
License: (LGPL) View Here
Version: 0.1.0.0
File download: Download Here Download Here

As a long time Windows user I have had my fair share of dull, gray toolbars, buttons and controls. Prior to Windows Vista, Microsoft’s first real attempt to pretty up the system – sorry XP, making the taskbar blue just doesn’t cut it – I even looked to Mac OSX with some jealousy.

Flash forward to The Linux Experiment and I have been introduced to a whole new set of environment graphics. Some of them are quite beautiful and some are just… plain ugly. On the plus side, the nice thing about Linux is it’s ability to customize just about every detail, including how my desktop looks. But is there really any excuse for some of the horrible themes, colour choices (*cough* Ubuntu *cough*), and graphics that are still present in Linux today? Surely there are some artists out there in the open source community that could be let loose on these problems? Come on people, I know you can do better!

Over at The Linux Experiment we have decided to shake things up a little bit by forcing a change of desktop environments on everyone. Whatever we have been using thus far as to go for at least two weeks. If you care to follow along you can start by reading about how my transition from KDE to GNOME went below.

Check it out here: The road to GNOME

Just wanted to point out that we over at The Linux Experiment have pushed out our first podcast. Join us as we discuss our experiences with Linux, and complain about all of the little issues we’ve been having.

Check it out here: The Linux Experiment Podcast #1: The Pilot