We are always envious of the Star Trek Enterprise computers. You can just sort of ask them a hazy question and they will — usually — figure out what you want. Even the automatic doors seemed to know the difference between someone walking into a turbolift versus someone being thrown into the door during a fight. [River] decided to try his new API keys for the private beta of an AI service to generate Linux commands based on a description. How does it work? Watch the video below and find out.
Some examples work fairly well. In response to “email the Rickroll video to Jeff Bezos,” the system produced a curl command and an e-mail to what we assume is the right place. “Find all files in the current directory bigger than 1 GB” works, too.
You need to package up a bunch of files, send them somewhere, and do something with them at the destination. It isn’t an uncommon scenario. The obvious answer is to create an archive — a zip or tar file, maybe — and include a shell script that you have to tell the user to run after unpacking.
That may be obvious, but it assumes a lot on the part of the remote user. They need to know how to unpack the file and they also need to know to run your magic script of commands after the unpack. However, you can easily create a shell script that contains a file — even an archive of many files — and then retrieve the file and act on it at run time. This is much simpler from the remote user’s point of view. You get one file, you execute it, and you are done.
In theory, this isn’t that hard to do, but there are a lot of details. Shell scripts are not compiled — at least, not typically — so the shell only reads what it needs to do the work. That means if your script is careful to exit, you can add as much “garbage” to the end of it as you like. The shell will never look at it, so it’s possible to store the payload there.
When Google halted production of the Chromecast Audio at the start of 2019, there was a (now silent) outcry. Fans of the device loved the single purpose audio streaming dongle that delivered wide compatibility and drop-dead simplicity at a rock bottom $35 price. For evidence of this, look no further than your favorite auction site where they now sell for significantly more than they did new, if you can even find an active listing. What’s a prolific hacker to do about this clear case of corporate malice? Why, reinvent it of course! And thus the Otter Cast Audio V2 was born, another high quality otter themed hack from one of our favorite teams of hardware magicians [Lucy Fauth, Jana Marie Hemsing, Toble Miner, and Manawyrm].
USB-C and Ethernet, oh my!
The Otter Cast Audio is a disc about the shape and size of standard Chromecast (about 50mm in diameter) and delivers a nearly complete superset of the original Chromecast Audio’s features plus the addition of a line in port to redirect audio from existing devices. Protocol support is more flexible than the original, with AirPlay, a web interface, Spotify Connect, Snapcast, and even a PulseAudio sink to get your Linux flavored audio bits flowing. Ironically the one thing the Otter Cast Audio doesn’t do is act as a target to Cast to. [Jan] notes that out of all the protocols supported here, actual Cast support was locked down enough that it was difficult to provide support for. We’re keeping our fingers crossed a solution can be found there to bring the Otter Cast Audio to complete feature parity with the original Chromecast Audio.
But this is Hackaday, so just as important as what the Otter Cast Audio does is how it does it. The OtterCast team have skipped right over shoehorning all this magic into a microcontroller and stepped right up to an Allwinner S3 SOC, a capable little Cortex A7 based machine with 128 MB of onboard DDR3 RAM. Pint sized by the bloated standards of a fully interactive desktop, but an absolutely perfect match to juggling WiFi, Bluetooth, Ethernet, and convenient support for all the protocols above. If you’re familiar with these hackers’ other work it won’t surprise you that what they produced here lives up to the typical extremely high quality bar set by such wonders as this USB-C adapter for JBC soldering iron handles and this TS-100 mainboard replacement.
We love seeing Linux run on basically anything with a processor. It’s a classic hack at this point. Nintendo has traditionally kept its consoles fairly locked down, though, even in the face of some truly impressive efforts; so it’s always a treat to see the open-source OS run relatively smoothly on the console. This Ubuntu install is based on NVIDIA’s Linux for Tegra (L4T) package, which affords some performance gains over Android installations on the same hardware. As we’ve seen with those Android hacks, however, this software mod also makes use of the Switchroot project and, of course, it only works with specific, unpatched hardware. But if you’ve won the serial number lottery and you’re willing to risk your beloved console, [LOE TECH] also has a video detailing the process he used to get Ubuntu up and running.
Check out the video below for a medley of Gamecube game test runs. Some appear to run great, and others, well… not so much. But we truly appreciate how he doesn’t edit out the games that stutter and lag. This way, we get a more realistic, more comprehensive overview of unofficial emulation performance on the Switch. Plus, it’s almost fun to watch racing games go by in slow motion; almost, that is, if we couldn’t empathize with how frustrating it must have been to play.
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.
An old joke from the Linux community about its prevalence in computing quips that Linux will run on anything, including some animals. While the joke is a little dated, it is true that Linux can run on just about any computing platform with a certain amount of elbow grease. The current exception is the new Apple M1 silicon, although one group called Asahi Linux is currently working to get Linux running on this novel hardware as well.
While the Apple M1 is specifically built to run macOS, there’s no technical reason why Linux couldn’t run on it once all of the kinks are ironed out. This progress report from last month outlines some of the current areas of focus, especially around booting non-Mac kernels. The new Apple silicon runs on an ARM processor and because of this it functions more like an embedded device than a PC with standardized BIOS or UEFI. This means a lot of workarounds to the proprietary boot process have to be created to get a Linux kernel to boot. Luckily there are already versions of Linux that run on ARM so a lot of work has already been done, but there’s still much ahead.
While it’s probably best to buy an x86 machine for the time being if you need a Linux on your own personal machine, it seems like only a matter of time until all of the barriers to Linux are overcome on the M1 silicon. If Linux is able to take advantage of some of the efficiency and performance benefits of these chips, it could be a game-changer in the Linux world and at least give us all another option for hardware. Of course, we will still be needing software that can run on ARM, too.
Eakins cameras have become a relatively popular, relatively inexpensive choice for electronics hobbyists to inspect their small-scale work. The cameras have a USB port for a mouse and overlay a GUI on the HDMI output for controlling the camera’s various settings and capturing images to the SD card. Using the mouse-based GUI can feel clunky, though, so users have already endeavored to streamline the process to fit better in their workflow. [charliex] decided to take streamlining a few steps further.
One issue in microscope photography is that microscopes have an extremely tight focus plane. So, even at the minuscule scales of an SMD circuit board, the components are simply too tall. Only a sub-millimeter-thick layer can be in focus at a time. If you take just a single image, much of what you want to see will be lost in the blurry distance. Focus stacking solves this problem by taking multiple pictures with the focus set at different depths then combining their focused bits into a single sharp image.
This takes care of the focus issue, but even the most streamlined and intuitive manual controls become tedious given the multitude of pictures required. So [charliex] searched for a way to remotely control his camera, automating focus stacking and possibly even full PCB scans.
