NVIDIA Releases Drivers With Openness Flavor

May 13, 2022 by Arya Voronova 27 Comments

This year, we’ve already seen sizeable leaks of NVIDIA source code, and a release of open-source drivers for NVIDIA Tegra. It seems NVIDIA decided to amp it up, and just released open-source GPU kernel modules for Linux. The GitHub link named open-gpu-kernel-modules has people rejoicing, and we are already testing the code out, making memes and speculating about the future. This driver is currently claimed to be experimental, only “production-ready” for datacenter cards – but you can already try it out!

The Driver’s Present State

Of course, there’s nuance. This is new code, and unrelated to the well-known proprietary driver. It will only work on cards starting from RTX 2000 and Quadro RTX series (aka Turing and onward). The good news is that performance is comparable to the closed-source driver, even at this point! A peculiarity of this project – a good portion of features that AMD and Intel drivers implement in Linux kernel are, instead, provided by a binary blob from inside the GPU. This blob runs on the GSP, which is a RISC-V core that’s only available on Turing GPUs and younger – hence the series limitation. Now, every GPU loads a piece of firmware, but this one’s hefty!

Barring that, this driver already provides more coherent integration into the Linux kernel, with massive benefits that will only increase going forward. Not everything’s open yet – NVIDIA’s userspace libraries and OpenGL, Vulkan, OpenCL and CUDA drivers remain closed, for now. Same goes for the old NVIDIA proprietary driver that, I’d guess, would be left to rot – fitting, as “leaving to rot” is what that driver has previously done to generations of old but perfectly usable cards. Continue reading “NVIDIA Releases Drivers With Openness Flavor” →

From Car To Device: How Software Is Changing Vehicle Ownership

May 2, 2022 by Jenny List 48 Comments

For much of the last century, the ownership, loving care, and maintenance of an aged and decrepit automobile has been a rite of passage among the mechanically inclined. Sure, the battle against rust and worn-out parts may eventually be lost, but through that bond between hacker and machine are the formative experiences of motoring forged. In middle-age we wouldn’t think of setting off across the continent on a wing and a prayer in a decades-old vehicle, but somehow in our twenties we managed it. The Drive have a piece that explores how technological shifts in motor vehicle design are changing our relationship with cars such that what we’ve just described may become a thing of the past. Titled “The Era of ‘the Car You Own Forever’ Is Coming to an End“, it’s well worth a read.

At the crux of their argument is that carmakers are moving from a model in which they produce motor vehicles that are simply machines, into one where the vehicles are more like receptacles for their software. In much the same way as a smartphone is obsolete not necessarily through its hardware becoming useless but through its software becoming unmaintained, so will the cars of the future. Behind this is a commercial shift as the manufacturers chase profits and shareholder valuations, and a legal change in the relationship between customer and manufacturer that moves from ownership of a machine into being subject to the terms of a software license.

This last should be particularly concerning to all of us, after all if we’re expected to pay tens of thousands of dollars for a car it’s not unreasonable to expect that it will continue to serve us at our convenience rather than at that of its manufacturer.

If you’re a long-time Hackaday reader, you may remember that we’ve touched on this topic before.

Header image: Carolyn Williams, CC BY 2.0.

Tiny RISC Virtual Machine Is Built For Speed

April 28, 2022 by Bryan Cockfield 13 Comments

Most of us are familiar with virtual machines (VMs) as a way to test out various operating systems, reliably deploy servers and other software, or protect against potentially malicious software. But virtual machines aren’t limited to running full server or desktop operating systems. This tiny VM is capable of deploying software on less powerful systems like the Raspberry Pi or AVR microcontrollers, and it is exceptionally fast as well.

The virtual machine is built from scratch, including the RISC processor with only 61 opcodes, a 64 bit core, and runs code written in his own programming language called “Brackets” or in assembly. It’s designed to be modular, so only those things needed for a given application are loaded into the VM. With these design criteria it turns out to be up to seven times as fast as comparably small VMs like NanoVM. The project’s creator, [koder77], has even used its direct mouse readout and joystick functionality to control a Raspberry Pi 3D camera robot.

For anyone looking to add an efficient VM to a small computing environment, [koder77] has made the project open-source on his GitHub page. This also includes all of the modules he has created so far which greatly expand the project’s capabilities. For some further reading on exceedingly tiny virtual machines, we featured this project way back in 2012 which allows users to run Java on similar hardware.

90s Apple Computer Finally Runs Unsigned Code

April 28, 2022 by Bryan Cockfield 12 Comments

Back in the 90s, the console wars were in full swing. Nintendo vs Sega was an epic showdown at first, but when Nintendo seemed sure to clench the victory Sony came out of nowhere with the PlayStation. While these were the most popular consoles at the time, there were a few others around that are largely forgotten by history even if they were revolutionary in some ways. An example is the Pippin, a console made by Apple, which until now has been unable to run any software not signed by Apple.

The Pippin was Apple’s only foray into gaming consoles, but it did much more than that and included a primitive social networking system as well as the ability to run Apple’s Macintosh operating system. The idea was to be a full media center of sorts, and the software that it would run would be loaded from the CD-ROM at each boot. [Blitter] has finally cracked this computer, allowing it to run custom software, by creating an authentication file which is placed on the CD to tell the Pippin that it is “approved” by Apple.

The build log goes into incredible detail on the way these machines operated, and if you have a Pippin still sitting around it might be time to grab it out of the box and start customizing it in the way you probably always wanted to. For those interested in other obscure Apple products, take a look at this build which brings modern WiFi to the Apple Newton, their early PDA.

Continue reading “90s Apple Computer Finally Runs Unsigned Code” →

Open-Source Farming Robot Now Includes Simulations

March 17, 2022 by Bryan Cockfield 14 Comments

Farming is a challenge under even the best of circumstances. Almost all conventional farmers use some combination of tillers, combines, seeders and plows to help get the difficult job done, but for those like [Taylor] who do not farm large industrial monocultures, more specialized tools are needed. While we’ve featured the Acorn open source farming robot before, it’s back now with new and improved features and a simulation mode to help rapidly improve the platform’s software.

The first of the two new physical features includes a fail-safe braking system. Since the robot uses electric geared hub motors for propulsion, the braking system consists of two normally closed relays which short the motor leads in emergency situations. This makes the motors see an extremely high load and stops them from turning. The robot also has been given advanced navigation facilities so that it can follow custom complex routes. And finally, [Taylor] created a simulation mode so that the robot’s entire software stack can be run in Docker and tested inside a simulation without using the actual robot.

For farmers who are looking to buck unsustainable modern agricultural practices while maintaining profitable farms, a platform like Acorn could be invaluable. With the ability to survey, seed, harvest, and even weed, it could perform every task of larger agricultural machinery. Of course, if you want to learn more about it, you can check out our earlier feature on this futuristic farming machine.

Code Wrong: Expand Your Mind

January 29, 2022 by Elliot Williams 24 Comments

The really nice thing about doing something the “wrong” way is that there’s just so much variety! If you’re doing something the right way, the fastest way, or the optimal way, well, there’s just one way. But if you’re going to do it wrong, you’ve got a lot more design room.

Case in point: esoteric programming languages. The variety is stunning. There are languages intended to be unreadable, or to sound like Shakespearean sonnets, or cooking recipes, or hair-rock ballads. Some of the earliest esoteric languages were just jokes: compilations of all of the hassles of “real” programming languages of the time, but yet made to function. Some represent instructions as a grid of colored pixels. Some represent the code in a fashion that’s tantamount to encryption, and the only way to program them is by brute forcing the code space. Others, including the notorious Brainf*ck are actually not half as bad as their rap — it’s a very direct implementation of a Turing machine.

So you have a set of languages that are designed to be maximally unlike each other, or traditional programming languages, and yet still be able to do the work of instructing a computer to do what you want. And if you squint your eyes just right, and look at as many of them all together as you can, what emerges out of this blobby intersection of oddball languages is the essence of computing. Each language tries to be as wrong as possible, so what they have in common can only be the unavoidable core of coding.

While it might be interesting to compare an contrast Java and C++, or Python, nearly every serious programming language has so much in common that it’s just not as instructive. They are all doing it mostly right, and that means that they’re mostly about the human factors. Yawn. To really figure out what’s fundamental to computing, you have to get it wrong.

Python Ditches The GILs And Comes Ashore

November 3, 2021 by Matthew Carlson 38 Comments

The Python world has been fractured a few times before. The infamous transition from version 2 to version 3 still affects people today, and there could be a new schism in the future. [Sam Gross] proposed a solution to drop the Global ~~Interrupt~~ Interpreter Lock (GIL), which would have enormous implications for many projects that leverage the CPython internals, such as Pandas and NumPy.

The fact that Python is interpreted is a double edge sword. It means there can be different runtimes, such as Pyston, Cinder, MicroPython, PyPy, and others, that might support the whole language, a specific version, or a subset. But if you’re using Python, you’re probably running CPython. And it has something known as global interpreter lock that affects threaded code. In a nutshell, only one thread can run in the interpreter at a time. There are some ways around it, such as moving performance-critical sections to C or having multiple interpreters. However, most existing solutions come with considerable downsides. Continue reading “Python Ditches The GILs And Comes Ashore” →