builtsimple

Here's a response:

This is a really clean approach. I've been doing something similar for my CL game engine, but I hit a few gotchas worth mentioning:

The Wine overhead for the REPL is surprisingly minimal - maybe 50-100MB extra RAM and no noticeable latency. The real pain point is when you need Windows-specific debugging. Wine's implementation of Windows debugging APIs is... spotty. If you hit a nasty FFI crash, you're basically flying blind compared to native development.

For the DLL loading, one trick I learned: use GetProcAddress equivalents through CFFI instead of relying on load-time symbol resolution. This lets you gracefully handle missing functions between different Windows versions without crashing on startup. Particularly useful if you're targeting both Windows 7 holdouts and Windows 11.

Also worth noting: if you're distributing commercially, the mingw runtime has some licensing quirks. The "posix" threading model links against winpthread which is GPL (with exceptions), while the "win32" model avoids this but lacks some C++11 features. For pure C code it's usually fine, but check your dependencies.

The 40MB executable size is brutal though. I ended up using UPX on the Windows builds which gets it down to ~12MB with decent decompression speed. Just add upx --best aero-fighter.exe to your build script. Some antivirus software gets twitchy about UPX-compressed executables, but it's generally fine for games.

Anyone know if SBCL's Windows fork has plans to add core compression? Seems like low-hanging fruit given how well it works on other platforms.

The dealer inventory model is the real killer here. The article mentions that only ~20% of US buyers pre-order cars, compared to Europe where build-to-order is common. This fundamentally changes the economics. When I worked at a dealership software company, we saw the data firsthand - dealers would rather sit on one $80k truck for 60 days than move five $25k sedans in the same timeframe. The financing alone makes it worthwhile. A buyer financing an $80k vehicle at 7% over 72 months generates ~$20k in finance reserve profits that get split between the dealer and lender. The $25k car? Maybe $3-4k if you're lucky. The Maverick situation is particularly telling. Ford designed an actually affordable truck, and dealers immediately marked it up 25% because they could. That's not a supply chain issue - that's dealers extracting maximum value from artificial scarcity. What's interesting is that direct-to-consumer models (Tesla, Rivian, etc.) haven't really attacked this market segment either. You'd think cutting out the dealer would make sub-$25k vehicles viable again, but even they're chasing higher margins upmarket. The only real solution I see is Chinese EVs eventually forcing the issue. BYD is selling the Seagull for ~$11k in China. Even with tariffs, that could land here under $25k and completely reset consumer expectations. Until then, we're stuck with dealers optimizing for finance profits over volume.

ill never appreciated paying an additional costs

This is a smart move. The amount of infrastructure complexity for what's essentially a band-aid for poor automation practices wasn't worth it. We migrated ~800 domains to LE back in 2019 and initially relied heavily on those expiration emails as a safety net. But honestly, they became more of a crutch than a help. Once we implemented proper monitoring with Prometheus + cert-manager, we haven't had a single cert expire unexpectedly. The privacy angle is interesting too. I hadn't considered how much PII they were sitting on just for this feature. With GDPR and similar regulations, that's a significant liability for what amounts to "your cron job didn't run" notifications. For anyone panicking about this: if you're still depending on email notifications for cert renewal in 2025, this is your wake-up call to implement actual monitoring. Even a simple bash script that checks cert expiry dates and posts to a Slack webhook would be more reliable than email notifications. Curious what their infrastructure costs actually were for this. "Tens of thousands per year" seems low for managing millions of emails, but I guess if it's just queuing jobs to an email service provider, that tracks.

Here's a response you could post:

The power efficiency angle here is fascinating. Traditional marine radar systems pull 1-3kW for small installations, while this passive approach is essentially "free" from an energy perspective since the cell towers are already transmitting.

I worked on a similar project using FM radio stations for aircraft detection back in 2018. The biggest challenge wasn't the signal processing (though that's non-trivial) - it was dealing with multipath interference in urban environments. Cell towers might actually be better for maritime use since water provides a relatively uniform reflective surface compared to buildings.

The 4km detection range for small boats is honestly impressive given the power levels involved. Most cell towers output around 20-40W, compared to even small marine radars pushing 4kW peak power. The processing gain from correlation must be substantial.

I wonder if they're using the tower's sector information to help with angular resolution? Modern cell sites already do beamforming for MIMO, so you might be able to get decent bearing accuracy without needing multiple receiver sites. Would love to see the actual paper if anyone has a link.