If you ever think about it, computers are exceedingly stupid. Even the most powerful CPU can’t do very much. However, it can do what it does very rapidly and repeatably. Computers are so fast, they can appear to do a lot of things at once, too and modern computers have multiple CPUs to further enhance their multitasking abilities. However, we often don’t write programs or shell scripts to take advantage of this. However, there’s no reason for this, as you’ll see.
Bash Support
It is surprisingly easy to get multiple processes running under Bash. For one thing, processes on either side of a pipe run together, and that’s probably the most common way shell scripts using multiprogramming. In other words, think about what happens if you write ls | more.
Under the old MSDOS system, the first program would run to completion, spooling its output to a temporary file. Then the second program will run, reading input from the same file. With Linux and most other modern operating systems, both programs will run together with the input of the second program connected to the first program’s output. Continue reading “Linux Fu: Walk, Chew Gum”→
These days we expect even the cheapest of burner smartphones to feature a multi-core processor, at least a gigabyte of RAM, and a Linux-based operating system. But obviously those sort of specs are unnecessary for an old school POTS desktop phone. Well, that’s what we thought. Then [Josh Max] wrote in to tell us about his adventures in hacking the CaptionCall, and now we’re eager to see what the community can do with root access on a surprisingly powerful Linux phone.
As the names implies, the CaptionCall is a desk phone with an LCD above the keypad that shows real-time captions. Anyone in the United States with hearing loss can get one of these phones for free from the government, so naturally they sell for peanuts on the second hand market. Well, at least they did. Then [Josh] had to go ahead and crack the root password for the ARMv7 i.MX6 powered phone, started poking around inside of its 4 GB of onboard NAND, and got the thing running DOOM.
Tapping into the serial port.
If you’re interested in the technical details, [Josh] has done a great job taking us step by step through his process. It’s a story that will be at least somewhat familiar to anyone who’s played around with embedded Linux devices, and unsurprisingly, starts with locating a serial port header on the PCB.
Finding the environment variables to pretty tightly locked down, he took the slow-route and dumped the phone’s firmware 80 characters at a time with U-Boot’s “memory display” command. Passing the recovered firmware image through binwalk and a password cracker got him the root credentials in short order, and from there, that serial port got a whole lot more useful.
[Josh] kicked the phone’s original UI to the curb, set up an ARM Debian Jessie chroot, and started working his way towards a fully functional Linux environment. With audio, video, and even keypad support secured, he was ready to boot up everyone’s favorite 1993 shooter. He’s been kind enough to share his work in a GitHub repository, and while it might not be a turn-key experience, all the pieces are here to fully bend the hardware to your will.
Historically, running DOOM on a new piece of hardware has been the harbinger of bigger and better things to come. With unfettered access to its Linux operating system up for grabs, we predict the CaptionCall is going to become a popular hacking target going forward, and we can’t wait to see it.
The life of a Linux user can be a bit difficult. Sometimes you have to — or want to — run Windows. Why Windows? Sometimes you have a work computer or a laptop that Linux doesn’t support well. Or it might be software. Although there are plenty of programs that can edit, say, Word documents, there’s always that one document that doesn’t quite translate correctly. Things like videoconferencing software sometimes works on Linux but might have fewer features.
So what do you do? You can dual boot, of course, but that’s not very handy. You can run Windows in a virtual machine if you have enough horsepower. There’s also Wine, but that often has its own set of problems with features and stability of complex programs. However, recent versions of Windows provide the Windows Subsystem for Linux (WSL).
With WSL, you can have most of what you like about Linux inside your Windows session. You just have to know how to set it up, and I’m going to show you one way that works for me with reasonably stable versions of Windows 10. Continue reading “Linux Fu: The Windows X11 Connection”→
The SMART Response XE is a handheld computer that was originally sold for use in the classroom as a terminal for pupils taking tests. It’s now cheap enough on the surplus market to have become a target for experimenters, and we’ve seen them with a variety of cool hacks. We particularly like what [chmod775] has done with it, putting a VT100 terminal emulator on the device and hiding a NanoPi Neo Air single board computer in the battery bay. Powered from a USB battery bank, it gives a fully-featured Linux terminal in the palm of the hand. We see it running an Ubuntu LTS version, and it’s clear that it’s a functional and usable device.
This raises a more abstract question though: We’d guess comparatively few of us write software through an old-style dumb terminal, instead we’re more likely to get our terminal experience at a much more accomplished command line with all the conveniences of a modern desktop surrounding it. How many of us could comfortably return to the limited confines of a VT100 emulator on an odd-sized LCD display? We’d be interested to hear [chmod755]’s experiences using it, because if it retains usability it’s a device we wouldn’t mind having ourselves.
Over the last few months we’ve been keeping an eye on WiFiWart, an ambitious project to develop a Linux single-board computer (SBC) small enough to fit inside a USB wall charger. Developer [Walker] says the goal is to create an easily concealable “drop box” for penetration testing, giving security researchers a valuable foothold inside a target network from which to preform reconnaissance or launch attacks. Of course, we don’t need to tell Hackaday readers that there’s plenty of other things you can do with such a tiny open hardware Linux SBC.
Today we’re happy to report that [Walker] has gotten the first version of the board booted into Linux, though as you might expect given a project of this complexity, there were a few bumps along the way. From the single missing resistor that caused U-Boot to throw up an error to the finer points of compiling the kernel for an embedded board, the latest blog post he’s written up about his progress provides fascinating insight into the little gotchas of bringing up a SBC from scratch.
Once the board was booted into Linux, [Walker] started testing out different aspects of the system. A memory benchmark confirmed the finicky DDR3 RAM was working as expected, and he was able to load the kernel modules for the dual RTL8188 interfaces and connect to a network. While the two WiFi modules are currently hanging off the board’s full-sized USB ports, they will eventually be integrated into the PCB.
Critically, this prototype board is also allowing [Walker] to get an idea of what the energy consumption of the final hardware might be. Even at full tilt, this larger board doesn’t go over 500 mA at 5 VDC; so if he designs the power supply with a maximum output of 1 A, he should have a nice safety margin. As mentioned in the previous post, the plan is currently to put the PSU on its own board, which will allow more effective use of the charger’s internal volume.
With the software and hardware now largely locked in, [Walker] says his attention will be turned towards getting everything small enough to fit into the final form factor. This will certainly be the most challenging aspect of the project, but with a growing community of hackers and engineers lending their expertise to the cause, we’re confident the WiFiWart will soon be a reality.
You can hardly mention the sudo command without recalling the hilarious XKCD strip about making sandwiches. It does seem like sudo is the magic power to make a Linux system do what you want. The only problem is that those superpowers are not something to be taken lightly.
CC-BY-NC-2.5 by [XKCD]If you are surfing the web, for example, you really don’t want to be root, because if someone naughty takes over your computer they could do a lot more harm with your root password. But still, there are times when you want to run certain commands that are normally root-only and don’t want to bother with a password. Luckily, sudo can handle that use case very easily.
Why?
As a simple example, suppose you like to shut your computer down at the end of the day. You run the shutdown command from the terminal but it doesn’t work because you aren’t root. You then have to do it again with sudo and if you haven’t logged in lately, provide your password. Ugh.
You may remember the Pipewire coverage we ran a couple weeks ago, and the TODO item to fix up Firewire device support with Pipewire. It turns out that this is an important feature for kernel hackers, too, because the Alsa changes just got pulled into the 5.14 kernel, and included is the needed Firewire audio work. Shout-out to [Marcan] for pointing out this changeset. Yes, that’s the same as [Hector Martin], the hacker bringing Linux to the M1, who also discovered M1racles. We’ve covered some of his work before.
It turns out that some Firewire audio devices expect timing information in the delivery stream to match the proper playback time for the audio contained in the stream. A naive driver ends up sending packets of sound to the Firewire device that wanted to be played before the packet arrives. No wonder the devices didn’t work correctly. I’m running a 5.14 development kernel, and so far my Focusrite Saffire Pro40 has been running marvelously, where previous kernels quickly turned its audio into a crackling mess.
There is another fix that’s notable for Pipewire users, a reduction in latency for USB audio devices. That one turned out to be not-quite-correct, leading to a hang in the kernel on Torvald’s machine. It’s been reverted until the problem can be corrected, but hopefully this one will land for 5.14 as well. (Edit: The patch was cleaned up, and has been pulled for 5.14. Via Phoronix.) Let us know if you’d like to see more kernel development updates!
