MurphyA/hacker-news huggingface dataset:
by sn9 | 2025-12-16 22:55:09+00:00
I'd also check out HtDP [0] or the similar two-book set on problem solving and program design by Marco T. Morazán [1].

They both come from the Racket school of pedagogy and focus on systematic program design [2]. The first resource is free and excellent, but the second goes into more detail.

[0] https://htdp.org/2024-11-6/Book/index.html

[1] https://www.amazon.com/stores/author/B09QMPRYYM/allbooks?ccs...

[2] https://felleisen.org/matthias/Thoughts/The_Design_Recipe.ht...
by SpicyLemonZest | 2025-12-16 22:55:17+00:00
The subject of the article, Kimberly Prost, is one of the specific decisionmakers at the ICC who ruled that the Afghanistan investigation could proceed over American objections. I agree with what I think is your implication, that it wouldn't make much sense to sanction random ICC employees.

What I'd want in some hypothetical situation, though, doesn't have much to do with it. If it were up to me, I'd rather the US ratify the Rome Statute so there's no jurisdictional issue in the first place.
by zamadatix | 2025-12-16 22:56:11+00:00
In all of these cases, 95% of the comments are by <1% of the users and are probably less relevant goals to Mozilla than us power users would like them to be. Someone is always going to be angry, that doesn't really decide whether you're damned if you do/don't though. I honestly wonder if "internet privacy" is even something the average user is truly interested in either.

I wouldn't be surprised if 'lame' things like "videos look a lot more vivid in Chrome" (due to the years of lag getting HDR support in Mac/Windows) lost Firefox more users than they gained for maintaining support for MV3 uBO. I.e. fewer than 10% of FF installs have uBO installed, even after Chrome dropped it, but the volume of comments about MV3 would have led you to believe this is all browser makers need to consider to be successful.
by DarmokJalad1701 | 2025-12-16 22:56:40+00:00
Depends on the method/recipe. Most of the recipes I follow have at least two rising steps, following by another one after the dough is shaped into its final loaf (or whatever shape you want). Each one would be about an hour and half or so. It could be done with a single rise as well, but two rises tends to give more flavor. If you don't want it right away, a slow overnight rise in the fridge is also pretty good.

"No-knead" recipes usually involve 20-30 minute cadence of "fold-and-stretch" followed by a rise to allow the gluten to develop naturally without kneading. Usually about four times.
by cafebeen | 2025-12-16 22:56:44+00:00
Thank you for publishing that paper, which I think greatly helped address this problem at the time, which you accurately describe. I guess things have to be taken in their historical context, and science is a community project which may not uniformly follow best practices, but work like this can help get everyone in line! It's unfortunate, and no fault of the authors, that the general public has run wild with referencing this work to reject fMRI as a experimental technique. There's plenty of different ways to criticize it today, for sure.
by dismalaf | 2025-12-16 22:56:58+00:00
Honestly, who cares?

This will no doubt be used by many people who use Hyprland and I really don't think Vaxry cares about anything else. He's a college kid from Poland who now is getting enough donations he probably will never have to work for someone else if he doesn't want to, and can just continue developing his own ecosystem.
by pacjam | 2025-12-16 22:57:20+00:00
I think it cuts both ways - for example I've definitely had the experience where when typing into ChatGPT I know ahead of time that whatever "memory" they're storing and injecting is likely going to degrade my answer, so I hop over to incognito mode. I've also had the experience where I've had a loosely related follow-up question to something and I didn't want to dig through my chat history to find the exact convo, so it's nice to know that ChatGPT will probably pull the relevant details into context.

I think similar concepts apply to coding - in some cases, you have all the context you need up front (good coding practices help with this), but in many cases, there's a lot of "tribal knowledge" scattered across various repos that a human vet working in the org would certainly know, but an agent wouldn't (of course, there's somewhat of a circular argument here that if the agent eventually learned this tribal knowledge, it could just write it down into a CLAUDE.md file ;)). I think there's also a clear separation between procedural knowledge and learned preferences, the former is probably better represented as skills committed to a repo, vs I view the latter more as a "system prompt learning" problem.
by EvanAnderson | 2025-12-16 22:57:49+00:00
It's doesn't seem like much of a grey area to me. Presumably Flock serves the useful function of satisfying the third-party doctrine, making the surveillance they gather immune from 4th amendment protection (since I "willingly shared" my location with them by passing one of their cameras). If law enforcement has access to that data without a warrant it's de facto public to me.

FOIA isn't the same thing as having the data at my fingertips like LE does. I think the public deserves the same access LE has. If they can run ad hoc searches so should the public.

Personally I'd rather see all dragnet surveillance just go away.
by pron | 2025-12-16 22:58:07+00:00
... if it's achievable at all in the near future! But we don't know that. It's just that if we assume AI can do X, why do we assume it cannot, at the same level of capability, also do Y? Maybe the tipping point where it can do both X and Y is near, but maybe in the near future it will be able to do neither.
by embedding-shape | 2025-12-16 22:58:30+00:00
> A purist approach like in scenario 1 leaves everyone poor.

That depends, not always. Sometimes the employees of said company manages to contribute back upstream, on the dime of the company. If the "free software" they used and contributed to have a lot of users, it's certainly not "leaves everyone poor" but rather "helps everyone, beyond monetary gain".

Sure, you can make the argument that it isn't that great for the company, and you may be right. But the world is bigger than companies making money, killing a few companies along the way to make small iterative steps on making free software for absolutely everyone is probably a worthwhile sacrifice, if you zoom out a bit.
by jdashg | 2025-12-16 22:58:34+00:00
And the GPU API cycle of life and death continues!

I was an only-half-joking champion of ditching vertex attrib bindings when we were drafting WebGPU and WGSL, because it's a really nice simplification, but it was felt that would be too much of a departure from existing APIs. (Spending too many of our "Innovation Tokens" on something that would cause dev friction in the beginning)

In WGSL we tried (for a while?) to build language features as "sugar" when we could. You don't have to guess what order or scope a `for` loop uses when we just spec how it desugars into a simpler, more explicit (but more verbose) core form/dialect of the language.

That said, this powerpoint-driven-development flex knocks this back a whole seriousness and earnestness tier and a half: > My prototype API fits in one screen: 150 lines of code. The blog post is titled “No Graphics API”. That’s obviously an impossible goal today, but we got close enough. WebGPU has a smaller feature set and features a ~2700 line API (Emscripten C header).

Try to zoom out on the API and fit those *160* lines on one screen! My browser gives up at 30%, and I am still only seeing 127. This is just dishonesty, and we do not need more of this kind of puffery in the world.

And yeah, it's shorter because it is a toy PoC, even if one I enjoyed seeing someone else's take on it. Among other things, the author pretty dishonestly elides the number of lines the enums would take up. (A texture/data format enum on one line? That's one whole additional Pinocchio right there!)

I took WebGPU.webidl and did a quick pass through removing some of the biggest misses of this API (queries, timers, device loss, errors in general, shader introspection, feature detection) and some of the irrelevant parts (anything touching canvas, external textures), and immediately got it down to 241 declarations.

This kind of dishonest puffery holds back an otherwise interesting article.
by danudey | 2025-12-16 22:58:49+00:00
LLMs by their inherent nature cannot be relied on to be true and correct, which by coincidence are the only traits that matter in accounting.

If you want better software, then sure, maybe a coding assistant can help you write it faster, but when it comes to actually doing accounting I would not rely on an LLM in any way shape or form any more than I would do so for law.
by ilamont | 2025-12-16 22:59:10+00:00
You should have seen Taiwan in the 1990s. It was a hot mess of older Western romanization systems, historical and dialectical exceptions, competing Taiwanese and pro-China sensibilities, a widely used international standard (pinyin), and lots of confusion in official and private circles about the proper way to write names and locations using the Latin alphabet. In 1998, the City of Taipei even made up its own Romanization system for street names at the behest of its then-new mayor, a supporter of Taiwan independence (https://pinyin.info/news/2019/article-on-early-tongyong-piny...).

The chart halfway down this blog post lays out some of the challenges once the hanyu pinyin standard was instituted in 2009:

https://frozengarlic.wordpress.com/on-romanization/

The author concludes with this observation:

So that’s why people in Taiwan can’t spell anything consistently and why all the English-language newspapers spell the same things differently. As for me, I’m giving up on trying to remember how everyone spells their name. I know lots of people, especially Taiwan nationalists, dislike having the PRC hanyu pinyin system. I dislike imposing it upon them. However, in only three weeks, I’ve found myself spelling the same thing in multiple ways and wasting time looking up how I did it last time. Since almost no one reads my blog anyway, I’ll do it the way that’s most convenient for me.

I’ll also always provide the Chinese characters so that people who can read them know who I’m talking about.
by 1718627440 | 2025-12-16 22:59:35+00:00
Most commenters seem to miss that this is the throwaway code for HN, with a maximum allocated time of five minutes. I wouldn't commit it like this. The final code did cope with percent-encoding even though the project didn't took any user generated values at all. And I did read the RFCs, which honestly most developers I meet don't care to do. I also made sure the percent-decodation function did not rely on the ASCII ordering (it only relies on A-Z being continuous), because of portability (EBCDIC) and I have some professional honor.
by ssl-3 | 2025-12-16 23:00:18+00:00
Sure. It's better to start with an excellent home design that most-effectively uses every iota of modern tech to optimize efficiency. And sure, even more efficiency can be eeked out if one is willing to layer on their own productive infrastructure hacks.

But not everybody has those opportunities. Not every home has an existing conditioned space within which to put a water heater. Not every person is equipped (mentally or physically) to engineer and use tempering loops and/or water-cooling compressor motors.

As a practical matter: In a warm-climate home that already has a water heater in the garage (which is very common in the American south, from my limited direct observation), replacing a traditional water heater with one that uses a heat pump can make a lot of sense.

This replacement is something that any person and a friend with minimal plumbing and electrical experience can accomplish on their own in one afternoon, without incurring the expense and inconvenience of relocating their water heater somewhere else. There will be no drywall dust, and no paint.

It's a natural fit.

---

And don't take any of this the wrong way. You've got some great ideas there.

But not all environments are the same. During the warmer months in my own city, I've measured incoming water at 76F/24C -- warmer than the house, and also warmer than the basement where the plumbing lives. A tempering loop may make sense for you in your environment, but it would be the opposite of useful in my environment: "Oh neat! A thing that makes my home harder to cool in the summer!" (Unusual? Perhaps. But it's my reality anyway. I've never run out of hot water in this city during the summer. Not even close. But things do change in the winter -- maybe I'll measure the input temperature again when I get home tonight.)

It's fun to think about niche concepts that don't have broad-scale adoption. And sometimes, it makes sense to set forth and make them a reality.

But it's always important to remember that there's often very real reasons for them to remain niche concepts that aren't broadly utilized.
by Seattle3503 | 2025-12-16 23:00:54+00:00
> I am highly skeptical that Enterprise customers in times such as these will be willing to pay for something that they can get for free from Google or Microsoft.

They would have to build a better enterprise offering. Companies like Chrome because can use Google as their IDP, and when their employees log in with their company account the company can push certs and security politicies to their Chrome install.

Firefox doesn't have that level of integration with Google security services.
by wooders | 2025-12-16 23:01:00+00:00
I think the problem with ChatGPT / other RAG-based memory solutions is that it's not possible to collaborate with the agent on what it's memory should look like - so it makes sense that its much easier to just have a stateless system and message queue, to avoid mysterious pollution. But Letta's memory management is primarily text/files based so very transparent and controllable.

An example of how this kind of memory can help is learned skills https://www.letta.com/blog/skill-learning - if your agent takes the time to reflect/learn from experience and create a skill, that skills is much more effective at making it better next time than just putting the raw trajectory into context.
by jacquesm | 2025-12-16 23:01:16+00:00
This is a tough thing to do: predictions that are premised on the invention of something that does not exist today or that does not exist in the required form hinges on an unknown. Some things you can imagine but they will likely never exist (time travel, ringworlds, space elevators) and some hinge on one thing that still needs to be done before you can have that particular future come true. If the thing you need is 'AGI' then all bets are off. It could be next week, next month, next year or never.

This is - in my opinion - one of those. If an AI is able to formally verify with the same rigor that a system designed specifically for that purpose is able to do it I think that would require AGI rather than a simpler version of it. The task is complex enough that present day AI's would generate as much noise as they would generate signal.
by nextos | 2025-12-16 23:01:18+00:00
That's my opinion as well. Some functional language, that can also offer access to imperative features when needed, plus an expressive type system might be the future.

My bet is on refinement types. Dafny fits that bill quite well, it's simple, it offers refinement types, and verification is automated with SAT/SMT.

In fact, there are already serious industrial efforts to generate Dafny using LLMs.

Besides, some of the largest verification efforts have been achieved with this language [1].

[1] https://www.andrew.cmu.edu/user/bparno/papers/ironfleet.pdf
by hamdingers | 2025-12-16 23:01:20+00:00
That's a great question, honestly, and I like your framing of trust.

I do not trust Mozilla to keep a product alive. I was frustrated by Firefox OS and more recently Pocket, but everything they've tried or acquired aside from the browser itself (and Thunderbird I guess?) has failed and been shut down. That has burned a lot of people along the way.

For this reason I can't see myself becoming a user of any future Mozilla projects.
by Sytten | 2025-12-16 23:01:30+00:00
Maybe with this "investment" will get an actual solution for Github Actions sh*t version management of actions[1] after just closing the Immutable Actions issue with a "sucks to be you" comment[2]. AI-Native Github action Agentic package management for Copilot /s

[1] https://nesbitt.io/2025/12/06/github-actions-package-manager... [2] https://github.com/github/roadmap/issues/592
by pacjam | 2025-12-16 23:01:47+00:00
> Does somebody have a clear case on why this is something that we should want

For coding agents, I think it's clear that nobody wants to repeat the same thing over an over again. If a coding agent makes a mistake once (like `git add .` instead of manually picking files), it should be able to "learn" and never make the same mistake again.

Though I definitely agree w/ you that we shouldn't aspire to 1:1 replicate human memory. We want to be able to make our machines "unlearn" easily when needed, and we also want them to be able to "share" memory with other agents in ways that simply isn't possible with humans (until we all get neuralinks I guess)
by chamomeal | 2025-12-16 23:02:24+00:00
Formal methods are very cool (and I know nothing about them lol) but there's still a gap between the proof and the implementation, unless you're using a language with proof-checking built in.

If we're looking to use LLMs to make code absolutely rock-solid, I would say advanced testing practices are a good candidate!. Property-based testing, fuzzing, contract testing (for example https://github.com/griffinbank/test.contract) are all fun but extremely tedious to write and maintain. I think that makes it the perfect candidate for LLMs. These kinds of tests are also more easily understandable by regular ol' software developers, and I think we'll have to be auditing LLM output for quite a while.
by manquer | 2025-12-16 23:02:46+00:00
> abhorrent and downright abusive move

Is it that egregious?. I read it as they are redistributing the costs. It is in combination dropping the managed runner costs by a good margin and charging for the orchestration infrastructure. The log storage and real time streaming infra isn't free for them (not $84/month/runner expensive perhaps but certainly not cheap )

We don't need to use the orchestration layer at all, even if we want to use rest of the platform, either for orchestration or runners. Github APIs have robust hooks(not charged extra) and third-party services(and self-hostable projects) already provide runners, they will all add the orchestration layer now after this news.

--

Competition is good, free[2] kills competition. Microsoft is the master of doing that with Internet Explorer or Teams today.

Nobody was looking at doing the orchestration layer because Github Actions was good enough at free[1], now the likes of BuildJet, Namespace Labs etc are going to be.

[1] Scheduler issues in Github Actions not withstanding, it was hard to compete against a free product that costs money to build and run.

[2] i.e. bundled into package pricing,
by PunchyHamster | 2025-12-16 23:02:53+00:00
I shudder to think about calling Telegram UI "good". Maybe chats like Discord spoiled me but both of those feel like way below level of "comfort" for communication longer than "asking about what food you want", especially when talking about code or other stuff that benefits from more richer formatting.

Both look ass at desktop too, way too many wasted space, tho Telegram at least doesn't stretch the chat on the entire width of monitor when in fullscreen, having to go from far left to far right just to read the chat
by socketcluster | 2025-12-16 23:03:05+00:00
Yes. I feel like people who are trying to push software verification have never worked on typical real-world software projects where the spec is like 100 pages long and still doesn't fully cover all the requirements and you still have to read between the lines and then requirements keep changing mid-way through the project... Implementing software to meet the spec takes a very long time and then you have to invest a lot of effort and deep thought to ensure that what you've produced fits within the spec so that the stakeholder will be satisfied. You need to be a mind-reader.

It's hard even for a human who understands the full business, social and political context to disambiguate the meaning and intent of the spec; to try to express it mathematically would be an absolute nightmare... and extremely unwise. You would literally need some kind of super intelligence... And the amount of stream-of-thought tokens which would have to be generated to arrive at a correct, consistent, unambiguous formal spec is probably going to cost more than just hiring top software engineers to build the thing with 100% test coverage of all main cases and edge cases.

Worst part is; after you do all the expensive work of formal verification; you end up proving the 'correctness' of a solution that the client doesn't want.

The refactoring required will invalidate the entire proof from the beginning. We haven't even figured out the optimal way to formally architect software that is resilient to requirement changes; in fact, the industry is REALLY BAD at this. Almost nobody is even thinking about it. I am, but I sometimes feel like I may be the only person in the world who cares about designing optimal architectures to minimize line count and refactoring diff size. We'd have to solve this problem first before we even think about formal verification of 'most software'.

Without a hypothetical super-intelligence which understands everything about the world; the risk of misinterpreting any given 'typical' requirement is almost 100%... And once we have such super-intelligence, we won't need formal verification because the super-intelligence will be able to code perfectly on the first attempt; no need to verify.

And then there's the fact that most software can tolerate bugs... If operationally important big tech software which literally has millions of concurrent users can tolerate bugs, then most software can tolerate bugs.
by AlbertoGP | 2025-12-16 23:03:29+00:00
We had several Quickshot II's at home for our Commodore 64; each broke after a while and we had to get a new one.

It looked and felt fantastic and was cheap, but the garbage switch mechanism was a thin metal cross pushed down onto contacts on the board in such a way that it would inevitably snap and render the joystick useless.

I did what I could as a kid without proper materials or tools to repair them but nothing lasted.

I ended up building my own from scratch with steel and wood, reusing the cable of one of them, and could finally play without fear of breaking and leaving me high and dry.

From my experience with a previous product from Retro Games Ltd, The A500, I expect this one to be much better than the original.
by danudey | 2025-12-16 23:03:52+00:00
The tech company playbook:

1. Defy the law (and ethics) so that you can grow rapidly without the constraint of regulations, and provide things cheaper without the overhead of compliance

2. Get so ubiquitous as a result that if government starts trying to regulate you they look like the bad guys

3. Hire lobbyists to write laws in your favor.
by fkarg | 2025-12-16 23:04:24+00:00
well, this is where being pedantic bites me in the a* again. Our codebase has been mostly pyright-focused, with many very specific `pyright: ignore[...]` pragmas. Now it would be great if ty (pyrefly has an option!) could also ignore those lines. There's not _that_ many of them, but .... it's a pain.