The Humble Geek

Stuff I write.

Keyword - linux

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
  • X.org


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.

Crossing the Streams to the Playstation 3 (part 1)

I wish I didn't have to write this article, but when there's a dozen audio formats, a dozen video formats, and a dozen media containers there's only one result: headaches. If you own a Playstation 3, a Linux computer, and have Mediatomb installed, you can take advantage of the UPnP feature on the PS3 to play your audio or video over the network. This part 1 of 2 posting will start with audio.

FLAC to PCM

The Playstation 3 is a funny thing when it comes to audio. If you only have Optical (TosLink) or Coax audio output you're stuck with 48kHz sample rate. If you have HDMI you can go higher. The example below will get you FLAC transcoding into 48kHz PCM that the Playstation 3 will play.

/etc/mediatomb/config.xml

<profile name="audio-flac" enabled="yes" type="external">
   <mimetype>audio/L16</mimetype>
   <accept-url>no</accept-url>
   <first-resource>yes</first-resource>
   <hide-original-resource>yes</hide-original-resource>
   <accept-ogg-theora>no</accept-ogg-theora>
   <sample-frequency>48000</sample-frequency>
   <audio-channels>2</audio-channels>
   <agent command="ffmpeg-flac" arguments="%in %out" />
   <buffer size="4194304" chunk-size="262144" fill-size="0"/>
</profile>

/usr/local/bin/ffmpeg-flac

#!/bin/bash

exec /usr/bin/ffmpeg -threads 2 -i "$1" -ar 48000 -acodec pcm_s16be -f alaw - > "$2"

Why 48kHz? I have some 96kHz media so I'd rather it go to the PS3 at the best possible rate. The PS3 will resample to 48kHz if you choose to go with 44.1kHz anyway so you might as well go with 48kHz. You can up this to 96kHz on an HDMI connection, but I don't have one to test with.

Extra Credit

Mediatomb development does not seem very active, but some folks have made patches to add features that make streaming more enjoyable. One annoying part of streaming on the PS3 is the default grey music icon for your tracks. This can be replaced by the album art with patch number one. You can't seek in tracks either, but that is also negated with patch number two.

Coming up: Transcoding matroska containers into the best possible format.

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").

library-maddness

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.

Thirty Ways a Software Grows

The following recount is rather generic in nature so I do not have to worry about stepping on any toes, but it is all true.

yeah

Everyone has a workplace story to tell and I've finally gotten around to writing about my own. I have had a rare opportunity to write and maintain software for a company that has plenty of history. The company I, still, work for has been around almost as long as Microsoft to give you a point of reference.

In The Beginning In traditional fashion of the time, which still holds true today, the company started by buying the rights to a software that someone else wrote. The country of origin: Canada. I do not know much about the company or who were the original authors besides a few names I've seen in copyrights, so unfortunately I do not have any juicy stories to tell about them. They wrote to Minix, which surprisingly still exists today. The data was stored in ISAM databases (Google it), which unfortunately still exists today. The program displayed via a terminal-based text screen with support for input fields and displaying different types of screen layouts, which, also unfortunately, still exists today. The only saving grace was that it was written in the C language.

Abraham Lincoln The company originated in a log cabin, now turned historical landmark. I heard the winters were cold, and the summers were hot. The size of the cabin is about the size of a traditional living room with two whole stories. There was also the shift from Minix to UNIX and DOS operating systems to keep up with growing demand.

Enterprise Split Eventually the software became outdated, in a sense, for the customer base the company wished to sell to. Enterprises wanted a more robust and fully featured software. The solution? Rewrite! The company moved to a different city, but left behind the original software - to live in its own filth.

Dungeon Upkeep Keeping the software maintained to a point people could still use it was the job of a fellow I only met once when I was being interviewed (for an unrelated position!) so I can't tell you any juicy stories about them either. However, I can tell you the software essence remained the same. They continued to use the original UNIX compiler and coding techniques. These techniques include typedefs to normal C keywords and functions. Numerous programs that simply copy & paste code from other programs. Global pointers ruled the entire source code base from top to bottom. Return values were rarely checked. Instead of calling the standard rename or delete functions, system calls were made to the operating system's shell tools. The source control system involved cloning the main source directory per release - some of which I did not find when I took over. Take this scenario for instance: One customer was given a compiled program on Monday but changes would be made to the same program and given to a different customer on Tuesday. Every customer had a unique compiled version of the software. Let that settle in your mind for a moment.

Change of Hands A friend of mine, who has moved on to greener pastures, took over a few years ago. He began a very important and rigorous job of evolving the software into a state that a guy off the street could come in and program to. The code went from 1980s leftovers to 1990s l33tsauce. It was now source controlled in CVS and macros were removed. Some of the copied code were moved into libraries that were compiled against. A small set back to the improvements happened when another programmer was hired and began transforming perfectly good code into obfuscated and over coded code. String pointers were turned into "static const char *const variable;" nightmares. Functions were rewritten to be twice as long and contained bugs that I had to find and fix for about a year.

Modern Tools After I took over we released a major version. This version was the first version where all of the software was released in one update. It was all source controlled, and I implemented a sane update system that insured customers would all be on the same software level. Lately we've moved the code into git and I have been loving every minute of it. The software is slowly emerging from its colorful past.

Over the Rainbow GUI, SQL, Cross-platform. These three words are the embodiment of the future of the company. If I get a chance to finish the project, it should provide the company and its customers with a fresh breath of life.

- page 1 of 3