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.
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.
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.
[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.
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.
Time zones have been a necessity since humans could travel faster than a horse, but with computers, interconnected over a vast hive of information, a larger problem has emerged. How do you keep track of time zones? Moreover, how do you keep track of time zones throughout history?
Quick question. If it’s noon in Boston, what time is it in Phoenix? Well, Boston is in the Eastern time zone, there’s the Central time zone, and Phoenix is in the Mountain time zone; noon, eleven, ten. If it’s noon in Boston, it’s ten o’clock AM in Phoenix. Here’s a slightly harder question: if it’s noon in Boston, what time is it in Phoenix during Daylight Savings Time? Most of Arizona doesn’t observe Daylight Savings Time, so if it’s noon in Boston, it’s 9 AM in Phoenix. What about the Navajo Nation in the northwestern part of Arizona? Here, Daylight Savings Time is observed. You can’t even make a rule that all of Arizona is always on Mountain Standard Time.
Indiana is another example of bizarre time zones. For most of the 20th century, Indiana was firmly in the Central time zone. Starting in the 1960s, the line between Eastern and Central time slowly moved west from the Ohio border. Some countries opted not to observe Daylight Savings Time. In 2006, the entire state started to observe DST, but the northwest and southwest corners of the state remained firmly in the Central time zone. The odd geographic boundaries of time zones aren’t limited to the United States, either; Broken Hill, New South Wales, Australia is thirty minutes behind the rest of New South Wales.
Working out reliable answers to all of these questions is the domain of the Time Zone Database, a catalog of every time zone, time zone change, and every strange time-related political argument. It records Alaska’s transition from the Julian to the Gregorian calendar. It describes an argument in a small Michigan town in 1900. It’s used in Java, nearly every kind of Linux, hundreds of software packages, and at least a dozen of the servers and routers you’re using to read this right now.
Even if you like using a graphical user interface, you can probably agree that writing a graphical program is usually harder than writing an old-fashioned text-based program. Putting that GUI into an online format means even more to think about. [Adam Kewley] has the answer to that problem: Jobson. As you can see in the video below, the program is a web server that runs command line programs as jobs.
Simply write a YAML file to describe the program’s inputs and outputs and Jobson will create input fields for arguments and display the output in a web page. Any files the program creates are available to download. Basically any command line program can be quickly and easily pulled into one web interface to rule them.
If a program takes a long time to run, Jobson will let you switch away and then later resume looking at the output. You can also abort a job or look at the arguments it received. Jobson can also authenticate users with several different methods to prevent just anyone from executing jobs.
If you really want to write a graphical program, try QTCreator. Or, you can get a shell in a web browser if you want to go that route. But this is the smoothest method we’ve seen for gathering command line programs into one place for monitoring and control. Neat!