Making The Case For Slackware In 2018

January 30, 2018 by Tom Nardi 147 Comments

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” →

Speech Recognition For Linux Gets A Little Closer

January 17, 2018 by Al Williams 33 Comments

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

January 11, 2018 by Al Williams 46 Comments

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” →

PostMarketOS Saves Old Smartphones

January 9, 2018 by Tom Nardi 67 Comments

Modern smartphones, even the budget models, are extremely impressive pieces of technology. Powerful ARM processors, plenty of RAM, and an incredible number of sensors and radios are packed into a device that in some cases are literally given away for free when you sign up for a service plan. Unfortunately manufacturers are not obligated to keep up with software updates, and while the hardware may be willing to keep on fighting, the user is often pushed to upgrade due to perennially outdated software. Even if you aren’t the kind of person to be put off by using a phone that doesn’t have the latest and greatest OS, the lack of software security updates pose a clear threat in a world where mobile devices are increasingly targeted by attackers.

But what if the operating system on your phone worked more like the on one your computer? That’s the dream of postmarketOS, a Linux distribution created by [Oliver Smith] that is designed to be installed on outdated (mostly Android) smartphones and tablets. He’s recently made a comprehensive blog post about the state of the project a little over 6 months since it started, and we have to say things are looking very impressive so far.

One of the key goals of postmarketOS is to avoid the fragmented nature of previous attempts at replacing Android with a community-developed operated system. By avoiding binary blobs and focusing on getting the mainline Linux kernel running on as much as the hardware as possible, there’s no need to make different forks and releases for each supported device. By unifying the OS as much as far as it can be, an upstream update can be pushed to all devices running postmarketOS regardless of their make and model, just like with traditional Linux distributions.

The blog post shows two things very clearly: that the community is extremely excited and dedicated to the prospect of running what is essentially desktop Linux on old smartphones and tablets, and that postmarketOS still has a long way to go. In these early days, many devices aren’t what could be considered “daily drivers” by most standards. In fact, the blog post mentions that they’ve decided to abandon the term “supported” when talking about devices, and make no claims beyond the fact that they will boot.

Still, incredible progress is being made on everything from mainline kernel development to getting standard Linux desktops such as Gnome, MATE and XFCE4 running. Work has also been done on the backend process of compiling and packaging up components of the operating system itself, promising to speed up development times even for those who don’t have a beefy machine they can dedicate to compiling. The blog post ends with a helpful list of things the reader can do to help support postmarketOS, ranging from making your own t-shirts to porting to new hardware.

At Hackaday we’ve seen our fair share of hackers and makers re-purposing old smartphones and tablets, keeping them out of the landfills they would almost certainly end up in otherwise. A project that aims to make it even easier to hack these cheap and incredibly useful devices is music to our ears.

Go Retro To Build A Spectre And Meltdown-Proof X86 Desktop

January 7, 2018 by Brian Benchoff 95 Comments

[Yeo Kheng Meng] had a question: what is the oldest x86 processor that is still supported by a modern Linux kernel? Furthermore, is it actually possible to use modern software with this processor? It’s a question that surely involves experimentation, staring into the bluescreen abyss of BIOS configurations, and compiling your own kernel. Considering Linux dropped support for the 386 in 2012, the obvious answer is a 486. This supposition was tested, and the results are fantastic. You can, indeed, install a modern Linux on an ancient desktop.

This project got its start last month at a Super Silly Hackathon where [Yeo] and [Hui Jing] installed Damn Small Linux on an ancient IBM PS/1 desktop of 1993 vintage. The hardware consists of an AMD 486 clone running at 133MHz, 64 MB of RAM, a 48x IDE CDROM drive (wow!), a floppy emulator, a Sound Blaster, 10Mbps Ethernet card, and a CompactFlash to IDE adapter. By any account, this is a pimped-out rig for 1993 that would have cost more than a car at the time. The hardware works, but can you run a modern Linux kernel on it?

[Yeo] decided to install the Gentoo x86 minimal installation, but sanity and time constraints meant compiling a kernel on a 486 wasn’t happening. That was done on a modern Thinkpad after partitioning all the drives, verifying all the compilation parameters, and configuring the kernel itself. The bootloader is LILO (Grub2 didn’t work), but for the most part, this is entirely modern software running on a 25-year-old machine. The step-by-step instructions for becoming a /g/entooman on a 486 are available on GitHub.

The entire (boring) boot process can be seen in the video below. One interesting application of this build is that the 486 does not support out-of-order execution, making this completely safe from Meltdown and Spectre attacks. It’s an impressive retrocomputing achievement that right now could not be more timely.

Continue reading “Go Retro To Build A Spectre And Meltdown-Proof X86 Desktop” →

Learn To Reverse Engineer X86_64 Binaries

January 6, 2018 by Sven Gregori 16 Comments

Opening up things, see how they work, and make them do what you want are just the basic needs of the average hacker. In some cases, a screwdriver and multimeter will do the job, but in other cases a binary blob of random software is all we have to work with. Trying to understand an unknown binary executable is an exciting way to discover a system’s internal functionality.

While the basic principles of software reverse engineering are universal across most platforms, the details can naturally vary for different architectures. In the case of the x86 architecture, [Leonora Tindall] felt that most tutorials on the subject focus mostly on 32-bit and not so much on the 64-bit specifics. Determined to change that, she ended up with an extensive introduction tutorial for reverse engineering x86_64 binaries starting at the very basics, then gradually moving forward using crackme examples. Covering simple string analysis and digging through disassembled binaries to circumvent fictional security, the tutorial later introduces the Radare2 framework.

All example source code is provided in the accompanying GitHub repository, although it is advised to avoid looking at them to keep it more interesting and challenging. And in case you are looking for more challenges later on, or generally prefer a closer connection to the hardware, these MSP430 based capture the flag online challenges might be worth to look at next.

Fixing Linux Audio One Chipset At A Time

November 25, 2017 by Christian Trapp 34 Comments

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” →