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.
The idea of having software translation programs around to do things like emulate a Super Nintendo on your $3000 gaming computer or, more practically, run x86 software on a new M1 Mac, seems pretty modern since it is so prevalent in the computer world today. The idea of using software like this is in fact much older and easily traces back into the 80s during the era of Commodore and Atari personal computers. Their hardware was actually not too dissimilar, and with a little bit of patience and know-how it’s possible to compile the Commodore 64 kernel on an Atari, with some limitations.
This project comes to us from [unbibium] and was inspired by a recent video he saw where the original Apple computer was emulated on Commodore 64. He took it in a different direction for this build though. The first step was to reformat the C64 code so it would compile on the Atari, which was largely accomplished with a Python script and some manual tweaking. From there he started working on making sure the ROMs would actually run. The memory setups of these two machines are remarkably similar which made this slightly easier, but he needed a few workarounds for a few speed bumps. Finally the cursor and HMIs were configured, and once a few other things were straightened out he has a working system running C64 software on an 8-bit Atari.
Unsurprisingly, there are a few things that aren’t working. There’s no IO besides the keyboard and mouse, and saving and loading programs is not yet possible. However, [unbibium] has made all of his code available on his GitHub page if anyone wants to expand on his work and may also improve upon this project in future builds. If you’re looking for a much easier point-of-entry for emulating Commodore software in the modern era, though, there is a project available to run a C64 from a Raspberry Pi.
Thanks to [Cprossu] for the tip!
Linux has come a long way from its roots, where users had to compile the kernel and all of the other source code from scratch, often without any internet connection at all to help with documentation. It was the wild west of Linux, and while we can all rely on an easy-to-install Ubuntu distribution if we need it, there are still distributions out there that require some discovery of those old roots. Meet SkiffOS, a lightweight Linux distribution which compiles on almost any hardware but also opens up a whole world of opportunity in containerization.
The operating system is intended to be able to compile itself on any Linux-compatible board (with some input) and yet still be lightweight. It can run on Raspberry Pis, Nvidia Jetsons, and x86 machines to name a few, and focuses on hosting containerized applications independent of the hardware it is installed on. One of the goals of this OS is to separate the hardware support from the applications, while being able to support real-time tasks such as applications in robotics. It also makes upgrading the base OS easy without disrupting the programs running in the containers, and of course has all of the other benefits of containerization as well.
It does seem like containerization is the way of the future, and while it has obviously been put to great use in web hosting and other network applications, it’s interesting to see it expand into a real-time arena. Presumably an approach like this would have many other applications as well since it isn’t hardware-specific, and we’re excited to see the future developments as people adopt this type of operating system for their specific needs.
Thanks to [Christian] for the tip!
When I began programming microcontrollers in 2003, I had picked up the Atmel STK-500 and learned assembler for their ATtiny and ATmega lines. At the time I thought it was great – the emulator and development boards were good, and I could add a microcontroller permanently to a project for a dollar. Then the ESP8266 came out.
I was pretty blown away by its features, switched platforms, except for timing-sensitive applications, and it’s been my chip of choice for a few years. A short while ago, a friend gave me an ESP32, the much faster, dual core version of the ESP8266. As I rarely used much of the computing power on the ESP8266, none of the features looked like game changers, and it remained a ‘desk ornament’ for a while.
About seven weeks ago, support for the
libSodium Elliptic Curve Cryptography library was added. Cryptography is not the strongest feature of IoT devices, and some of the methods I’ve used on the ESP8266 were less than ideal. Being able to more easily perform public-private key encryption would be enough for me to consider switching hardware for some projects.
However, my preferred automated build tool for NodeMCU wasn’t available on the ESP32 yet. Compiling the firmware was required – this turned out to be a surprisingly user-friendly experience, so I thought I’d share it with you. If I had known it would be so quick, this chip wouldn’t have sat on my desk unused quite so long! Continue reading “Compiling NodeMCU For The ESP32 With Support For Public-Private Key Encryption”
Regular reader [MS3FGX] recently wrote a guide to compiling OpenWRT from source. You may be wondering why directions for compiling an open source program warrant this kind of attention. The size and scope of the package make it difficult to traverse the options available to you at each point in the process, but [MS3FGX] adds clarity by discussion as much as possible along the way.
OpenWRT is an open source alternative firmware package that runs on may routers. It started as a way to unlock the potential of the Linksys WRT54G. But the versatility of the user interface, and the accessibility of the Linux kernel made it a must-have for any router. This is part of what has complicated the build process. There are many different architectures supported and you’ve got to configure the package to build for your specific hardware (or risk a bad firmware flash!).
You’ll need some hefty hardware to ease the processing time. The source package is about 300 MB but after compilation the disk usage will reach into the Gigabyte range. [MS3FGX] used a 6-core processor for compilation and it still took over 20 minutes for a bare-bones distribution. No wonder pre-built binaries are the only thing we’ve ever tried. But this is a good way to introduce yourself to the inner workings of the package and might make for a
frustrating fun weekend project.
Relief is here from long compile times when developing firmware for your Arduino project. [Paul] was puzzled by the fact that every file used in a sketch is fully recompiled every time you hit upload–even if that file didn’t change. To make things more confusing, this behavior isn’t consistent across all Arduino compatible hardware. The Teensy has an additional feature not seen when working with other hardware boards in that it reuses previously compiled code if nothing has changed. It even tells you which files are being reused, as shown in the image above.
After the break we’ve embedded [Paul’s] video that walks us through the process of editing the Arduino IDE to reuse previously compiled files. It’s a one-liner addition to the boards.txt file. For example, if you’re working with the Arduino Uno all that needs to be added is ‘uno.build.dependency=true’. [Paul] had previously submitted a patch to roll this into the Arduino IDE source code, but it was not accepted citing a need for more testing. He’s asking for help with that testing and wants you to post your thoughts, or any bug information, on the new issue he’s opened regarding this feature. Continue reading “Get The Lead Out Of The Arduino Compile Process”
[Sergio Campamá] wrote in to tell us he’s assembled a guide for compiling the latest release of MSPGCC. This is a cross-compiling tool chain for the popular MSP430 line of microncontrollers. We used a version available from the Ubuntu repositories when developing with the TI Launchpad and the eZ430-F2013.
Installing from repositories is easy, but you don’t get the newest features and often newer hardware isn’t supported. [Sergio] reports that the newest version, called Uniarch, pulls source code and header files from the middle of this month and supports over 300 devices. In fact, it specifically outlines the goal of making new hardware easier to incorporate than with previous versions. He’s tailored this guide specifically for Ubuntu but while we were wading through a Google search we also found a page that outlines compilation for OSX.
We didn’t really notice before, but GitHub sure does make those README.md files look nice when viewed on the web, doesn’t it?