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.
In the class which I have managed the infrastructure for, we have 1 to 2 students per VM, so this is less of an issue and there aren't any restrictions.
One of the reasons we provide the VMs is so that students can experience working in a remote server environment. The concern that I have is that these remote ssh tools allow you to bypass learning/practicing how to perform basic actions, e.g. cd, read/edit files.
Granted, as mentioned, you can scp/rsync (or git pull), but at least this seems to be more appropriate when you eventually need to interact with a real production server.
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.
From looking at various patents, I believe they put down a layer of PZT and then etch it into cubes with photolithography. Look at the process diagram at the bottom of my article, step 1128.
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