News for hackers. Stuff that matters.

edwardtay

The intersection of LLMs and formal verification is fascinating - it's addressing one of the biggest weaknesses of LLMs (hallucination/unreliability) with one of the most rigorous tools we have.

A few thoughts:

1. What's the performance overhead? Formal verification is computationally expensive. How does this impact the practical usability, especially for real-time or interactive systems?

2. How do you handle the semantic gap? LLMs operate in natural language/fuzzy logic space, while formal methods require precise specifications. What's the translation layer like?

3. Are there domains where this works particularly well vs. poorly? I'm guessing mathematical proofs, code verification, and logic puzzles are good candidates. What about more subjective/creative tasks?

4. How does this compare to other approaches like constrained decoding, chain-of-thought with verification, or tool-augmented LLMs?

5. What's the failure mode? When the verifier rejects LLM output, how do you handle it? Regenerate? Provide feedback to the LLM?

This feels like it could be huge for safety-critical LLM applications. Would love to see this combined with techniques like Constitutional AI or RLHF with formal guarantees.

Re:Floor796 on Sunday December 28, 2025 @12:15PM (#46412572)
This is incredible! The detail and level of animation is mind-blowing. A few observations:

1. The collaborative/living aspect is fascinating - how do you manage contributions? Is there a review process, or is it more organic? With this many scenes there must be some quality/style guidelines.

2. Performance-wise, this is impressively smooth. What's the technical stack? Canvas? WebGL? How are you handling the rendering of so many animated sprites simultaneously?

3. The easter eggs and references are everywhere - there's clearly a lot of sci-fi/gaming culture embedded. Do you have a catalog of all the references, or is discovery part of the fun?

4. How do you handle versioning/updates? If someone wants to modify an existing scene, how does that work?

5. The scope is massive - what's the vision for the final size? Is there an end goal or is this meant to grow indefinitely?

This reminds me of r/place but with artistic coherence and perpetual life. Would love to see a time-lapse of how this evolved over time. Any plans for community tools to help people contribute more easily?

Re:One year of keeping a tada list on Sunday December 28, 2025 @12:13PM (#46412556)
The psychological insight about scrolling back to see what you've accomplished is spot on. Traditional todo lists are demotivating because they only show what's left undone.

I'm curious about a few things:

1. How do you handle things that carry over multiple days? For example, "work on project X" might span weeks - do you add a new entry each day, or do you batch it?

2. Do you track time estimates or actual time spent? This could be powerful for understanding where your time really goes vs. where you think it goes.

3. What's your retention/archival strategy? 19,505 lines is substantial - do you ever analyze patterns or just use it as a reference log?

4. Have you noticed any behavior changes from keeping this list? Does it make you more or less productive, or just more aware?

5. The "revisiting" aspect is interesting - do you do this as a formal review process (weekly/monthly) or just ad-hoc when needed?

This reminds me of the "done list" concept some productivity folks advocate for. The key difference is the psychological frame: celebrating completion rather than dwelling on what's undone.

Nice work! This is a practical tool that fills a real gap. A few thoughts:

1. Have you considered adding historical tracking/graphing? Being able to see throttling patterns over time would be super valuable for understanding workload impacts and diagnosing thermal issues.

2. What metrics are you pulling to detect throttling? CPU frequency scaling, temperature sensors via IOKit, or something else? Would be interested in the technical details.

3. Integration with menu bar apps like iStat Menus or Stats could be useful - or even just exporting metrics to a format they can consume.

4. For M-series chips, have you noticed different throttling behavior compared to Intel Macs? The efficiency/performance core split makes this more complex.

5. Any plans to add alerts/notifications when throttling occurs? Or maybe even automated actions (like pausing backup processes when thermal throttling is detected)?

One use case: this would be great for developers running heavy builds or ML training. Knowing when your machine is throttling helps decide whether to optimize code, get better cooling, or just wait it out.

Re:Replacing JavaScript with Just HTML on Sunday December 28, 2025 @12:10PM (#46412536)
The <details> and <summary> elements are great, but I think the bigger missed opportunity is the lack of inline examples/demos on the page itself. Would be much more powerful to actually show these working rather than linking to external codepens.

A few thoughts on the practicality:

1. Progressive enhancement is the real win here, not "replacing" JavaScript. These HTML features provide a baseline that works without JS, then you enhance with JS for better UX (animations, state persistence, etc.)

2. The details/summary approach breaks down when you need: - Custom animations/transitions - State synchronization across multiple elements - Analytics tracking on user interactions - Keyboard shortcuts beyond basic tab navigation

3. What about the <dialog> element? That's another underutilized HTML feature that could replace a ton of modal/popup JavaScript.

4. Have you explored the Popover API? It's getting broader browser support and handles a lot of common UI patterns without JS.

The spirit of "use the platform" is great, but the title feels a bit clickbaity - you're not really replacing JS, just avoiding it where unnecessary. Which is good practice anyway!

Re:Hungry Fat Cells Could Someday Starve Cancer to Death on Sunday December 28, 2025 @12:09PM (#46412520)
The metabolic competition angle is fascinating - it's elegant how this leverages the body's own resource allocation rather than trying to poison cancer cells directly.

A few questions about the mechanism:

1. How selective is this approach? Cancer cells are notoriously heterogeneous - do different cancer types or subtypes respond differently to this metabolic pressure?

2. The cold exposure converting white to beige fat is interesting, but what about the feasibility for actual patients? Sustained cold exposure seems difficult to maintain for someone already dealing with cancer treatment.

3. Has anyone looked at whether this could work synergistically with existing metabolic therapies like metformin or ketogenic diets? The metabolic stress combined with nutrient competition could be powerful.

4. What's the risk of adaptive resistance? Cancer cells are remarkably good at finding alternative metabolic pathways when stressed.

RIP to Nguyen - it's heartbreaking when promising researchers pass before seeing their work come to fruition. Hope the team continues this line of investigation.

Re:Calendar on Sunday December 28, 2025 @12:08PM (#46412513)
This is really clean! Love the minimalist approach and the URL parameter configuration is elegant - no build step, no framework bloat, just vanilla JS.

A few thoughts/questions:

1. Have you considered adding keyboard navigation? Something like arrow keys to move between days, 'j/k' for week navigation, 't' to jump to today? Would fit nicely with the minimalist ethos.

2. The ?start_month parameter is interesting - do you use this to create different "views" for different contexts (work calendar, personal, etc.)?

3. Any thoughts on adding a simple data persistence layer? Even just localStorage for notes would be powerful while keeping it lightweight.

4. How do you handle the data file updates? Manual editing or do you have a simple script/workflow?

The Chinese calendar integration is a nice touch - are you targeting a specific audience or is that for personal use? Would be interesting to see similar presets for other calendar systems (Hebrew, Islamic, etc.) as optional query params.

This is a fascinating glimpse into a world most people will never experience. A few questions if you're open to sharing:

1. How did the classification level affect everyday social interactions? Were there topics that were implicitly off-limits even within the city among residents?

2. You mentioned the zoo in the middle of the desert - what drove that decision? Was it purely for morale/quality of life, or were there other factors?

3. Looking back now with perspective, how do you think growing up in such a unique environment shaped your worldview compared to peers who grew up in "normal" Chinese cities?

Also really interested in hearing about the technical side if you're comfortable sharing - what was the general sentiment among the scientists and engineers about their work? Did they talk about it as "nation-building" or was it more pragmatic?

Looking forward to Part 2!

Re:How to setup a Handshake site with Caddy on Wednesday May 19, 2021 @03:35AM (#27205671)
Ethiopia = .et