New Part Day: A $6 Linux Computer You Might Be Able To Write Code For

November 12, 2018 by Brian Benchoff 81 Comments

The latest news from the world of cheap electronics is a single board computer running Linux. It costs six dollars, and you can buy it right now. You might even be able to compile code for it, too.

The C-Sky Linux development board is listed on Taobao as an ‘OrangePi NanoPi Raspberry Pi Linux Development Board” and despite some flagrant misappropriation of trademarks, this is indeed a computer running Linux, available for seven American dollars.

This board is based on a NationalChip GX6605S SoC, a unique chip with an ISA that isn’t ARM, x86, RISC-V, MIPS, or anything else that would be considered normal. The chip itself was designed for set-top boxes, but there are a surprising number of build tools that include buildroot, GCC and support for qemu. The company behind this chip is maintaining a kernel, and support for this chip has been added to the mainline kernel. Yes, unlike many other single board computers out there, you might actually be able to compile something for this chip.

The features for this board include 64 MB of DDR2 RAM, HDMI out (with a 1280 x 720 framebuffer, upscaled to 1080p, most likely), and a CPU running at just about 600 MHz. There are a few buttons connected to the GPIO pins, two USB host ports, a USB-TTL port for a serial console, and a few more pins for additional GPIOs. There does not appear to be any networking, and we have no idea what the onboard storage is.

If you want a challenge to get something compiled, this is the chip for you.

Linux Fu: Pimp Your Pipes

November 7, 2018 by Al Williams 17 Comments

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.

The Linux Throwie: Powering A Linux Server With A 0.3W Solar Panel

November 2, 2018 by Sean Boyce 63 Comments

Have you ever had one of those moments, when you’re rummaging through your spare parts heap, and have a rather bizarre project idea that you can’t quite get out of your head? You know, the ones that have no clear use, but simply demand to be born, of glass and steel and silicon?

This time, the stubborn idea in question was sort of like a solar-rechargeable LED throwie, but instead of a blinking light, it has a fully cloud-accessible embedded Linux server in the form of a Raspberry Pi 3 Model B+. Your choice of embedded Linux board should work — I just happen to have a lot of these due to a shipping error.

There were two main challenges here: First, it would have to combine the smallest practical combination of solar panel, power supply, and Li-ion cell that could run the Raspberry Pi. Second, we’ll need to remotely activate and access the Pi regardless of where it is, as well as be able to connect it to WiFi without direct physical access. In this article we’ll be dealing with the first set of problems — stay tuned for the rest.

Continue reading “The Linux Throwie: Powering A Linux Server With A 0.3W Solar Panel” →

Linux Fu: Marker Is A Command Line Menu

October 24, 2018 by Al Williams 21 Comments

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

Perfecting The Solar Powered Web Server

October 8, 2018 by Tom Nardi 35 Comments

Running a server completely off solar power seems like it would be a relatively easy thing to do: throw up a couple of panels, tack on a charge controller and a beefy battery, and away you go. But the reality is somewhat different. Most of us hackers are operating on a relatively limited budget and probably don’t have access to the kind of property you need to put out big panels; both pretty crippling limitations. Doing solar on a small-scale is hard, and unless you really plan ahead your setup will probably be knocked out on its first cloudy day.

So when [Kris de Decker] wanted to create a solar-powered version of his site “Low-tech Magazine”, he went all in. Every element of the site and the hardware it runs on was investigated for potential power savings, and luckily for us, the entire process was written up in meticulous detail (non-solar version here). The server still does go down from time to time if the weather is particularly poor, but in general it maintains about 90% uptime in Barcelona, Spain.

The solar side of the equation is fairly simple. There’s a 50 watt photovoltaic panel charging a 12V 7Ah lead-acid battery though a 20A charge controller. With an average of 4 to 6 hours of sunlight a day, the panel generates 300 Wh of electricity in the best case scenario; which needs to be split between charging the battery and running the server itself.

As for the server, [Kris] chose the Olimex Olinuxino A20 Lime 2 in part because of it being open source hardware, but also because it’s very energy-efficient and includes a AXP209 power management chip. Depending on processor load, the Olimex board draws between 1 and 2.5 watts of power, which combined with charging losses and such means the system can run through two days of cloudy weather before giving up the ghost. A second battery might be added in the future to help improve the run time during low-light conditions, but for now its been working pretty well.

Perhaps the most interesting part of the whole project are the lengths to which the website itself was optimized to keep resource utilization as low as possible. Images are compressed using dithering to greatly reduce their file sizes, and the site eschews modern design in favor of a much less processor intensive static layout. There’s even a battery capacity display integrated into the page through some clever use of CSS. Even if you aren’t looking to set up your own sun worshiping website, there are tips here for building efficient web pages that could absolutely be put to use in other projects.

If you’re interested in solar projects, we’ve got you covered. From an open source charge controller to building DIY photovoltaic panels, there’s plenty of prior art you should find very…illuminating. Please clap.

Linux Fu: Keep An Eye On That File

October 4, 2018 by Al Williams 38 Comments

One of the things that’s nice about Linux or Unix compared to many other operating systems is there’s a good chance a Linux program will spew out informational messages to a log somewhere. Many commands even have a way to turn on more logs. I know that Windows has the event viewer, but many programs don’t have much to say which makes it difficult to know what’s happening when things go wrong.

The problem is, sometimes programs tell you too much information. How do you find what you want to know? It looks cool on a movie where the hacker is in front of a terminal scrolling 500 lines a second of some log file, but in real life, it is hard to read a moving screen, although with some practice you can sometimes — unreliably — pick out a keyword as it whizzes by.

Like most Unix things, there’s a tool for that. In fact, unsurprisingly, there are many tools for that. If you are using the tail command, that’s certainly one of them. But there are others you should consider.

Continue reading “Linux Fu: Keep An Eye On That File” →

Linux, Without The Git Factor

September 17, 2018 by Jenny List 82 Comments

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.