Writings

Technology, open source, personal essays, and everything that isn't climate.

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:

ESC[1mNAMEESC[0m
ls - list directory contents

ESC[1mSYNOPSISESC[0m
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.

Related: Standing Desk · Prettier fonts for Git Gui on Ubuntu · The Power of Perl: Converting an A4 PDF to Letter with Margins

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.

Related: Give the gift of Open Software this holiday season · The Open CD · MHVLUG Meeting Notes - January 3rd 2007

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.

Related: What I'm listening to · More gems from Redmonk: Google Linux Repositories, and DrunkandRetired.com · The future of open source

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.

Related: MHVLUG November Meeting Synopsis · 10 Years of MHVLUG · 7 Years of MHVLUG

Slashdot Comments for Posterity

I've had the following up on my office wall since 1999, when I first read it. It is reproduced here for posterity, though you can read the static version at the source.

My software design process (Score:4) by Shoeboy (16224) on Monday August 09, @07:45PM (#1755777) (http://adequacy.org/)

This is how the shoeboy does things:

  1. All the probable users are asked to contribute their thoughts on what the project was supposed to do. Most of them suggest things entirely unrelated to the description of the project.
  2. All reasonable suggestions are torn up and fed to a goat.
  3. The goat is sacrificed in the middle of an inverted pentagram while the PM chants "CTHULHU FNAGN" (this step is optional)
  4. The development group works out a good application framework on a whiteboard. The least popular member of the group is then assigned to create a powerpoint detailing the proposed framework.
  5. Out of bitterness, the guy writing the powerpoint discards the teams ideas and writes his own. The powerpoint is then sent to management.
  6. Management approves or vetoes the project based on the color scheme used.
  7. The team suddenly finds themselves commited to a shitty framework. The alpha geek on the team blames the PM and begins playing political games to get him/her replaced.
  8. Deciding that misery loves company, the team asks the Unix and NT admins what platform the app should run on.
  9. The Unix wookies and the NT trolls declare total war on each other and the PM gets cc'd on every message in the resulting flame war.
  10. The team hires a bunch of contractors to help develop the project.
  11. Performance review time. Everyone tries to look good at the expense of others. Massive flame wars erupt.
  12. Team begins to develop application while attempting to keep PM in the dark.
  13. PM gets revenge by requesting customer feedback on the proposed feature set.
  14. Team vetoes all customer requests, promises to include them in the next version.
  15. Management hears the customer complaints. Demands more powerpoints.
  16. Reorg time. PM now reports to a new manager.
  17. Team missed deadline for first beta as they are working on powerpoint slides.
  18. Cubicle move. Work interrupted as everyone in the building starts moving cubes to the tune of 'pop goes the weasel'. When the music stops, they all rush to a new cube except for one sluggish contractor who is promptly fired.
  19. Team missed second beta deadline due to the loss of the contractor fired in step 18.
  20. Management decides that the project will never get finished, cancels it. This isn't the best way to design software, but it seems to be a common method. --Shoeboy
Related: Best Customer Service Call Ever · Observe the Moon at Vassar Farm · A tale of two tech teams

The Open CD

On Friday I spent the day with IT Staff of a couple of different school districts in Connecticut. We were there to see how they were using Open Source in the schools, and what sort of future plans they have in that area. For me, it was a very eye opening experience. While you may "understand" how constrained our public schools are when it comes to resources, until you spend a day with them, you probably don't. It is extremely notable if an entire school district has a programmer on staff (almost no one has that). A programmer is defined as someone that knows PHP. For an pen applications to take hold in this space, they must be graphical, and never require dumping out to a shell to configure. While many open source projects are headed in this direction, very few are really there today.

Over the course of the day, The Open CD came up a few times, being discussed by some of the open technology advocates within the CT system. The Open CD is a CD ISO of Open Source applications that run natively on Microsoft Windows, and are considered best in class applications. It includes Open Office (equiv of MS Office), Scribus (page layout), GIMP (photo editing), Audacity (sound editing), Inkscape (vector drawing), Gaim (instant messaging), Firefox, Thunderbird (email), Celestia (astronomy application). As all the programs are under open licenses you can install it as many times as you like, wherever you like, with no fear of violating licenses. This is still a bit foreign to Windows users, but something people can get over the hump on pretty quickly. Prior to this meeting, I wasn't really aware of The Open CD, but a weekend of stewing on it made me realize it is one of the best things since sliced bread.

While I remain a Linux advocate, and am not planning on running windows on any of my home boxes any time soon, Windows remains a reality on the desktop. But the strangle hold on the desktop is more about the applications than anything else. If you get people over to an Open Office, GIMP, Firefox world, then sitting at a windows machine with those installed is the same as sitting at an LTSP terminal with them installed, at least from a user perspective. This is a huge lesson that Novell learned in it's mass linux migration: migration the application set to open alternatives first. The transition to Linux is much easier after this. The application stickiness is the big reason that alternative desktops have grown slowly.

Another fact is that nearly every retail computer sold comes with Windows, but you pay extra for MS Office. Instead of going after that which the user sees as part of the hardware for an open replacement, go after the thing that costs that an extra $100 dollars. If you bought the most popular proprietary versions of the applications on the open cd, at retail prices, you'd end up spending a couple thousand dollars for the set: MS Office, Adobe PageMaker, Adobe Photoshop, Adobe Illustrator, etc. And just think, now you are also putting Cellestia and Blender into the hands of kids, and just letting their imagination take them away. How exciting is that!

As MHVLUG starts out on it's fifth year, we've had a bunch of members start to be really interested about ways in which we can tap into this large group of open source experts, and expand into our communities; giving back where it matters most. It seems to me that advocacy around The Open CD is a good place to start, as it provides a very real, very easy on ramp into the world of Open Technology that the 95% of Windows users can participate in as well. We'll work on getting them over to Linux for critical components later, but just getting people exposed to a world where people write software under open licenses and give it away for free helps a lot to understanding why Linux is special, and why it is often the right answer for the job at hand.

Over the next many months I think we'll be getting together with this group multiple times to provide some volunteer assistance in navigating the waters of Open Technology. I have to say, after Friday I was seriously energized about all the things we could do to help schools in this area, and can't wait to see how this plays out over time.

Related: Give the gift of Open Software this holiday season · Getting Involved in Open Source · Upcoming Talk: Getting Involved in Open Source

Riding the Rail Trails

Yesterday Susan, Mike, Matt, Pyg, and I decided it would be a good day for a bike ride. Susan is just getting used to a bike with gears, so heading out to the Harlem Valley Rail Trail seemed like the thing to do.

It's about a 40 minute drive from our house to Amenia, one of the main park and ride points for the rail trail. From Amenia you can ride 8 miles north, to Millerton, or 2.5 miles south, to the start of the trail. Along the way you ride past farms, streams, a swamp or two, and lamas. It took us just under an hour to get to Millerton, where the rail trail currently ends, awaiting completion of section 4 of the trail (sometime in 2008), which will add another 8 miles, and connect in the already completed section 5, which is 4 miles on it's own. The ride back is slightly down hill, which meant we were flying along at 15 mph most of the way. 16 miles in 1:45 isn't bad for a Sunday afternoon, especially considering everyone was riding mountain bikes.

It was the first ride out for most folks of the year, so there was the normal amount of "seat numbness", but subsequent rides should have everyone toughened up enough that that won't be an issue. It's great to get out and explore a new area. I think next time we'll probably start at the beginning of the trail, and remember our wallets, so we can get a little bite to eat in Millerton, then spin around and come home. I honestly can't wait until the full 23 miles is opened up, as that would make a really nice full day trek.

Related: The Dutchess County Rail Trail Expands · Biking to Work · Bike Radar