A Bootable Greeting For The Xenomorph In Your Life

October 7, 2019 by Tom Nardi 4 Comments

When he needed a gift for his Alien superfan friend, [Stephen Brennan] decided the best way to put his unique set of skills to use would be to create a bootable Linux operating system that captures the sights and sounds of the Nostromo’s retro-futuristic computer systems. We could all use a friend like that.

Even if would never occur to you gift somebody a bootable flash drive, there’s a wealth of information in this blog post about Linux customization which could be useful for all sorts of projects. From creating a bootsplash image to automatically starting up a minimalistic windowing environment so a single graphical application takes center stage.

Whether you’re looking to tweak your desktop machine or build a Raspberry Pi kiosk, the commands and tips that [Stephen] shows off are sure to be interesting for anyone who’s not quite satisfied with how their Linux distribution of choice looks “out of the box”.

But there’s more to this project than a custom wallpaper and some retro fonts. [Stephen] actually took the time to create a facsimile of the “Personal Terminal” computer interface shown in the recent Alien: Isolation game in C using ncurses. The resulting program, aptly named “alien-console”, is released under the BSD license and is flexible enough that you could either use it as a base to build your own cyberpunk UI, or just load it up with custom text files and use it on your cyberdeck as-is.

Finally, to really sell the Alien feel, [Stephen] went through and ripped various audio clips from the film and wove them into the OS so it would make the movie-appropriate boops and beeps. He even included a track of the Nostromo’s ambient engine noise for proper immersion. But perhaps our favorite trick is the use of the sleep command to artificially slow down the terminal and give everything a bit more “weight”. After all, flying a pretend starship should feel like serious business.

Linux Fu: Shell Scripts In C, C++, And Others

September 17, 2019 by Al Williams 44 Comments

At first glance, it might not seem to make sense to write shell scripts in C/C++. After all, the whole point to a shell script is to knock out something quick and dirty. However, there are cases where you might want to write a quick C program to do something that would be hard to do in a traditional scripting language, perhaps you have a library that makes the job easier, or maybe you just know C and can knock it out faster.

While it is true that C generates executables, so there’s no need for a script, usually, the setup to build an executable is not what you want to spend your time on when you are just trying to get something done. In addition, scripts are largely portable. But sending an executable to someone else is fairly risky — but your in luck because C shell scripts can be shared as… well, as scripts. One option is to use a C interpreter like Cling. This is especially common when you are using something like Jupyter notebook. However, it is another piece of software you need on the user’s system. It would be nice to not depend on anything other than the system C compiler which is most likely gcc.

Luckily, there are a few ways to do this and none of them are especially hard. Even if you don’t want to actually script in C, understanding how to get there can be illustrative.

Continue reading “Linux Fu: Shell Scripts In C, C++, And Others” →

Writing Characters Straight To The Linux Framebuffer

September 16, 2019 by Lewin Day 15 Comments

These days, working with a display in software is fairly easy. Thanks to the convenience of the modern OS, we’re blessed with graphical user interfaces, where things such as buttons and windows and text are all taken care of for us. Of course, once you start to wander off the beaten track, particularly in embedded systems with no GUI, things can get a little more difficult. For these situations, [JSBattista] wrote some code to blast text directly to the Linux framebuffer.

It’s a project borne out of necessity. Working with a Raspberry Pi with no X server, it was found that the console text size made it difficult to display data. By writing directly to the framebuffer, it would be possible to display text of a larger size without having to implement a full GUI, and overheads could be kept to a minimum.

Working in this manner comes with some limitations. Glyphs are taken from an array in bitmap format, rather than font files. In this case, a font akin to that of the Alien sentry gun interface was chosen, for an attractive sci-fi look. Lowercase characters are currently unimplemented. Testing thus far has been on Raspberry Pi and Beaglebone non-GUI systems, with performance varying depending on platform.

It’s a project we suspect might prove useful to the developers of lightweight embedded systems. It’s something that may take some tweaking and experimentation to implement, but the hacker set rarely shy away from a challenge. If you’re eager to get down and dirty with some heavy programming, this tutorial on Linux graphics will help.

Linux Fu: Interactive SSH Applications

September 6, 2019 by Al Williams 4 Comments

[Drew DeVault] recently wrote up some interesting instructions on how to package up interactive text-based Linux commands for users to access via ssh. At first, this seems simple, but there are quite a few nuances to it and [Drew] does a good job of covering them.

One easy way — but not very versatile — is to create a user and make the program you want to run the default shell. The example used is to make /usr/bin/nethack the shell and now people can log in as that user and play nethack. Simple, right? However, there are better ways to get there.

Continue reading “Linux Fu: Interactive SSH Applications” →

Linux Fu: It’s A Trap!

August 26, 2019 by Al Williams 14 Comments

It is easy to think that a Linux shell like Bash is just a way to enter commands at a terminal. But, in fact, it is also a powerful programming language as we’ve seen from projects ranging from web servers to simple utilities to make dangerous commands safer. Like most programming languages, though, there are multiple layers of complexity. You can spend a little time and get by or you can invest more time and learn about the language and, hopefully, write more robust programs.

Continue reading “Linux Fu: It’s A Trap!” →

Linux Fu: Named Pipe Dreams

July 12, 2019 by Al Williams 30 Comments

If you use just about any modern command line, you probably understand the idea of pipes. Pipes are the ability to connect the output from one program to the input of another. For example, you can more easily review contents of a large directory on a Linux machine by connecting two simple commands using a pipe:

ls | less

This command runs ls and sends its output to the input of the less program. In Linux, both commands run at once and output from ls immediately appears as the input of less. From the user’s point of view it’s a single operation. In contrast, under regular old MSDOS, two steps would be necessary to run these commands:

ls > SOME_TEMP_FILE
less < SOME_TEMP_FILE

The big difference is that ls will run to completion, saving its output a file. Then the less command runs and reads the file. The result is the same, but the timing isn’t.

You may be wondering why I’m explaining such a simple concept. There’s another type of pipe that isn’t as often used: a named pipe. The normal pipes are attached to a pair of commands. However, a named pipe has a life of its own. Any number of processes can write to it and read from it. Learn the ways of named pipes will certainly up your Linux-Fu, so let’s jump in!

Continue reading “Linux Fu: Named Pipe Dreams” →

The Saga Of 32-Bit Linux: Why Going 64-Bit Raises Concerns Over Multilib

July 9, 2019 by Tom Nardi 137 Comments

The story of Linux so far, as short as it may be in the grand scheme of things, is one of constant forward momentum. There’s always another feature to implement, an optimization to make, and of course, another device to support. With developer’s eyes always on the horizon ahead of them, it should come as no surprise to find that support for older hardware or protocols occasionally falls to the wayside. When maintaining antiquated code monopolizes developer time, or even directly conflicts with new code, a difficult decision needs to be made.

Of course, some decisions are easier to make than others. Back in 2012 when Linus Torvalds officially ended kernel support for legacy 386 processors, he famously closed the commit message with “Good riddance.” Maintaining support for such old hardware had been complicating things behind the scenes for years while offering very little practical benefit, so removing all that legacy code was like taking a weight off the developer’s shoulders.

The rationale was the same a few years ago when distributions like Arch Linux decided to drop support for 32-bit hardware entirely. Maintainers had noticed the drop-off in downloads for the 32-bit versions of their distributions and decided it didn’t make sense to keep producing them. In an era where even budget smartphones are shipping with 64-bit processors, many Linux distributions have at this point decided 32-bit CPUs weren’t worth their time.

Given this trend, you’d think Ubuntu announcing last month that they’d no longer be providing 32-bit versions of packages in their repository would hardly be newsworthy. But as it turns out, the threat of ending 32-bit packages caused the sort of uproar that we don’t traditionally see in the Linux community. But why?

Continue reading “The Saga Of 32-Bit Linux: Why Going 64-Bit Raises Concerns Over Multilib” →