This excellent content from the Hackaday writing crew highlights recurring topics and popular series like Linux-Fu, 3D-Printering, Hackaday Links, This Week in Security, Inputs of Interest, Profiles in Science, Retrotechtacular, Ask Hackaday, Teardowns, Reviews, and many more.
Sounds like somebody had a really bad day at work, as Western Digital reports that “factory contamination” caused a batch of flash memory chips to be spoiled. How much, you ask? Oh, only about 7 billion gigabytes! For those of you fond of SI prefixes, that’s 7 exabytes of storage; to put that into perspective, it’s seven times what Google used for Gmail storage in 2012, and enough to store approximately 1.69 trillion copies of Project Gutenberg’s ASCII King James Version Bible. Very few details were available other than the unspecified contamination of two factories, but this stands poised to cause problems with everything from flash drives to phones to SSDs, and will probably only worsen the ongoing chip shortage. And while we hate to be cynical, it’ll probably be prudent to watch out for any “too good to be true” deals on memory that pop up on eBay and Ali in the coming months.
Among the many facets of modern technology, few have evolved faster or more radically than the computer. In less than a century its very nature has changed significantly: today’s smartphones easily outperform desktop computers of the past, machines which themselves were thousands of times more powerful than the room-sized behemoths that ushered in the age of digital computing. The technology has developed so rapidly that an individual who’s now making their living developing iPhone applications could very well have started their career working with stacks of punch cards.
With things moving so quickly, it can be difficult to determine what’s worth holding onto from a historical perspective. Will last year’s Chromebook one day be a museum piece? What about those old Lotus 1-2-3 floppies you’ve got in the garage? Deciding what artifacts are worth preserving in such a fast moving field is just one of the challenges faced by Dag Spicer, the Senior Curator at the Computer History Museum (CHM) in Mountain View, California. Dag stopped by the Hack Chat back in June of 2019 to talk about the role of the CHM and other institutions like it in storing and protecting computing history for future generations.
To answer that most pressing question, what’s worth saving from the landfill, Dag says the CHM often follows what they call the “Ten Year Rule” before making a decision. That is to say, at least a decade should have gone by before a decision can be made about a particular artifact. They reason that’s long enough for hindsight to determine if the piece in question made a lasting impression on the computing world or not. Note that such impression doesn’t always have to be positive; pieces that the CHM deem “Interesting Failures” also find their way into the collection, as well as hardware which became important due to patent litigation.
Of course, there are times when this rule is sidestepped. Dag points to the release of the iPod and iPhone as a prime example. It was clear that one way or another Apple’s bold gambit was going to get recorded in the annals of computing history, so these gadgets were fast-tracked into the collection. Looking back on this decision in 2022, it’s clear they made the right call. When asked in the Chat if Dag had any thoughts on contemporary hardware that could have similar impact on the computing world, he pointed to Artificial Intelligence accelerators like Google’s Tensor Processing Unit.
In addition to the hardware itself, the CHM also maintains a collection of ephemera that serves to capture some of the institutional memory of the era. Notebooks from the R&D labs of Fairchild Semiconductor, or handwritten documents from Intel luminary Andrew Grove bring a human touch to a collection of big iron and beige boxes. These primary sources are especially valuable for those looking to research early semiconductor or computer development, a task that several in the Chat said staff from the Computer History Museum had personally assisted them with.
Towards the end of the Chat, a user asks why organizations like the CHM go through the considerable expense of keeping all these relics in climate controlled storage when we have the ability to photograph them in high definition, produce schematics of their internals, and emulate their functionality on far more capable systems. While Dag admits that emulation is probably the way to go if you’re only worried about the software side of things, he believes that images and diagrams simply aren’t enough to capture the true essence of these machines.
Quoting the the words of early Digital Equipment Corporation engineer Gordon Bell, Dag says these computers are “beautiful sculptures” that “reflect the times of their creation” in a way that can’t easily be replicated. They represent not just the technological state-of-the-art but also the cultural milieu in which they were developed, with each and every design decision taking into account a wide array of variables ranging from contemporary aesthetics to material availability.
While 3D scans of a computer’s case and digital facsimiles of its internal components can serve to preserve some element of the engineering that went into these computers, they will never be able to capture the experience of seeing the real thing sitting in front of you. Any school child can tell you what the Mona Lisa looks like, but that doesn’t stop millions of people from waiting in line each year to see it at the Louvre.
The Hack Chat is a weekly online chat session hosted by leading experts from all corners of the hardware hacking universe. It’s a great way for hackers connect in a fun and informal way, but if you can’t make it live, these overview posts as well as the transcripts posted to Hackaday.io make sure you don’t miss out.
This week, Hackaday Editor-in-Chief Elliot Williams and Assignments Editor Kristina Panos fawn over a beautiful Italian split-flap clock that doesn’t come cheap, and another clock made of floppies that could be re-created for next to nothing. We’ll also sing the praises of solderless circuitry for prototyping and marvel over a filament dry box with enough sensors to control an entire house. The finer points of the ooh, sparkly-ness of diffraction gratings will be discussed, and by the end of the show, you’ll know what we each like in a microscope.
Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
(And if you’re wondering about what my joke about not having Kristina on the show for 28 seconds, and all the professionalism, was about — we both forgot to press record the first time through and got ~15 minutes into the show before noticing. Yeah. But we had a good time the second time around anyway.)
Running Chrome or a Chromium-based browser? Check for version 98.0.4758.102, and update if you’re not running that release or better. Quick tip, use chrome://restart to trigger an immediate restart of Chrome, just like the one that comes after an update. This is super useful especially after installing an update on Linux, using apt, dnf, or the like.
CVE-2022-0609 is the big vulnerability just patched, and Google has acknowledged that it’s being exploited in the wild. It’s a use-after-free bug, meaning that the application marks a section of memory as returned to the OS, but then accesses that now-invalid memory address. The time gap between freeing and erroneously re-using the memory allows malicious code to claim that memory as its own, and write something unexpected.
Google has learned their lesson about making too many details public too early, and this CVE and associated bug aren’t easily found in in the Chromium project’s source, and there doesn’t seem to be an exploit published in the Chromium code testing suite. Continue reading “This Week In Security: Chrome 0-day,Cassandra, And A Cisco PoC”→
What would you make if you were given about ten square millimeters of space on a silicon wafer on a 130 nm process? That’s the exact question that the Open MPW program asks, and that [Matt Venn] has stepped up to answer. [Matt] came to Remoticon in 2020 to talk about his journey from nothing to his own ASIC, and he came back in 2021 to talk about what has happened in a year.
[maxiborga] has been making beautiful renders of his and others’ chip designsWe expected great designs, but the variety of exciting and wonderful designs that have been submitted we think exceeded our expectations. [Matt] goes through quite a few of them, such as an analog neuron, a RISC-V Arduino-compatible microprocessor, and a satellite transceiver. Perhaps an unexpected side effect has been the artwork. Since the designs are not under an NDA, anyone can take the design and transform it into something gorgeous.
Of course, all of this hardware design isn’t possible without an open toolchain. There is an SRAM generator known as OpenRAM that can generate RAM blocks for your design. Coriolis2 is an RTL to GDS tool that can do placement and routing in VLSI. Finally, FlexCell is a cell library that tries to provide standard functions in a flexible, customizable way that cuts down on the complexity of the layout. There are GitHub actions that can run tests and simulations on PRs to keep the chip’s HDL in a good state.
However, it’s not all roses, and there was an error on the first run (MPW1). Hold time violations were not detected, and the clock tree wasn’t correct. This means that the GPIO cannot be set up, so the designs in the middle could be working, but without the GPIO, it is tricky to determine. With a regular chip, that would be the end, but since [Matt] has access to both the layout and the design, he can identify the problem and come up with a plan. He’s planning on overriding the IO setup shift register with an auxiliary microcontroller. (Ed Note: [tnt] has been making some serious progress lately, summarized in this video.)
It is incredible to see what has come from the project so far, and we’re looking forward to future runs. If this convinces you that you need to get your own ASIC made, you should check out [Matt]’s “Zero to ASIC” course.
Unix and, by extension, Linux, has a mantra to make everything possible look like a file. Files, of course, look like files. But also devices, network sockets, and even system information show up as things that appear to be files. There are plenty of advantages to doing that since you can use all the nice tools like grep and find to work with files. However, making your own programs expose a filesystem can be hard. Filesystem code traditionally works at the kernel module level, where mistakes can wipe out lots of things and debugging is difficult. However, there is FUSE — the file system in user space library — that allows you to write more or less ordinary code and expose anything you want as a file system. You’ve probably seen FUSE used to mount, say, remote drives via ssh or Dropbox. We’ve even looked at FUSE before, even for Windows.
What’s missing, naturally, is the Hackaday RSS feed, mountable as a normal file. And that’s what we’re building today.
Writing a FUSE filesystem isn’t that hard, but there are a lot of tedious jobs. You essentially have to provide callbacks that FUSE uses to do things when the operating system asks for them. Open a file, read a file, list a directory, etc. The problem is that for some simple projects, you don’t care about half of these things, but you still have to provide them.
Luckily, there are libraries that can make it a lot easier. I’m going to show you a simple C++ program that can mount your favorite RSS feed (assuming your favorite one is Hackaday, of course) as a file system. Granted, that’s not amazing, but it is kind of neat to be able to grep through the front page stories from the command line or view the last few articles using Dolphin. Continue reading “Linux Fu: Fusing Hackaday”→
Though some of us are heavily assisted by smart phone apps and delivery, humans don’t need GPS to find food. We know where the fridge is. The grocery store. The drive-thru. And we don’t really need a map to find shelter, in the sense that shelter is easily identifiable in a storm. You might say that our most important navigation skills are innate, at least when we’re within our normal environment. Drop us in another city and we can probably still identify viable overhangs, cafes, and food stalls.
The question is, do these navigational skills vary by species or environment? Or are the tools necessary to forage for food, meet mates, and seek shelter more universal? To test the waters of this question, Israeli researchers built a robot car and taught six fish to navigate successfully toward a target with a food reward. This experiment is one of domain transfer methodology, which is the exploration of whether a species can perform tasks outside its natural environment. Think of all the preparation that went into Vostok and Project Mercury.
