While it is undeniable that cloud-based services are handy, there are people who would rather do it themselves. For many of us, it is because we want what we want the way we want it. For others, it is a distrust of leaving your personal data on someone’s server you don’t control. Umbrel is a Linux distribution just for people who want to self-host popular applications like NextCloud or Home Assistant. [ItsFoss] has a good review that points out some of the plusses and minuses of the early version of Umbrel.
What’s really interesting, though, is the approach the distro takes to installing software. Like most modern distributions, Umbrel has a package manager. Unlike most, though, the packages are actually docker containers. So when you install an app, it is preconfigured and lives in its own bubble, unlikely to conflict with other things you might install.
We also like that it has a specific build for a Raspberry Pi, although it will work on other 64-bit hardware and you can even install it within docker on top of your normal operating system. Of course, the docker container concept is also a drawback — at least for now — because it can be difficult to adjust settings inside the container compared to a more conventional install.
It amazes us that hardware has become so capable that it is easier to just duplicate entire operating systems than it is to work out the required dependency interactions. Still, it works, and in most cases, it works well.
If you want to know more about Docker, we’ve covered it a few times in the past. You can even use it for very simple development cases if you like.
Continue reading “Easier Self Hosting With Umbrel”
Most computer operating systems suffer from some version of “DLL hell” — a decidedly Windows term, but the concept applies across the board. Consider doing embedded development which usually takes a few specialized tools. You write your embedded system code, ship it off, and forget about it for a few years. Then, the end-user wants a change. Too bad the compiler you used requires some library that has changed so it no longer works. Oh, and the device programmer needs an older version of the USB library. The Python build tools use Python 2 but your system has moved on. If the tools you need aren’t on the computer anymore, you may have trouble finding the install media and getting it to work. Worse still if you don’t even have the right kind of computer for it anymore.
One way to address this is to encapsulate all of your development projects in a virtual machine. Then you can save the virtual machine and it includes an operating system, all the right libraries, and basically is a snapshot of how the project was that you can reconstitute at any time and on nearly any computer.
In theory, that’s great, but it is a lot of work and a lot of storage. You need to install an operating system and all the tools. Sure, you can get an appliance image, but if you work on many projects, you will have a bunch of copies of the very same thing cluttering things up. You’ll also need to keep all those copies up-to-date if you need to update things which — granted — is sort of what you are probably trying to avoid, but sometimes you must.
Docker is a bit lighter weight than a virtual machine. You still run your system’s normal kernel, but essentially you can have a virtual environment running in an instant on top of that kernel. What’s more, Docker only stores the differences between things. So if you have ten copies of an operating system, you’ll only store it once plus small differences for each instance.
The downside is that it is a bit tough to configure. You need to map storage and set up networking, among other things. I recently ran into a project called Dock that tries to make the common cases easier so you can quickly just spin up a docker instance to do some work without any real configuration. I made a few minor changes to it and forked the project, but, for now, the origin has synced up with my fork so you can stick with the original link.
Continue reading “Linux Fu: Docking Made Easy”
If you want the classic experience of working with an IBM mainframe or another classic computer like a DEC VAX, you have a few choices. You could spend a lot of money trying to find one, transport it, and refurbish it. But, of course, most of us will settle for an emulator. While there are great emulators out there, most of the time you aren’t interested in running just the bare machine — you want the operating systems, the compilers, and the other software that made these machines so interesting. Running your three lines of machine code isn’t as much fun as playing hunt the wumpus or compiling some Fortran IV code. Unfortunately, finding copies of all this old software can be daunting. But thanks to the efforts of [Rattydave], you can do it with no problems at all. The secret? Pre-built docker images that have everything you need in one place.
Continue reading “Your Own IBM Mainframe (or Vax, Or Cray…) The Easy Way”
Farming is a challenge under even the best of circumstances. Almost all conventional farmers use some combination of tillers, combines, seeders and plows to help get the difficult job done, but for those like [Taylor] who do not farm large industrial monocultures, more specialized tools are needed. While we’ve featured the Acorn open source farming robot before, it’s back now with new and improved features and a simulation mode to help rapidly improve the platform’s software.
The first of the two new physical features includes a fail-safe braking system. Since the robot uses electric geared hub motors for propulsion, the braking system consists of two normally closed relays which short the motor leads in emergency situations. This makes the motors see an extremely high load and stops them from turning. The robot also has been given advanced navigation facilities so that it can follow custom complex routes. And finally, [Taylor] created a simulation mode so that the robot’s entire software stack can be run in Docker and tested inside a simulation without using the actual robot.
For farmers who are looking to buck unsustainable modern agricultural practices while maintaining profitable farms, a platform like Acorn could be invaluable. With the ability to survey, seed, harvest, and even weed, it could perform every task of larger agricultural machinery. Of course, if you want to learn more about it, you can check out our earlier feature on this futuristic farming machine.
When the PlayStation 3 first launched, one of its most lauded features was its ability to officially run full Linux distributions. This was of course famously and permanently borked by Sony with a software update after a few years, presumably since the console was priced too low to make a profit and Sony didn’t want to indirectly fund server farms made out of relatively inexpensive hardware. Of course a decision like this to keep Linux off a computer system is only going to embolden Linux users to put it on those same systems, and in that same vein this project turns a more modern Playstation 4 into a Kubernetes cluster with the help of the infamous OS.
The Playstation 4’s hardware is a little dated by modern desktop standards but it is still quite capable as a general-purpose computer provided you know the unofficial, unsupported methods of installing Psxitarch Linux on one. This is a distribution based on Arch and built specifically for the PS4, but to get it to run the docker images that [Zhekun Hu] wanted to use some tinkering with the kernel needed to be done. With some help from the Gentoo community a custom kernel was eventually compiled, and after spending some time in what [Zhekun Hu] describes as “Linux Kernel Options Hell” eventually a working configuration was found.
The current cluster is composed of two PS4s running this custom software and runs a number of services including Nginx, Calico, Prometheus, and Grafana. For those with unused PlayStation 4s laying around this might be an option to put them back to work, but it should also be a cautionary tale about the hassles of configuring a Linux kernel from scratch. It can still be done on almost any machine, though, as we saw recently using a 386 and a floppy disk.
Until a few years ago, developing for FPGAs required the use of proprietary locked-down tools, but in the last few years, the closed-source dam has burst, and open-source FPGA tools such as Yosys, SimbiFlow, and Icestorm have come flooding out. Setting up a build environment for these exciting new tools can still be quite a challenge, but [Carlos Eduardo] has decided to make setting up an open-source toolchain for Xilinx FPGAs a breeze with Docker.
His image only has three prerequisites: Docker, Python 3, and OpenOCD (which is used to load your FPGA with your bespoke bitfile). After the Docker image has been built and all of the tools installed, [Carlos] guides you through using Python, FuseSoc, and SymbiFlow to build your first open-source Xilinx FPGA project.
In addition to making setup a whole lot easier, utilizing containers allows the same development environment to be built on Linux, Mac, and Windows (using WSL), which will make life a lot easier for teams working across different OSs. [Carlos’s] Dockerfile is unique because it supports the popular Artix-7 series of FPGAs — for the Lattice FPGAs that have been supported for a lot longer, there are existing Docker files already up on DockerHub. It’s easier than installing the vendor’s toolchain!
If this has you thinking it might be time to dip your toes into open-source FPGA development, check out this rundown of open-source FPGA tools from the 2019 Superconference.
We can sympathize with [Benjamin Cabé]. He has a lot of development boards and it has become painful to maintain the many toolchains for each board. We’ve also suffered from upgrading one tool breaks another tool in some obscure way. His solution? Use Github Codespaces which you can get early access for beta testers.
The idea is that you can spin off a container-specific to a GitHub repository that has all the proper versions and dependencies required to work with a project.
If you sign up for the beta, you’ll be on a waitlist, but it is interesting to see [Benjamin] go through the steps. The service is free during the beta and you get two codespaces. Presumably, you’ll eventually be able to pay for more capability.
The idea is good, but we’ll have to see about the implementation. A preconfigured container might move from machine to machine or even to deep storage for later reconstitution. Flashing the binary image to the device looked painful from the browser. We’ve seen it done nicely with, for example, the online Arduino IDE but it did take some installable software helpers to do that.
We’ll be curious about how many different platforms this will support. However, you can roll your own version of this and avoid the cloud using Docker or even a full-blown VM like VirtualBox. Sure, it is more work, but you control your destiny. Add something like Platform.IO and your choice of development tools and you can avoid having so many competing development tools all in your main computer.
Continue reading “Codespaces For Embedded Development”