MurphyA/hacker-news huggingface dataset:
by tripzilch | 2025-08-11 12:53:23+00:00
So first of, people who _can't_ read or write have a certain disability (blindness or developmental, etc). That's not a reasonable comparison for LLMs/AI (especially since text is the main modality of an LLM).

I'm assuming you meant to ask about people who haven't _learned_ to read or write, but would otherwise be capable.

Is your argument then, that a person who hasn't learned to read or write is able to model language as accurately as one who did?

Wouldn't you say that someone who has read a whole ton of books would maybe be a bit better at language modelling?

Also, perhaps most importantly: GPT (and pretty much any LLM I've talked to) does know the alphabet and its rules. It knows. Ask it to recite the alphabet. Ask it about any kind of grammatical or lexical rules. It knows all of it. It can also chop up a word from tokens into letters to spell it correctly, it knows those rules too. Now ask it about Chinese and Japanese characters, ask it any of the rules related to those alphabets and languages. It knows all the rules.

This to me shows the problem is that it's mainly incapable of reasoning and putting things together logically, not so much that it's trained on something that doesn't _quite_ look like letters as we know them. Sure it might be slightly harder to do, but it's not actually hard, especially not compared to the other things we expect LLMs to be good at. But especially especially not compared to the other things we expect people to be good at if they are considered "language experts".

If (smart/dedicated) humans can easily learn the Chinese, Japanese, Latin and Russian alphabets, then why can't LLMs learn how tokens relate to the Latin alphabet?

Remember that tokens were specifically designed to be easier and more regular to parse (encode/decode) than the encodings used in human languages ...
by general1726 | 2025-08-11 12:55:03+00:00
If 200 USD / month would replace a developer, then it would be a bargain.

If 2000 USD / month would replace a developer, then it would be a fair price.

Problem is that none of existing models are capable to replace a developer. They all need babysitting. And I am saying that as a probable customer who would actually pay something between 200-2000USD for AI junior developer which can actually work and understand what it is doing. Either those models will start doing what has been promised by tech CEOs, or AI winter is upon us.
by Arnt | 2025-08-11 12:55:34+00:00
People keep saying that. There are two problems with that, namely ① Google's own ads are easy to block using the new API and ② the new API is effective at blocking various evil attacks. If Google wanted to get rid of ad blockers, I'm sure they could come up with an API that does a better job than that.

https://textslashplain.com/2024/10/13/content-blocking-in-ma... shows a ten-line ad blocker that blocks Google's ads, https://github.com/extesy/hoverzoom/discussions/670 is a list of polite email messages from people who'd like to have elevated access to browsers.
by aeve890 | 2025-08-11 12:56:10+00:00
Cool show, weird plot, but what totally ruined for me was... Travis Fimmel. IMO this guy has zero range. Always the same lazy, drunk-ish style since, I don't know, Vikings. Ragnar in Kattegat, Ragnar in Azeroth, Ragnar in space, Ragnar in Dune.
by digitalPhonix | 2025-08-11 12:56:18+00:00
> Even if there are MEPs and parties in the EP that support what I want, there is no such entity in my country so I can vote for someone else who is against my opinions, or just not vote (and help the biggest party).

Does that mean there’s the potential to form a party around your views?

(Not saying it’s a practical solution for you, but that the system probably would expect a new view to voice itself)
by dage212 | 2025-08-11 12:57:45+00:00
A lightweight, efficient local API debugger

I’ve developed a simple yet powerful API debugging tool that runs locally. It’s faster and more intuitive than Postman, with a focus on speed and usability. With minimal setup, you can start testing APIs immediately. No complex configurations, just straightforward, real-time debugging. Check it out on GitHub and let me know what you think!Feel free to try it out and provide feedback! https://github.com/dage212/fire-doc
by burntsushi | 2025-08-11 12:58:09+00:00
Good write-up. This is a very popular approach to substring search! It is still worst case `O(m*n)` though. Do you have a fallback implementation like the `memchr` crate has to guarantee `O(m+n)`?

I'll also push back on some bits in the end:

> But if it’s so much better, then why haven’t I made a pull request to > change std.mem.indexOf to use SIMD? Well, the reason is that > > std.mem.indexOf is generic over element size, and having a size > larger than u8 makes the algorithm much slower > > The algorithm used in stdmem.indexOf is cross-platform, while the > SIMD code wouldn’t be. (not all platforms have SIMD registers at all, > Arm has only 128-bit)

Does Zig not have a way to specialize this for sequences of unsigned 8-bit integers? If not, and you're thereforce force to used a more generic algorithm, that seems pretty unfortunate.

> Substring searching is rarely the bottleneck in programs, > especially ones written in a fast language like Zig. That’s why > I don’t personally think it would be worth it to add it to the > standard library.

Oh I'm not sure I buy this at all! Substring search is a primitive operation and easily can be a bottleneck. There's a reason why widely used substring search implementations tend to be highly optimized.
by taylodl | 2025-08-11 12:58:21+00:00
If your system needs to prevent leakage of creation time - typically due to regulatory or privacy requirements - you can use AES-SIV to encrypt UUIDv7 identifiers.

All APIs and URLs would expose only the encrypted form of the ID. When performing record lookups, your data tier would decrypt the ID to retrieve the original UUIDv7. This preserves the indexing and sortability benefits of UUIDv7 while mitigating timestamp leakage.

This approach is compatible with technologies like GraphQL, but you’ll need to treat the encrypted ID as an opaque string in your schema. Your resolvers will decrypt the ID before querying the database. Just ensure that:

- The encryption is deterministic (so the same UUIDv7 always maps to the same encrypted ID).

- You handle decryption securely and efficiently in your resolver logic.

This pattern works well for systems where external exposure of creation time is undesirable, but internal sortability and uniqueness are still critical.
by netsharc | 2025-08-11 12:59:24+00:00
Let's use blockcha... I mean, AI!

Huh, an AI that reads the latest news and suggest conversation topics would be funny, if conversing with someone interested in celebrity gossip, then it could delve into that topic, e.g. "What about astronaut Katy Perry, am I right?! Did you read that she was spotted having a meal with Justin Trudeau?".
by hamandcheese | 2025-08-11 12:59:32+00:00
Please refer to my original comment:

> You can of course solve the same thing with JSON, but, well, YOU have to solve it.

There is not a single well established convention across all languages/impls. The default behavior in many languages if a field is missing is to either panic, or replace it with a null pointer (which will just panic later, most likely).
by xoa | 2025-08-11 13:00:05+00:00
>As far as I understand, the key material for any post quantum algorithm is much, much larger compared to non-quantum algorithms which leads to huge overheads in network traffic and of course CPU time.

Eh? Public-key (asymmetric) cryptography is already very expensive compared to symmetric even under classical, that's normal, what it's used for is the vital but limited operation of key-exchange for AES or whatever fast symmetric algorithm afterwards. My understanding (and serious people in the field please correct me if I'm wrong!) is that the potential cryptographically relevant quantum computer issue threats almost 100% to key exchange, not symmetric encryption. The best theoretical search algorithm vs symmetric is Grover's which offers a square-root speed up, and thus trivially countered if necessary by doubling the key size (ie, 256-bits vs Grovers would offer 128-bits classical equivalent and 512-bits would offer 256-bits, which is already more than enough). The vast super majority of a given SSH session's traffic isn't typically handshakes unless something is quite odd, and you're likely going to have a pretty miserable experience in that case regardless. So even if the initial handshake gets made significantly more expensive it should be pretty irrelevant to network overhead, it still only happens during the initiation of a given session right?
by gruez | 2025-08-11 13:00:06+00:00
For the people downvoting, that's unironically a thing:

https://www.irs.gov/publications/p525#en_US_2024_publink1000...

>Illegal activities.

>Income from illegal activities, such as money from dealing illegal drugs, must be included in your income on Schedule 1 (Form 1040), line 8z, or on Schedule C (Form 1040) if from your self-employment activity.
by fdalvi | 2025-08-11 13:00:20+00:00
It is indeed not something clarified by the code snippets; In normal feedforward layers, it is common to choose the "hidden_dim = 4 x emb_dim", while in GLU feedforward layer, the convention is to use "hidden_dim = 2/3 * regular_ffn_hidden_dim" (to keep the overall number of parameters roughly the same). In the case of gpt-oss, they chose to go a bit more extreme and set "hidden_dim = emb_dim", thus reducing the overall number of parameters!
by daneel_w | 2025-08-11 13:00:26+00:00
We're nowhere near the point where there's any general concern regarding the sizes of 256 bits or 512 bits for hashes, block sizes, key sizes etc. Currently we don't need to consider the problem as a question of what time is required, because we don't have the electrical energy required to explore even a fraction of an unfathomably smaller 128 bit space. We don't have computers that can ingest such power either. "Relax, guy."
by stockresearcher | 2025-08-11 13:01:53+00:00
I’m not sure economic woes are the main factor.

On a $$$ per unit of dopamine measure, Vegas stopped being worth it at least 10 years ago. Long before Covid and inflation and whatever. I’m just surprised it took the average person this long to realize.

This is the first year my big group of family and friends aren’t heading back to our fair alma mater for a football weekend, renting RVs, tailgating, drinking at all the spots we remembered fondly, buying merchandise, etc. things have been getting progressively worse for years, this year was just the breaking point. It’s not economic woes. In fact, it’s just the opposite. Too much money sloshing around, ruining everything it touches.
Show HN: New GNU/Linux post-install configuration tool (iptables, zram, zsh...)
by git-user-cpp | 2025-08-11 13:02:54+00:00
Hey folks! A few months back I built a GNU/Linux post‑installation setup program to make getting started way smoother. Since then, I’ve given it a boost with new features and refinements — and it’s now live on GitHub!

Built in Rust — fast, safe, and reliable

Works out‑of‑the‑box for: Arch, Debian, Fedora

Automates essential configs:

- iptables firewall rules

- vim setup

- zsh + Oh My Zsh customization

- zram for improved performance

- Installs either default software packages or your chosen ones

Designed to save you time and take the pain out of post‑install tweaks.

If that sounds useful, check it out and drop a star on GitHub — every bit of support keeps the project moving forward!

https://github.com/glcomtech/glwiz
by boffinAudio | 2025-08-11 13:02:56+00:00
Very cute language ..

match x { is table { print(indent_this + "{") for pair in pairs(x) { write(indent + " " + to_string(pair.key) + ": ") pretty_print_internal(pair.value, indent + " ", false) } print(indent + "}") }

.. okay, you got my attention (long-time Lua fan) .. will have to give this some workbench time and learn it ..
by miroljub | 2025-08-11 13:03:05+00:00
As much as we are fighting Chat Control, we also need a plan B. What do we do if EU regime really enact it? Which messengers could we use then? What were the practical alternatives?

Self hosted, decentralized, encrypted, standard based, ... , the only thing that comes to mind is something like delta.chat for texts, which builds upon a standard mail protocol.

Can we do something better than that?
by snapplebobapple | 2025-08-11 13:03:30+00:00
Insurance, homes, etc. are flows for the purposes of this analysis and so they aren't really that big a problem. Change the codes, so the stupid can't be recreated and it will handle itself as the old stuff is destroyed and not rebuilt/rebuilt in a way that can handle the reality of the situation with minimal insurance claim. Even if the rate of disaster doubles it's still an insurable problem in this setup and within 20-30 years the problem handles itself through natural aging out plus insurable destruction of the old stuff.

The key is to make it very easy to rebuild whatever you want within the constraint of new codes that ensure your building can handle its environment. If we let a california happen and hold everything up in development hell so almost nothing is being rebuilt six months to a year after the destruction is the real economy killer that is relevant here.
Ask HN: Has anyone built a simple habit app that works?
by codewhall | 2025-08-11 13:04:24+00:00
I’m an indie developer planning to build an app to help people build good habits—consistently and with as little friction as possible.

What got me started was hitting a wall myself.

About six months ago, I began my solo founder journey. The first couple of months were awesome—I was energized and productive. But by month three, things started slipping. I got distracted, procrastinated, and stuck in my own head.

I tried everything to get back on track:

* Working at the same time and place to cut down on decision fatigue

* Breaking tasks into tiny steps and checking each one off to build momentum

* Using Pomodoro sessions with little rewards like stretching or a sip of water to stay focused

* Regular workouts to keep my energy and mood steady

* Most importantly: shifting from relying on willpower to building systems

I realized that unless actions become automatic, it’s tough to keep going long term.

It took me about two months to rebuild a solid daily rhythm. These small habit tweaks made a huge difference—more focus, more clarity, and way better output.

Now, I’m turning that low-friction, sustainable, anti-procrastination system into a simple, practical app. No fluff, no hype—just one clear goal: make consistency easier.

Do you have a similar need?

Would you use a tool like this?

How much would you pay monthly for a stable version?

Any features you’d want to see?
by rambambram | 2025-08-11 13:05:54+00:00
Don't act like RSS is done with. It's twenty plus years old, and still going strong. Nobody is stopping you from using it, whether you only read or also post.

Hyped up tech is like milk, it stinks after a couple of days. Open protocols are like fine wine, they age beautifully.

P.S. Your site is offline. If it wasn't and you even had one interesting article, I would have added your website to my list of feeds. I picked up hundreds of interesting websites/feeds through HN alone in the last years.
by Devolver | 2025-08-11 13:05:56+00:00
SignalWire is a client of mine. They shipped POM in April.

We noticed that Microsoft released the POML (Prompt Orchestration Markup Language) yesterday.

SignalWire's version complies to markdown or XML.

The very close parallels may be pure coincidence, but it may not be.

If a clone job...not a good look to rip off OSS software without even a link to the inspiration.

If a coincidence: the co-founders at SignalWire have a lot of foresight (they hacked a tool use framework within two weeks of GPT-4, before OpenAI introduced tool calling).

Their AI toolset is worth a deeper look.
by hoherd | 2025-08-11 13:07:03+00:00
Shellcheck has been a huge game changer for me. The lack of a linter is the main reason I don't consider switching to zsh anymore.

When I first found shellcheck, I'd sit on the train every morning and fix all the stupid little bugs in all our shell code. I learned a TON about shell scripting, because the shellcheck wiki is amazing. We had some redhat 6 init scripts checked into our repos, and shellcheck helpd me find syntax errors in those init scripts. If Redhat can't reliably write shell scripts without a linter, or catch bugs from upstream, what makes us think we're any better?

I wouldn't write serious programs in another language without a linter. Why should I write shell scripts without one?
by Jotalea | 2025-08-11 13:07:42+00:00
There are two possible answers, but I'm only qualified to respond with one of them.

The reason why they can handle 700M users is money. I'm not saying you're poor, I'm saying they are extremely rich, and with all that money they can afford these machines.

The other reason is optimization techniques, but I don't have enough experience to talk about that.
by vorticalbox | 2025-08-11 13:08:56+00:00
huihui-ai[1] on hugging face has abliterated models including a gpt-oss 20B[2] and you can download a few from ollama[3] too.

If you are interested you can read about the how its removed[4]

[1] https://huggingface.co/huihui-ai [2] https://huggingface.co/collections/huihui-ai/gpt-oss-abliter... [3] https://ollama.com/huihui_ai [4] https://www.lesswrong.com/posts/jGuXSZgv6qfdhMCuJ/refusal-in...
by Someone | 2025-08-11 13:11:14+00:00
By that logic, I think most toString/fromString pairs are broken. Many “string to int” functions accept some strings that their counterpart “int to string” never produces, for example “-0”, “0000”, and “01”.

(Chances are ‘fromString’ accepts strings with very long prefixes of zeroes)

Having said that, I do think accepting “1E9” may go too far. If you accept that, why would you disallow “12E3”, “1.23E4”, “12300E-2”?

If you’re going to widen what the function accepts, I would add support for hexadecimal (“0x34”) and binary (“0b1001”) before adding this.
by kbolino | 2025-08-11 13:13:06+00:00
In the past, at least, RAM upgrades weren't just about filling in the slots you couldn't afford to fill on day one. RAM modules also got denser and faster over time too. This meant you could add more and better RAM to your system after waiting a couple years than it was even physically possible to install upfront.

Part of the reason I have doubts about the physical necessity here is because PCI Express (x16) is roughly keeping up with GDDR in terms of bandwidth. Of course they are not completely apples-to-apples comparable, but it proves at least that it's possible to have a high-bandwidth unsoldered interface. I will admit though that what I can find indicates that signal integrity is the biggest issue each new generation of PCIe has to overcome.

It's possible that the best solution for discrete PC components will be to move what we today call RAM onto the CPU package (which is also very likely to become a CPU+GPU package) and then keep PCIe x16 around to provide another tier of fast but upgradeable storage.
Show HN: I missed Japan so I built a daily 30-second cultural escape app
by bouyaveman6 | 2025-08-11 13:14:01+00:00
After years of traveling to Japan, I found myself craving those small cultural moments back home: the sound of temple bells, seasonal haikus, morning radio snippets.

Gachari gives you one authentic piece of Japanese culture daily in 30 seconds. No overwhelming content, just a small cultural vitamin.

21 users so far with 30% coming back daily. The progressive onboarding (3 free draws) seems to hook people without overwhelming them.

Try it: https://www.gachari.com
by ekr____ | 2025-08-11 13:14:48+00:00
As a number of people have observed, what's happening now is mostly about key establishment, which tends to happen relatively infrequently, and so the overhead is mostly not excessive. With that said, a little more detail:

- Current PQ algorithms, for both signature and key establishment, have much larger key sizes than traditional algorithms. In terms of compute, they are comparably fast if not faster.

- Most protocols (e.g., TLS, SSH, etc.) do key establishment relatively infrequently (e.g., at the start of the connection) and so the key establishment size isn't a big deal, modulo some interoperability issues because the keys are big enough to push you over the TCP MTU, so you end up with the keys spanning two packets. One important exception here is double ratchet protocols like Signal or MLS which do very frequent key changes. What you sometimes see here is to rekey with PQ only occasionally (https://security.apple.com/blog/imessage-pq3/).

- In the particular case of TLS, message size for signatures is a much bigger deal, to a great extent because your typical TLS handshake involves a lot of signatures in the certificate chain. For this reason, there is a lot more concern about the viability of PQ signatures in TLS (https://dadrian.io/blog/posts/pqc-signatures-2024/). Possibly in other protocols too but I don't know them as well
by sigmoid10 | 2025-08-11 13:15:12+00:00
>it appears that most of the barriers to a cryptographically-relevant quantum computer are engineering challenges rather than underlying physics

I've heard this 15 years ago when I started university. People claimed all the basics were done, that we "only" needed to scale. That we would see practical quantum computers in 5-10 years. Today I still see the same estimates. Maybe 5 years by extreme optimists, 10-20 years by more reserved people. It's the same story as nuclear fusion. But who's prepping for unlimited energy today? Even though it would make sense to build future industrial environments around that if they want to be competitive.
by snapplebobapple | 2025-08-11 13:15:23+00:00
The first point isn't really true. We should definitely consider insurance company input when setting policy, we just have to be careful we consider if it's self serving BS, politically motivated nonsense, or intelligent concern with policy changes that could benefit humanity by mitigating the problem. As long as your putting 80% of what they say into bucket 1 or 2 you're probably fine.
by phkahler | 2025-08-11 13:15:27+00:00
>> but turning cars into cells on wheels made everyone way too eager to not ship finished product.

I knew a former manager of OTA (over the air updates) at one manufacturer. I said that needed to be used for emergency updates only and not so people could be late with features or QA. She totally agreed and said it was becoming a battle with all the software teams thinking it meant they could be late and it'd be OK. They think it makes the deadline fuzzy or non-existant.
by freeourdays | 2025-08-11 13:15:38+00:00
Many people find it difficult and time-consuming to choose personal and thoughtful gifts, often spending hours searching online only to settle for a generic option. This leads to frustration for the gift-giver and a less meaningful experience for the recipient.

A platform that uses AI to analyze a recipient's public social media profiles, stated hobbies, and personality traits can automatically generate a highly personalized list of gift ideas.This service saves time, reduces stress, and helps users discover unique products that genuinely match the recipient's interests, making gift-giving more enjoyable and impactful.