Thursday, January 18, 2018

Programming with ncurses

Over at Linux Journal, I am writing an article series about programming on Linux. While graphical user interfaces are very cool, not every program needs to run with a point-and-click interface. So in my "Getting started with ncurses" article series, I discuss how to write programs using the ncurses library functions.

Maybe you aren't familiar with curses or ncurses, but I guarantee you've run programs that use this library. Many programs that run in "terminal" mode, including vi editor, use the curses set of functions to draw to the screen. The curses functions allow you to put text anywhere on the screen, or read from the keyboard.

My article series starts with a simple example that demonstrates how to put characters and text on the screen. My example program is a chaos game iteration of Sierpinski's Triangle, which is a very simple program (only 73 lines).

Follow-up articles in the series will include a "Quest" program to demonstrate how to query the screen and use the arrow keys, and how to add colors.

Monday, January 1, 2018

Write about open source software

I just wanted to point out that over on the FreeDOS Blog, we're asking people to write about FreeDOS.

It's a new year, and we wanted to encourage people to contribute to FreeDOS in new ways. If you're already working on FreeDOS through code, design, testing, or some other technical way - thank you!

If you aren't sure how to contribute to FreeDOS, or want to contribute in a new way, we'd like to encourage you to try something new: Write about FreeDOS!

Write about something that interests you! Others will want to see how you're using FreeDOS, to run existing programs or to write your own programs. We want to hear from everyone! It's not just about developers, or people who contribute to the FreeDOS Project directly. Tell us how you use FreeDOS.

Post on your own blog, or email your articles to me and I'll put them up as a guest post on the FreeDOS Blog. If we can gather enough articles by Spring, we'll try to collect them in a "how-to" ebook in time for the 24th "birthday" of FreeDOS on June 29.

Friday, December 29, 2017

So long, Linux Journal

If you don't know, Linux Journal has ceased publication. Unless an investor drops in at the last minute, the LJ website will soon shut down. Thus ends over twenty-three years in Linux and open source publication. That's quite a legacy!

Linux Journal first hit shelves in April 1994. To remind you about those times: that's when Linux reached the 1.0 version milestone. That's also the same year that I started the FreeDOS Project. Elsewhere in technology, Yahoo!, Amazon, and Netscape got their start in 1994. That's also the same year the shows E.R. and Friends first hit TV. Also that year, the movies Pulp Fiction, Forrest Gump, Speed, and Stargate.

In 1994, you most likely connected to the Internet using a dial-up modem. KDE and GNOME were several years away, so the most popular Linux graphical interface in 1994 was FVWM, or the more lightweight TWM. In 1994, you probably ran an 80486 Intel CPU, unless you had upgraded to the recently-released Pentium CPU. In mainstream computing, Microsoft's Windows 3.1 ruled; Windows95 wouldn't come out for another year. In the Apple world, Macs ran MacOS 7.1 and PowerPC CPUs. Apple was strictly a hardware company; no one had heard of iTunes or an iPod.

With that context, we should recognize Linux Journal as having made an indelible mark in computing history. LJ chronicled the new features of Linux, and Linux applications. I would argue that Linux Journal helped raise the visibility of Linux and fostered a kind of Linux ecosystem.

Linux Journal operated in the same way that Linux developers did: LJ encouraged its community to write articles, essays, and reviews for the magazine and website. You didn't do it for the money; I think I received tiny payments for the articles I submitted. Rather, you wrote for LJ for the love of the community. That's certainly why I contributed to Linux Journal. I wanted to share what I had learned about Linux, and hoped others would enjoy my contributions.

So before the Linux Journal website goes dark, I wanted to share a few articles I wrote for them. Here you are:


Looks like Linux Journal was saved at the last minute by investors! From the article:
In fact, we're more alive than ever, thanks to a rescue by readers—specifically, by the hackers who run Private Internet Access (PIA) VPN, a London Trust Media company. … In addition, they aren't merely rescuing this ship we were ready to scuttle; they're making it seaworthy again and are committed to making it bigger and better than we were ever in a position to think about during our entirely self-funded past.

Saturday, December 23, 2017

Top ten in 2017 (part 2 of 2)

Following up from part 1, here's the rest of my favorite blog articles from this year:

6. Debian and GNOME usability testing
Intrigeri emailed me to share that "During the Contribute your skills to Debian event that took place in Paris last week-end, we conducted a usability testing session" of GNOME 3.22 and Debian 9. They have posted their usability test results at Intrigeri's blog: "GNOME and Debian usability testing, May 2017." The results are very interesting and I encourage you to read them! Here's an overview.
7. FreeDOS is 23 years old
In the 1980s and early 1990s, I was a huge DOS nerd. I loved DOS, and used it for everything. I wrote all my class papers in WordPerfect or shareware Galaxy Write on MS-DOS, and did all of my physics lab analysis using the As-Easy-As shareware spreadsheet. I just though DOS was a great little operating system. So I wasn't pleased when Microsoft said they were going to "kill" MS-DOS with the next release of Windows (Windows95). In June 1994, I announced an open source software project to create our own compatible implementation of DOS, which became the FreeDOS Project. In June 2017, FreeDOS turned 23 years old. See also our free FreeDOS ebook.
8. A look back at Linux 1.0
The Linux kernel turned 26 years old this year. To celebrate, I installed one of the first true Linux distributions: SoftLanding Systems Linux 1.03, featuring the then-new Linux 1.0 kernel. I wrote about it on Great to go back to explore what Linux looked like in 1994.
9. How I put Linux in the enterprise
I used to work in higher ed. In the late 1990s, we moved to a new student records system. We created an "add-on" web registration system, so students could register on-line—still a new idea in 1998. But when we finally went live, the load crushed the web servers. No one could register. We tried to fix it, but nothing worked. Then we had the idea to move our web registration to Linux, which rescued our failing system. I wrote about the experience on, and shared some lessons you can apply to your own Linux migration.
10. Reflection on trip to Kiel
This summer, I attended the Kieler Open Source und Linux Tage in Kiel, Germany. I shared two presentations: a history of the FreeDOS Project, and how to do usability testing in open source software. Here is my summary of that trip.

And here's looking forward to a great 2018!

Saturday, December 16, 2017

Top ten in 2017 (part 1 of 2)

It's been a great year in the usability of open source software. As I look back on the last twelve months, I thought it would be interesting to highlight a few of my favorite blog posts from the year. And here they are, in no particular order:

1. The importance of the press kit
In December 2016, we released FreeDOS 1.2. Throughout December and into January, FreeDOS was the subject of many many articles in tech press, magazines, websites, and journals. I credit our press kit, which made it really easy for anyone to write an article about FreeDOS. In this essay, I explain how we created our press kit, and the features your open source software press kit should contain so journalists can write about you.
2. Good usability but poor user experience
I like to remind people that usability is not the same as user experience. They really are two different concepts. Usability is about making software that real people can use to do real tasks in a reasonable amount of time. User experience is more about the emotional response users have when they use the software. Often, programs that have good usability will have a positive user experience, and vice versa. But it's possible for a program to have good usability and a negative user experience. Here's one example.
3. I can't read your website
The current trend in website design seems to be grey text on a light background. That's really hard for most people to read. And your small font sizes aren't helping, either. Here are a few examples of the same stanza of text in different styles. See also Calculating contrast ratios of text and The readability of DOS applications as interesting followup.
4. Screencasts for usability testing
When you're moderating a usability test, you may ask your testers to use the "speak aloud" protocol, where they say out loud what they are trying to do. If they are looking for a Print button, they should say "I'm looking for a Print button." As the tester works through the usability test, you might take notes about what the tester is doing, and where they are "looking" with their mouse. An easier way to track this is to record a screencast, for later playback. Here's an example in GNOME.
5. How many testers do you need?
Usability testing in open source software isn't that hard. But when I talk about how to do a usability test in open source software, most people ask me "How many testers do I need?" It turns out that you don't need that many people. The short answer is "about five."

I'll share part two of my top-ten list next week!

Sunday, December 10, 2017

The art of the usability interview

During a usability test, it's important to understand what the tester is thinking. What were they looking for when they couldn't find a button or menu item? During the usability test, I recommend that you try to observe, take notes, capture as much data as you can about what the tester is doing. Only after the tester is finished with a scenario or set of scenarios should you ask questions.

But how do you ask questions in a way to gain the most insight? Asking the right questions can sometimes be an art form; it certainly requires practice. A colleague shared with me a few questions she uses in her usability interviews, and I am sharing them here for your usability interviews:

Before starting a scenario or set of scenarios:

  • What are three things you might do in this application?
  • What menu options do you see here and what do you think they do?
  • What might you do on this panel?
  • What is your first impression of the application?
  • What do these icons do? What do they represent?

After finishing a set of scenarios:

  • Who do you think the application was created for?
  • How easy did you think it was to get around the application?
  • If you could make one change to the application, what would it be?
  • Is there a feature you think is missing?
  • Do you remember any phrases or icons that you didn't understand?

The goal is to avoid leading questions, or any questions that suggests a "right" and "wrong" answer.

Saturday, November 18, 2017

Happy birthday to Fortran!

A recent article reminded me that the Fortran programming language is now sixty years old! This is a major milestone. And while I don't really write Fortran code anymore, the article was a great reminder of my early use of Fortran.

My first compiled language was Fortran. I was an undergraduate physics student at the University of Wisconsin-River Falls, and as part of the physics program, every student had to learn Fortran programming. Since this was the very early 1990s, we used FORTRAN 77 (the new capitalization of "Fortran" would be established with Fortran 90, a few years later).

We learned FORTRAN 77 so could do numerical analysis, or other programmatic analysis of lab data. For example, while spreadsheets of the era could calculate a linear fit to x-y data, including standard deviations, we could not fit polynomials to nonlinear data. But given a maths textbook, you could write your own program in FORTRAN 77. I wrote many programs like this throughout my undergraduate career.

As a research intern at a national lab between my junior and senior years, my mentors discovered I knew FORTRAN. So I got the assignment to port a FORTRAN IV program to FORTRAN 77 (Fortran 90 had recently been defined, and the lab didn't have the compiler yet). It was my first programming "job" and through experience I realized I wanted a career in IT rather than physics research.

I also taught myself the C programming language, and thereafter switched to C when I needed to write a program. I haven't needed to write Fortran code since then.

The last time I wrote anything in Fortran was a few years ago. At the time, I read an article about a proposed proof to the Collatz conjecture: the so-called "hailstone" sequence. From Slashdot: "A hailstone sequence starts from any positive integer n the next number in the sequence is n/2 if n is even and 3n+1 if n is odd. The conjecture is that this simple sequence always ends in 1. Simple to state but very difficult to prove and it has taken more than 60 years to get close to a solution."

I hadn't heard of the hailstone sequence before, but I thought it was an interesting problem. I could have easily written this program in C or even Bash, but I used the opportunity to return to my roots with Fortran. I created a simple FORTRAN 77 program to iterate the hailstone sequence. To celebrate Fortran's milestone birthday, I'd like to share my program with you:

C     IS 3N+1. ITERATE.

 10   PRINT *, 'Enter starting number (any positive integer):'
      READ *, N

C      PRINT *, 'You entered: ', N

      IF (N.LT.1) THEN
         PRINT *, 'You must enter a positive integer'
         GOTO 10


      PRINT *, N

      ITER = 0

 20   IF (MOD(N,2).EQ.0) THEN
         N = N / 2
         N = (3 * N) + 1

      ITER = ITER + 1

      PRINT *, N
      IF (N.NE.1) GOTO 20

      PRINT *, 'Number of iterations: ', ITER


This program doesn't demonstrate the best programming practices, but it does represent many FORTRAN 77 programs. To illustrate, allow me to walk you through the code:

First, FORTRAN code was originally written on punched cards. The first FORTRAN used columns to understand the program listing. FORTRAN 77 programs used the same column rules:

  • If a C or * in column 1, the line is a comment
  • Program labels (line numbers) are in columns 1–5
  • Program statements begin on column 7, but cannot go beyond column 72
  • Any character in column 6 will continue the line from the preceding line (not used here)

While you could (and should) declare variables to be of a certain type, FORTRAN 77 used a set of implicit rules to assign variable types: all variables starting IN are assumed INTEGER, and variables starting with other letters are declared REAL (floating point).

My program uses only two variables, N and ITER, which are both integer variables.

FORTRAN 77 is a simple language, so you should be able to figure out what the program is doing based on those rules. I'll add a note about the code starting with line label 20. FORTRAN 77 doesn't have a do-while loop concept, so you end up constructing your own using a label, IF, and GOTO.

And that's what happens starting at label 20. The program begins a loop iteration, following the rules of the hailstone sequence: for each positive integer n the next number in the sequence is n/2 if n is even and 3n+1 if n is odd. After updating the ITER iteration count and printing the current value of N, the program continues to loop back to line label 20 (using GOTO) until N reaches 1.

When the loop is complete, the program prints the number of iterations, and exits.

Here's a sample run:

 Enter starting number (any positive integer):
 Number of iterations:           14

Happy birthday, Fortran!