If you are a Linux user that has to use Windows — or even a Windows user that needs some Linux support — Cygwin has long been a great tool for getting things done. It provides a nearly complete Linux toolset. It also provides almost the entire Linux API, so that anything it doesn’t supply can probably be built from source. You can even write code on Windows, compile and test it and (usually) port it over to Linux painlessly.
However, Cygwin’s package management is a little clunky and setting up the GUI environment has always been tricky, especially for new users. A project called Swan aims to make a full-featured X11 Linux environment easy to install on Windows.
The project uses Cygwin along with Xfce for its desktop. Cygwin provides pretty good Windows integration, but Swan also includes extra features. For example, you can make your default browser the Windows browser with a single click. It also includes spm — a package manager for Cygwin that is somewhat easier to use, although it still launches the default package manager to do the work (this isn’t a new idea, by the way).
Continue reading “Swan: Better Linux on Windows”
There was a time a few years ago when the first Android phones made it to market, that they seemed full of promise as general purpose computers. Android is sort of Linux, right, or so the story went, so of course you must be able to run Linux on an Android phone and do all sorts of cool stuff with it.
As anyone who tried to root an Android phone from 2010 will tell you, it was a painful and unrewarding process. There was normally a convoluted rooting process followed by somehow squeezing your own Linux filesystem tree onto the device, then chroot-ing into it. You’d then have to set up a VNC server and VNC into it, and eventually you’d feel immensely proud of your very slow tiny-screen Linux desktop that you’d slaved over creating. It was one of those things that’s simple in theory, but extremely convoluted in practice.
But six years have passed since those days, phones have gotten much faster and so has the software for tasks such as rooting, so maybe it’s time to return to the topic of Linux on an Android device. [Pete Scargill] gave it a try when a friend gave him a Chinese quad-core Android phone with a broken screen. He proceeded to put a Debian installation on it, upon which he runs his collection of server processes.
Rooting the phone was straightforward process using the KingRoot app, a sideloaded version as it seems there’s a bogus copy on the Play Store. Then bringing a Linux system to it could be achieved with the LinuxDeploy app. The result is surprisingly useful, after some installation steps upon which he goes into detail.
You might ask what would be the point of this exercise, given that you can do the same thing much more easily with a single board computer such as a Raspberry Pi. But to buy a Pi, SD card, screen, and UPS, as he points out you’d have to spend a lot more than you would for a second-hand phone from eBay — or a free, slightly broken, one from friends or family.
If getting more from your Android phone is your thing, perhaps you’d like to know about installing Busybox on it. We’ve also advocated for using old Android phones for ARM dev.
Kids today are being loud with their ‘drum machines’ and ‘EDM’. Throw some Raspberry Pis at them, and there’s a need for a low-latency sound card with MIDI and all the other accouterments of the modern, Skrillex-haired rocker. That’s where PiSound comes in.
Of course, the Pi already comes with audio out, but that’s not enough if you want to do some real audio processing. You need audio in as well, and while you’re messing around with that, adding some high-quality opamps, ADCs, DACs, and some MIDI would be a good idea. This is what the PiSound is all about.
[Pranciskus], the guy who has been working on the PiSound for a while now, developed this multitool for audio on a tiny Linux system. One of the killer features on the PiSound is ‘The Button’, a simple tact switch that runs a script if the button is pressed, another script if the button is held down, and two more if the button is pressed two or three times. This is actually a pretty nifty UI, and we wouldn’t mind seeing this on a few more Pi accessories.
If you’d like to see some example projects using the PiSound, there example MIDI controllers, networked audio players, and some goofing around with LV2 plugins over here.
If you’ve used Linux from the early days (or, like me, started with Unix), you didn’t have to learn as much right away and as things have become more complex, you can kind of pick things up as you go. If you are only starting with Linux because you are using a Raspberry Pi, became unhappy with XP being orphaned, or you are running a cloud server for your latest Skynet-like IoT project, it can be daunting to pick it all up in one place.
Recently my son asked me how do you make something run on a Linux box even after you log off. I thought that was a pretty good question and not necessarily a simple answer, depending on what you want to accomplish.
There’s really four different cases I could think of:
- You want to launch something you know will take a long time.
- You run something, realize it is going to take a long time, and want to log off without stopping it.
- You want to write a script or other kind of program that detaches itself and keeps running (known as a daemon).
- You want some program to run all the time, even if you didn’t log in after a reboot.
Continue reading “Linux-Fu: Keeping Things Running”
Cyber security is on everyone’s minds these days. Embedded devices like cameras have been used by bad guys to launch attacks on the Internet. People worry about data leaking from voice command devices or home automation systems. And this goes for the roll-your-own systems we build and deploy.
Many network-aware systems use Linux somewhere — one big example is pretty much every Raspberry Pi based project. How much do you think about security when you deploy a Pi? There is a superior security system available for Linux (including most versions you’d use on the Pi) called SELinux. The added letters on the front are for “Security-Enhanced” and this project was originally started by the NSA and RedHat. RedHat actually has — no kidding — a coloring book that helps explain some of the basic concepts.
We aren’t so sure the coloring book format is really the right approach here, but it is a light and informative read (we didn’t stay in the lines very well, though). Our one complaint is that it doesn’t really show you anything in practice, it just explains the ideas behind the different kind of protections available in SELinux. If you want to actually set it up on Pi, there’s a page on the Pi site that will help. If you have an hour, you can get a good overview of using SELinux in the video below.
Continue reading “Better Linux Through Coloring”
A lot of embedded systems are running Linux on platforms like Raspberry Pi. Since Linux is fully functional from a command line and fully network-capable, it is possible to run servers that you’ve never had physical access to.
There are a few problems, though. Sometimes you really need to reboot the box physically. You also need to be at the console to do things like totally install a new operating system. Or do you? Over on GitHub, user [marcan] has a C program and a shell script that allows you to take over a running system without using any software on the root filesystem. It starts an ssh server and you can remotely unmount the main drive, do any maintenance you want and –presumably–reboot into a new operating system.
Continue reading “Giving Linux the Remote Boot”
Autodetection of hardware was a major part of making computers more usable for the average user. The Amiga had AutoConfig on its Zorro bus, Microsoft developed Plug And Play, and Apple used NuBus, developed by MIT. It’s something we’ve come to take for granted in the modern age, but it doesn’t always work correctly. [Evan] ran into just this problem with a video capture card that wouldn’t autodetect properly under Linux.
The video capture card consisted of four PCI capture cards with four inputs each, wired through a PCI to PCI-E bus chip for a total of sixteen inputs. Finding the cause of the problem wasn’t too difficult – the driver was detecting the card as a different model with eight inputs, instead of the sixteen inputs actually present on the card. The driver detects the device plugged in by a unique identifier reported by the card. The code on the card was identical to the code for a different model of card with different hardware, causing the issue.
As a quick test, [Evan] tried fudging the driver selection, forcing the use of a driver for a sixteen-input model. This was successful – all sixteen inputs could now be used. But it wasn’t a portable solution, and [Evan] would have to remember this hack every time the card needed to be reinstalled or moved to a different computer.
Looking further at the hardware, [Evan] discovered the card had four 24c02 EEPROM chips on board – one for each PCI card on board. Dumping the contents, they recognised the unique identifier the driver was using to determine the card’s model. It was then a simple job to change this value to one that corresponded with a sixteen-input card to enable functional autodetection by burning a new value to the EEPROM. [Evan] then published the findings to the LinuxTVWiki page. Continue reading “EEPROM Hack to Fix Autodetection Issues”