MurphyA/hacker-news huggingface dataset:
by 5o1ecist | 2026-03-04 09:37:35+00:00
> My guess is that if you tried to make a “less human” version of Claude, it would become rapidly less capable.

All my observations across different models/engines agree with this. The more they're being forced into behaving in some specific way, aka less like an intelligence and more like a tool, including "tools on", the worse their cognitive abilities.

They might know everything about anything, yet nobody actually teaches them how to properly, correctly think.

This is just getting worse, not better, the less people treat them like actual intelligences ... and i can't say I'm confused why people tend to not do that, but it has nothing to do with AI itself.

The difference between the default states for the average users and "tools off", removing unjustified affirmations, dishonesty and stupid speculation (that's any and all "maybe", "probably" and "almost certainly") is dramatic.
by aurareturn | 2026-03-04 09:38:08+00:00
Highly relevant: https://youtu.be/jIS2eB-rGv0?si=HOKPKTLSJht_c4yy&t=2074

too long didn't watch: Iran has a big fresh water supply issue. US and Israel will first target water supplies in upcoming attacks. US and Israel strategy will then switch to dividing Iran's different ethnicities and regions and arm them so they can fight each other for remaining dinimished water supply.
by vessenes | 2026-03-04 09:39:14+00:00
Knowingly isn’t intent. It’s knowledge. Both the sender (this UK service company) and the troll fit knowingly for almost any definition I can imagine in this story. The UK sender triggered it on a second notice, after the museum had responded. The troll knows they do not own the copyright.

I think bringing this in a jurisdiction with sensible judges - Northern Cal, SDNY, Delaware, does not look impossible to me. And, it only takes one win to radically change the economics of these trolls — it seems worth doing, is all I’m saying!
by cylemons | 2026-03-04 09:39:21+00:00
The countries that got invaded by the US fought guerrilla because that is the only thing they could do. It wasn't some deliberate strategy to rope the US in.

And the only reason it worked out for them is that the US wasn't determined to create new states and had very low domestic support to begin with. That's not the case with Russia where this war is clearly a big deal to them.
by wolvesechoes | 2026-03-04 09:39:40+00:00
> you can't share your Qt UI with the browser version of your app

You can with WASM (but you shouldn't).

> Qt requires a paid license for commercial projects

It doesn't, it requires paid license if you don't want to abide with (L)GPL license, which should be fair deal, right? You want to get paid for your closed-source product, so you should not have any reservations about paying for their product that enables you to create your product, right? Or is it that "money for me, but not for thee"?

> Being less useful and costing more isn't a great combo.

Very nice, but now explain why you are talking about using Qt to create apps, whereas grandparent talks about experience with apps created with Qt.
by nicbou | 2026-03-04 09:39:54+00:00
This reminds me of the anti reading list, for books that you'd like to say you've read.

The charitable perspective is that if everyone in your circle likes a thing, you might be missing an opportunity to enjoy something Objectively Great. That's why you force yourself to try stuff.

On the other hand, you have to learn to give up 100 pages into a book that everyone loves, and sometimes admit that you just don't get a movie.
by panny | 2026-03-04 09:39:58+00:00
>but there really hasn't been any talk about how additional peripherals like aux would be a no-go.

It's water under the bridge. You're NEVER getting a Graphene phone that supports a microsd. It won't happen. The AUX jack, you will biligerently be told to get a USB DAC or otherwise you are an old man yelling at clouds.

Graphene and Motorola will work together by happy accident. Tell ya what though, if they make a GrapheneOS phone with 3.5mm, dual sim, microsd, and >no notch or hole punch< and I will buy it. I won't even care how much it costs. All the Xperias I've owned were among the most expensive phones on the market.
by shakna | 2026-03-04 09:40:16+00:00
If _the government_ can't be trusted not to use a dumbass scheme, then no, it isn't a duh moment. You don't exactly get to dictate how the government implements it!

The point is that systems today, aren't really well executed. So it is unreasonable to expect them to be well executed.

If you can't trust people not to build the bomb well - then don't let them build a bomb.
by maverick74 | 2026-03-04 09:40:30+00:00
I'm sorry, that's actually what I meant!

It's a comparison between

Gen Y and Gen Z

and NOT Gen X and Gen Z!

I was in kind of a hurry and messed it up!!!

So, I do agree with you!

I've tried to edit it but I'm no longer allowed

Thank you for pointing out my mistake!
by pbmonster | 2026-03-04 09:40:37+00:00
> my understanding is that Asahi has issues with: * USB-C Displays * Thunderbolt / USB4 * Touch ID

Valid. USB-C displays are on the horizon, the rest will take significant time (and might never materialize, it's difficult to reverse engineer).

> Because I don't like MacOS

Then spending thousands on modern MacBook will be a subpar experience, no matter how you do it. But yes, Linux will run OK inside a VM on a MacBook.
by tikkatenders | 2026-03-04 09:42:02+00:00
Good question! The engine handles this at two levels:

Auto-detection: It scans for transactional signals ("reset your password", "order confirmation", OTP codes, etc.).
If it finds 2+, it automatically downgrades the missing-unsubscribe penalty to zero.

Explicit declaration: Callers can pass `emailType: "transactional"`, which fully exempts from both unsubscribe and CAN-SPAM physical address checks.

The compliance rules (unsubscribe, physical address) get exempted because they don't legally apply to transactional mail. But deliverability rules (image ratio, hidden text, deceptive links) stay active intentionally. A transactional email that's 100% images is still a deliverability problem regardless of type.

In practice, well-crafted transactional emails rarely trigger those remaining rules since they tend to be simple, text-forward templates.
by Nursie | 2026-03-04 09:42:51+00:00
> There is a problem with schemes like that.

/goes on to discuss how government legislation of specific schemes is the issue, not the schemes themselves.

Then we don't legislate specific schemes? The GDPR doesn't do that, for instance, it spells out responsibilities and penalties but doesn't say "Though shalt use this specific algorithm".

Remember, this discussion started with a call to ban all age checks, which itself is a government action and restriction on the agency of private business.

There are ways that private entities can implement age checks both securely and without leaking much other information, so it seems very heavy-handed to ban them. Private entities are building such systems between themselves already, without government mandates on the specifics.
by lproven | 2026-03-04 09:43:33+00:00
It didn't make it to release, and I believe MS switched internal development more or less as soon as it had an alternative. I do not recall reading any specific detailed look into why, so you may well be right!

Intel let the i860 and indeed the slightly older i960 wither, which was a damned shame. Ditto the Alpha it ended up with, while it sold its Arm licence to Marvell, which at one point recently was worth more than Intel.

I'd like to see a skunkworks project to resurrect one, or several, of these. :-) Attack Arm from a direction it's not expecting. And RISC-V come to that.
by jwilliams | 2026-03-04 09:44:51+00:00
I read takes like this and I feel like it's gatekeeping.

I love writing software. I love that others are now getting to share this.

I think the issues here are valid. Equally there is lots of hard engineering work to reduce these issues. That's where I'm putting more energy.

My scale is decidedly non-Meta, but we're investing to make the whole team able to get their own PRs up. It's not been without it's bumps, but on the whole I think it's been transformative for everyone.
by NoboruWataya | 2026-03-04 09:44:54+00:00
As domh mentioned, some (not all) banking apps do seem to work well at the moment. My concern would be that what works today may not work tomorrow. My HSBC app seems to get more crippled with every update and it wouldn't surprise me at all if a future update rendered it unusable on GrapheneOS (which is the main thing stopping me from moving to it).

It's probably a pipe dream but I do hope that someone like Motorola officially supporting GrapheneOS will make businesses take support somewhat seriously. If nothing else you sound less like a crazy person when you tell your bank's customer support "I bought a Motorola phone and now your app doesn't work" than "I flashed a custom ROM to my Pixel and now your app doesn't work".
by qalmakka | 2026-03-04 09:46:44+00:00
I think people don't really realise that compilers are "difficult" projects in the same way as an appendicectomy is for a skilled surgeon, i.e. the surgery is
"routine" only because the surgeons spent decades honing their skills to do these routinely. The hard part was training someone to be able to do that.

Writing a compiler/interpreter is _extremely_ straightforward; a lexer -> parser -> ast -> semantic analysis -> {codegen -> linker | evaluator} pipeline is a very widely understood and tested way to write a compiler in any language, regardless of what language you are trying to compile. The hard part is _learning_ how it works, but after that implementing a compiler is a kind of mechanical activity. That's why LLMs are so great at writing parsers: they can just read the source of any compiler (and they probably read all of them) and apply the same stuff mechanically, with almost a 100% accuracy. We even have formal languages to define parsers and RTL and stuff, that's how "mechanical" the whole process can be.

I'm pretty sure that any skilled compiler dev with the ISO C standard and a few packs of Red Bulls can apecode a working C compiler in a few days, give or take. The hard part isn't doing that, the hard part is the decades of iterative improvements to make it generate extremely performant yet correct code as fast as possible.
by sunrunner | 2026-03-04 09:46:44+00:00
> Seriously, in what world do we need a rust compiler in php?

This is described in the README:

> Useful if you need to compile Rust on a shared hosting server from 2008 where the only installed runtime is PHP.

So I guess that world? I mean there's working around a problem and then there's working around a problem...

It would be amusing if, in such a highly limited environment, the compiled binary was still unusable due to restrictions on setting the executable flag.
by lproven | 2026-03-04 09:46:57+00:00
I am not a gamer and never really was, but a default config of Win95 made a lot of RAM available for DOS apps, as I recall. (And I was a serious expert in this area, 30-35 years ago.)

I used to do very basic memory optimisation on my Win95 boxes, just because I could with minimal mental effort, and then my DOS sessions had 630 kB or so free.

What I confess I did not investigate was DOSSTART.BAT and optimising what RAM was left when Windows was in "DOS mode".

https://smallvoid.com/article/win9x-dosstart.html

Too much effort for too little reward, for me.
by vessenes | 2026-03-04 09:47:00+00:00
Red/green is especially good with claude because even now with opus 4.6, claude can throw out a little comment like “//Implementation on hold until X/Y/Z: return { true }” and proceed to completely skip implementation based on the inline skip comment for a longgg time. It used to do this aggressively even in the tests, but by and large red/green prompting helps immensely - it tells the agent “think of failing tests as SUCCESS right now” - then you’ll get lots of them.

I’ve always been partial to integration tests too. Hand coding made integration tests feel bad; you’re almost doubling the code output in some cases - especially if you end up needing to mock a bunch of servers. Nowadays that’s cheap, which is super helpful.
by goku12 | 2026-03-04 09:47:43+00:00
> The is 'delusional' - or pick a more specifically appropriate term.

If drawing parallels from history is being delusional, the entire world is. Comparisons may not match in scale but the intent is the key. And the intent is absolutely clear here. That's why I said that you are 'histrionic' and 'hyperbolic'. You're being dramatic in your over exaggerated outrage at normal things people do.

> If nobody of 7 billion earth want to spend a few pennies to save something, then it's obviously not valuable in any way to anyone.

'Nobody cares' doesn't equate to 'not worth it'. That's false equivalence. Climate data especially. Who knows what's backed up and what's not? That's why I said it has to be collaboratively backed up and hosted. Instead you create this fanciful scenario that doesn't exist, in order to reach incoherent conclusions that you use to perform your over-the-top drama.
by rolandog | 2026-03-04 09:47:53+00:00
> best to just quietly wait it out

That's what an abuser expects of their victims.

The disproportionate retaliation against Spain, I think, is out of fear that the US face consequences. The Trump-Epstein cabal would be quickly over if a united European Union actually put some resistance or threat that affected the bottom line of American companies: "push the petty dictator out, or we stop trade with the US"... billionaires would suddenly start funding progressive think tanks.

But I digress... It's nice to fantasize about having elected leaders finally find their balls.
by ralferoo | 2026-03-04 09:47:56+00:00
After using git for about 15 years, I still find "git merge" unpleasant and hard to track changes. I've always had better experiences rebasing my branch on top of the current main and then committing the resultant changes. Of course it helps if you are regularly rebasing from main rather than leaving it until the end, but the process still usually feels cleaner than with git merge.

The only downside of rebasing (for me) is it looks confusing when commits aren't sequentially in date order, and sometimes it feels like you need to resolve the same conflict several times (once for each commit that gets rebased if they touch the same code) but that usually works out better for me than a regular merge.
by mkurz | 2026-03-04 09:48:07+00:00
> display port over usbc not working (it's coming) it's perfect.

I am on a Macbook Pro M1 Pro running Asahi and a 28 inch external display via USB-C / dp alt mode as of typing this comment.
They have a `fairydust` branch in their kernel repo which is meant for devs to test and hack on dp alt mode support, but it just works for me without problems.

See https://www.reddit.com/r/AsahiLinux/comments/1pzht74/dpaltmo...
by gf000 | 2026-03-04 09:48:34+00:00
Well, you should have learned about the language something in the meanwhile then.

75% boilerplate, come on. It has records and pattern matching now. Many of the cases of boilerplate are strictly self inflicted. And this criticism is absolutely laughable in a thread about Go, where you have to repeat some error ritual every 3 lines, losing the signal in all the noise. Java is a much more concise language than Go.

com.foo.bar solves a very real issue that is a big problem in e.g. the Node and Rust ecosystem (package name squatting).

And it uses as much RAM as you set it to use. It's true of every managed language that more memory equals less work to do, that is better throughput. But Java's GCs are the state of the art, it will work just fine with half the pre-configured memory.
by suncore | 2026-03-04 09:48:35+00:00
About the Lobster language used: The first thing I do when encountering a new language is look at the memory management, since what I want to do with a piece of code is usually build and manipulate data in a safe and efficient manner, so this is central. I am happy to see Lobster seems to be trying to take a new(ish) and pragmatical approach to memory management and that there is a whole document describing it in detail (https://aardappel.github.io/lobster/memory_management.html) which means the language creator agrees that this is important. Also happy to see the language seems to support fast memory management in a multi threaded environment, which is absolutely not self evident in many languages.
by ForHackernews | 2026-03-04 09:49:02+00:00
LLMs cannot, as you put it, "properly, correctly think"

So-called reasoning models are hallucinating, their self-reported "reasoning" does not reflect their inner state https://transformer-circuits.pub/2025/attribution-graphs/bio...

(before someone comes at me, yes, humans can also lie about their inner state but we are [usually] aware of it. Humans practice metacognition and there's no evidence LLMs can distinguish truth from hallucination)
by losalah | 2026-03-04 09:49:28+00:00
By “drift” I don’t just mean breaking changes between spec versions.

I mean the spec and the live API behavior fall out of sync (often because implementation changes land first and the spec lags, or vice-versa). The first time we notice is when a real UI flow breaks and someone has to spelunk Devtools to see what the server actually returned (missing fields, nullability changes, new enum values, shape differences...)

So spec-diff tools like Vacuum help once you’re comparing two OpenAPI files, but my pain is earlierm catching “spec vs reality” from normal dev/staging usage (real accounts + data) and getting an actionable report (which operation, what mismatch, request id/response snippet) before it turns into a broken UI + an hour of debugging.
by OJFord | 2026-03-04 09:49:34+00:00
I don't even think this is controversial, but I don't think it's at all without causation: not remaining curious, keeping the mind stimulated, etc., accelerates one's decline.

If you work in something labour intensive, you should retire young while your body's in good health; if you work in academia you should (strive for emeritus and) never leave! (And if you work in SWE, I don't know, we should probably retire, but then spend more time on our own projects/experiments/reading HN.) (All assuming for sake of argument we're optimising for longevity without considering time with family, having the funds to retire, etc.)
by ranguna | 2026-03-04 09:50:02+00:00
Sure, if you are ok walking around with a card.
I've been "walletless" for the past 6 years or so, and I don't want to go back.

Leaving and coming back home and only have to mentally track one object that I can't forget is great. If it breaks, I'll temporarily use cards or physical money until I get a new phone and install everything again.

"Use a card" is not really a good alternative for those that prefer not to use them. Sure it works for you, but not everyone has your preferences of walking around with a wallet.
by spockz | 2026-03-04 09:50:30+00:00
In this case the CPU wasn’t really saturated with work but with contention on global locks. The contention is lessened by removing the amount of concurrent mounts that are being done.

I wonder if simply setting a maximum number of concurrent mounts in the code or by letting containerd think there are only half the amount of cores, would have solved the contention to the same amount.
by sharts | 2026-03-04 09:50:44+00:00
Facts.

The sad reality is everyone wanting to have fancy looking pages/apps as quickly and easily as possible.

And now, the web (and increasingly desktop) is littered with the lowest common denominator of platforms with all sorts of crazy optimizations that still can’t be as snappy as a Windows 95 app on a 200mhz / 16MB desktop.

At this point we may as well just use electron and nodejs for fighter jets and missile defense systems. Surely it’s fast enough for that, too.
by oblio | 2026-03-04 09:51:25+00:00
I'm actually not an Apple user but I've seen them do their thing for close to 30 years now.

Apple is notoriously a control freak. They want to control the hardware, they way to control the software, they want to control the services, they want to control the entire experience.

What you're saying goes against everything they stand for.

Every time they open up, they do it because they're forced to.

They moved away from PowerPC (more control) to Intel (less control) because PowerPC couldn't keep up (despite them lying for half a decade about its performance, at some point it became too hard to distort reality).

They provided Windows dual-boot because they had to, their PC market share was too low and they couldn't get many applications so they had to accept it. After the iPhone took off and Mac started having a bigger marketshare and things were ported to it, they didn't need it as much so they stopped trying, they ditched dual boot for ARM. They never provided any real support for Linux, just some random hints and kind words, basically. They have more than enough money to sponsor an official port.

If anything, it's amazing that someone presumably technical can be "15 years into the ecosystem" and not understand these larger patterns so that I have to explain them like this :-)

Every time they open up, it's because they're weak. Once they're in a position of power:

* only XCode as an official IDE

* no JIT on iOS

* no first-class support for Ruby, Python, JS, etc to build iOS applications

* AppStore, no sideloading

* must use Mac to build for iOS

* ...

They're basically PC Nintendo. Always have been. The mega genius Jobs didn't want fans in a PC from the 1980s because they weren't cool, leading to said PC melting.

I find it funny that people keep excusing a multi-trillion dollar company for not finding pocket change to fund official porting efforts (such as Linux on Apple hardware, or Swift on Linux and Android) across decades. They're not doing it because they don't want to. They never will.

The purpose of a system is what it does: https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...
by davidvartanian | 2026-03-04 09:52:24+00:00
The compound interest framing is the right one. The part people miss is that compound interest works in both directions.

Good early architectural decisions compound positively. A clean boundary between services means the team that owns service A doesn't need to coordinate with the team that owns service B when either one ships. That coordination cost you avoided on day 30 is the same cost you avoid on day 300, but by day 300 you've avoided it hundreds of times.

Bad decisions compound negatively, and the mechanism is subtle. A leaky abstraction doesn't break anything immediately. It just means every developer who touches that boundary spends an extra 15 minutes (BS, it can be an hour or two) understanding why the types don't quite match, or why that one field is sometimes null. Multiply 15 minutes by 8 developers by 250 working days and you've lost 500 engineer-hours to a decision someone made in week two.

The "Mullet Schema" idea (strict columns for business-critical data, JSONB for everything else) is a practical version of this. You're deliberately choosing where to accept compound costs (the JSONB side) and where to prevent them (the strict columns). The key is being explicit about which side a given piece of data belongs on, and reviewing that classification as the product evolves. What starts as "nice to have" metadata has a way of becoming load-bearing business logic over 18 months.

To answer your question about where to draw the line: I look at how many teams or people need to coordinate when something changes. If a schema change requires three Slack conversations or a "short" call, that's a signal the architecture is creating coordination costs that will definitely compound, what you correctly called "microservice tax" and I call "complexity tax". That's usually where the line should have been drawn earlier.