Monday, October 15, 2018

Making a first contribution in Outreachy usability testing

If you want to join us in GNOME usability testing as part of the upcoming cycle in Outreachy, you'll need to make a first contribution as part of your application process. Every project in Outreachy asks for a first contribution; this is a requirement in Outreachy.

Don't make too big of a deal about your first contribution in usability testing. We don't expect interns to know much about usability testing as they enter the internship. Throughout the internship, you'll learn about usability testing. So for this first contribution, we set a low bar.

GNOME is a desktop system, so the GNOME programs would be part of the desktop system. If you have installed a Linux distribution with the GNOME desktop, you can pick one or two GNOME programs that come installed as part of GNOME, and do a usability test on them. (If you haven't installed a Linux distribution, you can easily do so inside a PC emulator or virtual machine such as VirtualBox and install a desktop-focused Linux distribution like Fedora Workstation.)

Some GNOME programs you might pick from include:

  • gedit (GNOME text editor)
  • GNOME Web
  • GNOME Files
  • GNOME Software
  • GNOME Notes
  • Evince (GNOME PDF viewer)
  • GNOME Calendar
  • GNOME Photos

Or if you have a favorite GNOME program, you can do a usability test on that too.

A short usability test of 5 scenario tasks (I suggest 3 tasks for one program, and 2 tasks for another program) and 5 testers is a good first contribution. (Five testers may sound like a lot, but you can do your usability test with friends and family, which is completely valid.)

Here are some resources showing some usability test results with the above programs:

You can search for "scenario tasks" on the blog to help you write scenario tasks. Some of the blog articles there actually list some scenario tasks you can use, such as Ciarrai's first contribution from 2016 (skip ahead to Appendix/Scenarios for the scenario tasks Ciarrai used in their usability test contribution; you can just copy from there and that's fine). If you need help, let me know.

When you've done your usability test contribution, email me and we can arrange a conversation or discuss over email.

Sample Scenario Tasks

Here are six scenario tasks for gedit and four scenario tasks for GNOME Files. Feel free to pick and choose the tasks that you want to use in your usability test first contribution.

Note that the first scenario task for GNOME Files requires creating a file before the test. Don't forget to do that.

gedit (GNOME text editor)

1. You need to type up a quick note for yourself, briefly describing an event that you want to remember later. You start the Gedit text editor (this has been done for you).

Please type the following short paragraphs into the text editor:
Note for myself:

Jenny and I decided to throw a surprise party for Jeff, for Jeff's birthday. We'll get together at 5:30 on Friday after work, at Jeff's place. Jenny arranged for Jeff's roommate to keep him away until 7:00.

We need to get the decorations up and music ready to go by 6:30, when people will start to arrive. We asked everyone to be there no later than 6:45.
Save this note as party reminder.txt in the Documents folder.

2. After typing the note, you realize that you got a few details wrong. Please make these edits:

  • In the first paragraph, change Friday to Thursday.
  • Change 5:30 to 5:00.
  • Move the entire sentence Jenny arranged for Jeff's roommate to keep him away until 7:00. to the end of the second paragraph, after no later than 6:45.

When you are done, please save the file. You can use the same filename.

3. Actually, Jeff prefers to go by Geoff, and Jenny prefers Ginny. Please replace every occurrence of Jeff with Goeff, and all instances of Jenny with Ginny.

When you are done, please save the file. You can use the same filename.

4. You'd like to make a copy of the note, using a different name that you can find more easily later. Please save a copy of this note as Geoff surprise party.txt in the Documents folder.

For the purposes of this exercise, you do not need to delete the original file.

5. You decide the text in the editor is difficult to read, and you would prefer to use a different style of text. Please change the text to DejaVu Sans Mono, 12 point.

6. You decide the black-on-white text is too bright for your eyes, and you would prefer to use different colors. Please change the colors to the Oblivion color scheme.


1. Yesterday, you re-organized your files and you don’t remember where you saved the copy of one of the articles you were working on. Please search for a file named The Hobbit.

2. Files and folders are usually displayed as icons, but you can display them in other ways too. Change how the file manager displays files and folders, to show them as a list.

3. You don’t have your glasses with you, so you aren’t able to read the names of the files and folders very well. Please make the text bigger, so it is easier to read.

4. Please search for a folder or a file that you recently worked on, maybe this will help you find the lost article.

Tuesday, October 9, 2018

Usability testing with Outreachy

I've volunteered with Allan and Jakub to mentor more GNOME usability testing in the next cycle of Outreachy, from December 4, 2018 to March 4, 2019. Outreachy expressly invites applicants from around the world who are women (both cis and trans), trans men, and genderqueer people.

Interns will work with the GNOME team and mentor(s) to do usability testing on GNOME. The goal is to perform several cycles of usability testing on prototypes of new designs, and provide usability testing results and feedback to the GNOME team so a new iterative design can be updated based on those results. We would like to use a "test what you've got" approach where we set up a testing schedule, and the intern tests whatever prototype or model is ready at that time. So if "test day" is Thursday, we could nail down what to test by Monday, and have the intern post results on Friday or the weekend.

What you need to know

You don't need to know usability testing to intern with us! We'll start the internship with a few weeks of "usability 101" with the mentor to learn about usability testing and usability processes, including how to lead a usability test. After the first few weeks, interns should expect to learn as they go, or "learn by doing."

This "learn by doing" approach will help you gain practical experience about usability testing. By the end of the internship, you will understand usability testing, and why it is important in open source software (this applies to any open source software project).

As an intern, you can have a direct impact on the GNOME desktop! Your results will help us improve the next versions of GNOME, and make GNOME easier for everyone to use.

I'll also note that in previous cycles of Outreachy, many of the interns have done such great work that I co-authored articles with them. If your tests are successful and generate useful results, we may co-author an article with you, and submit it to a technology/open source magazine or news website, or (non-academic) journal. That's a big bonus to your resume!

How to start

If you're interested in joining us for GNOME usability testing, you first need to apply for an internship at Outreachy. You'll also need to make a first contribution.

You can do your first contribution by performing a usability test of your own, using GNOME, since that's the topic of the usability testing internship. You can pick one or a few programs from GNOME, and do a total of ten scenario tasks.

When you've finished your usability test, generate a heat map of your results, then write a brief summary about the experience. This is not a formal paper, it's something you would write on a blog or send in an email. Please use an informal voice here; imagine you are explaining your test to a friend. Email your summary to me ( in OTF or PDF format, and I'll review the results with you. Or if you prefer, you can publish your results on your blog and email the URL to me.

Friday, September 28, 2018

Open source tools I used to write my latest book

I first used and contributed to Free software and open source software in 1993, and since then I've been an open source software developer and evangelist. I've written or contributed to dozens of open source software projects, although the one that I'll be remembered for is the FreeDOS Project, an open source implementation of the DOS operating system.

I recently wrote a book about FreeDOS. Using FreeDOS is my celebration of the 24th anniversary of FreeDOS. This is a collection of how-tos about installing and using FreeDOS, essays about my favorite DOS applications, and quick-reference guides to the DOS command line and DOS batch programming. I've been working on this book for the last few months, with the help of a great professional editor.

Using FreeDOS is available under the Creative Commons Attribution (cc-by) International Public License. You can download the EPUB and PDF versions at no charge from the FreeDOS e-books website. (There's also a print version, for those who prefer a bound copy.)

The book was produced almost entirely with open source software. I'd like to share a brief insight into the tools I used to create, edit, and produce Using FreeDOS.

Google Docs
This was the only tool that wasn't open source software. I uploaded my first drafts to Google Docs so my editor and I could collaborate. I'm sure there are open source collaboration tools, but the ability for two people to edit the same document at the same time, comments, edit suggestions, change tracking—not to mention the use of paragraph styles and the ability to download the finished document—made Google Docs a valuable part of the editing process.
I started on LibreOffice 6.0 but I finished the book using LibreOffice 6.1. I love LibreOffice's rich support of styles. Paragraph styles made it really easy to apply a style for titles, headers, body text, sample code, and other text. Character styles let me modify the appearance of text within a paragraph, such as inline sample code or a different style to indicate a filename. Graphics styles let me apply certain styling to screenshots and other images. And page styles allowed me to easily modify the layout and appearance of the page.
My book includes a lot of DOS program screenshots, website screenshots, and FreeDOS logos. I used the GIMP to modify these images for the book. Usually this was simply cropping or resizing an image, but as I prepare the print edition of the book, I'm using the GIMP to create a few images that will be simpler for print layout.
Most of the FreeDOS logos and fish mascots are in SVG format, and I used Inkscape for any image tweaking here. And in preparing the PDF version of the ebook, I wanted a simple blue banner at top of the page, with the FreeDOS logo in the corner. After some experimenting, I found it easier to create an SVG image in Inkscape that looked like the banner I wanted, and pasted that into the header.
While it's great to use GIMP to do the fine work, sometimes it's just faster to run an ImageMagick command over a set of images, such as to convert into PNG format or to resize images.
LibreOffice can export directly to EPUB format, but it wasn't a great transfer. I haven't tried creating an EPUB with LibreOffice 6.1, but LibreOffice 6.0 didn't include my images. It also added styles in a weird way. I used Sigil to tweak the EPUB file and make everything look right. Sigil even has a preview function so you can see what the EPUB will look like.
Because this book is about installing and running FreeDOS, I needed to actually run FreeDOS. You can boot FreeDOS inside any PC emulator, including VirtualBox, QEMU, GNOME Boxes, PCem, Bochs. But I like the simplicity of QEMU. And the QEMU console lets you issue a screendump in PPM format, which is ideal for grabbing screenshots to include in the book.

And of course, I have to mention running GNOME on Linux. I use the Fedora distribution of Linux.
This article originally appeared on as 6 open source tools for writing a book.

Wednesday, August 22, 2018

Getting back into Outreachy

Outreachy is a great organization that helps women and other minorities get involved in open source software. (Outreachy was formerly the GNOME Outreach Program for Women.) I've mentored several cycles in Outreachy, doing usability testing with GNOME. I had a wonderful time, and enjoyed working with all the talented individuals who did usability testing with us.

I haven't been part of Outreachy for a few years, since I changed jobs. I have a really hectic work schedule, and the timing hasn't really worked out for me. Outreachy recently posted their call for participation in the December-March cycle of Outreachy. December to March should be a relatively stable time on my calendar, so this is looking like a great time to get involved again.

I don't know if GNOME plans to hire interns for the upcoming cycle of Outreachy, at least for usability testing. But I am interested in mentoring if they do.

Following conversations with Allan Day and Jakub Steiner, from GNOME Design, I'm thinking about changing the schedule we would use in usability testing. In previous cycles, I set up the schedule like a course on usability. That was a great learning experience for the interns, as they had a ramp-up in learning about usability testing before we did a big usability project.

But Allan and I would like to get interns involved more quickly. Also, Allan would prefer to have testing be more integrated to a current design project. Allan has a great point in saying, "rather than releasing something and having it tested weeks or months later, we need to be testing what we are working on right now."

My idea for the next cycle is to accelerate usability testing! I would imagine restructuring the internship so applicants would do a "crash course" in usability concepts the first week, then start doing usability tests immediately after that. Learn by doing!

For a 13 week internship, I imagine an intern or interns could spend almost the whole time leading usability tests, especially focusing on "you need five testers for an iterative process" so they are doing basically the same test throughout the internship, against different iterations of different designs. That would provide more immediate feedback to designs you are working on at the time.

A possible schedule could be:
  1. Quick study of usability testing background and methods
  2. Review test needs with Design Team; plan test #1
  3. Execute test #1
  4. Discuss results with Design Team
  5. Plan test #2
  6. Execute test #2
  7. Discuss results with Design Team
  8. Plan test #3
  9. Execute test #3
  10. Discuss results with Design Team
  11. Plan test #4
  12. Execute test #4
  13. Discuss results with Design Team; wrap-up

Based on that schedule, we could fit 4 usability test iterations in 13 weeks. We might do as many as 5 if things accelerate toward the end, such as shorter turnaround in refining the design. This depends on the time required to generate a new design based on the input of the usability tests.

The key would be to connect the design process and timeline to the internship timeline. And then to be realistic in testing. For example, we might have the intern do a paper prototype test one week, then spend the next week discussing results and figuring out the next iteration, and the intern does another paper prototype test, etc.

Paper prototypes are probably the fastest to turn around, because they don't require coding. But if there's a working interface or some animatic, the intern could do usability tests based on iterations of that.

For a simpler paper prototype, a more aggressive schedule could be:
  1. Quick study of usability testing background and methods
  2. Review test needs with Design team; plan test #1
  3. Execute test #1
  4. Discuss results with Design Team; plan test #2
  5. Updated prototype; execute test #2
  6. Discuss results with Design Team; plan test #3
  7. Updated prototype; execute test #3
  8. Discuss results with Design Team; plan test #4
  9. Updated prototype; execute test #3
  10. Discuss results with Design Team; plan test #5
  11. Updated prototype; execute test #3
  12. Discuss results with Design Team; plan test #6
  13. Wrap-up

But that may not be realistic, even for a paper prototype. There's still logistical issues, such as finding test volunteers. We'll have to adjust the schedule as we go. I think the thing to remember is we'd target at least 4 and maybe 6 usability tests during the Outreachy cycle.

If you're interested in participating in Outreachy, the anticipated schedule is:

Sept. 10, 2018 Applications and the eligibility check opens. Applicants can see and apply to listed projects.
Oct. 2, 2018 Last date for new mentoring community listings
Oct. 9, 2018 Last date for new internship project listings
Oct. 23, 2018 Application deadline
Oct. 30, 2018 Late application deadline
Nov. 5, 2018 Deadline for mentors to select interns
Nov. 14, 2018 Accepted interns announced
Dec. 4, 2018 to March 4, 2019 Internships period

Tuesday, July 31, 2018

The next step in open data is open source

Governments at all levels are moving to embrace open data, where governments share public data proactively with citizens. Open data can be used, reused, mixed, and shared by anyone.

For example, The US Government has an open data portal that publishes data on various topics, including agriculture, education, energy, finance, and other public data sets. Where I work (Ramsey County, Minn.) we established an open data portal that shares expenses and other public data about the county that users can access in different views.

Through open data, governments become more transparent. We have seen this in several instances. The Oakland Police Department used a 2016 open data study from Stanford University to address racial bias in how officers behave towards African Americans versus Caucasians during routine traffic stops. In 2017, Steve Ballmer launched the USAFacts website that uses open data to reveal how governments spend tax dollars to benefit citizens. Also from 2017, Los Angeles, California’s comprehensive “Clean Streets LA” initiative uses open data to assess and improve the cleanliness of public streets.

Governments at all levels have recognized that open data feeds citizen engagement. By sharing data in a way that encourages citizens to remix and transform open data to provide new insights, governments and citizens move closer together. According to the Open Data Barometer, many municipalities already provide open data for geographic information, transportation, trade, health, and education, with a mix of other open data sets. Those governments that do not yet provide an open data portal are likely working to provide one.

What is the next step beyond open data? After sharing data, what is the next evolution for governments to engage with citizens?

I believe that next step is open source. Where we provide government data sets for anyone to view, adapt, and remix, we need to offer government source code for others to view, adapt, and remix.

While there is a balance to be made in moving to government open source, the default should be to share as much source code as possible. Just as governments found a balance in providing open data, government open source must consider what software can and cannot be shared as open source software. In the same way that some data needs to remain private because it identifies individuals or because it contains certain nonpublic data, some government source code may need to remain “closed source.”

In adopting government open source, we should follow the open data model. The default in government open data is to share as much data as possible, to release public data for public consumption. That should be the same with government open source. In cases where government application development teams write custom software, we should make as much of our source code available to the public as possible.

Some government agencies are already moving to an open source model, and that is good. In August 2016, US Chief Information Officer Tony Scott and US Chief Acquisitions Officer Anne Rung issued instructions for federal departments and agencies “to release at least 20 percent of new custom-developed code as Open Source Software (OSS) for three years.” In support of this directive, the US Government established an open source portal at to share government source code under the Creative Commons Zero (CC0) and other open source software licenses. Via the open source portal, users can download open source projects, toolkits, installer profiles, online forms, JavaScript widgets, and other code samples.

The challenge we face in moving to government open source is not technical, but cultural. Many governments have relied on proprietary or “closed source” software for decades. Through the lens of these government IT departments, all software is proprietary. This view often extends to software that is custom-developed by municipalities.

It will take a culture shift for governments to release their source code for public access. But governments faced that same culture shift in moving to open data, and we overcame that cultural inertia. We can do the same with open source.

The benefits to adopting a government open source model are many. Like open data, government open source will provide additional transparency to citizens. Users will be free to investigate the source code, and re-use it for other purposes. Motivated citizen developers may modify the source code to fix bugs or add new features, and contribute those improvements back to the government. This last example is the ideal model, providing a feedback loop of engagement where the government partners with its citizens to improve services.

I believe the next iteration from open data is open source. I encourage government Chief Information Officers at all levels to investigate how software created by government application development teams can be made available to outside users. Use the US open source portal as a model to set goals and measure progress. Finally, establish relationships with partners most likely to engage in government open source, including local universities and businesses.

Through open data, governments became more transparent to citizens. With government open source, Chief Information Officers have an opportunity to lead the next evolution in citizen engagement. Through open source, we can take government transparency to the next level.

Monday, July 30, 2018

What an icon says about you

Icons are an important part of modern computing. We see icons everywhere, from actions on the desktop to navigation in an application to action icons on a website. You can't go long without seeing an icon.

When I first started doing usability testing, I focused on icons. How will users perceive the function exposed by a single button, especially if that button is an icon? Icons can be abstract or representative. For example: in a word processing program, what icon would you click to print a document? The icon you have in mind probably looks something like this: (*wikimedia)

That is a fairly artistic rendering of a printer. But how simple can you make the printer icon, and still recognize it as a printer? (*wikimedia)

This high contrast icon is still recognizable as a printer to many users. Especially when presented on a toolbar with other icons, usually on the left end of the toolbar near the new-file and open-file and save-file icons, you'd probably recognize this as a printer icon. (In this case, certain icons can be learned based on association. In most applications, the "Print" action is usually near the "New File" and "Save File" actions.)

Branding is another form of an icon. You can associate a product or a brand through its icon. You can immediately recognize certain products through their icons, from the Nike "swoosh," the McDonald's "M," the Apple "apple," and the AT&T "Death Star." Open source software has its own recognizable icons, including Tux the Penguin, the GNU gnu, and "Beastie" the BSD Daemon.

Once upon a time, the Netscape "N" was instantly recognizable as the web browser's brand icon. Later, the organization spun off into Mozilla, represented by a less memorable big red dragon head. Finally, we have Firefox, represented by a stylized fox wrapped around a small globe. The fox icon has represented the Firefox brand for years, although now the Firefox organization wants to change the brand icon.

From an article in Venture Beat: "For most people, Firefox refers to a browser, but the company wants the brand to encompass all the various apps and services that the Firefox family of internet products cover," and "The fox with a flaming tail 'doesn't offer enough design tools to represent this entire product family'." The Firefox name will remain, but the branding will change.

This is a tall order. Changing any well-known branding for an organization or a product family is tough. Will users continue to recognize the product as one they have used before? Or will the new branding suggest to users that everything has changed, and the product they've used and known for years has now flipped to something completely different?

Firefox has proposed two possible branding options:

Venture Beat describes the icons as follows: "The first icon is the Firefox masterbrand icon, an umbrella under which all the product lines will live" and "The next [two] lines, in order, are as follows: general purpose browser icons (including Developer Edition and Nightly colors), singularly-focused browser icons (Firefox Focus and Firefox Reality)"and the last five icons are "new applications and services."

First, let me make some guesses about the new applications and services, represented by the five icons in the last two lines. I'm not sure what the first one represents, but I think the second is some kind of photo service, perhaps something like Instagram or maybe a static photo hosting service like Flickr. At least, that's what the green icon suggests to me. The third icon is clearly some kind of password management service, like LastPass or 1Password; the hexagonal "lock" icon is a clearer representation of a password service.

I'm not sure what the last two are. These are too abstract for me to interpret what they mean, but perhaps the last icon is some kind of interaction service, such as a private chat application.

Jumping back the the rest of the list. The first line of icons (the standard web browser, the in-development web browser, and the nightly-build web browser) are still recognizable to me. I don't use the Firefox Developer Edition or the nightly builds, but the different colors in those two icons suggest to me that they are not the standard web browser.

The System 1 icons are more familiar to me, compared to the current Firefox logo. I think if Firefox used the first row icons from System 1, their users would be satisfied that the browser product isn't completely new.

The second row of icons (including Firefox Focus and Firefox Reality) are a mix for me. I'm not sure what Firefox Focus is, based on this image. The Firefox Focus web page describes Focus as a "dedicated privacy browser with tracking protection and content blocking." I don't get that from either the System 1 or System 2 icons. Similarly, the icon for Firefox Reality doesn't suggest what Reality does for me. The Firefox blog describes Reality as a "cross-platform browser for mixed reality." I don't get "augmented reality" from any of the icons in System 1 or System 2.

What about the "parent" logo, the Firefox masterbrand icon at the top? For me, the System 2 icon better represents the "Firefox" family of products. I get the abstract fox icon from System 1, but I think it's too abstract. When I first saw the icon, I assumed it was a red book icon, but the designer had set the alpha channel to be too transparent, so the yellow diamond underneath the book was visible. (And now you probably can't un-see the "book" icon. Sorry.)

But negative space means something, too. As humans, we naturally look for negative space, and read a lot into what shapes we find there. For example, most people see a rightward arrow in the FedEx logo, suggesting speed.

Applying this negative space visual concept to the Firefox logos, my mind naturally tries to find meaning in the negative space of the System 2 icons. I'm less bothered by the negative space of the System 2 masterbrand icon, because the negative space forms a rough circle. But look at the first row of icons. What shape is that? I'm confused.

My recommendation to Firefox is to use the System 2 masterbrand icon, but use the first row of the System 1 icons to represent the web browser. Use the green "Photos" icon (or something like it) and the hexagonal "lock" icon for the Password application.

But go back to the drawing board for Focus and Reality, and the three other extra applications. I'm not sure what those represent, so I think they need more work.

Finally, I encourage Firefox to do a quick usability test. They may have done this already to create this first set of design concepts. Find a bunch of users, and show them the icons in isolation. For one set of testers, don't provide context. "What does this icon mean to you?" Let the user give a reply without knowing what application the icon might be used to represent. For another set of testers, provide some context, but don't indicate which icon is intended for which application. "Which icon represents a web browser?" "Which icon represents a Photos application?" You can probably do this with ten testers in each group, but I'd recommend a larger sample such as twenty testers in each group.

Compare your results. Do the unprompted testers associate the same icon with the same application as the prompted users? If the testers have strong agreement, then you've identified icons that most users will recognize for the purpose you intend.

Thursday, July 5, 2018

First impressions of PureOS

My new Librem 13 arrived yesterday, and it was my first opportunity to play around with PureOS. I thought I'd share a few thoughts here.

First, PureOS uses GNOME for the desktop. And not that it matters much to usability, but they picked a beautiful default desktop wallpaper:

Because it's GNOME, the desktop was immediately familiar to me. I've been a GNOME user for a long time, and I work with GNOME in testing usability of new features. So the GNOME desktop was a definite plus for me.

It's not a stock GNOME, however. PureOS uses a custom theme that doesn't use the same colors as a stock GNOME. GNOME doesn't use color very often, but I noticed this right away in the file manager. Clicking on a navigation item highlights it in a sort of rust color, instead of the usual blue.

Overall, I thought PureOS was okay. It doesn't really stand out in any particular way, and I didn't like a few choices they made. So in the end, it's just okay to me.

However, I did run into a few things that would seem odd to a new user.

What's that file icon?

When I clicked on Activities to bring up the overview, I was confused about what looked like a "file" icon in the dock.

I understood the other icons. The speaker icon is Rhythmbox, my favorite music application. The camera icon is clearly a photo application (GNOME Photos). The blue file cabinet is the GNOME file manager. And the life ring is GNOME's Help system (but I would argue the "ring buoy" icon is not a great association for "help" in 2018; better to use an international circle-"?" help symbol, but I digress).

Two icons seemed confusing. The "globe" icon was a little weird to me, but I quickly realized it probably meant the web browser. (It is.)

But the one that really confused me was the "file" icon, between the camera and the file manager icons. What was a "file" icon doing here? Was it a broken image, representing an icon that should exist but wasn't on the system? I didn't need to click on it right away, so I didn't discover until later that the "file" icon is LibreOffice. I hadn't seen that icon before, even though that's actually the LibreOffice icon. I guess I'm used to the LibreOffice Writer or LibreOffice Calc icons, which is what I launch most of the time anyway.

No updates?

I wanted to install some extra applications, so I launched GNOME Software. And from there, I realized that PureOS didn't have any updates.

Really? Linux gets updates all the time. Even if Purism updated the OS right before shipping my laptop to me, there should have been a few updates in the time FedEx took to deliver the laptop. But maybe Purism is slow to release updates, so this could be expected. It seemed odd to me, though.

Where's the extra software?

Once I was in GNOME Software, I realized the "store" was quite empty. There's not much to choose from.

If this were my first experiment with Linux, I'd probably think Linux didn't have very many applications. They don't even have the Chromium or Firefox web browsers available to install.

But really, there are a ton of applications out there for Linux. It's just the packages that PureOS makes available through GNOME Software seems pretty limited.

The terminal is broken?

Finally, I'll mention the terminal emulator. PureOS doesn't use the standard GNOME Terminal package, but rather the Tilix terminal emulator. It's a fine terminal, except for the error message you see immediately upon launching it:

I wondered why a pre-configured operating system, aimed at the Linux community, would ship with a broken configuration. I clicked on the link shown, and basically the fix is to set Tilix as a login shell, or to do some other setup steps.

Presenting an error message the first time the user runs a program is very poor usability. I haven't run it yet, so I assume the program should be using defaults. Everything should be okay the first time I run the program. I assume things will "just work." Instead, I get an error message. If I were a novice user, this would probably turn me off PureOS.


In the end, PureOS is a GNOME desktop that runs well. But with a few confusing issues or problems here and there, it doesn't exactly stand out. To me, PureOS is just "okay." It's not bad, but it's not great.

I think my biggest concern as a longtime Linux user is that the distribution doesn't seem to have updates. I'm curious to hear from any PureOS users how often updates are pushed out. I run Fedora Linux, and I get updates pretty regularly. What should I have expected on PureOS?

Tuesday, July 3, 2018

Librem 13: Review

In May, I decided it was finally time to replace my old laptop. Technically, there wasn't anything wrong with my old laptop (Lenovo Thinkpad X1 Carbon, first-gen) but after six years, I thought it was time to replace it.

Of course, I wanted my new laptop to only run Linux. After some searching, I decided on the Librem 13, from Purism. Purism laptops are designed and built for Linux, and I wanted to support a hardware vendor that aimed squarely at the Linux and Free/open source software market.

Unfortunately, I had a few problems with the Librem laptop. The Intel on-board video card "flickered" when I used the internal display, and sometimes would go to "sleep" (not sure it was really in sleep mode or just shut itself off, but when the screen goes black and the laptop is still running, that feels like "sleep" to me). I contacted Purism, and they suggested this was a hardware fault they've seen on some laptops, and they gave me an RMA to return it for repair.

A tech later emailed me to say they couldn't repair the laptop, so they sent me a new one instead. My new Librem 13 arrived today, and it's great!

System information

I've highlighted the ordered specs and the system details so they are easier to compare: memorydisk, and CPU. Here's what I ordered: (copied from my order confirmation)

  • Keyboard: English (US)
  • TPM: Include
  • Memory: 16GB (1x16GB) (+$209.00) $209.00
  • Storage (M.2 SSD): 500GB (NVMe) (+$499.00) $499.00
  • Storage (2.5" SATA 3 SSD): None -$99.00
  • AC Adapter Power Plug: US
  • Wireless: Include Wireless
  • Operating System: PureOS
  • Warranty: 1 Year

I figured I'd max out the memory. I'd like this laptop to last a long time, and memory is a good investment there. Also, I swapped out the standard SATA SSD storage for a 500GB M.2 SSD storage. The prices here reflect those changes.

And the technical details: (*see note)

$ free -h
              total        used        free      shared  buff/cache   available
Mem:            15G        2.5G        5.5G        616M        7.6G         12G
Swap:          7.9G        263M        7.6G

$ cat /proc/cpuinfo |egrep '^processor|^model name'
processor : 0
model name : Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
processor : 1
model name : Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
processor : 2
model name : Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
processor : 3
model name : Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz

$ sudo fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x46f877a1

Device         Boot     Start       End   Sectors   Size Id Type
/dev/nvme0n1p1 *         2048   2099199   2097152     1G 83 Linux
/dev/nvme0n1p2        2099200 940814335 938715136 447.6G 83 Linux
/dev/nvme0n1p3      940815444 976768064  35952621  17.1G 83 Linux

First impressions

I've been using the new laptop for a few hours now, and I'm happy so far. This is a great system.
Video flicker is fixed
I'm happy to report that the video "flicker" problem is not present on this model! So that seems to have been a hardware fault, and not a driver problem. Very pleased that ended up being a fixable hardware issue.
Wrong key code for backslash and pipe
The keyboard issue is still there. The Purism laptop uses a keyboard that sends the wrong key code for the backslash key (\). The "shift" on this key is the pipe symbol (|). Try running any commands at the Linux command line, and you'll quickly run into a problem where you can't send the output of one program into another program. You need the pipe for that. Or try escaping a character at the command line, or in program code. You need the backslash for that.

This is a known issue on the Librem, but it's easy to fix. You need to run setkeycodes 56 43 to reset the correct key codes for that key system-wide. To make the fix permanent, create a new /etc/rc.d/rc.local file that is executable (I used mode 750, but anything that's executable and owned by root should do) and has these lines:

setkeycodes 56 43
exit 0

This fixes the problem each time the system boots. You don't need to do anything at the user level. Note that I have my Librem connected to an external display, and I'm using an external keyboard and mouse. This key code fix doesn't impact backslash or pipe on my external keyboard, so I'm good there.
Operating system
I did end up re-installing the operating system. When I first booted the Librem, it was using the pre-installed PureOS Linux distribution. I played with it for a while, and actually did some work online with it, then decided I'd rather run the Fedora Linux distribution that I'm used to. I'll post an article later with impressions about PureOS.
*The numbers don't match exactly, and that's expected. Note that free and fdisk display powers-of-ten Gibibytes (GiB), while the specs from Purism display powers-of-two Gigabytes (GB). So 500 GB = 466 GiB and 16 GB = 15 GiB. (see comment)
Update: I'm still having screen flicker problems. It's just not as noticeable because the first screen flicker problem was wide "bands" of what looked like static. This new screen flicker problem basically looks like thin black lines that appear randomly on the screen, but just for a moment. I didn't notice at first because I use an external display as my primary, so my laptop display was just showing the wallpaper (a dark image) and my music player. But yes, Purism confirmed this is another hardware issue, so they are replacing it. They won't have new stock until sometime in August, so I'm using my old laptop until then.

Wednesday, June 27, 2018

A few thoughts on GNOME usability

I recently learned that GNOME developers have proposed moving the application menu off the "top black bar" and into the application window. The proposal is on the GNOME Wiki at App Menu Migration.

The wiki has a few mockups of how the menus would appear. The top-level application menu would be presented as a "hamburger" icon, and any secondary menus would appear as a "three dots" icon.

I have to say that I think this would improve usability. My previous usability testing shows that users prefer menus that are obviously part of the application (think "menu bar"). The application menu in the black top bar doesn't stand out as part of the application experience.

I was never completely a fan of GNOME's decision to put actions behind the application menu. I thought it was sometimes confusing. And in usability testing, many users didn't immediately realize it exposed a menu. Once you click on the application menu, in most applications there's just an option for "Quit" (which is the same as clicking the "x" icon in the upper-right, anyway). But in multi-monitor setups, the application window might be shown on a separate monitor from the display that has the black top bar. So you lose the association between the application menu and the application itself.

Moving the application menu into the application window makes a lot of sense.

My immediate thought is that the icons could be confusing. Instead, I'd recommend a "gear" icon for the top-level application menu, and any secondary menus appear as either the "hamburger" icon or a "three dots" icon. I'd pick the gear icon because most top-level menus are where you find the Preferences. I have a slight preference for the hamburger icon, but prototype usability testing would demonstrate which one was better for the user.

I have two recommendations:

  1. Make it very clear that one button is the top-level menu, and the other button is the secondary menu. For good usability, users want to find the right icon on the first try. They don't want to hunt for the right menu icon. Users need to make an immediate decision which icon to click. And for that, the top-level menu icon needs to be obvious, and the secondary menu icon needs to be visually distinct.
  2. Be consistent in where you place the top-level menu icon and the secondary menu icon. Having learned where to find the menu icons in one GNOME application, users should be able to transfer that knowledge to another GNOME application. My personal preference is to put the top-level menu icon in the left-most position (similar to the clickable program icon menu in GNOME 2) and to put any secondary menu icons in the right-most position. For application windows that use a split view, the secondary menu icon should always be on the right of the "pane" view.

As a quick html mockup of a few title bars shows the top-level menu always the left-most icon, and the secondary menu always the right-most icon:

Application ×
<Application ×
<Application+ ×
< Applicationz ×
< App name  Detail view+ ×

My html mockup isn't perfect, but I hope you get the idea.

I think the next step is for the GNOME developers to do a few prototype usability tests. Which icon would best carry the meaning of "top-level menu" and "secondary menu"? And where do users think to look for a "top-level menu" button vs a "secondary menu" button"?

Ciarrai did a great job with their prototype usability test of the then-proposed Settings app. Ciarrai and I co-authored an article for called Usability testing for early-stage software prototypes that provides a good model for how to do prototype usability testing. And remember, you only need about five testers to get "good enough" results, if you do iterative usability tests.

A few thoughts on Windows usability

FYI: I decided to take down this post.
If you missed it, the highlights are: I've been a Linux desktop user at home since 1993, and I ran Linux on my desktop at work from 2002 until the end of 2015. At my current job, we use Windows on the desktop. There are a few things about Windows that continue to bug me: ctrl-backspace isn't the same everywhere, PrtScr acts differently to me, and no virtual desktops.

I don't want to focus too much on Windows in this blog. But I thought the usability comparison was interesting. I took down the post because I decided I want my blog to be about open source software and not talk about proprietary stuff.

Saturday, June 9, 2018

Battery on my new Librem 13

Last month, I finally bought a new laptop. My Lenovo X1 Carbon (1st gen.) still performed well, even at six years old (2012). I think that's partially because I'm running Linux, which has less bloat. CPU loads were usually fine, unless I was really pushing things. The real problem was the battery. After six years of use, the battery held a charge for less than three hours. Not bad, but annoying when I want to work all day.

Sure, I could buy a new X1 Carbon battery for less than $100, but I was also worried about the laptop failing unexpectedly, and just when I needed it. I do a fair amount of work from home (especially writing) and it would suck to have my laptop die when I was trying to get something done. So I finally decided to buy a new system.

After waffling between "do I buy a new laptop?" and "maybe I should just get a desktop," I decided on a new laptop, but with an extra monitor and keyboard that were more comfortable. And soon after that, I decided on the Librem 13, by Purism. (In case you're curious, I'm also running an ASUS VE248H 24" Full HD 1920x1080 2ms HDMI-DVI-VGA Back-lit LED Monitor, and a Perixx PERIBOARD-512 Ergonomic Split Keyboard. I bought those elsewhere.)

I don't often travel with a laptop, but when I do, I prefer to use my primary system so I don't have to keep things synced. And I wanted it to run Linux. Purism is aimed at the Linux market, and I wanted to support that. Go Purism!

My remaining question was "how to manage the battery?" I know laptop batteries don't last forever. But how should I run my laptop so the battery lasts the longest? I remembered that it's not a problem with modern batteries to leave them plugged in all the time, but then there's the heat issue. Heat will kill a laptop battery. An article on How-To Geek answered Should I Leave My Laptop Plugged In All The Time? with a kind of non-answer. There is no straight answer. From the article:
Ultimately, it’s not clear which is worse for a battery. Leaving the battery at 100% capacity will decrease its lifespan, but running it through repeated discharge and recharge cycles will also decrease its lifespan. Basically, whatever you do, your battery will wear down and lose capacity. That’s just how batteries work. The real question is what makes it die more slowly.

Laptop manufacturers are all over the place on this. Apple used to advise against leaving MacBooks plugged in all the time, but their battery advice page no longer has this piece of advice on it. Some PC manufacturers say leaving a laptop plugged in all the time is fine, while others recommend against it with no apparent reason.
I found an interesting question on the Purism discussion board providing advice on battery use. User "Uncle_Vova" recommends "never discharge it completely" and "never keep it at high states of charge (say, above 60%) at high temperatures (above 50°C)." Later in the discussion, user "mrtsolar" also advises "Keep charge between 20-80% when possible."

That pretty much matches what I had found elsewhere: all laptop batteries degrade over time, eventually all batteries will hold less charge and not last as long between charging. But there are some things you can do to extend the life of a laptop battery: don't always keep it plugged in, don't let it go all the way to zero, let its charge stay within a range, avoid heat, take the battery out (if you can) if you're going to leave it plugged in all the time (like at the office, especially if it's in a "dock").

I suppose I could have looked into a power/charging threshold. Doing this is very dependent on the system firmware. I learned via an Ask Ubuntu forum there was a feature to do this on my Lenovo laptop, but I never tried it. I just plugged the laptop into a power strip, and I turned the strip off and on when needed. That usually kept the laptop battery between 15% and 99% charged, depending on when I remembered to turn off/on the power strip.

Being lazy, I wanted a way to automate that when using my new Librem laptop. Again, I could look into a power/charging threshold for the Librem. But for less than $20, I picked up a power strip that had a timer (Century 8 Outlet Surge Protector with Mechanical Timer). Four outlets on the strip are always on, and four are connected to a built-in timer. That allows me to plug in my monitor and LED desk light to an always-on outlet, and my laptop to a timed outlet. I still turn the power strip off when I'm not using the computer, but that's a habit I've had for ages, so that's not a big deal.

The power needs for a laptop aren't that big, so I'm not worried about over-taxing the power strip. This thing is built to run high-load devices like an aquarium water pump and light, or a heat lamp for a terrarium. The Librem runs a pretty light load in comparison: about 60-80W when charging the battery, according to user "Derriell" on the Purism forum.

I'm still tweaking the duty cycle. My goal is to exercise the battery somewhere between 20% and 80%. The Librem 13 will run on battery for roughly seven to nine hours, and it takes upwards of four hours to fully recharge, so right now I have the power strip timer set at five hours "off" and three hours "on." So if I only have the power strip turned on when I'm using the computer, the laptop is running from battery for five hours, then it charges for three hours, then it's back to battery. I have to keep the total (eight hours) evenly divisible by twenty-four hours.

Maybe I'm overthinking it, but this seems a good solution to me. How do you manage the battery on your laptop? If there's a more elegant way, let me know in the comments.

Sunday, May 27, 2018

Librem 13: A few problems

I bought my old Lenovo Thinkpad X1 Carbon (1st gen.) when I entered grad school for my Master's program, in 2012. And after six years, the Thinkpad still ran well, but it was getting old, so I figured it was time for a change. I went back and forth about what kind of system should replace my laptop. I don't travel that much, so I figured a desktop would be better. And I could get a bigger screen.

After going back and forth on the decision, I decided to get a laptop. I don't often travel with a laptop, but when I do, I prefer to use my primary system so I don't have to keep things synced. Of course, I wanted my system to run Linux. Purism is aimed at the Linux laptop market, and I wanted to support that. So I bought a Librem 13.

I've had it now for about a week, and I love it now. But I'll be honest, I didn't love it right out of the box. I'd like to note two issues for folks who are thinking about getting a Librem laptop, so you aren't surprised like I was.

1. The backslash key sends the wrong key code

The Purism laptop uses a keyboard that sends the wrong key code for the backslash key (\). The "shift" on this key is the pipe symbol (|). So you know, you need these. Try running any commands at the Linux command line, and you'll quickly run into a problem where you can't send the output of one program into another program. You need the pipe for that. Or try escaping a character at the command line, or in program code. You need the backslash for that.

This is a known issue on the Librem. Every other keyboard known to man gets this right, but I guess Purism used a different keyboard.

To fix, you need to set setkeycodes 56 43 to reset the correct key codes for that key system-wide. To make the fix permanent, create a new /etc/rc.d/rc.local file that is mode 750 and has these lines:

setkeycodes 56 43
exit 0

Here's the file entry:

-rwxr-x---. 1 root root 37 May 22 18:50 /etc/rc.d/rc.local

This fixes the problem each time the system boots. You don't need to do anything at the user level. Note that I have my Librem connected to an external display, and I'm using an external keyboard and mouse. This key code fix doesn't impact backslash or pipe on my external keyboard, so I'm good there.

2. The Intel video card gives serious video flicker

When I first booted the Librem, it was using the pre-installed PureOS Linux distribution. I played with it for a while, then decided I'd rather run the Fedora Linux distribution that I'm used to. But after I'd re-installed, I quickly realized I had a problem. The laptop screen would flicker at random times.

Ah well, I figured. This is a driver issue, just do an update. Except that every time I ran an update, the laptop display went to sleep. Very annoying. In the end, I had to boot into run level 3, and run the update from text mode. The screen still flickered once in a while, but not as badly, and the display didn't go to sleep.

It turns out that this is also a known issue. Some users reported that using i915.enable_rc6=0 as a kernel option will prevent or reduce the issue. Or you can try i915.enable_psr=0. But on my Librem, neither seemed to completely fix the problem. I still get flicker on the laptop display. I'm not sure what kernel settings Purism used in the pre-installed PureOS Linux, since I wiped that when I re-installed with Fedora Linux.

The problem is likely caused in the Intel i915 power management driver. Also reported as Constant display flicker after i915 is initialised. For the Librem suggested fix, see Troubleshooting > Screen Flickering.

Interestingly, I don't get this problem when I'm using only the external display. I mentioned that I have my Librem connected to an external display, and I'm using an external keyboard and mouse. I set GNOME to only use the external display. I can still see the laptop's screen flicker at the graphical login screen (on the laptop display), but once GNOME switches to the external display, the laptop's display turns off so the problem doesn't seem to get triggered.
With those two fixes in place (rc.local, and using an external display) I'm very happy with my Librem 13. I'm effectively using it as a desktop computer. I'm hoping there's a fix for the i915 video by the time I take my next trip in October, or I'll be very unhappy.

If you know of a better solution for the i915 display flicker problem, please let me know in the comments.
Update (6/6/18): I'm still having the screen flicker problem. I reached out to Purism via Twitter, and they asked that I open a support case, which I have. They've seen this on some machines.

Update (6/9/18): I shipped back my Librem 13 today. I feel better knowing this is a hardware issue that others have seen, and that it's fixable.

Update (6/26/18): Purism has shipped my replacement laptop! I should have it in a few days.

Tuesday, May 15, 2018

Announcing Board of Directors Elections 2018

From 2016 to 2017, I was a director on the GNOME Foundation Board of Directors. This is a great opportunity for anyone working on the GNOME project. And because Board elections are coming up, I wanted to share the news.

The most important deadlines in the GNOME Board Elections are the following:
May 12
List of candidates opens.

May 24
Last day to announce candidacies, submit summary statements.

May 25
Final list of candidates.

May 26
Instructions mailed to eligible voters, voting begins.

June 9
Voting closes.
Preliminary results will be announced on June 12, with June 19 as the last day to challenge results (election becomes official).

Serving on the Board is a great way to participate in open source software. I found my time on the Board to be personally very rewarding.

Time commitments are generally a regular phone call (an hour) and attendance at GUADEC. Directors also pick up projects and to-dos from time to time.

I would submit my name again for the Board, but GUADEC falls at a time when I need to be here at the County. That's our budget presentation time, so I can either attend GUADEC or I can present my department budget to the county Board.

Saturday, May 5, 2018

A few thoughts on copyright

Every once in a while, I'll come across a discussion where someone justifies pirating a movie or popular TV show with "nothing of value was lost." Basically, these people claim that it isn't really "stealing" if the content creator (HBO, Disney, etc) keeps the original copy.

It baffles me why people say this.

I think I get where they're coming from, just not their conclusions. I think these people don't like the US copyright system. And I certainly agree that there's a lot wrong with the current US copyright laws. The Copyright Term Extension Act, a.k.a. the Sonny Bono Act, or (sometimes) the Mickey Mouse Protection Act has extended copyright terms dramatically. And that's not good.

The original US copyright system was designed so that a content creator could control the rights to their creations for a certain term, then that creation would fall into the public domain. But the Copyright Term Extension Act continues to stretch that term. From Wikipedia:
Under this Act, works made in 1923 or afterwards that were still protected by copyright in 1998 will not enter the public domain until 2019 or later. Mickey Mouse specifically, having first appeared in 1928, will be in a public domain work in 2024 or afterward (depending on the date of the product) unless the owner of the copyright releases them into the public domain before then.
And yes, that sucks.

But whether you realize it or not, copyright protection works for more than just the Big Media companies (HBO, Disney, etc). Copyright works for Free software and open source software, too. In fact, the copyleft afforded by the GNU General Public License only works because of copyright protections.

Copyright gives you, the author (or maintainer or contributor) of a software project the right to say how people can copy it. In proprietary software, they are very strict to how you can copy their software (basically, you can't). In Free software licenses, it's very liberal (in most cases, you can give it away, as long as you make the source code available).

So to say "it was only a copy, nothing of value was lost" basically says "I don't care about Free software." If you ignore copyright because you don't like how Big Media profits from copyright terms, then what's to stop someone else from ignoring your copyright on your open source software project? Because if copyright doesn't exist, then there's nothing to stop Big Software companies like Microsoft from taking Free software and making it proprietary.

Friday, April 27, 2018

Open source software reading list

A colleague recently asked what books I'd recommend about open source software. I go back a ways with open source software. I first contributed to Free software and open source software in 1993, before the term "open source software" was widely adopted.

So my list of book recommendations has some older titles on there. And that's good, because this list also provides a solid grounding for contributing to open source software.

I have to share our free (CC-BY) ebook that we published last year about the history of FreeDOS, written by our developers, contributors, and fans:

And some older books that I find interesting:

​Related to FreeDOS,​ there's Pat Villani's original 1996 book about how you would write a DOS-like operating system. It's a bit dated now (FreeDOS has changed a lot since then) but it's a good introduction to writing operating system kernels:

​Along similar lines (but less technical) is Linus Torvalds and David Diamond's 2002 book about how Linus created Linux:

I might also recommend Eric's 2001 book of essays about open source software:

Most of the contents, including the "Cathedral and the Bazaar" essay, are also available for free from Eric's website:

​I have the original paperback for this, which is now falling apart due to years of use, but O'Reilly has made Unix Text Processing (1987) available as a free ebook. This has some interesting not-necessarily-programmer stuff about how you can leverage Unix (and Linux) tools to do various things with text - including vi, ex, nroff/troff, and some awk:

​Other interesting free O'Reilly books include:

Wednesday, April 25, 2018

A gentle introduction to FreeDOS

FreeDOS is an old operating system, but it is new to many people. New users often ask, "I installed FreeDOS, but how do I use it?" If you haven't used DOS before, the blinking C:\> DOS prompt can seem a little unfriendly. And maybe scary.

So I wrote a gentle introduction to FreeDOS for It offers just the basics: how to get around and how to look at files. But it's surprising how much you can do in FreeDOS just with CD (change director) and DIR (directory listing). Learn those two commands, and you can easily become a DOS master.

Tuesday, April 24, 2018

March Madness brackets in PHP (scores)

To get ready for this year's March Madness, I updated my Bash script that filled out basketball game brackets. The new version is a PHP page that generates a bracket in a nice, formatted form that you can print out and hang on your office wall.

This made it really easy for me to participate in the office March Madness pool, even though I don't follow basketball. I'm not really a sports guy, but I like to engage with my office colleagues. It's entertaining! My script gives me a stake to follow the games, but without the emotional investment if my bracket doesn't perform well. And that's good enough for me!

But how did my March Madness brackets fare this year?

Following the standard method for How to score March Madness brackets, each round has 320 possible points, regardless of number of games. In round one, you assign ten points for each correctly selected outcome. That's eight games in each of four regions, so 8 × 4 = 32, times ten points for each contest gives 32 × 10 = 320 in each round. In round two, assign twenty points for each correct outcome. And so on. From that, the math is pretty simple.

Round 1

My Midwest bracket did really well in the first round, predicting 7 of 8 games correctly. My East region was off, only predicting 4 games correctly. West did well, with 6 games correct. My South bracket had 5 correct predictions. So that's (7 + 4 + 6 + 5) × 10 = 220.

Round 2

Things fell apart pretty quickly in my second round. My Midwest bracket had 2 correct predictions, and East had 2. My West bracket also predicted 2 games correctly, but my South had only 1 correct. Total for this round was (2 + 2 + 2 + 1) × 20 = 140.

Round 3

I was almost completely knocked out in the third round. Of all my teams, my PHP script only correctly predicted one game (Villanova). In this round, my score was 1 x 40 = 40.

Rounds 4–6

If you followed March Madness this year, you know Villanova went the distance to win the NCAA. Fortunately, my PHP script also predicted Villanova all the way to the end. For the Final Four and the championship round, I made to make my own guesses (Villanova). That makes the math very easy:

round 4: 1 × 80 = 80
round 5: 1 × 160 = 160
round 6: 1 × 320 = 320


Overall, my PHP script did pretty well. Across all rounds, my final score was 220 + 140 + 40 + 80 + 160 + 320 = 960. That's great!

Compared to an earlier version of my Bash script to fill out March Madness brackets, 960 points is excellent! In that previous iteration, I had two runs of the script, with 530 and 490 points each. In an improved version of that Bash script, a sample run netted 390 points. My 960 compares well!

Of course, the outcome of my PHP script is based on weighted guesses, so things could have gone the other way very easily. Without Villanova, my brackets would have been completely out in the third round, resulting in only 220 + 140 = 360 points. So don't use my PHP script to bet with. But my script did keep up my interest in this year's March Madness basketball games, and that's a good thing.

Wednesday, March 7, 2018

March Madness brackets in PHP

It's March, and that means I've written yet another article about a program that helps you fill in your NCAA "March Madness" game brackets. This article is a bit different. Where my previous articles described how to write a Bash script to "predict" March Madness brackets, this year's article walks through a PHP script that generates a full bracket.

For those of you who aren't in the U.S., we have a game here called Basketball. And every year in March, the university level (called the National Collegiate Athletic Association, or NCAA) holds a single-elimination championship of the different university teams. If you follow basketball, you can fill out a bracket to "predict" the championship outcomes at each round.

Some people really get into creating their brackets, and they closely follow the teams over the season to see how they are doing. I used to work in an office that cared a lot about March Madness (although in honesty, the office I'm in now doesn't really follow the games that much—but forgive me that I didn't update my Linux Journal article to say so.) I didn't want to miss out on the fun in following March Madness.

I don't follow basketball, but one year I decided to write a little random-number generator to predict the games for me. I used this program to fill out my brackets. And a few years ago, I started writing about it.

Read the article, and use the PHP program to fill out your own March Madness bracket! Let me know how your bracket fared in this year's games.
image: Wikimedia (public domain)

Wednesday, February 21, 2018

Using groff to write papers

In 1993, I discovered Linux, when I was an undergraduate university student. Linux gave me the same power as the Big Unix systems in our campus computer labs, but on my personal computer. I was immediately hooked.

But in the early 1990s, Linux didn't have a lot of applications. When I needed a word processor to write a paper for class, I rebooted into MS-DOS and ran WordPerfect or the shareware word processor, Galaxy Write. I wanted to stay in Linux as much as possible, but I also needed to write papers for class.

I knew a bit about the nroff and troff text processing systems from our campus computer labs, and I was pleased to find that nroff and troff existed on Linux as GNU groff. So I taught myself how to use the groff macro sets to write my class papers. The first macros I learned were the "e" macros, also known as "groff -me" because that was how you invoked the macros from the command line.

I recently wrote an article for OpenSource about How to format academic papers on Linux with "groff -me." I cover the basics for writing most papers, and skip the really esoteric stuff like keeps and displays, nested lists, tables, and figures. This is just an introduction for how to use "groff -me" to write common documents, like papers for class.

Wednesday, February 14, 2018

What open source software programs I love

Earlier this week, someone asked me what Free software and open source software programs I really love. I thought I'd share that here, too.

As I started to go through my favorite programs, I realized it was quite long. So I'm trying to keep the list short here, just the programs I use the most:

I'll start with Linux. I first installed Linux in 1993, when I was still an undergraduate university student. When I heard about Linux, a free version of Unix that I could run on my 386 computer at home, I immediately wanted to try it out. My first Linux distribution was Softlanding Linux System (SLS) 1.03, with Linux kernel 0.99 alpha patch level 11. That required a whopping 2MB of RAM, or 4MB if you wanted to compile programs, and 8MB to run X windows.

I ran a dual-boot Linux and Windows system at home until about 1998, using Windows only to play games. Then I switched to Linux full-time, and haven't looked back. Today, I run Fedora Linux, with GNOME as the desktop.

My other favorite operating system is FreeDOS, but that's not a surprise because I am the founder and project coordinator for the FreeDOS Project. FreeDOS is a complete, free, DOS-compatible operating system that you can use to play classic DOS games, run legacy business software, or develop embedded systems. Any program that works on MS-DOS should also run on FreeDOS.

I usually boot FreeDOS inside a PC emulator called QEMU. I used to run DOSEmu, which was ideal for writing FreeDOS programs because DOSEmu boots its C: drive from a folder in my Linux home directory. That made it really easy to transfer files between FreeDOS and Linux. In QEMU, I set up a folder that is mapped in QEMU as a D: drive.

I write a lot of articles, and now some books, and I use LibreOffice for all of my finish work. In total honesty, I do my collaboration and initial drafts via Google Docs, but all my final drafts and formatting is done in LibreOffice.

Many of my articles are about writing programs, and I use GNU Emacs as my editor. I'll use vim to write shell scripts, and GNOME gedit to edit web pages, but I prefer GNU Emacs for all my programming work. Emacs was my first Unix editor, even before I learned vi, so I'll always have a fondness for it.

While I could compile and debug programs from inside GNU Emacs, I prefer to do that work at the command line using GNOME Terminal.

For any graphics work, I rely on GIMP. This works great for creating graphics for my websites, or enhancing a personal photo, or creating a new cover for my next book.

And finally, I like to listen to music while I'm working, so I usually have Rhythmbox running in the background. I like to listen to one of several streaming radio stations, or I'll listen to my own MP3 music collection.

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.
Update: Linux Journal has posted the second part of my article series: Creating an adventure game in the terminal using ncurses. And part three: Programming in color with ncurses. Soon to come: why the Linux console only has sixteen colors, and how to use windows and frames in ncurses.

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.