Line Printer Does Its Best Teletype Impression

Back in the early days of computing, user terminals utilized line printers for output. Naturally this took an incredible amount of paper, but it came with the advantage of creating a hard copy of everything you did. Plus it was easy to annotate the terminal output with nothing more exotic than a ballpoint pen. But once CRT displays became more common, these paper terminals (also known as teleprinters, or teletypes) quickly fell out of style.

A fan of nostalgic hacks, [Drew DeVault] recently tried to recreate the old-school teletype experience with (somewhat) more modern hardware. He picked up an Epson LX-350 line printer, and with a relatively small amount of custom code, he was able to create a fairly close approximation of what it would have been like to use one of these terminals. He’s published all the source code, so if you’ve got an old line printer and a Linux box, you too can learn what it was like to measure your work day in reams of paper.

This is made possible by the fact that the modern Linux virtual terminal is simply a userspace emulation of those physical terminals of yore. [Drew] just need to write some code that would essentially spawn a shell on the Linux USB line printer device, plus sprinkle in some quality of life improvements such as using Epson’s proprietary ANSI escape sequences to feed the paper out far enough so the user can see what it says before pulling it back in to write the next interactive line.

Of course, the experience isn’t perfect as the printer naturally doesn’t have a keyboard attached to it. If you’re looking for something a bit more authentic, you could always convert an old electric typewriter into a modern-ish teletype.

Tales From The Sysadmin: Dumped Into The Grub Command Line

Today I have a tale of mystery, of horror, and of hope. The allure of a newer kernel and packages was too much to resist, so I found myself upgrading to Fedora 30. All the packages had downloaded, all that was left was to let DNF reboot the machine and install all the new packages. I started the process and meandered off to find a cup of coffee: black, and darker than the stain this line of work leaves on the soul. After enough time had elapsed, I returned, expecting the warming light of a newly upgraded desktop. Instead, all that greeted me was the harsh darkness of a grub command line. Something was amiss, and it was bad.

(An aside to the reader, I had this experience on two different machines, stemming from two different root problems. One was a wayward setting, and the other an unusual permissions problem.)

How does the fledgling Linux sysadmin recover from such a problem? The grub command line is an inscrutable mystery to the uninitiated, but once you understand the basics, it’s not terribly difficult to boot your system and try to restore the normal boot process. This depends on what has broken, of course. If the disk containing your root partition has crashed, then sorry, this article won’t help.

In order to get a system booting, what exactly needs to happen? How does booting Linux work, even? Two components need to be loaded into memory: the kernel, and the initramfs. Once these two elements are loaded into memory, grub performs a jump into the kernel code, which takes over and finishes the machine’s boot. There is one more important detail that we care about — the kernel needs to know where to find the root partition. This is typically part of the kernel parameters, specified on the kernel boot line.

When working with an unfamiliar shell, the help command is a good starting point. grub runs in a very limited environment, and running the help command scrolls most of the text off the screen. There is an environment variable that helps out here, enabling output paging:set pager=1.
Continue reading “Tales From The Sysadmin: Dumped Into The Grub Command Line”

Will The Real UNIX Please Stand Up?

Ken Thompson and Dennis Ritchie at a PDP-11. Peter Hamer [CC BY-SA 2.0]
Ken Thompson and Dennis Ritchie at a PDP-11. Peter Hamer [CC BY-SA 2.0]
Last week the computing world celebrated an important anniversary: the UNIX operating system turned 50 years old. What was originally developed in 1969 as a lighter weight timesharing system for a DEC minicomputer at Bell Labs has exerted a huge influence over every place that we encounter computing, from our personal and embedded devices to the unseen servers in the cloud. But in a story that has seen countless twists and turns over those five decades just what is UNIX these days?

The official answer to that question is simple. UNIX® is any operating system descended from that original Bell Labs software developed by Thompson, Ritchie et al in 1969 and bearing a licence from Bell Labs or its successor organisations in ownership of the UNIX® name. Thus, for example, HP-UX as shipped on Hewlett Packard’s enterprise machinery is one of several commercially available UNIXes, while the Ubuntu Linux distribution on which this is being written is not.

When You Could Write Off In The Mail For UNIX On A Tape

The real answer is considerably less clear, and depends upon how much you view UNIX as an ecosystem and how much instead depends upon heritage or specification compliance, and even the user experience. Names such as GNU, Linux, BSD, and MINIX enter the fray, and you could be forgiven for asking: would the real UNIX please stand up?

Continue reading “Will The Real UNIX Please Stand Up?”

Linux’s Marketing Problem

The cult classic movie Office Space is a scathing critique of life for software engineers in a cubicle farm, and it did get a lot of things right even if it didn’t always mean to. One of those is the character of Tom Smykowski whose job is to “deal with the customers so the engineers don’t have to”. The movie treats Tom and his job as a punchline in a way, but his role is actually very important for most real businesses that rely on engineers or programmers for their core products.

Engineers can have difficulty relating to customers, and often don’t have the time (or even willingness) to handle the logistics of interacting with them in the first place. Customers may get frustrated understanding engineers or communicating their ideas clearly to them. A person like Tom Smykowski is often necessary to bridge the gap and smooth out the rough edges on both sides, but in the Linux world there are very few Toms to rely on. The customers, or users, have to deal directly with the engineers in many situations, and it’s not working out very well for either group. Linux has a marketing problem, and it needs a marketing solution if it ever wants to increase its market share in the PC realm. Continue reading “Linux’s Marketing Problem”

Worn Out EMMC Chips Are Crippling Older Teslas

It should probably go without saying that the main reason most people buy an electric vehicle (EV) is because they want to reduce or eliminate their usage of gasoline. Even if you aren’t terribly concerned about your ecological footprint, the fact of the matter is that electricity prices are so low in many places that an electric vehicle is cheaper to operate than one which burns gas at $2.50+ USD a gallon.

Another advantage, at least in theory, is reduced overal maintenance cost. While a modern EV will of course be packed with sensors and complex onboard computer systems, the same could be said for nearly any internal combustion engine (ICE) car that rolled off the lot in the last decade as well. But mechanically, there’s a lot less that can go wrong on an EV. For the owner of an electric car, the days of oil changes, fouled spark plugs, and the looming threat of a blown head gasket are all in the rear-view mirror.

Unfortunately, it seems the rise of high-tech EVs is also ushering in a new era of unexpected failures and maintenance woes. Case in point, some owners of older model Teslas are finding they’re at risk of being stranded on the side of the road by a failure most of us would more likely associate with losing some documents or photos: a disk read error.

Continue reading “Worn Out EMMC Chips Are Crippling Older Teslas”

Pack Your Bags – Systemd Is Taking You To A New Home

Home directories have been a fundamental part on any Unixy system since day one. They’re such a basic element, we usually don’t give them much thought. And why would we? From a low level point of view, whatever location $HOME is pointing to, is a directory just like any other of the countless ones you will find on the system — apart from maybe being located on its own disk partition. Home directories are so unspectacular in their nature, it wouldn’t usually cross anyone’s mind to even consider to change anything about them. And then there’s Lennart Poettering.

In case you’re not familiar with the name, he is the main developer behind the systemd init system, which has nowadays been adopted by the majority of Linux distributions as replacement for its oldschool, Unix-style init-system predecessors, essentially changing everything we knew about the system boot process. Not only did this change personally insult every single Perl-loving, Ken-Thompson-action-figure-owning grey beard, it engendered contempt towards systemd and Lennart himself that approaches Nickelback level. At this point, it probably doesn’t matter anymore what he does next, haters gonna hate. So who better than him to disrupt everything we know about home directories? Where you _live_?

Although, home directories are just one part of the equation that his latest creation — the systemd-homed project — is going to make people hate him even more tackle. The big picture is really more about the whole concept of user management as we know it, which sounds bold and scary, but which in its current state is also a lot more flawed than we might realize. So let’s have a look at what it’s all about, the motivation behind homed, the problems it’s going to both solve and raise, and how it’s maybe time to leave some outdated philosophies behind us.

Continue reading “Pack Your Bags – Systemd Is Taking You To A New Home”

Linux Fu: Python GUIs For Command Line Programs (Almost) Instantly

Not every programmer likes creating GUI code. Most hacker types don’t mind a command line interface, but very few ordinary users appreciate them. However, if you write command line programs in Python, Gooey can help. By leveraging some Python features and a common Python idiom, you can convert a command line program into a GUI with very little effort.

The idea is pretty simple. Nearly all command line Python programs use argparse to simplify picking options and arguments off the command line as well as providing some help. The Gooey decorator picks up all your options and arguments and creates a GUI for it. You can make it more complicated if you want to change specific things, but if you are happy with the defaults, there’s not much else to it.

At first, this article might seem like a Python Fu and not a Linux Fu, since — at first — we are going to focus on Python. But just stand by and you’ll see how this can do a lot of things on many operating systems, including Linux.

Continue reading “Linux Fu: Python GUIs For Command Line Programs (Almost) Instantly”