Optimizing Your Linux Shell Experience

Are you familiar with Huffman encoding? That’s where you pick shorter codes for more frequent letters. Morse code is the same way, in that the most-used letters are the shortest. [Matheus Richard] had the same idea for optimizing your workflow in the Linux shell. The idea is to measure what commands you use the most and make them shorter.

Continue reading “Optimizing Your Linux Shell Experience”

Finally… A Man Page For Life

How often have you wished to have an instruction manual — or, at least, a Unix man page — for life? Well, your wait is over. Of course, you probably were hoping for instructions on how to navigate life, but [cve’s] mott program plays life inside a man page. That might not be as useful as a real manual for life, but it is still pretty cool.

To understand what’s happening, you have to understand how man pages work. They use an old form of markup known as roff, which later begat nroff and troff. While roff is made to do crude word processing at the dawn of Unix, it is also a Turing-complete language.

Continue reading “Finally… A Man Page For Life”

Running Fusion 360 On Linux With Wine

One of the major reasons why using Linux on a desktop system is unsuitable for many is due to the lack of Linux support for many major applications, including Autodesk Fusion 360. Naturally, using Wine this should be easy in an ideal world, but realistically getting something like Fusion 360 set up and ready to log in with Wine will take some serious time. Fortunately [Steve Zabka] created some shell scripts to automate the process. As demonstrated by [Tech Dregs] on YouTube, this seems to indeed work on a Fedora system, with just a few glitches.

Among these glitches are some rendering artefacts like application controls remaining on the desktop after closing the application, in-application line rendering and [Tech Dregs] was unable to switch from the DirectX 9 renderer to the DirectX 11 one. Since Fusion 360 will soon drop DirectX 9 and OpenGL support, this would seem to be rather an important detail. The GitHub project seems to indicate that this should work, but [Tech Dregs] reported only getting a black screen after switching.

Clearly, using applications like Fusion 360 on Linux isn’t quite what you’d want to use for a production workflow in a commercial setting (even ignoring lack of Autodesk support), but it could be useful for students and others who’d like to not switch to Windows or MacOS just to use this kind of software for a course or hobbyist use.

Continue reading “Running Fusion 360 On Linux With Wine”

A Potential Exploit With The Ext Filesystem

The extended filesystem, otherwise known as ext, has been a fundamental part of Linux since before the 1.0 release in 1994. Currently the filesystem is on its fourth major revision, in use since its release in 2008 thanks to its stability, reliability, and backwards compatibility with the other ext filesystem versions. But with that much history there are bound to be a few issues cropping up here and there. [Will] recently found an exploit with this filesystem that can cause a Linux kernel to immediately panic when a manipulated USB drive is inserted into a computer.

[Will] discovered this quirk when investigating the intricacies of the filesystem for problems and other vulnerabilities. A tool called tune2fs, used for administering and modifying ext filesystems, includes the ability to pass certain commands to the Linux kernel when certain situations arise with the filesystem itself, including that the kernel should panic. One situation is that the ext filesystem itself becomes corrupted, which can then cause the kernel panic. Armed with this knowledge, a USB drive can be purposefully given a corrupted ext filesystem which, when plugged into a Linux machine, can cause the computer to shut down.

The post linked above goes into some discussion about how this exploit could be used maliciously to gain access to a Linux system, including rebooting computers where no access to a power button is otherwise enabled or making other changes to the system before needing a reboot to apply the changes. In general, though, it’s good to assume an attacker could take any route to gain access to a machine. This exploit from a few years ago, for example, allowed another Linux tool to be used to gain root access.

Thanks to [Timothy] for the tip!

Alternatives Don’t Need To Be Bashed

By default, bash is the most popular command language simply because it’s included in most *nix operating systems. Additionally, people don’t tend to spend a lot of time thinking about whatever their computer uses for scripting as they might for other pieces of software like a word processor or browser. If you are so inclined to take a closer look at this tool that’s often taken for granted, there are a number of alternatives to bash and [monzool] wanted to investigate them closely.

Unlike other similar documentation that [monzool] has come across where the writers didn’t actually use the scripting languages being investigated, [monzool] is planning to use each of these and accomplish specific objectives. This will allow them to get a feel for the languages and whether or not they are acceptable alternatives for bash. Moving through directories, passing commands back and forth, manipulating strings, searching for files, and manipulating the terminal display settings are all included in this task list. A few languages are tossed out before initial testing even begins for not meeting certain specific requirements. One example is not being particularly useful in [monzool]’s preferred embedded environments, but even so there are enough bash alternatives to test out ten separate languages.

Unfortunately, at the end of the day none of the ten selected would make a true replacement for bash, at least for [monzool]’s use case, but there were a few standouts nonetheless. Nutshell was interesting for being a more modern, advanced system and [monzool] found Janet to be a fun and interesting project but had limitations with cross-compiling. All in all though this seemed to be an enjoyable experience that we’d recommend if you actually want to get into the weeds on what scripting languages are actually capable of. Another interesting one we featured a while back attempts to perform as a shell and a programming language simultaneously.

Linux Fu: Audio Network Pipes

Life was simpler when everything your computer did was text-based. It is easy enough to shove data into one end of a pipe and take it out of the other. Sure, if the pipe extends across the network, you might have to call it a socket and take some special care. But how do you pipe all the data we care about these days? In particular, I found I wanted to transport audio from the output of one program to the input of another. Like most things in Linux, there are many ways you can get this done and — like most things in Linux — only some of those ways will work depending on your setup.

Why?

There are many reasons you might want to take an audio output and process it through a program that expects audio input. In my case, it was ham radio software. I’ve been working on making it possible to operate my station remotely. If all you want to do is talk, it is easy to find software that will connect you over the network.

However, if you want to do digital modes like PSK31, RTTY, or FT8, you may have a problem. The software to handle those modes all expect audio from a soundcard. They also want to send audio to a soundcard. But, in this case, the data is coming from a program.

Of course, one answer is to remote desktop into the computer directly connected to the radio. However, most remote desktop solutions aren’t made for high-fidelity and low-latency audio. Plus, it is nice to have apps running directly on your computer.

I’ll talk about how I’ve remoted my station in a future post, but for right now, just assume we want to get a program’s audio output into another program’s audio input. Continue reading “Linux Fu: Audio Network Pipes”

I Installed Gentoo So You Don’t Havtoo

A popular expression in the Linux forums nowadays is noting that someone “uses Arch btw”, signifying that they have the technical chops to install and use Arch Linux, a distribution designed to be cutting edge but that also has a reputation of being for advanced users only. Whether this meme was originally posted seriously or was started as a joke at the expense of some of the more socially unaware Linux users is up for debate. Either way, while it is true that Arch can be harder to install and configure than something like Debian or Fedora, thanks to excellent documentation and modern (but optional) install tools it’s no longer that much harder to run than either of these popular distributions.

For my money, the true mark of a Linux power user is the ability to install and configure Gentoo Linux and use it as a daily driver or as a way to breathe life into aging hardware. Gentoo requires much more configuration than any mainline distribution outside of things like Linux From Scratch, and has been my own technical white whale for nearly two decades now. I was finally able to harpoon this beast recently and hope that my story inspires some to try Gentoo while, at the same time, saving others the hassle.

A Long Process, in More Ways Than One

My first experience with Gentoo was in college at Clemson University in the late ’00s. The computing department there offered an official dual-boot image for any university-supported laptop at the time thanks to major effort from the Clemson Linux User Group, although the image contained the much-more-user-friendly Ubuntu alongside Windows. CLUG was largely responsible for helping me realize that I had options outside of Windows, and eventually I moved completely away from it and began using my own Linux-only installation. Being involved in a Linux community for the first time had me excited to learn about Linux beyond the confines of Ubuntu, though, and I quickly became the type of person featured in this relevant XKCD. So I fired up an old Pentium 4 Dell desktop that I had and attempted my first Gentoo installation.

For the uninitiated, the main thing that separates Gentoo from most other distributions is that it is source-based, meaning that users generally must compile the source code for all the software they want to use on their own machines rather than installing pre-compiled binaries from a repository. So, for a Gentoo installation, everything from the bootloader to the kernel to the desktop to the browser needs to be compiled when it is installed. This can take an extraordinary amount of time especially for underpowered machines, although its ability to customize compile options means that the ability to optimize software for specific computers will allow users to claim that time back when the software is actually used. At least, that’s the theory. Continue reading “I Installed Gentoo So You Don’t Havtoo”