Last week I penned a cheesy fake relationship breakup letter to Ubuntu, my Linux distribution of choice for the last 15 years or so. It had well and truly delivered on its promise of a painless Linux desktop for most of that time, but the most recent upgrades had rendered it slow and bloated, with applications taking minutes to load and USB peripherals such as my film scanner mysteriously stopping working. I don’t have to look far to identify the point at which they adopted Snap packages as the moment when it all went wrong. I’d reached the point at which I knew our ways must part, and it was time to look for another distro.
The smart television is an interesting idea in theory. Rather than having the cable or satellite company control all of the content, a small computer is included in the television itself to host and control various streaming clients and other services. Assuming you have control of the software running on the computer, and assuming it isn’t turned into a glorified targeted advertising machine, this can revolutionize the way televisions are used. It’s even possible to turn a standard television into a smart TV with various Android devices, and it turns out there’s a lot more you can do with these smart TV contraptions as well.
With most of these devices, a Linux environment is included running on top of an ARM platform. If that sounds similar to the Raspberry Pi, it turns out that a lot of these old Android TV sets are quite capable of doing almost everything that a Raspberry Pi can do, with the major exception of GPIO. That’s exactly what [Timax] is doing here, but he notes that one of the major hurdles is the vast variety of hardware configurations found on these devices. Essentially you’d have to order one and hope that you can find all the drivers and software to get into a usable Linux environment. But if you get lucky, these devices can be more powerful than a Pi and also be found for a much lower price.
He’s using one of these to run RetroPie, which actually turned out to be much easier than installing a more general-purpose Linux distribution and then running various emulation software piecemeal. It will take some configuration tinkering get everything working properly but with [Timax] providing this documentation it should be a lot easier to find compatible hardware and choose working software from the get-go. He also made some improvements on his hardware to improve cooling, but for older emulation this might not be strictly necessary. As he notes in his video, it’s a great way of making use of a piece of electronics which might otherwise be simply thrown out.
While there have been hiccups here and there, the general trend of electronics is to decrease in cost or increase in performance. This can be seen in fairly obvious ways like more powerful and affordable computers but it also often means that more powerful software can be used in other devices without needing expensive hardware to support it. [Manawyrm] and [Toble_Miner] found this was true of a particular inexpensive thermal camera that ships with Linux installed on it, and found that this platform was nearly perfect for tinkering with and adding plenty of other features to turn it into a much more capable tool.
The duo have been working on a SC240N variant of the InfiRay C200 infrared camera, which ships with a Hisilicon SoC. The display is capable of displaying 25 frames per second, making this platform an excellent candidate for modifying. A few ports were added to the device, including USB and MicroSD, and which also allows the internal serial port to be accessed easily. From there the device can be equipped with the uboot bootloader in order to run essentially anything that could be found on any other Linux machine such as supporting a webcam interface (and including a port of DOOM, of course). The duo doesn’t stop at software modifications though. They also equipped the camera with a lens, attached magnetically, which changes the camera’s focal length to give it improved imaging capabilities at closer ranges.
While the internal machinations of this device are interesting, it actually turns out to be a fairly capable infrared camera on its own as well. The hardware and software requirements for these devices certainly don’t need a full Linux environment to work, and while we have seen thermal cameras that easily fit in a pocket that are based on nothing any more powerful than an ESP32, it does tend to simplify the development process dramatically to include Linux and a little more processing power if you can.
The computer world looks different from behind a TeleType or other hardcopy terminal. Things that tend to annoy people about Unix or Linux these days were perfectly great when you were printing everything the computer said to you. Consider the brevity of most basic commands. When you copy a file, for example, it doesn’t really tell you much other than it returns you to the prompt when it is done. If you are on a modern computer working with normal-sized files locally, not a big deal. But if you are over a slow network or with huge files, it would be nice to have a progress bar. Sure, you could write your own version of copy, but wouldn’t it be nice to have some more generic options?
One Way
The pv program can do some of the things you want. It monitors data through a pipe or, at least through its standard output. Think of it as cat with a meter. Suppose you want to write a diskimage to /dev/sdz:
cat diskz.img >/dev/sdz
But you could also do:
pv diskz.img >/dev/sdz
By default, pv will show a progress bar, an elapsed time, an estimated end time, a rate, and a total number of bytes. You can turn any of that off or add things using command line options. You can also specify things like the size of the terminal if it should count lines instead of bytes, and, in the case where the program doesn’t know what it is reading, the expected size of the transfer.
I hope this letter finds you well. I want to start by saying that our time together has been one of creativity and entertainment, a time in which you gave me the tools to develop a new career, to run a small electronics business, make fun things, and to write several thousand articles for Hackaday and other publications, but for all that it’s sadly time for our ways to part. The magic that once brought us together has faded, and what remains is in danger of becoming a frustration.
In our early days as an item you gave me for the first time a Linux distro that was complete, fast, and easy to use without spending too much time at the CLI or editing config files to make things happen; you gave me a desktop that was smooth and uncluttered, and you freed me from all those little utilities that were required to make Windows usable. You replaced the other distros I’d been using, you dual-booted with my Windows machines, and pretty soon you supplanted the Microsoft operating system entirely.
Me and Ubuntu in 2017, good times.
We’ve been together for close to two decades now, and in that time we’ve looked each other in the eye across a variety of desktop and laptop computers. My trusty Dell Inspiron 640 ran you for over a decade through several RAM, HDD, and SSD upgrades, and provided Hackaday readers with the first few years of my writing. Even the Unity desktop couldn’t break our relationship, those Linux Mint people weren’t going to tear us asunder! You captured my text, edited my videos and images, created my PCBs and CAD projects, and did countless more computing tasks. Together we made a lot of people happy, and for that I will always be grateful. Continue reading “Dear Ubuntu…”→
If you are a Pythonista or a data scientist, you’ve probably used Jupyter. If you haven’t, it is an interesting way to work with Python by placing it in a Markdown document in a web browser. Part spreadsheet, part web page, part Python program, you create notebooks that can contain data, programs, graphics, and widgets. You can run it locally and attach to it via a local port with a browser or, of course, run it in the cloud if you like. But you don’t have to use Python.
You can, however, use things with Jupyter other than Python with varying degrees of success. If you are brave enough, you can use C. And if you look at this list, you’ll see you can use things ranging from Javascript, APL, Fortran, Bash, Rust, Smalltalk, and even MicroPython.
Having a history of shell commands is a great idea. It is, of course, enormously handy when you have to run something repetitively or you make a simple mistake that needs correction. However, as I’ve mentioned in the past, bash history isn’t without its problems. For one thing, by default, you don’t get history in one window from typing in another window. If you use a terminal multiplexer or a GUI, you are very likely to have many shells open. You can make them share history, but that comes with its own baggage. If you think about it, we have super fast computers with tons of storage compared to the “old days,” yet shell history is pretty much the same as it has been for decades. But [Rcaloras] did think about it and created Bashhub, a history database for bash, zsh, and probably some other shells, too.
Command detail screen
You might think you don’t need anything more than what you have, and, of course, you don’t. However, Bashhub offers privately stored and encrypted history across machines. It also provides context about commands you’ve executed in the past. In other words, you can see the directory you were in, the exact time and date, the system you were on, and the last return code of the command.
