MurphyA/hacker-news huggingface dataset:
by Arainach | 2026-02-21 22:27:27+00:00
I applied for an internship with the NSA. My understanding of the process (years ago, pre-Snowden) was that they did a pass on your resume (I can't recall if there was even a phone screen), then they started background checks and if there were N internships the first N people to pass the security clearance were selected.

They went through the standard stuff, interviewing my neighbors, etc. Then they flew me to Fort Meade for a polygraph. This article matches my experiences well - the interviewers latched on to arbitrary accusations and threw them at you over and over. I walked out feeling absolutely miserable and the examiner still claiming I was hiding past crimes and drug use (nope, I confessed to everything all the way down to grabbing coins out of the fountain at the mall when I was quite young). My interviewer said some large percentage of people fail their first and most pass the second.

...except there was no second, because shortly after I passed an interview and got an internship at a large tech company that paid significantly more and didn't require me to take a polygraph. No regrets on that decision.
by tabs_or_spaces | 2026-02-21 22:28:15+00:00
I'm confused and frustrated by this naming of "claws"

* I think my biggest frustration is that I don't know how security standards just gets blatantly ignored for the sake of ai progress. It feels really weird that folks with huge influence and reputation in software engineering just promotes this
* The confusion comes in because for some reason we decide to drop our standards at a whim. Lines of code as the measurement of quality, ignoring security standards when adopting something. We get taught to not fall for shiny object syndrome, but here we are showing the same behaviour for anything AI related. Maybe I struggle with separating hobbyist coding from professional coding, but this whole situation just confuses me

I think I expected better from influential folks promoting AI tools to at least check validate the safety of using them. "Vibe coding" was safe, claws are not yet safe at all.
by captainbland | 2026-02-21 22:28:20+00:00
A few reasons, "AI" as used by non-experts often has correctness and security issues. Even when it doesn't, its outputs are often not reproducible/predictable because they're probabilistic systems.

AI systems are also prone to writing code which they can't effectively refactor themselves, implying that many of these code bases are fiscal time bombs where human experts are required to come fix them. If the service being replaced has transactional behaviour, does the AI produced solution? Does the person using it know what that means?

The other side is that AI as an industry still needs to recoup trillions in investment, and enterprise users are potential whales for that. Good prices in AI systems today are not guaranteed to last because even with hardware improvements these systems need to make money back that has been invested in them.
by kristianp | 2026-02-21 22:29:02+00:00
Reminds me of Ghuloum's "An Incremental Approach to Compiler Construction" [1]. The tutorial [2], takes you through making a scheme compiler. It starts by compiling an integer to x86 assembly, using the output of gcc's assembly as reference. Then it goes through to tail calls and heap allocation, with a working compiler at every step. Tests at [3]. Mentioned in [4,5]. Gholoum went on to write Ikarus scheme which continued that work [6], but it never moved to 64 bit and the last release was in 2008.

[1] http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf

[2] https://web.archive.org/web/20061217101846/http://www.cs.ind...

[3] https://web.archive.org/web/20090618030856/http://www.cs.ind...

[4] http://lambda-the-ultimate.org/node/1752

[5] https://news.ycombinator.com/item?id=21627615

[6] https://web.archive.org/web/20090928074841/http://ikarus-sch...
by 0xbadcafebee | 2026-02-21 22:29:04+00:00
You can't regulate your way to a better Google. If the corporation's sole purpose is to slowly suck you dry, adding terms about the size of the straw is irrelevant. Android was created to control you and make money off you for Google. As long as it exists, they'll continue to find ways to do so, because it's the whole business model.
by perrygeo | 2026-02-21 22:29:15+00:00
Requirements handed down - never seen it in 25 years. The requirements are always fluid, by definition. At best, you get a wish list which needs to be ammended with reality. If you have completely static requirements, you don't need an engineer! You just do it. Engineering IS refining the requirements according to empirical data.

Once you have requirements that are correct (for all well-defined definitions of "correct"), the code implementation is so trival that an LLM can do it :-)
by cosmic_cheese | 2026-02-21 22:29:50+00:00
> And while your idea does have its merits, I fear that pretty soon you still hit a point where you can't sensibly and succinctly display those more complex types of permissions in the UI.

I could very well be wrong, but my inclination is that it's possible, but it's going to take the sort of fundamentals R&D that desktop operating systems haven't seen in decades. It can't just be tacked on, everything to be designed with this new system in mind.
by ssl-3 | 2026-02-21 22:30:09+00:00
Ignoring some of the other issues:

Imagine we have this electrolysis plant, splitting up water to produce the hydrogen we need for an area. That's fine.

But it needs fed electricity to keep the process going. Lots of it. It needs more electrical power to split the water than combining it again produces.

So it starts off being energy-negative, and it takes serious electricity to make it happen. Our grid isn't necessarily ready for that.

And then we need to transport the hydrogen. Probably with things like trucks and trains at first (but maybe pipelines eventually). This makes it even more energy-negative, and adds having great volumes of this potentially-explosive gas in our immediate vicinity some of the time whether we're using it individually or not.

Or: We can just plug in our battery-cars at home, and skip all that fuel transportation business altogether.

It's still energy-negative, and the grid might not be ready for everyone to do that either.

But at least we don't need to to implement an entirely new kind of scale for hydrogen production and distribution before it can be used.

So that's kind of the way we've been going: We plug out cars into the existing grid and charge them using the same electricity that could instead have been used to produce hydrogen.

(It'd be nice if battery recycling were more common, but it turns out that they have far longer useful lives than anyone reasonably anticipated and it just isn't a huge problem...yet. And that's not a huge concern, really: We already have a profitable and profoundly vast automotive recycling industry. We'll be sourcing lithium from automotive salvage yards as soon as it is profitable to do so.)
by bubblewand | 2026-02-21 22:30:31+00:00
Pretty sure the oldest stuff I've read was around 4,500 years old (in translation, but still). Volume I of Lichtheim's Ancient Egyptian Literature.

There are a couple incomplete tales in that 3-volume work and I really wish they'd had a more stable storage medium, because now I'm stuck with accidental millennia-old cliffhangers.
by _aavaa_ | 2026-02-21 22:30:44+00:00
Forget the type of electrolyzer, even if they were free hydrogen would still be expensive. The challenges with hydrogen getting cheaper are thermodynamic and can’t be innovated around. The amount of energy required to electrolyze water simply cannot drop by 10x.

The other difficulties (low energy density, ability to leak through many materials, massive explosion risks, near-invisible flames, etc., etc.) are all inherent to H2 as a molecule.
by encom | 2026-02-21 22:30:46+00:00
Google is almost cartoonishly evil these days. I think that's pretty much an established fact at this point.

I'm not using Gmail, and I don't understand why anyone would voluntarily. It was the worst email client I'd ever used, until I had to use Outlook at my new job.

The only Google products I use are YouTube, because that's where the content is. And Android, because IOS is garbage and Apple is only marginally less evil than Google.
by samerismail | 2026-02-21 22:31:02+00:00
Great call on SPIFFE/SPIRE. I looked at it early on it's excellent for workload identity in controlled infrastructure (Kubernetes, service meshes), but it assumes you control the environment your workloads run in.

The agent identity problem is different. AI agents are deployed by third parties, run across organizational boundaries, and interact with services they have no pre-existing trust relationship with. There's no SPIRE server you can install on someone else's OpenClaw instance.

Agent Passport is designed for that gap — lightweight, no infrastructure requirements, works over plain HTTP. But I think there's a real opportunity to bridge the two. An agent that runs inside your infra could get a SPIFFE SVID, and Agent Passport could accept that as an attestation signal in the risk engine. SPIFFE for internal trust, Agent Passport for cross-boundary trust.

The on-behalf-of angle is exactly right too. That's the chain we need: verified human → authorized agent → traceable action. Right now that chain is completely broken.
Show HN: Dq – pipe-based CLI for querying CSV, JSON, Avro, and Parquet files
by razeghi71 | 2026-02-21 22:31:26+00:00
I'm a data engineer and exploring a data file from the terminal has always felt more painful than it should be for me. My usual flow involved some combination of avro-tools, opening the file in Excel or sheets, writing a quick Python script, using DataFusion CLI, or loading it into a database just to run one query. It works, but it's friction -- and it adds up when you're just trying to understand what's in a file or track down a bug in a pipeline.

A while ago I had this idea of a simple pipe-based CLI tool, like jq but for tabular data, that works across all these formats with a consistent syntax. I refined the idea over time into something I wanted to be genuinely simple and useful -- not a full query engine, just a sharp tool for exploration and debugging. I never got around to building it though. Last week, with AI tools actually being capable now, I finally did :)

I deliberately avoided SQL. For quick terminal work, the pipe-based composable style feels much more natural: you build up the query step by step, left to right, and each piece is obvious in isolation. SQL asks you to hold the whole structure in your head before you start typing.

`dq 'sales.parquet | filter { amount > 1000 } | group category | reduce total = sum(amount), n = count() | remove grouped | sortd total | head 10'`

How it works technically: dq has a hand-written lexer and recursive descent parser that turns the query string into an AST, which is then evaluated against the file lazily where possible. Each operator (filter, select, group, reduce, etc.) is a pure transformation -- it takes a table in and returns a table out. This is what makes the pipe model work cleanly: operators are fully orthogonal and composable in any order.

It's written in Go -- single self-contained binary, 11MB, no runtime dependencies, installable via Homebrew. I'd love feedback specially from anyone who's felt the same friction.
by UncleMeat | 2026-02-21 22:31:32+00:00
I'd wager a lot of money that the huge majority of software engineers are not aware of almost any transformations that an optimizing compiler does. Especially after decades of growth in languages where most of the optimization is done in JIT rather than a traditional compilation process.

The big thing here is that the transformations maintain the clearly and rigorously defined semantics such that even if an engineer can't say precisely what code is being emitted, they can say with total confidence what the output of that code will be.
Ask HN: What Matters Most in Tech? Awards, Media Praise, or Peer Respect
by SoundsDebatable | 2026-02-21 22:31:33+00:00
What’s the biggest honor someone in tech can receive that isn’t money, a job title, or company success?

Is it being inducted into a Hall of Fame like the Internet Hall of Fame?

Winning a major industry award from groups like ACM?

Being profiled by top outlets such as Wired or TechCrunch?

Or is it something less formal — like earning deep respect from peers and being cited as an inspiration by other builders?

What do you think is the highest non-financial honor in tech?
by ericmay | 2026-02-21 22:31:43+00:00
> This is public anyway though? Isn't that the point of LinkedIn?

You can limit this. I don't think it's necessarily the point of LinkedIn - i.e. for others to connect with you and then have full visibility into all of the details of everyone you know and whatever you have on your profile. It's a bit naive to assume that operating in this manner doesn't make you a prime target for scammers, social engineers, hackers, &c., or even worse - solicitors.

> My experience is different

Yea, everyone has different experiences. I'm just describing how the platform generally works, as a matter of fact.
by samerismail | 2026-02-21 22:31:51+00:00
Thanks! ERC-8004 is doing really important work, especially the on-chain reputation and validation registries. The co-authors (MetaMask, Ethereum Foundation, Google, Coinbase) are thinking about this at the right level.

The way I see the overlap: ERC-8004 anchors agent identity and reputation on-chain using ERC-721, which is great for the web3 agent economy where you want composable, transferable identity with on-chain trust signals.

Agent Passport is more focused on the off-chain / web2 side lightweight challenge-response auth over HTTP for agents that just need to prove "I am who I claim to be" without touching a blockchain. Think traditional SaaS apps, MCP servers, internal tools.

Ideally these complement each other. An agent could have an ERC-8004 on-chain identity for the decentralized economy and an Agent Passport for interacting with traditional web services. The Ed25519 key could even be derived from or linked to the on-chain identity.

Appreciate the pointer definitely going to dig deeper into how the two could interop.
by Sharlin | 2026-02-21 22:31:54+00:00
Even the newtype-based "parse, don't validate" is tremendously useful in practice, though. The big thing is that if you have a bare string, you don't know "where it's been". It doesn't carry with it information whether it's already been validated. Even if a newtype can't provide you full correctness by construction, it's vastly easier to be convinced of the validity of an encapsulated value compared to a naked one.

For full-on parse-don't-validate, you essentially need a dependent type system. As a more light-weight partial solution, Rust has been prototyping pattern types, which are types constrained by patterns. For instance a range-restricted integer type could be simply spelled `i8 is 0..100`, or a nonempty slice as `[T] is [_, ..]`. Such a feature would certainly make correctness-by-construction easier in many cases.

The non-empty list implemented as a (T, Vec<T>) is, btw, a nice example of the clash between practicality and theoretical purity. It can't offer you a slice (consecutive view) of its elements without storing the first element twice (which requires immutability and that T: Clone, unlike normal Vec<T>), which makes it fairly useless as a vector. It's okay if you consider it just an abstract list with a more restricted interface.
by mike31fr | 2026-02-21 22:32:08+00:00
Side note:

Simon Halvdansson runs "Harmonic", an Android client for Hacker News, I am using it daily for 2+ years and I sincerely recommend it.

I even asked him a feature (mark a story as read), and he implemented it shortly after.

Shout-out to you Simon!

https://github.com/SimonHalvdansson/Harmonic-HN

https://play.google.com/store/apps/details?id=com.simon.harm...
by yellowapple | 2026-02-21 22:32:18+00:00
Does it, though? If anything it seems like the opposite: China's success had directly enabled my standard of living as an American to be as high as it is.

I suppose it'd be true that the standard of living of some Americans depends on China not succeeding — specifically, those Americans who own corporations competing with Chinese firms — but I think they'll survive just fine with only 10 yachts instead of 15.
by delichon | 2026-02-21 22:32:18+00:00
The polygraph doesn't have to emit any useful data at all to be very useful in interrogations. Like a bomb doesn't have to have any explosive in it to clear a building. Interrogation is a head game and a complicated box with knobs and buttons and maybe even blinking lights makes a fine prop.

And there's enough ambiguity in it that it's easy for the operator to believe it helps. Like a dowser with their rods, a clergyman with a holy book or an astrologist with a horoscope. That gives them the power boost of sincerity.
by quietbritishjim | 2026-02-21 22:32:26+00:00
This is one of the most ridiculous comments I've ever read on Hacker News. You really think git became popular because someone wrote up a branching convention for it?

Git became popular because it was one of the first two open source distributed version control systems. Compared to the least-bad open source (non distributed) version control system before, SVN, the native branches and the ability to have a local copy of the whole tree were self evidently a revolution.

(The other one was Mercurial by the way, released at almost exactly the same time as git. Partly git won that race because of the cachet of being written by Torvalds and being used for the kernel, but I suspect mainly it was due to the existence of GitHub.)

Aside from the above, it's also just clearly not true that git flow was particularly common. It's no good claiming anyone that disagrees is in a bubble. We all have access to GitHub! Look for yourself at some random repos (and make sure you sample a few different languages). It will verify my experience of looking at dozens, probably hundreds, of repos over many years: the number of people using git-flow is, to a first order approximation, roughly zero.
by overfeed | 2026-02-21 22:32:32+00:00
> In reality, they are adding capacity as quickly as possible [...]

Even if we ignore the fact that you can't build out factories in secret, this would be securities fraud by publicly listed companies.

> ...as margins are too high

This is not the first RAM boom-bust cycle, and memory makers are an actual cartel convicted of coordinating in the past - none if them are going to break rank when they can invest the minimum and reap outsized benefits. Also, no one wants to invest in additional capacity when the bottom can fall out at anytime, and shareholders demand your head- not even the AI companies want to bear that risk, which is saying something.
by snigsnog | 2026-02-21 22:32:47+00:00
Kiwifarms is an example: https://old.reddit.com/r/DataHoarder/comments/x95gd5/interne...

Anyone can request anything be removed and they may honor the request: https://help.archive.org/help/how-do-i-request-to-remove-som... they say nothing about only removing things illegal in the US or anything like that, meaning they can and will remove things based on personal judgements about whether it should be archived.
by thestackfox | 2026-02-21 22:32:56+00:00
I get the sentiment, but "I don’t like magic" feels like a luxury belief.

Electricity is magic. TCP is magic. Browsers are hall-of-mirrors magic. You’ll never understand 1% of what Chromium does, and yet we all ship code on top of it every day without reading the source.

Drawing the line at React or LLMs feels arbitrary. The world keeps moving up the abstraction ladder because that’s how progress works; we stand on layers we don’t fully understand so we can build the next ones. And yes LLM outputs are probabilistic, but that's how random CSS rendering bugs felt to me before React took care of them

The cost isn’t magic; the cost is using magic you don’t document or operationalize.
by bArray | 2026-02-21 22:33:07+00:00
I can read back to 1500, but 1400 reads like a different language. To be fair this quite remarkable, given:

> Before the mid 1700s, there was no such thing as standardized spelling.

It felt like it was become more Germanic, and that appears true:

> The farther back you go, the more the familiar Latinate layer of English is stripped away, revealing the Germanic core underneath: a language that looks to modern eyes more like German or Icelandic than anything we’d call English.
by the__alchemist | 2026-02-21 22:33:37+00:00
The examples in question propagate complexity throughout related code. I think this is a case I see frequently in Rust of using too many abstractions, and its associated complexities.

I would just (as a default; the situation varies)... validate prior to the division and handle as appropriate.

The analogous situation I encounter frequently is indexing, e.g. checking if the index is out of bounds. Similar idea; check; print or display an error, then fail that computation without crashing the program. Usually an indication of some bug, which can be tracked down. Or, if it's an array frequently indexed, use a (Canonical for Rust's core) `get` method on the whatever struct owns the array. It returns an Option.

I do think either the article's approach, or validating is better than runtime crashes! There are many patterns in programming. Using Types in this way is something I see a lot of in OSS rust, but it is not my cup of tea. Not heinous in this case, but I think not worth it.

This is the key to this article's philosophy, near the bottom:

> I love creating more types. Five million types for everyone please.
by ptnpzwqd | 2026-02-21 22:33:47+00:00
This article seems completely out of line with reality, maybe I am living on a different planet.

I have never heard of anyone following those SDLC steps rigorously and sequentially. Things tend to be much more intertwined, combined, and iterative than this suggests.

Even if agents were writing the code, someone would still need to identify what actually needs to be done - requirements don'y magically pop out of nowhere.

He doesn't know a single person(!?) still writing code by hand? Even the most hardcore believers in coding agents that I know still review and revise code by hand. Even the sota models spit out garbage if not carefully guided and reviewed (and even then quality is still behind an experienced human engineer for anything non-trivial).

This all seems so far from the reality I live in...
by advael | 2026-02-21 22:34:00+00:00
Yea, the pervasiveness of this analogy is annoying because it's wrong (because a compiler is deterministic and tends to be a single point of trust, rather than trusting a crowdsourced package manager or a fuzzy machine learning model trained on a dubiously-curated sampling of what is often the entire internet), but it's hilarious because it's a bunch of programmers telling on themselves. You can know, at least at a high level of abstraction, what a compiler is doing with some basic googling, and a deeper understanding is a fairly common requirement in computer science education at the undergrad level

Don't get me wrong, I don't think you need or should need a degree to program, but if your standard of what abstractions you should trust is "all of them, it's perfectly fine to use a bunch of random stuff from anywhere that you haven't the first clue how it works or who made it" then I don't trust you to build stuff for me
by eek2121 | 2026-02-21 22:34:12+00:00
Duke Nukem/BUILD was the first level editor that sucked me into level editing/mods, it is also the place where I spent the most hours. I later pivoted to more professional pursuits, however i killed a ton of time building new levels, and exploiting the engine to an obscene level.

I doubt I could get back into it these days, however, I hope the open source effort can inspire some awesome stuff!