Nice write up! For this sort of thing, I have leaned towards AMD Epyc, Intel e810, and DPDK for the software stack. Unfortunately, lately the supermicro H13SSL line of mobo's appear to have become near-unobtainable with ridiculous 6+ month lead times.
No idea, you can still get one-off boards here and there, but buying anything in quantity has been tricky. I can only surmise supermicro's resources are largely tied up with AI data center build out, with everything else relegated to short runs.
My comment was directed at your statement "that at no point in history was the US dollar 100% backed by gold (or silver, originally). Never." which is entirely false. The US dollar (the currency unit), was at one point quite literally an exact weight of silver. This is no longer the case, but it was true in the past. This has nothing to do with the nation debt, or what is backing it. Obviously, the national debt isn't collateralized by precious metals or anything else except the military and power to raise taxes.
I have a old system with 3 ancient Tesla K40s which can easily run inference on ~30B parameter models (e.g. qwen3-coder:30b). I mostly use it as a compute box for other workloads, but its not completely incapable for some AI assisted coding. It is power hungry though, and the recent spike in local electricity rates is enough of an excuse to keep it off most of the time.
I'm surprised the accelerators of yore trick actually worked and balancing a trio is trivially more difficult than duo? I enjoy the idea of having tons of VRAM and system RAM and loading a big model and getting responses a few times per hour as long as its high quality
Yeah, I was equally surprised. I am using a patched version of ollama to run the models: https://github.com/austinksmith/ollama37 which has a trivial change to allow it to run with old versions of cuda (3.5, 3.7). Obviously this was before tensor cores were a thing, so you're not going to be blown away by the performance, but it was cheap. I got 3x k40s for $75 on ebay, they are passively cooled, so they do need to be in a server chassis.
These days you don't have to worry about endianness much (unless you dealing with raw network packets). However, you do need to worry about byte-padding. Different compilers/systems will place byte padding between items in your struct differently (depending on the contents and ordering of items), and if you are not careful the in-memory or on-disk placement of struct data elements can be misaligned on different systems. Most systems align to a 8-byte boundary, but that isn't guaranteed.
Just drill a small ~1mm hole in the seat/down tube of all bikes before each race. That shouldn't meaningfully affect the frame's structural integrity, but would easily disable any small motor attached to the crank.
This was bound to happen at some point, but probably net-on-net won't affect most users. I think it's pretty useful for a variety of tasks, but those tend to fall into a rather narrow category (boilerplate, simple UI change requests, simple doc-strings/summaries), and there is only so much of that work which is required in a month. I certainly won't be cancelling my plan over this change, but so far I also haven't seen a reason to increase it over the hobbyist-style $20/mo plan. When I do run into usage limits, its usually already at the end of the day, or I just pivot to another task where it isn't helpful.
> A limitation of this work is that the resulting de-oxygenated titanium contains yttrium, up to 1% by mass;
> After solving the yttrium contamination problem, applications to industrial manufacturing will be straightforward.
One wonders how much of a problem this is for most applications, and how easy it will be to solve...
