Two years ago [1], I wrote about running your TrueNAS VMs from the boot pool by manually updating the virsh configuration. The problem here, however, was that you had to repeat these steps each time you rebooted the VM as TrueNAS would reset the configuration. Also, it wasn't 100% reliable and the commands might need a few attempts to work.
Since then, two of my readers, John and Michael, reached out to me to tell me about a better solution they both (independently) discovered: Editing the TrueNAS database instead of manipulating the virsh service configuration.
WARNING! Just as last time, this guide is definitely not how TrueNAS is intended to be used. It may be better than my last approach, but it's still dirty. You may brick your installation (even if you followed this guide perfectly), or even worse, lose your VMs and data. Only do this if you can live with losing everything and having to reconfigure your entire system.
Please note that, by enabling this video, data is transferred to YouTube LLC, and is subject to their privacy policy.
Writing good code is hard. Testing it is arguably even harder. And with the advance of modern technologies, the demand for good verification only keeps growing along with it. However, especially the FPGA world appears to commonly use obsolete and inappropriate verification tools and methodologies. But it doesn’t have to be this way! This post outlines, guided by a real-world example, how to use modern verification languages and tools to create high-quality test benches in less time.
-- I'll probably regret this when I finally lose my data
Figure 1. TrueNAS VM configuration panel
I've been meaning to transfer my Raspberry Pi based services into a virtual machine on my main server running TrueNAS for a while now, but I've always delayed as I didn't know where to store the VM's disk. I have 7 disks in my main server: 2x 128 GB SSDs as the boot array, 4x 4 TB HDDs as the main array, and another single 4 TB HDD for less important data.
Basically, I don't care where I store the VM, but I want my HDDs to spin down during the night and low load periods. Since a VM will definitely keep the drives up, the mechanical drives are out, leaving me only with the boot pool. It has enough storage for what I need, but, and here comes the problem, TrueNAS does not allow me to keep custom datasets on the boot pool.
But, under the hood, TrueNAS is just FreeBSD. So as I had some time over the holidays, I set out to find a solution to do it nonetheless.
→ UPDATE: There is an updated, much more reliable version of this guide based on editing the database [1]. I strongly recommend to use that instead. ←
WARNING! This guide is definitely not how TrueNAS is intended to be used. It's dirty and terrible. If you brick your installation (even if you followed this guide perfectly), or even worse, lose your VMs and data, don't tell me I didn't warn you. Only do this if you can live with losing everything and having to reconfigure your entire system.
-- Based on an AVR and a Raspberry Pi 0W running MPD
Figure 1. DIY Web Radio
Last year, a friend gave me a dead DAB+ radio, whose only function that still worked was the heater-function -- Oh, it wasn't supposed to do that? OK... Then it was 100% dead. --
Either way, I've been meaning to get myself an Internet radio for a while now, but all on the market were missing some feature I wanted, plus building one myself didn't sound too hard.
This post describes the radio that I built in the end, based around only the original case and speaker from the DAB+ radio.
-- Now that's my definition of building a computer!
Figure 1. The finished LW-35
Do you still remember the old electronic typewriters from the nineties? Many of the later machines were already pretty much full-fledged computers, just with a word processor as the operating system. One of these typewriters is the Brother LW-35 released in Europe. I still had one of these lying around; Great keyboard, a fun daisy wheel printer, and a 14 line display for distraction free writing. It even had a floppy drive for data exchange. So in summary, a pretty cool device.
But there were a few problems with it. First of all, the floppy drive stopped working reliably. And secondly, on the days the floppy drive decided to work, it was still a floppy drive. Not exactly the most convenient way to store and transfer data these days, although I'm sure some of you will disagree. Also, the typewriter used its own file format, which needed to be converted on the device itself before it could be read in a DOS or UNIX environment. This may be OK if you're writing a longer document, and only write it on that machine. But as someone who constantly changes the machine they type on, it's not practical.
Yet, even with these problems, I just didn't have the heart to throw it out.
So what can we do about it? Upgrade it!
In this post, I will show you how I converted my old LW-35 typewriter into a modern computer while keeping all the good features of the old machine.
-- Building an FPGA from 74-series logic ICs. For fun and education.
Figure 1. TTL-FPGA
Technology is becoming more complex every day. Devices get smaller, integration gets higher. Consequently, it is becoming increasingly harder to understand how modern devices work.
In the 80s, you could open your PC and start probing signals on the mainboard to understand which instruction the CPU executed. These days, pretty much everything can be integrated into a single chip and everything is hidden away. One example of such a highly integrated component is the field programmable gate array (FPGA).
FPGAs essentially allow the designer to create large digital designs inside of an IC without having to create actual new silicon. As these designs are created by writing software-like source code, one might easily forget the fact that what is created is, indeed, a digital circuit. The immense overhead to provide this flexibility is easy to underestimate when working with these devices.
To aid students learning about FPGAs better understand the technology, this project aims to provide a platform to look at the inner workings of such a chip by breaking it out of the IC and bringing it onto a PCB where every signal can be traced and measured. Such projects are often done for central processing units (CPUs), but there isn't much when it comes to FPGAs.
Before I delve any deeper into my implementation, I want to highlight that this is only one of many ways to construct such an "FPGA." Also, this project does not accurately represent the circuits inside a commercial FPGA. Many things, especially the routing, had to be grossly simplified in order to be feasible. The basic concepts, however, should still hold true.
-- What if random access memories were actually true to their name?
Figure 1. Why do they even call it random?
In this post I will analyze the feasibility of using a memory which randomly performs either a read or write operation instead of giving the user the ability to choose between the two. Spoiler: It sucks!
