The Humble Geek

Stuff I write.

Keyword - freedom

Entries feed - Comments feed

Linux is [Unfortunately] About Choice

Ask anyone to name things they find wrong with the Linux ecosystem. I expect you'll get responses along the line of:

  • GNOME sucks
  • KDE sucks
  • GCC sucks
  • Firefox sucks
  • GPLv2 sucks
  • RPM sucks
  • Gaming sucks

What's the solution most commonly found? "Fork it, bro!"

Forking software is a legitimate reason under specific circumstances:

  • Licensing
  • M.I.A. upstream

Successful, legitimate forks:

  • LibreOffice
  • MariaDB

Forking is not a clear right to do anything you want such as creating a new distribution with a new, cool name and flashy art logos. Bad forking reasons:

  • I want to make a name for myself
  • I want a different desktop environment
  • I want a different desktop wallpaper

"Why not? I certainly am going to fork it!"

Yes, there is enough software produced for one person to be able to quickly and easily create an ISO file for users to download and call a new distribution. Before you say, yes, ask yourself these questions:

  • Do I have at least 5 people to provided a full-time job's worth of time to it?
  • Do I / they have enough time to apply security patches and / or update to the latest upstream version for a majority of the software?
  • Do you serve a product that provides a clear purpose other than a new desktop or flashy art?

All it takes is one "no" answer to put an end to your forking dreams. Just Don't Do It.

Red Hat Irony

A company devoted to promoting open source initiatives uses one of the largest closed source database engines on the planet. Red Hat uses Oracle, in particular, with their Satellite software (a.k.a. Spacewalk). The bright light at the end of the tunnel is that they are switching to using PostgreSQL, however it is not a high priority so it may take another year or two before the transition is complete.

Cross-Platform Graphical Library Maddness

An application that provides the user a window with buttons and input boxes is a given in today's graphically driven computer universe. Operating systems of all shapes and sizes provide a programmer the tools and libraries to accomplish their goal of providing such an application. Most of them are pretty boring or are too specialized to be worth taking time to study. The libraries that people should familiarize themselves with are those that can be utilized across operating systems, which include being able to run across multiple types of hardware devices. Two libraries come to mind - GTK+ [has a very interesting history] and Qt (pronounced "cute").


Today, both libraries offer very simple methods of creating a GUI. So, depending on what language your project requires, either one would be able to provide you with a robust and full featured set of options. The current drive to use Qt is entirely commercial driven - by Nokia - who owns Qt. It's the same drive that Sun made with Java. There's no logical reason to use Java. People have just be taught that it [Java] is the best and there is no other language that can do the same job (read: subjective).

I believe the "Qt hate" or "GTK+ hate" stems from the past when Qt didn't offer as many cross-platform routines as Glib (from GTK+) did or vice versa. It has been my observation that people have not spent any time with both libraries and make rash statements about the other library out of ignorance. Most Qt developers view GTK+ as a legacy library that should be abandoned. Don't tell them that there is still active GTK+ development (GTK+ 3.0 is coming soon) driven by a large community, which includes Red Hat.

Need a simple OpenGL widget in your window? There's GtkGLExt, or Clutter for GTK. Starting with Qt 4.0 a similar API for OpenGL handling was implemented.

Need video/audio capability? GTK+ apps can use GStreamer. Qt has phonon.

Need XML or HTML handling? GTK apps can use libxml or GtkWebKit while Qt apps would need to use the Qt APIs.

Nokia is also attempting to drive Qt as a "write once, run anywhere" library. This is great in that it some-what promotes FOSS, but if you wish to use GTK+ you can write once and run anywhere, too. I have done so with a GTK+ app for my $DAYJOB that can compile under Fedora and Windows and does advanced things like TLS encrypted XML packets over a TCP connection and scanning documents (using SANE). Neither library has an advantage.

More recently, Nokia has tried to push the mantra that you can write a Qt app quickly and simply. GTK+ developers can also use Vala to write a GTK+ app quickly and simply. The amount of code to write to accomplish the same goal in each library also ends up being about the same.

I can come up with any more number of examples, but those are ones I have seen used in arguments lately. The person arguing for using Qt has no idea about the matching GTK+ API and vice versa. I think it's great that both Qt and GTK+ offer such a wide range of features that are easy-to-use. You can choose a language (C, C++, Vala, Python, PHP) and write a program that could be used by thousands or millions of people across many different types of devices. Now get out there and start programming.

Developing Openly on Proprietary Land

My programming adventures continue. Nokia's experiment into Linux with Maemo is very alluring and since I've applied myself into a few Linux projects, I felt it would be worth looking into what Nokia has put together.

The Maemo SDK runs under Scratchbox, a virtual environment created in part by Nokia. The Scratchbox toolkit can run under any Linux distribution, and it requires it. If you wish to run the SDK under Windows, your only option is to use a virtual machine. Once your SDK is running, it is nearly identical to a running Maemo device. In order to use the SDK, basic knowledge of Linux goes a long way, but since Maemo is derived from Debian there are some distribution specific programs. I've been using Red Hat based distributions for years, so it took some time to get used to using dpkg and apt-get to handle packages. After a few months of using my N900, creating and handling packages takes less work under an RPM system, but it's adequate.

Since Maemo is Linux, any Linux application has a chance of life. This makes building new applications or porting existing Linux applications a walk in the park. You can literally compile any Linux program for ARM and run it, however, the necessary screen space and physical size of a N900 can make it difficult to use a large application such as Open Office, which has dozens of menus and toolbars. This is where Maemo ports come in. A finger-friendly UI can be designed and added, even sent to the upstream authors, and makes the app you port usable everyday on your device.

I started with building a brand new application. A stopwatch seemed like an easy first project. I noticed several stopwatch applications already existed, however they were written in Python or were not maintained in a long time. The Maemo Garage is a center for Maemo projects, so I created my own project page and began work. I decided to write in C, the native language of many Linux core libraries, and use GTK for the UI, a cross-platform, and the native toolkit for Maemo 5. During the programming process, I learned the Hildon additions to GTK made by Nokia, and the dbus methods to activate and listen for accelerator changes to allow my applications to turn into portrait mode when the user turns their N900. Here's the first incarnation: Stopish 0.9.0

Other programming projects are endless. I wanted to look at fixing a few usability issues. One was the RSS reader, which used a slider that was too thin for a finger. I submitted a patch to Nokia and it will be included in the next major firmware update. The second was the lack of FLAC tags in the media player. I now enjoy FLAC as my music format of choice, and it's possible to use since the Maemo media player uses gstreamer for media codecs and tracker for tags. In order to add FLAC tags, I had to extend the tracker program to be able to read them. Someone had already created such a plugin for vorbis, and so using it as a template, I made one for FLAC.

There are two Maemo repositories for projects, Maemo Devel and Maemo Extras. Finalized applications live in Maemo Extras, while developers can play with new applications in Maemo Devel Adding my projects to Maemo's repositories was a breeze. Just create a Maemo account and request upload access. I can use scp (SSH CoPy) to send my source code to the Maemo build server and it will package my projects and makes them available on the Maemo Devel repository. From this repository a developer can choose to promote it to Maemo Extras. During this promotion, other Maemo users vote on the application and if enough positive votes are made the project is automatically pushed into Maemo Extras.

Although most of Maemo is open source and source provided through gitorious, there's still a lot left closed - such as the phone, contact, and media player. Nokia's plans include more open source goodness in Maemo 6. The future of Maemo definitely looks bright even if they are forcing Qt down everyone's collective throats.

New Face, Same Blood

Hi there. You may remember me from such blogs as The Humble Geek. Due to a recent Blogger change, I've had to set up shop using server-side software. I looked at three different projects and ended up with Dotclear. I'll break down my selection pro/con list:

  • Wordpress

The big man in town. Unfortunately it uses MySQL for a backend and my server is PostgreSQL territory. Poor security is another minus. A Wordpress blog has probably been defaced by the time you've read this sentence.

  • blosxom

I saw this recommended as an alternative to Wordpress. It's Perl based and writes to flat files. Not very flexible for my taste.

  • Dotclear

Written in PHP, supporting PostgreSQL, themeable, plugable, and more. I couldn't ask for anything better. I have customized my own theme and added some plugins. The built-in functionality also allows me to add the Geek Tip as a widget. I don't have to manually edit the template as I had to with Blogger.

I may write about my Maemo programming shenanigans next, but don't hold your breath.

- page 1 of 3