Linux

“Linux is Linux is Linux,” is a direct quote I heard in a meeting I had recently with a major multi-national, critical-infrastructure company. Surprisingly and correctly, there was one intelligent and brave engineering executive who replied to this statement, made by one of his team members, with a resounding, “That’s not true.” Let’s be clear, selecting a commercial Linux is not like selecting corn flakes. This is especially true when you are targeting embedded systems. You must be considering key questions regarding the supplier of the distribution, the criticality of the target application, security and life-cycle support for your product.

Choose Wisely

There is a wonderful scene in the movie Indiana Jones and the Last Crusade when our hero, Indiana, must select the true Holy Grail. Set before him is a multitude of cups ranging from opulent, bejeweled challises to simple clay drinking cups. If you have seen the movie, Indiana reasons out the best choice, and it was a life or death selection. The knight who had been guarding the challises for centuries famously says, “You chose… wisely.” Why bring up this iconic scene? When you are selecting a commercial Linux distribution, you have a multitude of choices all bejeweled with wonderful marketing. The bottom line is that you want to save dollars that you would have otherwise spent on a DIY-Linux approach and ensure the commercial Linux selected fits your particular application. Here are some questions that you will need to keep in mind:

• Is this for an IT application?

• Is this for an OT (Operational Technology) application?

• How long will this system be in the field?

• What processes and procedures are used by my supplier to cover security vulnerabilities?

• Can my supplier integrate in other Linux packages that support functionality I need going forward?

This is the short list. Other elements to keep in mind are the specific distribution’s origin and the Open Source community upon which it is based. How important is that specific Linux supplier with regard to the Open Source community upon which the distribution is based? These elements need to be part of the thought process.

I’ll Let My Silicon Choose

Love Arduino but hate the GUI? Try arduino-cli.

In this article, I explore a new tool released by the Arduino team that can free you from the existing Java-based Arduino graphical user interface. This allows developers to use their preferred tools and workflow. And perhaps more important, it'll enable easier and deeper innovation into the Arduino toolchain itself.

The Good-Old Days

When I started building hobby electronics projects with microprocessors in the 1990s, the process entailed a discrete processor, RAM, ROM and masses of glue logic chips connected together using a point-to-point or "wire wrapping" technique. (Look it up kids!) Programs were stored on glass-windowed EPROM chips that needed to be erased under UV light. All the tools were expensive and difficult to use, and development cycles were very slow. Figures 1–3 show some examples of my mid-1990s microprocessor projects with discrete CPU, RAM and ROM. Note: no Flash, no I/O, no DACs, no ADCs, no timers—all that means more chips!

Figure 1. Example Mid-1990s Microprocessor

Figure 2. Example Mid-1990s Microprocessor

Figure 3. Example Mid-1990s Microprocessor

It all changed in 2003 with Arduino.

The word "Arduino" often invokes a wide range of opinions and sometimes emotion. For many, it represents a very low bar to entry into the world of microcontrollers. This world before 2003 often required costly, obscure and closed-source development tools. Arduino has been a great equalizer, blowing the doors off the walled garden. Arduino now represents a huge ecosystem of hardware that speaks a (mostly) common language and eases transition from one hardware platform to another. Today, if you are a company that sells microcontrollers, it's in your best interest to get your dev boards working with Arduino. It offers a low-friction path to getting your products into lots of hands quickly.

It's also important to note that Arduino's simplicity does not inhibit digging deep into the microcontroller. Nothing stops you from directly twiddling registers and using advanced features. It does, however, decrease your portability between boards.

A look at using OpenAI's Generative Pretrained Transformer 2 (GPT-2) to generate text.

It's probably fair to say that there's more than one person out there who is worried about some version of artificial intelligence, or AI, possibly in a robot body of some kind, taking people's jobs. Anything that is repetitive or easily described is considered fair game for a robot, so driving a car or working in a factory is fair game.

Until recently, we could tell ourselves that people like yours truly—the writers and those who create things using some form of creativity—were more or less immune to the march of the machines. Then came GPT-2, which stands for Generative Pretrained Transformer 2. I think you'll agree, that isn't the sexiest name imaginable for a civilization-ending text bot. And since it's version 2, I imagine that like Star Trek's M-5 computer, perhaps GPT-1 wasn't entirely successful. That would be the original series episode titled, "The Ultimate Computer", if you want to check it out.

So what does the name "GPT-2" stand for? Well, "generative" means pretty much what it sounds like. The program generates text based on a predictive model, much like your phone suggests the next word as you type. The "pretrained" part is also quite obvious in that the model released by OpenAI has been built and fine-tuned for a specific purpose. The last word, "Transformer", refers to the "transformer architecture", which is a neural network design architecture suited for understanding language. If you want to dig deeper into that last one, I've included a link from a Google AI blog that compares it to other machine learning architecture (see Resources).

On February 14, 2019, Valentine's Day, OpenAI released GPT-2 with a warning:

Our model, called GPT-2 (a successor to GPT), was trained simply to predict the next word in 40GB of Internet text. Due to our concerns about malicious applications of the technology, we are not releasing the trained model. As an experiment in responsible disclosure, we are instead releasing a much smaller model for researchers to experiment with, as well as a technical paper.

I've included a link to the blog in the Resources section at the end of this article. It's worth reading partly because it demonstrates a sample of what this software is capable of using the full model (see Figure 1 for a sample). We already have a problem with human-generated fake news; imagine a tireless machine capable of churning out vast quantities of news and posting it all over the internet, and you start to get a feel for the dangers. For that reason, OpenAI released a much smaller model to demonstrate its capabilities and to engage researchers and developers.

In this article, I want to look at a GIS option available for Linux—specifically, a program called SAGA (System for Automated Geoscientific Analyses). SAGA was developed at the Department of Physical Geography in Germany. It is built with a plugin module architecture, where various functions are provided by individual modules. A very complete API is available to allow users to extend SAGA's functionality with newly written modules. I take a very cursory look at SAGA here and describe a few things you might want to do with it.

Installing SAGA should be as easy as looking at the software repository for your favourite distribution. For Debian-based distros, you can install it with the command:

sudo apt-get install saga

When you first start it, you get a blank workspace where you can begin your project.

Figure 1. SAGA starts up with a central project window, several tool panes on the left and console messages at the bottom.

Two major categories of data sets are available that you can use within your projects: satellite imagery and terrain data. The tutorial website provides detailed walk-throughs that show how you can get access to these types of data sets for use in your own projects. The tutorial website also has sections on some of the processing tools available for doing more detailed analysis.

SAGA understands several data file formats. The typical ones used in GIS, like SHP files or point clouds, are the default options in the file selector window. You can work with these types of data, or satellite imagery or terrain data.

Let's start by looking at terrain analysis in SAGA. You'll need digital elevation data, in DEM format, which is available from the SRTM Tile Grabber site. You will get a zip file for each region you select, and these zip files contain geotiff files for the selected regions.

Load the geotiff file by clicking File→Open. By default, it will show only the common project file formats. To locate your downloaded geotiff files, you'll need to change the filter at the bottom of the file selector window to be all files. Once it is loaded, it will show up in the list of data sources in the bottom-left window pane.

Figure 2. You can load data sources, such as geotiffs, into your project.

Introducing the Yocto Project and the benefits of using it in embedded Linux development.

In embedded Linux development, there are two approaches when it comes to what operating system to run on your device. You either build your own distribution (with tools such as Yocto/OpenEmbedded-Core, Buildroot and so on), or you use a binary distribution where Debian and derivatives are common.

It's common to start out with a binary distribution. This is a natural approach, because it's a familiar environment for most people who have used Linux on a PC. All the commodities are in place, and someone else has created the distribution image for you to download. There normally are custom vendor images for specific hardware that contain optimizations to make it easy to get started to utilize your hardware fully.

Any package imaginable is an apt install command away. This, of course, makes it suitable for prototyping and evaluation, giving you a head start in developing your application and your product. In some cases, you even might ship pre-series devices using this setup to evaluate your idea and product further. This is referred to as the "golden image" approach and involves the following steps:

1. Flash the downloaded Debian image to an SD card.
2. Boot the SD card, log in and make any modifications needed (for example, installing custom applications). Once all the modifications are complete, this becomes your golden image.
3. Duplicate the SD card into an image on your workstation (for example, using dd).
4. Flash the "golden image" to a fleet of devices.

And every time you need to make a change, you just repeat steps 2–4, with one change—that is, you boot the already saved "golden image" in step 2 instead of the "vanilla" image.

At a certain point, the approach of downloading a pre-built distribution image and applying changes to it manually will become a problem, as it does not scale well and is error-prone due to the amount of manual labor that can lead to inconsistent output. The optimization would be to find ways to automate this, generating distribution images that contain your applications and your configuration in a reproducible way.

This is a crossroad where you decide either to stick with a binary distribution or move your idea and the result of the evaluation and prototyping phase to a tool that's able to generate custom distributions and images in a reproducible and automated way.