That’s a compelling niche. SOC 2 prep is a brutal rabbit hole for small teams. Even just a pre-flight checklist with integrations would be useful—curious how much automation they’re actually packing in.
It’s fascinating how long the BEAM has lasted. And even more fascinating how relevant its concurrency model still is in today’s async-heavy world. Built different.
N-body problems are the gateway drug into numerical physics. Writing one from scratch is a rite of passage. Bonus points if you hit that sweet spot where performance doesn’t completely tank.
At this point, “permission fatigue” is real. You almost get trained to click ‘Allow’ just to get work done—which defeats the whole point. Would love a tiered trust model, not binary prompts.
> You almost get trained to click ‘Allow’ just to get work done
I had an interesting experience of this with a normal/non-technical user when my wife asked for help setting up some money remittance app. Early in the install it popped up some dialog, something about whether you wanted to transfer money via credit card or...except she clicked the "OK" button before I could read more than that. As in, she clicked it literally as fast as she could process there was a pop-up and move her finger there.
I asked her why she clicked the pop-up away without reading it, it might have been important...and she literally began to argue with me that there hadn't been a pop-up and what was I talking about.
Just like how our brain has learned to edit out blinking, it seems like (at least in some circumstances) her brain has learned to edit out pop-ups and essentially muscle memory is clicking "Okay" as fast as possible to get back to whatever she was doing.
This piece hit hard. It’s strange how something so invisible to most of us is simultaneously one of the most complex, tightly-coupled systems running in the background of daily life.
But is it that complex? Airplanes arrive in your sector, you write the number and destination on a slip of paper, and put it on your board. You tell the plane, if needed, where to fly, and then you tell it to talk to the next sector controller when it leaves your area.
It seems rather non-complex, and I think it has to be, so it can be robust and offer room for errors etc.
Everything is simple at the highest levels of abstraction.
It is the details of actually making it work that raise the complexity levels and/or kill you if you don't get them right.
Remember: a decision that in the abstract with infinite thinking time is easy can be extremely stressful when it has to be made in seconds in real time and getting it slightly wrong will potentially cause a catastrophe. And ATC has to keep doing this throughout their entire work shift.
A lot of the complexity is the sheer volume of air traffic. Not so much at cruise, but as planes transit through populated areas. ATC over NorCal is a mess of overlapping zones, ~dozen airports, and hundreds of airplanes at any given time of day. NYC metro is similar.
The overall system will be powered by 48V DC on a 6-pin Molex Mini-Fit Jr connector, then stepped down to 12V by a 48->12V intermediate bus converter I've previously designed and characterized (https://serd.es/2024/10/15/Intermediate-bus-converter.html)
The 24-port line card has a 15W TDP overall (6.75W datasheet worst-case power consumption for each of the two 12-port PHYs, plus 1.5W added for power supply conversion losses and such). With my current bench setup (11/12 links up on PHY 0 and 2/12 on PHY 1, all linked up at gigabit but with PHY 1 not talking to the FPGA yet), they're happy but warm - 63.8 and 49.5C die temperature respectively, pulling a combined 7.173W (not counting power conversion losses) according to the internal sensors. PCB temperature is 37.2 to 49C at various measurement points.
The entire setup including the FPGA board, IBC, one of the two planned line cards, and some other glue components that won't be in the final switch is pulling 18W and change right now although the FPGA power consumption will go up as I build out more logic. I don't have measurements of just the FPGA's power consumption currently (I could put a current clamp on the 12V cable from the IBC I guess) but the PDU board does have I2C sensors that will measure consumption of the logic board and each line card separately; I just haven't written the firmware to read them yet. I also don't have FPGA temperature readings in the current firmware although last time I checked them via JTAG I had plenty of margin.
As of right now everything is happy with low-profile heatsinks (Wakefield-Vette 960-27-12-D-AB-0 on both the PHYs and FPGA) and passively cooled just sitting on my bench with no fans. I can go taller if increased power consumption or worse airflow in the future dictates, they're nowhere near the point of hitting the top of a 1U chassis.
My plan for the final system is to have air intakes somewhere on the sides and/or the front around the RJ45s and one or more fans exhausting out the back, details TBD based on more design and testing once I have better projections of the overall thermal load.
Very roughly my overall thermal/power budget is 15W per line card = 30W combined, plus no more than 20W for the logic board (probably quite a bit less) with all ports lit up and passing packets, for a total of 50W plus whatever the losses in the IBC are (it's roughly 94% efficient at this load based on previous testing). This is comfortably below the 72W output limit of the IBC, and should be very reasonable to reject from a 1U chassis with fairly basic air cooling, especially since it's not all coming from a single point load like a single-socket server.
Honestly surprised it took this long. For a project that depends so much on community contribution, being on GitHub just lowers the barrier for new devs. Curious to see if this revives contribution velocity.
In the very least, it will open up FTEs that can now work on what makes Mozilla projects unique, rather than on building and maintaining generic fundamentals.
It's a pet-peeve and personal frustration of mine. "Do one thing and do that well" is also often forgotten in this part of Open Source projects. You are building a free alternative to slack? spend every hour on building the free alternative to slack, not on selfhosting your Gitlab, operating your CI-CD worker-clusters or debugging your wiki-servers.
One underrated trick? Listening without trying to solve right away. I’ve seen engineers open up more when they feel heard rather than redirected. That alone can shift team dynamics faster than most “leadership frameworks.”
Yes, but also "feeling heard" is different from actually *being* heard — feelings work short term, being heard makes more of a difference the longer the time horizon.
I distinctly remember working at a company where management were very good at making you feel heard. But with time, it was clear that’s all they were doing.
Too often I flipped this around. I would hear what people had to say but did not put an effort into making sure that they felt heard. I process information quickly and would not pause and move quickly through a conversation. The results were not as good as they could be.
I learned how to make people feel heard and it worked wonders.
I don’t know how I could make someone feel heard without hearing them out.
