I really love E Ink (or epaper, eInk, etc) dashboards.
I love the low power, the contrast, and just the future yet low-tech look.
This post is on another dashboard I made to show the solar production of the array in my home.
This is the same 10" upcycled Kindle display as before:
The positive Y axis represents production by the array, and the negative Y axis represents consumption. I previously had a line in the middle that represented Net, but it looked too busy.
For the longest time I’ve thought that we were doing container images “wrong”1.
Container images always felt so unnecessarily BIG.
Yes, there are lots and lots of ways to make images smaller, but still fundamentally they are shipping a root filesystem around. “Works on my machine!” Let’s ship the machine then.
Multi-stage builds came around and solved one class of bloat problem. At least we don’t need to embed lots of intermediate layers.
High Performance Computing (HPC) has always been interesting to me, ever since the first time I read a Beowulf cluster joke on slashdot.
High performance interconnects, huge storage, hundreds of nodes all working as one, the Top 500 list, what is not to love?
I’ve only dabbled with the HPC world a little bit in my career, so this blog post is NOT written from the perspective of an HPC veteran.
This blog post falls into the “I hope it is useful to someone” category.
I recently had the pleasure of figuring out how to restore a Cru RTX800-TR RAID array that was suspected to be inoperable.
This thing is a beast, and worth saving.
This was a personal favor for a friend, not related to work.
This is a technical write-up of what I did.
Specs Product: RTX800-TR Interface: Thunderbolt up to 10 Gbps bi-directional Drive Types Supported: 3.
Stealing a poker metaphor, there is an important lesson that senior engineers exercise when working in tech: Knowing when to Hold ’em, Fold ’em, or when to walk (or run!) away.
> You've got to know when to hold 'em, > know when to fold 'em, > Know when to walk away, > know when to run. > You never count your money > when you're sittin' at the table. > There'll be time enough for countin' > when the dealin's done.
I had previously blogged about an Eink dashboard for tracking baby stuff (see more in the eink series at the end of the page).
I’ve now repurposed that original baby dashboard (since I no longer need to track poopy diapers) into a weather station, and I would like to share some technical details about how it works.
An Eink Weather Display This weather display also uses the 9.7 e-paper and ESP32 controller.
I had previously blogged about an Eink dashboard for tracking baby stuff.
I’ve since added a new display for our family calendar, and I would like to share some technical details about how it works.
An Eink Family Calendar This uses an Inkplate 10 display. It is a 9.7-inch e-paper with an embedded ESP32 to control it.
You might think that this is powered with some sort of headless javascript thingy running in the cloud, or on some local kubernetes cluster in my house, or some other crazy infrastructure.
I don’t normally write blog posts that regurgitate information from normal documentation, but this particular subject irks me.
If you are running an internal Kubernetes (k8s) platform, you owe it to yourself to make sure there is nothing external to your platform determining your reliability.
You could ask yourself: How many internet dependencies do you have to start a pod? Should be zero, right???
If you use stock k8s, you might be surprised to know that each of your k8s nodes is actually reaching out to registry.
Five years ago I wrote a blog post against Kubernetes sidecars. I wrote that in response to the early days of sidecar containers becoming in vogue, and in response to Airbnb’s talk demonstrating the 7 containers they need for service discovery.
At Yelp, we held off on running sidecars at all, and stuck to the single-container model on k8s for a long time, relying on host daemons for almost everything extra.
In part 1 I talked about why I don’t like sidecars generally. In this part 2, I want to look at why we don’t use good ole libraries instead.
I Wish Libraries Were Easier to Make and More In Vogue Perhaps remind yourself: Why do we have sidecars in the first place again?
There are usually a couple of answers:
Separation of concerns: keep the app small and externalize functionality to the sidecar Independent deployment lifecycle: upgrade sidecars independently of your main app Independent resource/request limits: Clamp your sidecar to a given amount of RAM/CPU Let’s look at each of these reasons more closely.