7,006 karma · joined December 12, 2014
https://mattkeeter.com
https://docs.google.com/document/d/1y3L6dXqkK3c5IN2j73HuZkda...
This is slightly specialized for the Product Marketing role; for engineering roles, the Market Analysis section is replaced with a similar section for engineering / system analysis.
(I work at Oxide, but this link is publicly available, albeit hard to find on the website)
Between the "blog" and "projects" categories, it's about 80 posts dating back to 2008 (wow).
In recent years, it's tended towards an eclectic mix of low-level programming, graphics research, and electrical engineering.
Many posts have substantial HN discussions, e.g.
- Do Not Taunt Happy Fun Branch Predictor (https://news.ycombinator.com/item?id=34520498)
- From Oscilloscope to Wireshark: A UDP Story (https://news.ycombinator.com/item?id=32428032)
- XModem in 2022 (https://news.ycombinator.com/item?id=31570953)
- It Can Happen To You (https://news.ycombinator.com/item?id=26337046)
Before starting up the fans, the guy running the control booth picked up the phone and had a short conversation, roughly
"Hi, this is [name] at the wind tunnel; can we turn it on?"
[someone on the other end replies]
"Great, thanks."
I asked who he was calling, and he explained that he had to check with the power company before powering it on. This was mid-winter, so grid demand was low; apparently during the summer (when everyone has ACs on), the start-up load could cause brownouts!
Unfortunately, I didn't know who she was, so my first encounter was having a seemingly random stranger stop me on the sidewalk and ominously declare:
"You didn't have a beard in your picture, Matthew."
Several of the boards discussed in the post were designed by people that are nominally on the embedded team, e.g. I designed the Gimletlet NIC and Root-of-Trust-Carrier-Carrier.
A good acquisition target company should be "willing to sunset old customers within 90 days or less, with an option to transition to GitLab" [1]
Given the pattern of startups being acquired, announcing "nothing will change", then sunsetting their original product [2], it's interesting to see this spelled out so plainly.
[1] https://about.gitlab.com/handbook/acquisitions/#acquisition-...
[2] https://ourincrediblejourney.tumblr.com/ is the canonical repository of these emails
The original is here:
https://www.businessinsider.com/amazon-chatgpt-openai-warns-...
(alternatively, https://archive.is/fkU7E)
IIRC, OpenSCAD uses CGAL and is all triangles under the hood; other tools use OpenCascade for NURBS modeling, or weirder DIY kernels.
Good catch; this should be fixed (using N for input length and W for window size consistently in the writeup).
For example, "Science Needs Sovereigns": https://www.palladiummag.com/2022/10/03/science-needs-sovere...
If you don't handle this correctly, then you'll have a Very Fun time [2].
What's especially Fun is that if you halt your program in a debugger and read back the contents of the JIT buffer, it will look perfectly correct – because those reads are coming through RAM / DCache, not ICache!
[1] https://developer.apple.com/library/archive/documentation/Sy... [2] https://twitter.com/impraxical/status/1579586601117548544
A very well-respected developer recently told me to "take down your blog entry and this repo before you generate more embarrassment for yourself", because I didn't do a comprehensive literature review (and cite their code) before writing a blog post.
(They later went back and edited their comments to turn down the vitriol, but guess which version I read immediately upon waking up?)
I've been around the industry for a while and have relatively thick skin, but even so, dealing with that ruined my day.
If I was new to the industry, I can't imagine how I would have reacted – but it certainly wouldn't have been positive; I could easily imagine burning out of open-source entirely given that reception.
https://wiki.winehq.org/Developer_FAQ#Who_can.27t_contribute...
Given that your Github issue [1] was originally titled "Take Down Notice", I'm now hesitant to read any LuaJIT code.
If I read lj_asm.c and learn from it, will you try to take down any register allocation code that I write in the future?
I promise that this was a genuine case of parallel evolution – I didn't read any LuaJIT source or documentation while writing the code or article.
Afterwards, I searched for "reverse linear scan register allocation", discovered the blog post which referenced LuaJIT, and linked it in the text.
I've updated the article to move the LuaJIT reference to the top, and adjusted the phrasing to be clear that this is not an invention, it's simply an interesting implementation. What you call "naive", others may consider didactic :)
Let me know if you have other feedback or suggested changes, either here or via email (in my profile).
https://hubris.oxide.computer/reference/
It's all open-source on Github:
https://github.com/oxidecomputer/hubris
(I work at Oxide, mostly using Hubris)
I wonder if they are running a scraper that automatically cross-posts trending repos...
(Also, the probe itself has a max bandwidth of 10 GHz, so it will filter those frequencies before they're sampled by the oscilloscope)
The higher sample rate is useful, because it effectively gives higher precision when finding the zero crossings; however, you could reduce the .wfm size by sampling at 50 GS/s on the scope then upsampling on the computer.
Hubris is intended to run on microcontrollers in a very low-level context (e.g. no display), so is very unlikely become a desktop / user-facing OS.
(I work at Oxide, mostly writing Hubris code)
It turns out I had misremembered; the cast I was thinking of is
https://github.com/oxidecomputer/hubris/blob/master/sys/kern...
from &mut MaybeUninit<[T]> to &mut [MaybeUninit<T>], which doesn't construct a reference to something uninitialized.
> A mutable reference must also never point to an invalid object, so doing let role = &mut *uninit.as_mut_ptr() if that object is not fully initialized is also wrong.
I'm curious who's right here, because I've seen your pattern in code recently!
For example, if you're building a system that does controls multiple motors, you'd naively do motion-planning calculations for only the motors that are actively running. If instead you do these calculations for every motor all the time, even the ones that aren't moving, you'll have a worst-case performance profile; if it still works, then you can be more confident about the system.
(I work at Oxide, but only for about a month, so this is more past experience than Hubris-specific)