iirc the bug that the R8127 patch was addressing was fixed in the R8169 driver upstream in kernel 6.18 and later. Not super sure what other patches there are and what the status of those are...
The Ampere cpu in that post has a "lack of single core CPU speed" despite ripping through compilation tasks with its 80 cores. But the DGX Spark's CPU has fairly decent single core speed and is more like Apple Silicon in this respect.
It's an Orico 9948C3 with four Seagate Barracuda 24TB drives. They were on sale last year [1].
Unfortunately, the enclosure doesn't work super well on Linux.
There is a weird bug where the drives don't enumerate when I boot up my computer. This happens on both my x86_64 AMD machine running Linux, and on the DGX Spark. The solution is... simply power cycle the enclosure a couple of times by toggling the power button on it and then it works. Once all four drives show up in lsblk, I can `sudo zfs import ...` manually. This is really gross and annoying. Replacing the USB cable, flipping the USB-C cable 180 degrees, hot plugging it, etc, all didn't work, both on the DGX Spark and the other Linux machine. I've also read reports of it being unstable in UAS mode on Linux but I haven't found a big difference in stability between enabling UAS or falling back to usb-storage.
Once it starts up correctly though, the drives are fast. I store my huge amount of 100 megapixel photos on it.
The Seagate Barracudas are helium-filled HAMR/CMR drives and are apparently rebranded/binned Exos drives. They aren't rated for 24/7 use but then neither are the refurbished Exos drives.
Sorry, my comment was confusingly worded, but I am precisely thinking about the head-space thing you are talking about. My point is: the fact that image generation models can generate a perfect pelican riding on a topologically correct and highly detailed bike frame [1], suggests that AI does have the capability to correctly understand it internally. But something is disconnected when we just let an LLM directly output the SVG, and all the nuanced understanding is lost.
As such, modern LLMs still kind of suck at generating pelican bike SVGs with obvious errors:
* some omitted the bottom of the diamond which connects from the pedals to the rear wheel
* some added an extra connection from the pedals to the front wheel, making it impossible to steer
* none could align the head tube with the fork
* none added a correct offset to the fork
* none could generate the chain properly in a way that attaches to the two sprockets correctly
... whereas these errors do not appear in the raster image. (To be fair, the raster image has other weirdnesses, like the bird having arms and only one leg)
If we could harness the sort of internal thinking that must have happened when it generated the highly consistent raster image, but make it output SVG instead, we'd get much better SVGs. So this would be indeed "visualize in their mind how to draw a picture" before outputting the SVG.
The DGX Spark hits a sweet spot for me where it can simultaneously work for general computing and run local LLM inference fast enough for some hobbyist dabbling. The RTX 6000 Pro Blackwell is more than twice the price (it has increased quite a bit recently from $8000 to $11600), not to mention the "rest of the PC" needed to get it working, so it's not really a fair comparison. Compared to other 128 GB unified memory devices like the Mac Studio and the Strix Halo, the DGX Spark fairly priced in my opinion.
Many other distros almost work out of the box (as in they boot and run without any modifications). The custom kernel patches you mentioned address mainly non-critical bugs such as a bug where the Realtek r8127 stops working after a reboot (but it works if you turn it off and on again) [1] [2]. I'd consider it in a way better state than trying to run other Linux distros on certain device tree-based devices like, say, Qualcomm Snapdragon machines. The regular NVIDIA drivers with the open source kernel modules work just fine. Talos Linux supports DGX Spark since version 1.12 [3]. I also know of people using Fedora and nixOS successfully.
I know. I'm just thinking about how to make AI create SVGs better... in theory, a sufficiently smart AI could "generate an image in its head", think about it, and then output the SVG paths to produce said image. Intuitively that would be somewhat closer to how human artists convert artistic visions into a sequence of arm movements while holding a brush (obviously, humans don't hold a fully formed, photorealistic image in the head while drawing, but rather vague concepts, but still).
> Every single one is a pelican, on a bicycle, first try. When every student gets an A, the exam has stopped grading.
Numerous pelicans and their bikes are clearly horribly malformed. In fact none of the bike frames are correct. Fable and Opus come close, but the top of the diamond is disconnected in Fable's case and the head tube is misaligned with the front fork in Opus's case.
And of course, as the parent post shows, labs don't actually seem to be training on the pelican bike case.
I feel like getting LLMs to spit out an SVG is akin to getting a human artist to draw something by just reciting a list of coordinates. It's insanely hard and unnatural.
Image generation models nowadays can easily generate a photorealistic pelican riding a bicycle, where the bicycle has perfect structure. But it is, of course, only a raster image.
It seems that we're missing a kind of step to decompose an image into a list of instructions (say, SVG paths, or even brush strokes with a real brush) to reproduce it properly. Doing so would probably need a true understanding of the structure of the scene, which is something that AI still struggles with to this day.
I totally understand the point of view from maintainers. Review fatigue of low quality slop is a legitimate issue.
The worst ones are fully autonomous AI agents looking for open source projects and adding random pull requests.
But in some cases, I find a legit bug that needs fixing. For example, I want to get a particular program working in Wine/FEX on aarch64 [1], or I find a 12 second hang in Darktable [2]. The problem is that, as a software engineer working in a totally different discipline, I have no knowledge of the low level C code to fully understand what the problem even is, or how to fix it. All I want to do is to fix the issue and help other people avoid running into the same issue. Right now, on my machine, I maintain a set of custom patches to get everything working. But I am too dumb and ignorant to figure out how to create the fix by hand, so I can't submit a pull request (or when I do, I feel really bad about it. I honestly feel like a horrible person, e.g. when a project added a "No AI" policy soon after I submitted some AI-generated PRs [3]). Going forward, I feel like this sort of scenario is going to be way more common.
Yeah, if I take a dense grid of photos near my house, it would reveal a 500 m circle. But in practice I don't take _that_ many photos in the neighborhood. Also, the circle isn't perfectly centered on my home.
For my personal website I have a lot of photography-oriented blog posts [1], but I have special code to strip out GPS info from the location if it's close to my home [2].
EDIT: my vibe-coding slop agent put my home GPS lat long in the example config in the README lol. Please don't rob my house; I'll go run git-filter-repo later.
The NVIDIA DGX Spark that I use has a fairly decent ARM CPU that's roughly on par with the M3 Pro and AMD AI Max 395+ according to Geekbench, plus a GPU that's very powerful (RTX 5070 level). I'm sure it will be more than powerful enough for me to get a decent experience.
There's a Linux amd64 version and a Windows arm64 version. However, I use a Linux arm64 machine, and arm64 machines are going to be a lot more common going forward. I wonder if there are plans to release a Linux arm64 build?
