I really like epaper displays for all of the reasons mentioned in the article. Shame the patent locks continue to keep prices high even though the core technology has improved enough for prices to drop.
A few years ago I came into a couple of e-ink displays that had been previously used for storefront/product pricing. The hardware to drive them was locked down but I was able to reverse engineer the panel by finding a datasheet that was close enough and hacking up an adafruit thinkink. I had a lot of fun writing my own driver/abstraction layer. I originally intended to support a bunch of different panels but ran out of steam after the first one did exactly what I wanted.
Glad I wasn’t the only one who thought this. The post is also missing one obvious thing that I expect in any technical post: code snippets. Let me see the code.
ChatGPT has ruined bullet points for the rest of us…
No offense but writing this blog post couldn’t take more than a few minutes, why spoil it with LLM? Shoot, use one to check grammar and recommend edits even.
Ah yes, one of my favorite skills learned in school was how to work around arbitrary rules made up by cranky sysadmins! I still use it all the time.
The smart kids (whom I’m sure look like they are learning that precious openssh client) are doing their assignment locally or on a free tier VPS with VS Code and scping the thing over when it’s done.
They’re also smart enough to learn openssh when they need it IRL.
I came here to say this. I haven’t worked with the Elite X but the past gen stuff I’ve used (865 mostly) the accelerators - compute DSP and much smaller NPU - required _very_ specific setup, compilation with a bespoke toolchain, and communication via RPC to name a few.
I would hope the NPU on Elite X is easier to get to considering the whole copilot+ thing, but I bring this up mainly to make the point that I doubt it’s just as easy as “run general purpose model, expect it to magically teleport onto the NPU”.
I don’t know the size or structure of your team, but one thing that has worked for me in addition to other strategies mentioned on this thread (specifically, that oncall is oncall, nothing else) is that you appoint one engineer - typically someone who has a more strategic mindset as the “OE Czar”. They are NOT on call, and ideally not even in the rotation, but rather there for two reasons: to support oncalls when they need longer term support, like burning down a longer running task/investigation or keeping continuity between shifts. The other is identifying and planning (or executing on) processes and systems for fixing issues that continually crop up. Our mandate was 20% of this person’s time spent doing Czar tasks vs scheduled work.
I spent quite a bit of time a few years ago recovering my old MySpace account only to realize they “messed up” (unclear whether it was incompetence, or purposeful) and deleted basically anything that had been, oh I dunno, actually interesting: pictures, videos, playlists…you can’t even see the profile pictures of people in your friends list.
In the rush to move to whatever the next big social media was, I’d never thought about backing up my stuff because why would it ever be gone and why would I care? Lesson learned.
I was weirdly bummed out about it. Back when the site first launched I spent loads of time learning HTML just to customize my page before I realized site profile generators existed.
A few years ago I came into a couple of e-ink displays that had been previously used for storefront/product pricing. The hardware to drive them was locked down but I was able to reverse engineer the panel by finding a datasheet that was close enough and hacking up an adafruit thinkink. I had a lot of fun writing my own driver/abstraction layer. I originally intended to support a bunch of different panels but ran out of steam after the first one did exactly what I wanted.
https://github.com/jaygreco/MagInkCal