Making The Case For Slackware In 2018

If you started using GNU/Linux in the last 10 years or so, there’s a very good chance your first distribution was Ubuntu. But despite what you may have heard on some of the elitist Linux message boards and communities out there, there’s nothing wrong with that. The most important thing is simply that you’re using Free and Open Source Software (FOSS). The how and why is less critical, and in the end really boils down to personal preference. If you would rather take the “easy” route, who is anyone else to judge?

Having said that, such options have not always been available. When I first started using Linux full time, the big news was that the kernel was about to get support for USB Mass Storage devices. I don’t mean like a particular Mass Storage device either, I mean the actual concept of it. Before that point, USB on Linux was mainly just used for mice and keyboards. So while I might not be able to claim the same Linux Greybeard status as the folks who installed via floppies on an i386, it’s safe to say I missed the era of “easy” Linux by a wide margin.

But I don’t envy those who made the switch under slightly rosier circumstances. Quite the opposite. I believe my understanding of the core Unix/Linux philosophy is much stronger because I had to “tough it” through the early days. When pursuits such as mastering your init system and compiling a vanilla kernel from source weren’t considered nerdy extravagance but necessary aspects of running a reliable system.

So what should you do if you’re looking for the “classic” Linux experience? Where automatic configuration is a dirty word, and every aspect of your system can be manipulated with nothing more exotic than a text editor? It just so happens there is a distribution of Linux that has largely gone unchanged for the last couple of decades: Slackware. Let’s take a look at its origins, and what I think is a very bright future.

Continue reading “Making The Case For Slackware In 2018”

Linux Fu: Custom Bash Command Completion

If you aren’t a Linux user and you watch someone who knows what they are doing use Bash — the popular command line interpreter — you might get the impression they type much faster than they actually do. That’s because experienced Linux users know that pressing the tab key will tend to complete what they are typing, so you can type just a few characters and get a much longer line of text. The feature is very smart so you may not have realized it, but it knows a good bit about what you could type. For example, if you try to unzip a file, it knows the expected file name probably has a .zip extension.

How does that happen? At first, you might think, “who cares how it happens?” The problem is when you write a shell script or a program that runs on Linux, the completion gets dumb. Someone has to make Bash smart about each command line program and if you are the author then that someone is you.

Continue reading “Linux Fu: Custom Bash Command Completion”

Making A Covox Speech Thing Work On A Modern PC

Long ago, when mainframes ruled the earth, computers were mute. In this era before MP3s and MMUs, most home computers could only manage a simple beep or two. Unless you had an add-on device like the Covox Speech Thing, that is. This 1986 device plugged into your parallel port and allowed you to play sound. Glorious 8-bit, mono sound. [Yeo Kheng Meng] had heard of this device, and wondered what it would take to get it running again on a modern Linux computer. So he found out in the best possible way: by doing it.

Continue reading “Making A Covox Speech Thing Work On A Modern PC”

Speech Recognition For Linux Gets A Little Closer

It has become commonplace to yell out commands to a little box and have it answer you. However, voice input for the desktop has never really gone mainstream. This is particularly slow for Linux users whose options are shockingly limited, although decent speech support is baked into recent versions of Windows and OS X Yosemite and beyond.

There are four well-known open speech recognition engines: CMU Sphinx, Julius, Kaldi, and the recent release of Mozilla’s DeepSpeech (part of their Common Voice initiative). The trick for Linux users is successfully setting them up and using them in applications. [Michael Sheldon] aims to fix that — at least for DeepSpeech. He’s created an IBus plugin that lets DeepSpeech work with nearly any X application. He’s also provided PPAs that should make it easy to install for Ubuntu or related distributions.

You can see in the video below that it works, although [Michael] admits it is just a starting point. However, the great thing about Open Source is that armed with a working set up, it should be easy for others to contribute and build on the work he’s started.

Continue reading “Speech Recognition For Linux Gets A Little Closer”

Meltdown Code Proves Concept

If you’ve read about Meltdown, you might have thought, “how likely is that to actually happen?” You can more easily judge for yourself by looking at the code available on GitHub. The Linux software is just proof of concept, but it both shows what could happen and — in a way — illustrates some of the difficulties in making this work. There are also two videos in the repository that show spying on password input and dumping physical memory.

The interesting thing is that there are a lot of things that will stop the demos from working. For example a slow CPU, a CPU without out-of-order execution, or an imprecise high-resolution timer. This is apparently especially problematic in virtual machines.

Continue reading “Meltdown Code Proves Concept”

Hands On With PocketBeagle

[Ken Shirriff] is no stranger to the pages of Hackaday. His blog posts are always interesting, and the recent one talking about the PocketBeagle is no exception. If you are old enough to remember the days when a Unix workstation set you back tens of thousands of dollars, you won’t be able to help yourself marveling at a Linux computer with 45 I/O pins, 8 analog inputs, 512M of RAM, and a 1 GHz clock, that fits in your pocket and costs $25. What’s more the board’s CPU has two 200 MHz auxiliary CPUs onboard to handle I/O without having to worry about Linux overhead.

These last parts are significant, and although the Beagles have had this feature for years ([Ken] talked about it earlier), the access and communication methods for using these slave processors has become easier. [Ken] shows a small snippet of C code that outputs a 40 MHz square wave no matter what the Linux OS is doing. In this way you can use Linux for the parts of your application that are not that critical, and use the slave processors to handle real time processing.

Continue reading “Hands On With PocketBeagle”

Fixing Linux Audio One Chipset At A Time

Linux audio may be confusing for the uninitiated. As a system that has evolved and spawned at least two independent branches over time it tends to produce results that surprise or irritate the user. On the other hand it is open source software and thus can be fixed if you know what you do.

Over at reddit [rener2] was annoyed by the fact that listening to music on his laptop was a significantly worse experience under Linux than under Windows. Running Windows the output of  the headphone jack covered the whole spectrum while his Linux set up cut off the low end resulting in a tinny sound. The culprit in this is the sound card: it has two different output paths for the internal speakers and the headphone jack. The signal for the internal speakers is routed through a high pass filter to spare them the embarrassment of failure to reproduce low frequencies.

When headphones are plugged in, the sound card driver is supposed to make the sound card bypass the filter and deliver the full spectrum. The authors of the Windows driver knew this and had it taken care of. In his video [rener2] runs us through the process of patching the ALSA driver while referencing the documentation of a sound card that he deems ‘similar enough’ to his Realtek ALC288.

Continue reading “Fixing Linux Audio One Chipset At A Time”