More gems from Redmonk: Google Linux Repositories, and

From sogrady’s daily links post (which I tend to find one new gem in every other day), I found that Google has a set of online repositories for just about every Linux distro out there. What a great way to make sure you’ve got the latest google earth, or any of their other apps you like. (Update: Apparently the repo only contains 2 packages, picassa, and google-desktop-linux. Boo google for not putting google earth in there, which is the only app I really care about at the moment.)

Through sogrady’s links I also came to the drunk and retired podcast, in which cote (another Redmonker) discusses current trends in technology, as well as dives into some technical topics in depth. The discussion of parsers, and Domain Specific Languages recently was surprisingly coherent for trying to explain something like that with audio only. While this isn’t MIT lectures by any stretch of the imagination, it’s a pretty good place to get exposed to technology trends that might be outside of your normal day to day environment.


Ah, those internets.

Refuctoring is the process of taking a well-designed piece of code and, through a series of small, reversible changes, making it completely unmaintainable by anybody except yourself. Comprehensive regression testing guarantees that nobody will be any the wiser.

Read the whole thing here.

Long standing man page display issue fixed

As I slowly started to upgrade my Linux systems between distros I found that my man pages started looking really bad. Basically, the magic color formatting codes were being escaped, so I would get pages like this:

ls - list directory contents

ESC[1mls ESC[22m[ESC[4mOPTIONESC[24m]... [ESC[4mFILEESC[24m]...

This, it turns out, makes it very hard to read. 🙂 Once my laptop finally succumbed to this fate, I needed to figure out a fix. I had originally thought it might be something to do with locales, so I turned off UTF8, to no avail. Yesterday I finally got around to digging deeper and in /etc/man.config found the following:

# Useful paths - note that COL should not be defined when
# NROFF is defined as "groff -Tascii" or "groff -Tlatin1";
# not only is it superfluous, but it actually damages the output.
# For use with utf-8, NROFF should be "nroff -mandoc" without -T option.
# (Maybe - but today I need -Tlatin1 to prevent double conversion to utf8.)
# If you have a new troff (version 1.18.1?) and its colored output
# causes problems, add the -c option to TROFF, NROFF, JNROFF.
TROFF           /usr/bin/groff -Tps -mandoc -c
NROFF           /usr/bin/nroff -Tutf8 -mandoc
JNROFF          /usr/bin/nroff -Tutf8 -mandocj

Changing the NROFF and JNROFF lines to have a -c on them means that my man pages look right again, and I get the following:

NAME        ls - list directory contents  SYNOPSIS        ls [OPTION]... [FILE]...

Hopefully this post will help someone else deal with the same problem in the future.

A novel aproach to addressing open source usability

I was just doing my morning catchup on RSS feeds with trusty Liferea, and ran across ingimp in my freshmeat feed, which has a rather interesting idea.

The standard method for usability testing in proprietary software is to pay to bring in a bunch of people “off the street” while your product is in beta, sit them down in front of your program, and give them a list of tasks to accomplish. You record the whole thing. Then you go back and figure out how long each of those tasks took, but more importantly, what sort of mistakes people made. When asked to Enable Grumocks, what menu did they guess grumock controls would be in?

While this is all good and fine for people with a bucket of money, in open source, something like this really can’t happen. Ingimp is a modified version of gimp (not a plugin), that provides transmits back to a central server what you are doing with gimp. This lets them get a snapshot of users as to what kinds of images they most often modify, which tools are most often used, etc. From their website:

Who uses GIMP? What do they use it for? What size images do they work on? How many layers do they have in their images? What tools do they use? How frequently do they use the software?

These are all important questions to consider during design. However, precise answers to these questions are generally unknown for the GIMP. While usability studies of the GIMP exist, and mailing lists and bug tracking software host ongoing discussions regarding the GIMP’s design, it is difficult to characterize how the GIMP is actually used in the real world, on a day-to-day basis.

ingimp is an instrumented version of the GIMP designed to gather this information, with minimal effort required. Just use ingimp as you would the normal version of GIMP and it will automatically collect information about how you use it — the commands you use, characteristics of your documents (number of layers, image width/height, etc.), and so on. When you quit the application, your usage data is sent to this website where it is publicly available for anyone to analyze.

ingimp is part of human-computer interaction (HCI) research at the University of Waterloo investigating new forms of sustainable open usability. In particular, our goal is to research new tools that assist open source projects in their efforts to make more usable software, without creating significant new overhead to end-users, developers, or other project members.

Unfortunately their instrumented version is still Gimp 2.2, and I’m on a 2.3 build in my distro. Perhaps after the next stable series I’ll give it a go.

MHVLUG Updates

June’s LUG meeting last week was on SELinux, presented by Bruce Locke. The subject is amazingly complex, and hence the talk ran the full 2 hours, with lots of great meaty information throughout. The SELinux transition model has always been something that I found interesting, but didn’t fully grok, and this talk helped quite a lot in that regard. Bruce used php in apache as the canonical example of a security issue you need to contain. While my opinion is largely don’t install php on any public facing machine, when you need to support real users, like Bruce does at SUNY New Paltz, that isn’t much of an option. At least with SELinux when, not if, your php app gets hacked, it can be contained pretty well, with a much smaller chance of getting a root shell. The explanation of the targeted policy in Fedora and RHEL was also useful, as it makes SELinux a lot less scary to run. SELinux has a long way to go on usability, but with the Fedora targeted policy, at least it is vaguely usable today.

I’m quite excited for the July meeting coming up, as James Vasille of the Software Freedom Law Center is coming up to talk. A full abstract will be up soon, but for those who have questions around the legal aspects of Open Source, here is one of the experts on the subject. SFLC worked with the Gaim community to get them through their suit with AOL over AIM trademark infringement (god I hate Time Warner). I’ll let James explain a lot more on what they do once he is here. It will be great to have him.

We’ve got September lined up, as Ed previously offered to do a dog and pony show on his Linux CNC machine. Perhaps we’ll add other show and tell Linux devices for that meeting.

August, and months after are still up for grabs, with a few folks giving me some tenative commitments at this point. As always, we are looking for speakers. If you can find someone that is interested in speaking, we’ll appreciate it. Finding and filling the speaker schedule of MHVLUG is always the biggest challenge, and help on that task is welcomed.

LUG Radio, Redmonk, and other things I learned recently

I was attempting to find a useful podcast tool on Linux so that I can get This American Life as a podcast, instead of my normal method of timeshifting our local NPR station. After a few attempts I found Castpodder, which had the best interface of any of the pieces of software that I could just package install off the network. And off I was to start setting up podcasts.

Castpodder had the benefit of prepopulating the tool with a couple of podcasts, one of which was LUG Radio, a regular podcast by a bunch of Linux Users in the UK. While there are parts of it where I think they could get their facts a bit better, overall it is a pretty amusing show, and it has definitely let me know about a few things I wouldn’t have otherwise.

One of them was Redmonk, an open source analyst firm. These guys do analysis of open source software and communities from a business perspective, and post all their content online. From their charter:

RedMonk is the first analyst firm built on open source. We’re dedicated to providing high quality research at no cost, and believe that the dialog that follows is beneficial to us, our community and our clients.

They also have a podcast, though I haven’t started listening to it yet as I’m getting through some of the LUG Radio backlog right now. However, as we start looking more at Linux in schools, it’s good to get some information on best bractices in Open Source beyond just my own personal experience. Redmonk looks like a reasonable place to gather some of that information.

The last thing I learned is that C# doesn’t kill puppies, at least not that many of them. I’ve been looking at it a bit recently, and basically it’s Java with all the rough edges scrubbed off. The fact that there is an actual open implementation that works, and that it comes with nearly every distro now.