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:

#!/bin/bash
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.

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 OpenSource.com. 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

Total

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.