MurphyA/hacker-news huggingface dataset:
by rft | 2025-07-13 11:28:28+00:00
Not trying to single you out here, I want to argue against how standard it has become to require a license server. A license server puts an expiry date on the software at an unknown point in the future. At some point the binary you downloaded after you paid for the software will stop working because the server got turned off, changed API, your internet connection is down, your local CA store got corrupted or any other kind of problem in the huge list of dependencies that goes into making a secure API call over the internet. Sure, you can put in safeguards against all kinds of issues, but that also comes at a development cost and you can never reach a point where the software will just continue to work, no matter what.

Even if you, as the company selling the software, can accept all of the above, a license server still is a liability. You sold someone a product and now you need to keep a public API running "forever" (as defined in your legalese). If something goes wrong on your end you are now denying the product you already sold to your customers who already paid for it. I know this is in the end all mitigated by some legalese, which is a whole different can of worms. You also need to make sure your license API is secure and can not leak user data or be twisted into exploiting your software during license checking. There is an ongoing cost to keep the infrastructure running.

As a sibling comment pointed out you can use local only license management like license keys or just nothing like WinRAR or FUTO Keyboard[1]. Yes, you will get users not paying for your software, there will be keygens out there. But even if you use a remote license check, there will be cracks on day 1, if your software is popular enough. I know this is an old and flawed argument, but if someone is willing to navigate a website full of malware infested, blinking ads to avoid paying for your software, they probably would not pay for it anyway.

As an example of what the end stage of hooking up every software to a remote API looks like, Stop Killing Games [2] has done a great job of highlighting just how bad it has gotten in the gaming market. I know there have been some heated discussions around the movement, but the core idea of being able to keep using the software you paid for, is something I absolutely support.

[1] https://keyboard.futo.org/

[2] https://www.stopkillinggames.com/ https://hn.algolia.com/?dateRange=pastYear&query=stop%20kill...
by sitkack | 2025-07-13 11:29:51+00:00
> The fact that all models at present credulously accept their training

Is this true?

So many on HN make these absolute statements about how LLMs operate and what they can and can't do, that it seems like they fail harder at this test than any other.

It is just autocomplete.

They can't generalize.

They can't do anything not in their training set.

All of which are false.
by mohsen1 | 2025-07-13 11:29:56+00:00
I’ve been exploring this too, since I rely on LLMs a lot to build software. I’ve noticed that our dev loop-writing, testing-is often mostly human-guided, but language models frequently outperform us in reasoning. If we plug in more automation; MCP tools controlling browsers, documentation readers, requirement analysers, we can make the cycle much more automated, with less human involvement.

This article suggests scaling up RL by exposing models to thousands of environments

I think we can already achieve something similar by chaining multiple agents:

1. A “requirement” agent that uses browser tools to craft detailed specs from docs.

2. A coding agent that sets up environments (Docker, build tools) via browser or CLI.

3. A testing agent that validates code against specs, again through tooling.

4. A feedback loop where the tester guides the coder based on results.

Put together, this system becomes a fully autonomous development pipeline-especially for small projects. In practice, I’ve left my machine running overnight, and these agents propose new features, implement them, run tests, and push to repo once they pass. It works surprisingly well.

The main barrier is cost—spinning up many powerful models is expensive. But on a modest scale, this method is remarkably effective.
by jeroenhd | 2025-07-13 11:30:33+00:00
Ladybird is advancing rapidly but I personally wouldn't use it as a daily driver yet. It's quite a small project in comparison to the giants like Chromium and Safari, but despite their talents and the from-the-ground-up approach free from legacy crap, it lacks a lot of functionality and performance enhancements for it to be a daily driver at the moment.

Give it another year or two and things may change, but if you daily drive it now you'll be either a beta tester or a volunteer part of the Q&A team.

Out of all the new and upcoming browser engines, I think the usability ranking is Flow, then Ladybird, then Servo, with none of them being a great daily driver yet.
by npteljes | 2025-07-13 11:30:41+00:00
I think that's because those everything else are products with an opaque structure, and Mozilla, and for example Wikipedia, are more transparent. Really highlights why some people don't open up, either themselves, their source code, or their organizational structure: it's just inviting endless criticism.

Adding to the point, donating to Mozilla (or Wikipedia) is optional, and paying for a product is not, legally. So if I'm buying clothing, it's whatever, I need my clothing, and the price is just the functional gateway of getting it. But in case of a Mozilla donation, I'm trying to do something good in the world. And if I discover that it's wasted, then I'm not just getting nothing - I am worse off, because I supported a bad cause.
by manquer | 2025-07-13 11:30:57+00:00
> an emergency airworthiness directive would have been issued by now. This hasn't happened.

737 Max incidents proved it isn’t always the case.

This is also not the NTSB or FAA doing direct investigation . Without certainty no one is issuing a directive, at this stage it is simply too early and only a possibility

I wouldn’t read so much intent during high stress part of takeoff from two non native speakers
by kayxspre | 2025-07-13 11:31:46+00:00
I suspect that they don't actually maintain the permanent library, but rather a formatted view of the content that used to be there. Some of the sites I have the URL saved have transitioned to paywall and/or merged, goes offline or disappeared for some reason, so I can't actually read many of the links I exported from it. Though for the one that actually catches interest, I'll look for it in archiving service, but it's a tiresome work to search for it one by one.

I still don't get over the fact Mozilla bought it and shattered it less than a decade later. Perhaps it doesn't make enough "impact" to justify their time and resources, and if this behavior subsists, I would be more discouraged to give them money ever again.
by Rochus | 2025-07-13 11:32:01+00:00
In any case, the author claims that each of these languages is "dead". There is a "Cause of Death" section for each language, which doesn't allow for another conclusion. By listing languages like ALGOL, APL, CLU, or Simula, the author implies that he means by "dead" "no longer in practical use, or just as an academic/historic curiosity". The article contradicts itself by listing languages like COBOL, BASIC, PL/I, Smalltalk, Pascal, or ML, for which there is still significant practical use, even with investments for new features and continuation of the language and its applications. The article actually disqualifies by listing COBOL or Pascal as "mostly dead", because there is still a large market and significant investment in these languages (companies such as Microfocus and Embarcadero make good money from them). It is misleading and unscientific to equate “no longer mainstream” with “no longer in use.” This makes the article seem arbitrary, poorly researched, and the author not credible.
by wafflemaker | 2025-07-13 11:32:05+00:00
So a foundation model instead, like discussed in: [Open Source Security] Open Source Foundations with Kelley Misata of Suricata #openSourceSecurity https://podcastaddict.com/open-source-security/episode/19338... via @PodcastAddict

I'm genuinely curious, no experience in any of that.
by Michelangelo11 | 2025-07-13 11:32:07+00:00
> Each replication task consists of a detailed specification and a reference implementation. The central idea is that AI models are trained to produce an implementation that precisely matches the reference behavior. This clear-cut approach significantly simplifies evaluation, as the grading criteria are objective and direct: either the generated implementation behaves identically to the reference, or it doesn’t.

OK, but then you have to produce the detailed specification, working backward from the reference implementation. This is extremely non-trivial and it significantly weakens the TFA's parallels to pre-training, in which you don't need really need inputs other than raw text corpora.

I'm not saying this eliminates the idea outright, but I do think it hobbles it badly.
by nashashmi | 2025-07-13 11:32:57+00:00
It might not be that hard to finance Firefox improvements. We should establish a Firefox improvement group. And then set a plan for bug improvements roadmap. Then publish that roadmap and set up a fund for the programmers.

I think what you are asking for is better steering of the Mozilla foundation. And maybe better steering for Firefox development. Possibly with less opinions. We might be better off supporting servo devs instead.
by TheOtherHobbes | 2025-07-13 11:33:31+00:00
It was already a libertarian/neoliberal fantasy - one where everything is corrupt, everyone is competing with everyone else, and the point of the game is to grab as much as you can for yourself while selling your services to the highest bidder.

There's nothing counter about it. It makes surviving in a white knuckle corporate techno-dystopia cool. It's a celebration, not a critique.

Compare with PKD or the much less well-known John Brunner in books like The Stone That Never Came Down and The Shockwave Rider - the latter being an obvious influence on Gibson.
by laborcontract | 2025-07-13 11:33:54+00:00
With all due respect to the people who have studied this, I do not care. I'm relatively young, and yet the pain of typing has started to become unmistakeable and chipped away at my productivity, motivation, and sense of invincibility.

You could tell me AI coding makes me 50% slower. I'm taking it. I refuse to grind my wrists to dust.
by SkiFire13 | 2025-07-13 11:34:13+00:00
> I do agree that in principle, there's still a form of function coloring going on. Arguably, our solution to the problem is just to color every function async-colored

I feel like there are two issues with this approach:

- you basically rely on the compiler/stdlib to silently switch the async implementation, effectively implementing a sort of hidden control flow which IMO doesn't really fit Zig

- this only solves the "visible" coloring issue of async vs non-async functions, but does not try to handle the issue of blocking vs non-blocking functions, rather it hides it by making all functions have the same color

- you're limiting the set of async operations to the ones supported in the `Io`'s vtable. This forces it to e.g. include mutexes, even though they are not really I/O, because they might block and hence need async support. But if I wrote my own channel how would this design support it?
Show HN: I hate buying shoes online so I built a service to fix that
by monsharen | 2025-07-13 11:34:28+00:00
Hi HN,

Some friends and I have been working on and off on a service called GetSize (https://www.getsize.shoes) since 2019 and feel we finally have enough pieces in place to take it somewhere. We’re however uncertain about quality and would love your feedback on any and all aspects of it.

The core insight is that pretty much everyone has returned shoes they bought online that didn’t fit well. There are 3d scanners in stores which are cool but that won’t help you at home, and AI photo apps are generally in a pretty sad state still. Consumers do however have multiple shoes with a preferred fit at home, and when applied at scale it’s a simple data problem:

If I have 5 shoes that fit me well, and you have 5 shoes that fit you well, and we have a shoe in common; then I can buy all the same models and sizes that you have.

We are now building a dataset for this purpose, and to do it we’ve simplified the size chart tango that all retailer sites offer today. We’ve ingested a bunch of brand specific size charts so that you no longer need to look at excel sheets essentially. Just a simple recommendation based on what you already own. And whatever shoes you add will contribute to creating a dataset that makes size charts obsolete.

So why does this matter? - Around 20-30% of shoes bought online are returned, half of that is due to poor sizing. - Retailers usually solve this in isolation or not at all. There are some great solutions, but isolated to specific sites because of their business model. - Size charts alone aren’t enough. They differ across brands and in many cases across models. And due to this, larger retailers can’t even map the correct chart to all of their models (See Europe’s largest online retailer Zalando as an example). They often use generic size charts.

The website design is a bit… developer-flavored. Our priority so far has been getting the backend, data collection, and recommendation engine working, and the texts are tailored for SEO to build organic traffic. Kind of hate that part personally but I guess it’s a necessity. Or is it?

I have written a first draft of our remote MCP server where the true value lies, but it’s not yet live. I hope it will put less emphasis on the need for a web frontend.

Regardless, would love to hear your thoughts and appreciate any feedback I can get.

Best regards, Thomas
by woodylondon | 2025-07-13 11:34:34+00:00
Good idea, and I also explored this idea and a year ago and also started building one, recognising a gap in the market for a solution that supports multiple LLMs, but also provides small businesses with a centralised managed AI client - billing, monitoring, logging, company prompts, etc.

Ultimately, I discovered https://www.typingmind.com, which offers all of these features. I am sure there are others - I was amazed that not more of these came out. Might be worth to see what they have built. The more of these that come out the better - its a whole new market.
by imtringued | 2025-07-13 11:35:29+00:00
Yeah this is the thing everyone here seems to ignore. The moment someone does age verification and downloads a file the whole thing falls apart.

You would have to lock down any electronics device that can be used to bypass the restrictions. In reality the best way to do this is to build a screen based nudity filter into the device, which is not only more effective, it exposes this whole nonsense as an attempt to grow the police state.
by Permit | 2025-07-13 11:35:44+00:00
This thread is a perfect example of why the ad-driven model will win every time. Most people don’t actually want to pay for things (that’s just what gets parroted in anti-AdTech posts here).

It appears doubly true for Mozilla in this case because people don’t want to pay executive salaries/bonuses (yet happily consume other goods/services where this is already happening).

I don’t feel optimistic for the future of Firefox given it seems they’re likely to lose their primary source of funding in the coming months.

What alternatives are there? The temporary benevolence of a mega-Corp with a vested interest in online advertising? Crypto mining in the browser? Replacing affiliate links?

I haven’t seen a solution that seems practical here but it seems clear to me that if privacy-motivated, anti-BigTech HN commenters won’t pay for it, no one will.
by Uehreka | 2025-07-13 11:35:56+00:00
I get why people are pissed at Mozilla, but I do feel like people on HN also underestimate how much hating Mozilla is becoming a hacker tribal signifier. It almost feel like each commenter is competing to out-hate the others or to add a layer of “in fact its so bad that we should (consequences)”.

Like, in general, I find that any HN thread where most of the comments are just agreeing, one-upping and yes-anding while invoking the same talking points and terminology (CEO ghouls, etc.) is probably a topic we might need to chill out on.
by chrsw | 2025-07-13 11:36:40+00:00
Human intelligence is not general intelligence. If it were, you'd be able to use your conscious thoughts to fight off diseases and you wouldn't need your immune system, for example.

The problem I see isn't that AGI isn't possible, that's not even surprising. The problem is the term "AGI" caught on when people really meant "AHI" or artificial _human_ intelligence, which is fundamentally distinct from AGI.

AGI is difficult to define and quite likely impossible to implement. AHI is obviously implementable but I'm unaware of any serious public research that has made significant progress towards this goal. LLMs, SSMs or any other trainable artificial systems are not oriented towards AHI and, in my opinion, are highly unlikely achieve this goal.
by ansc | 2025-07-13 11:36:54+00:00
I think they are actually pretty different in approach. rust sprinkle ”?” everywhere and wants to avoid dealing with the error, and golang is more explicit and robust handling. sure, most is similar if it is just ”if err return err” but I have definitely seen more ”extreme” and correct error handling in golang, whereas in rust the convenience of just bubbling it up wins. I still prefer rust, but I am not sure the comparison is as close as people claim
by bell-cot | 2025-07-13 11:37:23+00:00
Yeah - it's far more complex, and iron != steel.

(The article talks almost entirely about steel (vs. iron), but is too detail-fuzzed to trust that.)

I made very charitable assumption from this:

> Ultimately, the company hopes to license its technology to steelmakers.

Actual steelmakers know all the myriad costs and details and steps required to make steel - and would probably prefer that any radical new process replace as many of those step and details as possible, at an economic cost.
by Szpadel | 2025-07-13 11:37:58+00:00
with RL it's hard to define score function in many categories. rhis is especially visible in current coding capabilities. LLM will very often create sloppy solutions because they work well in RL. hardcoding API keys? ignoring errors? disabling lints? those pass in automated evaluation therefore are reinforced in training. are they good solutions? of course not.

It's very hard to define (in way to create lints) what makes core readable and maintainable. Using other LLM for this task could cause original model to game the system by abusing some weaknesses in the other model.

for other tasks, how do you even evaluate thinks like eg user experience/app design? how to properly evaluate pelican ridding bicycle?
Show HN: I built this to talk Danish to my girlfriend – works with any language
by lil_csom | 2025-07-13 11:38:18+00:00
I'm in my 4th year living in Denmark as an expat, and I finally decided it’s time to properly learn Danish. I do have a Danish girlfriend, after all. One way I’ve been practicing is by trying to text only in Danish, but I often find myself stuck. I start my message in Danish, then hit a wall because I don’t know a word or how to fit something naturally into the sentence.

Especially in those cases, I used to give up and translate the entire message from English, which kind of defeats the purpose and interrupts the learning process.

So I started prompting GPT. I’d write my message with wildcards or notes for the parts I didn’t know, and it would return a corrected version. That worked well, but reusing the prompt each time became tedious.

So I built a wrapper around it.

Now I can type in the target language, mark unclear parts with curly braces {like this}, and get an instant corrected version with explanations. I also added a history feature so I can review what I got wrong, and I plan to build more on that soon (eg. summary of areas or words to review).

This app is for language learners who want to practice writing without feeling insecure about mistakes or breaking their flow by switching to a translator.

I hope you find it useful!
by meindnoch | 2025-07-13 11:38:29+00:00
The lower HPV incidence rate is due to the fact that the skin on a circumcised penis is thickened due to the constant abrasion. Basically your penis gets covered with a callus. This thicker skin provides an improved barrier compared to the thin and moist skin inside an intact foreskin. But a thicker skin merely lowers the HPV infection rate, as evidenced by plantar warts on people's feet, which are also caused by HPV.

Luckily, as you've said, we already have HPV vaccines, so maybe it's time to stop cutting off pieces from little boys' penises?
by delusional | 2025-07-13 11:39:58+00:00
This has been part of my conclusion too.

There's an irony that in providing people the option of not paying, you are also inviting them to find flaws in your organization to avoid paying. We are all aware that Microsoft sucks, yet there's never any doubt that you'll have to pay for a 365 subscription if you're a serious business. At the same time we'll also gladly accept that small companies don't donate to the Linux foundation, because they have to pay their bills.

By using the control we advocate for (forking projects, reducing funding, etc) we only harm the projects that afford us that control. Not paying Mozilla does nothing to reduce the control of Google over chrome. It only hurts the one browser that gives you the choice.
by theGeatZhopa | 2025-07-13 11:40:11+00:00
On how I notice it:

It's the endless need of more and more resources for running xyz.

In former days, the resources where limited. So, the programmers cared for performance by good practice coding & (over) optimization. Example: NASA was in a search of an engineer to code on their old probe flying in space. The problem: very limited resources. So the engineer needs to think like the probe's built in processor and memory - slow and with limited registers. But capable of being highly optimized in doing that. They searched for a old (school) engineer from the 60ies or something like that.

My father, too, is an old school engineer. He doesn't like to use frameworks, but rather write everything by himself. He say "why should I learn logic of others, if I can do it by myself in same time without creating overhead. I use what is necessary, but not more."

And then, I remember whole office suite fitting on a bunch of 1.44mb floppy disks - compared to now's gigabytes.

And that's the problem. There's big * debt (where * insert what ever fits)

This needs more and more resources. In the same time, programmers do not care on the optimization side anymore, as the framework can't be touched easily, or because "it works like that".

This leads to the effect that everything is getting more opaque, with difficulty to catch bugs, or the bugs are introduced by external libs or something like that..

I see the cause with the bigger and bigger frameworks and the lazyness of programmers. Why should one use ORM when one can directly connect to database? Sure. The reasons are the same as the reasons for creating a ORM lib: to make it easier. But more resource hungry and maybe buggy.
by Retr0id | 2025-07-13 11:40:15+00:00
The perf difference between SHA1 and SHA256 was marginal on the systems I tested (3950x, M1 Pro), which makes SHA256 a no-brainer to me if you're just picking between those two (collision resistance is nice to have even if you "don't need it").

You're right that collision resistance doesn't really matter here, but there's a fair chance SHA1 will end up deprecated or removed from whatever cryptography library you're using for it, at some point in the future.