I recently upgraded to the 7900 XTX GPU which was a totally issue-free experience. Then today, I tried to install AMD ROCm so I could try out AMD’s TensorFlow fork that works with AMD GPUs. I ran into a lot of issues with this that resulted in my computer not being able to boot for a while. I eventually figured it out, but it was quite a struggle. It started after I downloaded and ran amdgpu-install - AMD’s tool for installing drivers and other software for use with their hardware.

Just today, I switched to the 7900 XTX GPU. I mostly just wanted an upgrade, but I also secretly hoped it would fix a lot of the weird GPU-related issues I’ve had over the past years. The 5700 XT is a rather buggy GPU as far as I can tell - especially on Linux which is my only OS on my desktop. I’ve run into multiple bugs with drivers and other mysterious green-screen crashes:

TL;DR: uPlot is a Spartan charting library that focuses intensely on minimalism and performance. It feels very much like a tool made for hackers, and it lacks many of the features and embellishments of fully-featured charting libraries. The main downside is that it has quite terrible docs and sometimes has confusing APIs I’m personally a big fan of its aesthetic and design goals, and I will probably be sticking with it as my primary charting library for the web for the forseeable future.

The main Rust workspace for my job at Osmos is very large. It has several thousand dependencies, does copious compile time codegen from gRPC protobuf definitions, and makes extensive use of macros from crates like serde, async-stream, and many others. While it’s really convenient having all of our code in one place, this results in a lot of work being done by the Rust compiler as well as rust-analyzer during normal development.

I recently encountered a bug in one of our services at my job at Osmos. Our service is written in Rust and connects to GCP PubSub via its gRPC interface. We were running into errors in our logs like this: Error, message length too large: found 5360866 bytes, the limit is: 4194304 bytes The service in question had been running for over 2 years without seeing this issue before, and the message size limits shown are smaller than the PubSub message size cap of 10MB.

I often need to expose some service running locally on my computer to the public internet for some reason or another. Demoing a website, exposing an API, giving someone access to download some local files, stuff like that. The popular solution for this is tools like ngrok. You download their CLI application to your computer, specify a port, and your local service is available at a URL like https://a78f837.ngrok.io/. The downside of this is that there are limits for the free versions of these services.

There’s a service https://tunnelto.dev/ which I’ve used in the past. It’s an ngrok alternative for exposing local services publically for things like demos, testing, etc. I heard about tunnelto.dev when it was announced on Hacker News and gave it a try along with several others on my team at Osmos. It looked fresh, was written Rust, and was at least partially open source - all great. I even signed up for the (very cheap) paid plan which gives custom subdomains and some other stuff.

Background I recently had the need to build a custom renderer for graphs generated by graphviz for a project visualizing computation graphs for RNNs. Graphviz has an output format called plain and plain-ext which generates a very simple text-based layout specification for all nodes and edges in the input graph. It’s pretty well spec’d out in the official docs for the most part: https://graphviz.org/docs/outputs/plain/. Here’s an example of what plain-ext output format looks like for a simple graph: