Linux Fu: Pimp Your Pipes

One of the best things about working at the Linux (or similar OS) command line is the use of pipes. In simple terms, a pipe takes the output of one command and sends it to the input of another command. You can do a lot with a pipe, but sometimes it is hard to work out the right order for a set of pipes. A common trick is to attack it incrementally. That is, do one command and get it working with the right options and inputs. Then add another command until that works. Keep adding commands and tweaking until you get the final results.

That’s fine, but [akavel] wanted better and used Go to create “up” — an interactive viewer for pipelines.

Pipe Philosophy

Pipes can do a lot. They match in with the original Unix philosophy of making each tool do one thing really well. Pipe is really good at allowing Linux commands to talk to each other. If you want to learn all about pipes, have a look at the Linux Info project’s guide. They even talk about why MSDOS pipes were not really pipes at all. (One thing that write up doesn’t touch on is the named pipe. Do a “man fifo” if you want to learn more for now and perhaps that will be the subject of a future Linux Fu.)

This program — called up — continuously runs and reruns your pipeline as you make changes to the pipe. This way, every change you make is instantly reflected in the output. Here’s the video, here’s a quick video which shows off the interactive nature of up.

Installing

The GitHub page assumes you know how to install a go program. I tried doing a build but I didn’t have a few dependencies. Turns out the easy way to do it was to run this line:

go get -u github.com/akavel/up

This put the executable in ~/go/bin — which isn’t on my path. You can, of course, copy or link it to some directory that’s on your path or add that directory to your path. You could also set an alias, for example. Or, like I did in the video, just specify it every time.

Perfect?

This seems like a neat simple tool. What could be better? Well, I was a little sad that you can’t use emacs or vi edit keys on the pipeline, at least not as far as I could tell. This is exactly the kind of thing where you want to back up into the middle and change something. You can use the arrow keys, though, so that’s something. I also wished the scrollable window had a search feature like less.

Otherwise, though, there’s not much to dislike about the little tool. If writing a pipeline is like using a C compiler, up makes it more like writing an interactive Basic program.

Linux Fu: Marker is a Command Line Menu

The command line. You either love it or hate it, but if you do anything with a Unix-like system you are going to have to use it eventually. You might find marker — a system billed as a “command palette for the terminal” — a useful program to install. We couldn’t decide if it was like command history on steroids or more of a bookmark system. In a way, it is a little of both.

Your history rolls off eventually and also contains a lot of small commands (although you can use the HISTIGNORE variable to ignore particular commands). With marker, you save specific commands and they stay saved. There are no extra commands nor do the ones you save ever roll off.

Of course, you could just make a shell script or an alias if that’s all there was to it. Marker lets you add a description to the command and then you can search through the commands and the descriptions using a fuzzy incremental search. In addition, you can put placeholders into your command lines that are easily replaced. There are some built-in commands to get you started and the same bookmarks will work in bash and zsh, if you use both.

Continue reading “Linux Fu: Marker is a Command Line Menu”

Can You “Take Back” Open Source Code?

It seems a simple enough concept for anyone who’s spent some time hacking on open source code: once you release something as open source, it’s open for good. Sure the developer might decide that future versions of the project close up the source, it’s been known to happen occasionally, but what’s already out there publicly can never be recalled. The Internet doesn’t have a “Delete” button, and once you’ve published your source code and let potentially millions of people download it, there’s no putting the Genie back in the bottle.

But what happens if there are extenuating circumstances? What if the project turns into something you no longer want to be a part of? Perhaps you submitted your code to a project with a specific understanding of how it was to be used, and then the rules changed. Or maybe you’ve been personally banned from a project, and yet the maintainers of said project have no problem letting your sizable code contributions stick around even after you’ve been kicked to the curb?

Due to what some perceive as a forced change in the Linux Code of Conduct, these are the questions being asked by some of the developers of the world’s preeminent open source project. It’s a situation which the open source community has rarely had to deal with, and certainly never on a project of this magnitude.

Is it truly possible to “take back” source code submitted to a project that’s released under a free and open source license such as the GPL? If so, what are the ramifications? What happens if it’s determined that the literally billions of devices running the Linux kernel are doing so in violation of a single developer’s copyright? These questions are of grave importance to the Internet and arguably our way of life. But the answers aren’t as easy to come by as you might think.

Continue reading “Can You “Take Back” Open Source Code?”

A $1, Linux-Capable, Hand-Solderable Processor

Over on the EEVblog, someone noticed an interesting chip that’s been apparently flying under our radar for a while. This is an ARM processor capable of running Linux. It’s hand-solderable in a TQFP package, has a built-in Mali GPU, support for a touch panel, and has support for 512MB of DDR3. If you do it right, this will get you into the territory of a BeagleBone or a Raspberry Pi Zero, on a board that’s whatever form factor you can imagine. Here’s the best part: you can get this part for $1 USD in large-ish quantities. A cursory glance at the usual online retailers tells me you can get this part in quantity one for under $3. This is interesting, to say the least.

The chip in question, the Allwinner A13, is a 1GHz ARM Cortex-A8 processor. While it’s not much, it is a chip that can run Linux in a hand-solderable package. There is no HDMI support, you’ll need to add some more chips (that are probably in a BGA package), but, hey, it’s only a dollar.

If you’d like to prototype with this chip, the best options right now are a few boards from Olimex, and a System on Module from the same company. That SoM is an interesting bit of kit, allowing anyone to connect a power supply, load an SD card, and get this chip doing something.

Currently, there aren’t really any good solutions for a cheap Linux system you can build at home, with hand-solderable chips. Yes, you could put Linux on an ATMega, but that’s the worst PC ever. A better option is the Octavo OSD335x SoC, better known as ‘the BeagleBone on a Chip’. This is a BGA chip, but the layout isn’t too bad, and it can be assembled using a $12 toaster oven. The problem with this chip is the price; at quantity 1000, it’s a $25 chip. At quantity one, it’s a $40 chip. NXP’s i.MX6 chips have great software support, but they’re $30 chips, and you’ll need some DDR to make it do something useful, and that doesn’t even touch the fiddlyness of a 600-ball package

While the Allwinner A13 beats all the other options on price and solderability, it should be noted that like all of these random Linux-capable SoCs, the software is a mess. There is a reason those ‘Raspberry Pi killers’ haven’t yet killed the Raspberry Pi, and it’s because the Allwinner chips don’t have documentation and let’s repeat that for emphasis: the software is a mess.

Still, if you’re looking for a cheap chip you can solder at home, this one seems to be the only game in town. We’re really looking forward to seeing what you make with it!

Linux, Without The Git Factor

Linux started as a student project in the 1990s, the creation of Linus Torvalds. He has attained celebrity status while steering his creation through the decades, but along the way he has also attracted a different reputation within the Linux and software community. He is famous for his outbursts and rants, some of which become rather personal, and it is not difficult at all to find kernel developers or would-be kernel developers who have turned their backs on the project as a result.

It’s very refreshing indeed then to read an update from [Linus] as part of his regular communications, in which he admits that he has an issue, and says that he is taking the time to seek help for it. There is an accompanying update to the kernel maintenance code of conduct, which suggests that this is likely to mark a sea-change in that environment, as well as we hope salvage that aspect of [Linus]’ reputation.

“My flippant attacks in emails have been both unprofessional and uncalled for. Especially at times when I made it personal. In my quest for a better patch, this made sense to me. I know now this was not OK and I am truly sorry.”

The Hackaday community has a much greater than average proportion of Linux users among its readership. Even those readers who use a desktop OS with BSD, Windows, or other kernels will almost certainly have a Linux kernel somewhere, whether it’s in their phone, their set-top-box, their children’s toys, or even their domestic appliances. And of course a large swath of the Internet runs on Linux. It is in the best interest of us all that we continually attract and retain brilliant people to contribute to the effort put into developing and maintaining the Linux kernel.

Without wishing to lionise [Linus] above the many others whose work has also contributed to Linux and its success, his contribution to our community has been beyond measure and it has been uncomfortable to see his other side. It’s a step in the right direction to apologize for personal attacks and behavior that drives a wedge into the kernel developer community, and seek to change that behavior. We’d urge others to follow his example, we’re sure every grouping has at times had its personality problems, and it’s never too late to enact some repairs.

While Linus steps away to work on his self improvement, veteran kernel developer Greg Kroah-Hartman will take the reigns among the kernel maintainers.

$99 Pinebook Gets KDE Neon Port

If you’re the kind of person who likes small and cheap Linux devices, you’re definitely alive in the perfect moment in history. It seems as if every few months we’ve got another tiny Linux board competing for our pocket change, all desperate to try to dethrone the Raspberry Pi which has already set the price bar exceptionally high (or low, as the case may be). We’ve even started to see these Linux boards work their way into appropriately cheap laptops, though so far none have really made that great of an impression.

But thanks to the efforts of Blue Systems and Pine64, the situation might be improving: they’ve worked together on a build of KDE Neon for the $99 Pinebook. The fact that they’ve gotten Plasma, KDE’s modern desktop environment, running on the rather mediocre hardware at all is an accomplishment by itself. But they’ve also set out tailor the entire system for the Pinebook, from the kernel and graphics drivers all the way up to Qt and Plasma tweaks.

In a blog post announcing the release candidate of the OS, Neon developer [Jonathan Riddell] says that these top-to-bottom improvements show that you can turn a super cheap Linux laptop into a practical computer if you’re willing to really get in there and optimize it. He also says the project has been something of a two-way street, in that improvements made for the Pinebook build have also been applied to upstream development.

The last time we looked at the Pinebook, we came away cautiously optimistic. It wasn’t great, but it was about as good as you could possibly expect given the price. If more developers are willing to go out on a limb and start optimizing their software for the device, it might become a very promising platform for low-cost mobile hacking.

Linux Fu: Modernize Your Command Line

If you use Linux and its associated tools on the desktop or on a Raspberry Pi, or on a server, you probably have used the command line. Some people love it and some people hate it. However, many of us have been using Linux for years and sometimes Unix before that, and we tend to use the same old tried-and-true tools. [Remy Sharp] had a recent post talking about how he had created aliases to replace those old tools with great modern replacements and it is definitely worth a read.

We’ll be honest, when we first saw the post we almost skipped reading it. A lot of Linux tip posts are pretty uninteresting unless you are a total beginner. But [Remy] has a lot of really great tools and how he has them installed including bat, which is like cat but with syntax coloring (see picture above), and fzf — a command line history search on steroids. He even shows how to join fzf and bat to make a very cool file browser from the command line (see below).

Continue reading “Linux Fu: Modernize Your Command Line”