cong-or
Joined 9 months ago
Karma
75
Submissions
18
Member since
Jan 28
Recent submissions
Comment · 9 months ago
Comment · 9 months ago
I built hud after getting burned by blocking in async Rust services during one too many 2am debugging sessions. Blocking on Tokio worker threads can quietly tank throughput and explode p99 latency, all without panics or anything obvious in the logs.
Most profiling tools technically work, but they expect you to reason clearly, correlate timelines, and keep a full mental model in your head. That’s fine at 2pm. At 2am, it’s hopeless. hud’s goal is to reduce cognitive load as much as possible: show something visual you can understand almost immediately.
The UI is modeled after a trans-Pacific night cockpit: dark, dense, and built to be readable when you’re exhausted.
Under the hood, hud uses eBPF to track scheduling latency—how long worker threads are runnable but not running. This correlates well with blocking (though it’s not a direct measurement). You can attach to a live process with no code changes and get a live TUI that highlights latency hotspots grouped by stack trace.
The usual suspects so far: std::fs, CPU-heavy crypto (bcrypt, argon2), compression (flate2, zstd), DNS via ToSocketAddrs, and mutexes held during expensive work.
Tokio-specific (worker threads identified by name). Linux 5.8+, root, and debug symbols required.
Very open to feedback—especially around false positives or flawed assumptions. Happy to answer questions.
Comment · 9 months ago
Interesting framing. The article makes a compelling case that we're seeing the hangover from 14 years of ZIRP-fueled hiring rather than an AI apocalypse.
But I'm curious what people think the equilibrium looks like. If the "two-tier system" (core revenue teams + disposable experimental teams) becomes the norm, what does that mean for the future of SWE as a career?
A few scenarios I keep turning over:
1. Bifurcation - A small elite of "10x engineers" command premium comp while the majority compete for increasingly commoditized roles
2. Craftsmanship revival - Companies learn that the "disposable workforce" model ships garbage, and there's renewed appreciation for experienced engineers who stick around
3. Consulting/contractor becomes default - Full-time employment becomes rare; most devs work project-to-project like other creative industries
For those of you 10+ years into your careers: are you optimistic about staying in IC roles long-term, or does management/entrepreneurship feel like the only sustainable path?
Comment · 9 months ago
The toxicology is pretty damning: codeine without morphine in stomach contents means someone crushed up Tylenol-3 and gave it to a 12-day-old baby. That's not a metabolic quirk—it's
homicide.
Koren's "ultra-rapid metabolizer" theory provided cover, and his research went on to clear 17 other caregivers in similar deaths. How many of those were actually murdered infants?
Comment · 9 months ago
2035: Apple takes 30% of my Patreon, Google matched it through their "Competitive Parity Agreement," and the EU fined them both €2 billion which they paid in 45 minutes of revenue then raised fees to 32% to cover legal costs.
The real innovation was convincing us this was inevitable.
Comment · 9 months ago
Surprised London holds this position given the cost of living. Housing alone eats such a massive chunk of salary that I'd expect talent to gravitate toward cities where their equity/salary goes further. How do early-stage startups compete for engineers when rent is £2k+ for a one-bedroom?
Comment · 9 months ago
Fair enough—I wasn’t imagining tiny compass-wielders. I was thinking more about whether the structure of a geometric construction might map to something computationally useful, like exact arithmetic systems (CGAL-style) that preserve geometric relationships and avoid floating-point degeneracies.
But for a constant like φ, you’re right—(1 + sqrt(5)) / 2 is trivial and stable. No clever construction needed.
Comment · 9 months ago
Is there a computational advantage to constructing φ geometrically versus algebraically? In rendering or CAD, would you actually trace the circle/triangle intersections, or just compute (1 + sqrt(5)) / 2 directly?
I’m curious if the geometric approach has any edge-case benefits—like better numerical stability—or if it’s purely for elegance.
Comment · 9 months ago
What’s the latency on a hostcall? A PCIe round-trip for something like File::open is fine—that’s slow I/O anyway. But if a println! from GPU code blocks on a host round-trip every time, that completely changes how you’d use it for debugging.
Is there device-side buffering, or does each write actually wait for the host?
Comment · 9 months ago
At ~$100B in AI funding, the question isn’t capital—it’s physical constraints.
Data centers need power (H100s are ~700W each), and recent capacity additions were mostly pre-allocated. Chip supply is also constrained by CoWoS packaging, not fab capacity, and expansions take years.
If power, packaging, and GPUs are fixed in the near term, does $100B mostly drive inflation in AI infrastructure prices rather than materially more deployed compute? Are we seeing the real cost of a usable GPU cluster rise faster than actual capacity?
Has anyone modeled what $100B actually buys in deployable compute over the next 2–3 years given these constraints—and whether that figure is shrinking as more capital piles in?
Most profiling tools technically work, but they expect you to reason clearly, correlate timelines, and keep a full mental model in your head. That’s fine at 2pm. At 2am, it’s hopeless. hud’s goal is to reduce cognitive load as much as possible: show something visual you can understand almost immediately.
The UI is modeled after a trans-Pacific night cockpit: dark, dense, and built to be readable when you’re exhausted.
Under the hood, hud uses eBPF to track scheduling latency—how long worker threads are runnable but not running. This correlates well with blocking (though it’s not a direct measurement). You can attach to a live process with no code changes and get a live TUI that highlights latency hotspots grouped by stack trace.
The usual suspects so far: std::fs, CPU-heavy crypto (bcrypt, argon2), compression (flate2, zstd), DNS via ToSocketAddrs, and mutexes held during expensive work.
Tokio-specific (worker threads identified by name). Linux 5.8+, root, and debug symbols required.
Very open to feedback—especially around false positives or flawed assumptions. Happy to answer questions.
https://github.com/cong-or/hud