Netbooks: The Next Generation — Chromebooks

June 24, 2020 by Jonathan Bennett 35 Comments

Netbooks are dead, long live the Chromebook. Lewin Day wrote up a proper trip down Netbook Nostalgia Lane earlier this month. That’s required reading, go check it out and come back. You’re back? Good. Today I’m making the case that the Chromebook is the rightful heir to the netbook crown, and to realize its potential I’ll show you how to wring every bit of Linuxy goodness out of your Chromebook.

I too was a netbook connoisseur, starting with an Asus Eee 901 way back in 2009. Since then, I’ve also been the proud owner of an Eee PC 1215B, which still sees occasional use. Only recently did I finally bite the bullet and replace it with an AMD based Dell laptop for work.

For the longest time, I’ve been intrigued by a good friend who went the Chromebook route. He uses a Samsung Chromebook Plus, and is constantly using it to SSH into his development machines. After reading Lewin’s article, I got the netbook bug again, and decided to see if a Chromebook would fill the niche. I ended up with the Acer Chromebook Tab 10, codename Scarlet. The price was right, and the tablet form factor is perfect for referencing PDFs.

Two Asus Netbooks and a ChromeOS tablet. — Behold, my netbook credentials.

The default ChromeOS experience isn’t terrible. You have the functionality of desktop Chrome, as well as the ability to run virtually any Android app. It’s a good start, but hardly the hacker’s playground that a Linux netbook once was. But we can still get our Linux on with this hardware. There are three separate approaches to making a Chromebook your own virtual hackspace: Crostini, Crouton, and full OS replacement.

Continue reading “Netbooks: The Next Generation — Chromebooks” →

Seeing Code: The Widescreen Rant

June 20, 2020 by Elliot Williams 114 Comments

A couple of weeks ago, Linus Torvalds laid down the law, in a particularly Linusesque sort of way. In a software community where tabs vs. spaces can start religious wars, saying that 80-character-wide code was obsolete was, to some, utter heresy. For more background on how we got here, read [Sven Gregori]’s history piece on Hackaday, and you’ll learn that sliced bread and the 80-character IBM punch card both made their debut in July, 1928. But I digress.

When I look at a codebase, I like to see its structure, and I’m not alone. That’s one of the reasons for the Linux Kernel style guide’s ridiculously wide 8-character tabs. Combined with a trend for variable names becoming more and more descriptive, which I take to be a good thing, and monitors’ aspect ratios growing seemingly without end, which I don’t, the 80-column width seems like a relic from the long-gone era of the VT-220.

In Linus’ missive, we learn that he runs terminals at 100 x 50, and frequently drags them out to a screen-filling 142 x 76. (Amateur! I write this to you now on 187 x 48.) When you’re running this wide, it doesn’t make any sense to line-wrap argument lists, even if you’re using Hungarian notation.

And yet, change is painful. I’ve had to re-format code to meet 73-column restrictions for a book, only to discover that my inline comments were too verbose. Removing even an artificial restriction like the 80-column limit will have real effects. I write longer paragraphs, for instance, on a wider screen.

I see a few good things to come out of this, though. If single thoughts can be expressed on single lines, it makes the shape of the code better reflect its function. Getting rid of pointless wrapping takes up less vertical space, which is at a premium on today’s cinematic monitors. And if it makes inline comments better (I know, another holy war!) or facilitates better variable naming, it will have been worth it.

But any way you slice it, we’re no longer typing on the old 80-character Hazeltine. It’s high time for our coding style and practice to catch up.

Linux-Fu: Automation For Chrome And The Desktop By Matching Screenshots

June 15, 2020 by Al Williams 11 Comments

I will be the first to admit it. This is almost not — at least not specifically — a Linux article. The subject? An automation tool for Chrome or Firefox. But before you hit the back button, hear me out. Sure, this Chrome plugin started out as a tool to automatically test web pages and automate repetitive tasks in the browser. However, it can extend that power to all programs on your computer. So, in theory, you can use it to graphically build macros that can interact with desktop applications in surprisingly sophisticated ways. In theory, anyway; there are a few problems.

The program has a few different names. Most documentation says UI Vision RPA, although there are some references to Kantu, which appears to be an older name. RPA is an acronym for Robotic Process Automation, which is an industry buzz word.

Let’s take it for a spin and see what it’s all about.

Continue reading “Linux-Fu: Automation For Chrome And The Desktop By Matching Screenshots” →

Linux Fu: Raspberry Pi Desktop Headless

June 1, 2020 by Al Williams 32 Comments

It seems to me there are two camps when it comes to the Raspberry Pi. Some people use them as little PCs or even laptops with a keyboard and screen connected. But many of us use them as cheap Linux servers. I’m in the latter camp. I have probably had an HDMI plug in a Pi only two or three times if you don’t count my media streaming boxes. You can even set them up headless as long as you have an Ethernet cable or are willing to edit the SD card before you boot the machine for the first time.

However, with the Raspberry Pi 4, I wanted to get to a desktop without fishing up a spare monitor. I’ll show you two ways to get a full graphical KDE desktop running with nothing more than a network connection.

The same principle applies to most other desktop environments, but I am using KDE and Ubuntu on the Pi, even though something lighter would probably perform better. But before we get there, let’s talk about how X11 has had a big identity crisis over the years.

The Plan

There are many ways to remotely access X programs, many of which are rarely used today. However, for this purpose, we are going to use SSH tunneling along with some special tricks to get the entire desktop running. It is easy to just run a single X program over SSH, and you’ve probably done that often. If so, you can skip to the next section.

Continue reading “Linux Fu: Raspberry Pi Desktop Headless” →

Linux Fu: Alternative Shells

May 21, 2020 by Al Williams 38 Comments

On Unix — the progenitor of Linux — there was /bin/sh. It was simple, by comparison to today’s shells, but it allowed you to enter commands and — most importantly — execute lists of commands. In fact, it was a simple programming language that could make decisions, loop, and do other things to allow you to write scripts that were more than just a list of programs to run. However, it wasn’t always the easiest thing to use, so in true Unix fashion, people started writing new shells. In this post, I want to point out a few shells other than the ubiquitous bash, which is one of the successors to the old sh program.

Since the 7th Edition of Unix, sh was actually the Bourne shell, named after its author, Stephen Bourne. It replaced the older Thompson shell written in 1971. That shell had some resemblance to a modern shell, but wasn’t really set up for scripting. It did have the standard syntax for redirection and piping, though. The PWB shell was also an early contender to replace Thompson, but all of those shells have pretty much disappeared.

You probably use bash and, honestly, you’ll probably continue to use bash after reading this post. But there are a few alternatives and for some people, they are worth considering. Also, there are a few special-purpose shells you may very well encounter even if your primary shell is bash.

Continue reading “Linux Fu: Alternative Shells” →

ZRAM Boosts Raspberry Pi Performance

May 20, 2020 by Al Williams 18 Comments

Linux is a two-edged sword. On the one hand, there’s so much you can configure. On the other hand, there’s so much you can configure. It is sometimes hard to know just what you should do to get the best performance, especially on a small platform like the Raspberry Pi. [Hayden James] has a suggestion: enable ZRAM and tweak the kernel to match.

Although the post focuses on the Raspberry Pi 4, it applies to any Linux system that has limited memory including older Pi boards. The idea is to use a portion of main memory as a swap file. At first, that might seem like a waste since you could use that memory to, you know, actually run programs. However, the swap devices are compressed, so you get more swap space and transfers from these compressed swap devices and main memory are lightning-fast compared to a hard drive or solid state disk drive.

Continue reading “ZRAM Boosts Raspberry Pi Performance” →

New Breakout Board For Grid-EYE Thermal Sensor

May 18, 2020 by Donald Papp 13 Comments

Panasonic’s Grid-EYE sensor is essentially a low-cost 8×8 thermal imager with a 60 degree field of view, and a nice breakout board makes it much easier to integrate into projects. [Pure Engineering] has created an updated version of their handy breakout board for the Grid-EYE and are currently accepting orders. The new breakout board is well under an inch square and called the GridEye2 (not to be confused with the name of the main component, the AMG8833 Grid-EYE by Panasonic.)

GridEye2 connected to CH341A dev board, allowing easy PC interface over USB.

A common way to interface with the Grid-EYE is over I2C, but to make connecting and developing on a PC more straightforward, [Pure Engineering] has made sure the new unit can plug right into their (optional) CH341A development board to provide a USB interface. Getting up and running on a Linux box is then as simple as installing the Linux drivers for the CH341A, and using sample C code to start reading thermal data from an attached GridEye2 board.

The Grid-EYE is a low-cost and capable little device that mates well with an LED matrix display, and on the more advanced side, a simple Gaussian interpolation can have a striking effect when applied to low-resolution sensors, making them appear higher resolution than they actually are.