MurphyA/hacker-news huggingface dataset:
by southernplaces7 | 2025-07-09 23:45:05+00:00
This yes and a fair worry for many who lived with older parents, grandparents etc, but the original comment mentioned an illness killing "you" assuming the partygoer, who, given the context of the article, is probably going to be a lot younger than anything close to elderly (though elderly people should party too. Socializing should never be under-estimated for helping vitality)
by imiric | 2025-07-09 23:45:58+00:00
> A computer always was a tool to enable people without technical knowledge to build software.

That's just not true.

Every past technology that claimed to enable non-technical people to build software has either failed, or was ultimately adopted by technical people. From COBOL, to BASIC, to SQL, to Low-Code, to No-Code, and others. LLMs are the latest attempt at this, and so far, they've had much more success and mainstream adoption than anything that came before.

The difference with LLMs is that it's the first time software can be built and deployed via natural language by truly anyone. This is, after all, their most advertised feature. The skills required to vibe code are reading and writing English, and basic knowledge to use a modern computer. This is a much lower skill requirement than for using any programming language, no matter how user friendly it is. Sure, there is a lot of poor quality software today already, but that will pale in comparison to the software that will be written by vibe coding. Most of the poor quality software before LLMs was limited in scope and reach. It would never have been deployed, and it would remain abandoned in some GitHub repo. Now it's getting deployed as quickly as it can be generated. "Just fucking ship it."

> LLMs are incredible engineering tools and brushing them aside as nonsense is imo doing a disservice to everybody

I'm not brushing them aside as nonsense. I use these tools as well, and have found them helpful at certain tasks. But there is a vast difference from how domain experts use these tools, and how the general public uses them. Especially people who are only now getting into software development, and whose main interest is to quickly cash out. If you think these people care about learning best software development practices, you'd be sorely mistaken. "Just fucking ship it."
by mlyle | 2025-07-09 23:46:45+00:00
We know:

* Plutonium is not well absorbed by ingestion compared to other heavy metals and know ballpark ingestion toxicities

* We also know that pretty much all the plutonium except the long-lived isotopes are gone on a timescale of tens of thousands of years-- leaving behind mostly uranium isotopes.

* There's no real reason to believe this mixture of uranium and a small fraction of long-lived plutonium isotopes is significantly worse than ingesting uranium. It might be worse to inhale fine dust, though.

* Mercury is way worse than uranium because it is so readily absorbed.
by deathanatos | 2025-07-09 23:47:35+00:00
You're not installing the untrusted tarball; helm is merely supposed to be extracting it, and then rendering the templates contained within.

(Those templates, once rendered, might then refer to pods, etc. that might be put into a k8s cluster (or perhaps we merely render then YAML, and never `apply` it), and in that sense, one might imagine that that is an install, but that's not the security boundary being crossed here; this would presumably result in execution on the host running helm, which would definitely be surprising.)
by TeMPOraL | 2025-07-09 23:48:55+00:00
I disagree. The actual problem that's specific to LLMs is that the model cannot process data without being influenced by it, and that's because the whole idea is ill-formed. LLMs just don't have explicit code/data separation, and cannot have it without losing the very functionality you want from them[0].

Everything else is just classical security stuff.

Or to put it another way, your controllable interface between LLM output and actions can't help you, because by definition the LLM-specific problem occurs when the action is legal from permission standpoint, but is still undesirable in larger context.

--

[0] - I feel like many people think that code/data separation is a normal thing to have, and the lack of it must be a bug (and can be fixed). I'm trying to make them realize that it's the other way around: there is no "code" and "data" in nature - it's us who make that distinction, and it's us who actively build it into systems, and doing so makes some potentially desirable tasks impossible.
by Dusseldorf | 2025-07-09 23:49:11+00:00
That's really rough. We bought into a neighborhood in an older college town, and I think that's helped things a bit for us. Smaller houses and yards, so people hang out around the neighborhood or in parks. Everyone's out walking their dogs all the time, and pretty much everyone is happy to stop and chat. I think it's just about getting lucky and finding places where people prioritize the community rather than having giant houses, giant yards with swingsets, and giant cars so they never need to talk to anyone.
by vedantnair | 2025-07-09 23:49:25+00:00
In this five-part series, we'll be deep diving into why schemas are so important for scaling a robotics configuration management system and battling it out between different schema formats.

By the end of the series, you'll be an expert at what schemas are best for what use case and their respective tradeoffs. This will give you and your team the confidence to choose a schema that's best for your fleet.

In this chapter, we'll be introducing schemas: why they're powerful, what they are used for, and what we care about when choosing a schema.
by mtlmtlmtlmtl | 2025-07-09 23:50:25+00:00
I looked at the code for this once. It's sort of a hack. It generates a random puzzle, tries to solve it with a deterministic backtracking(IIRC) solver that detects situations where it's stuck. If it is stuck, it shifts some mines around in the place where the solver got stuck, according to some heuristics, and keeps solving. It keeps doing this until the entire puzzle has been solved, verifying that the puzzle can be solved without any guesswork.

I will second the recommendation. As someone who's wasted too many hours on minesweeper, it radically changes the game. Because I know there's a logical solution, I'm able to find patterns that I never found in the original, because I'd often assume it was just one of those guesswork situations. It's similar to how chess puzzles are easier than an equivalent position during a game. Because you know there's a neat solution, you're more willing to put in the legwork of searching for it. Learned a lot about the game simply by playing Simon's version.
by kelas | 2025-07-09 23:50:45+00:00
(en passant, k is arguably more lispy than some lisps. for a lisp guy, the first cultural shock is usually the absence of 99% of superfluous parens)

as for LLM copilots and the quality of their lisp: why you'd expect them to excel in lisp better than they lisp in excel, pardon the pun?
by majormajor | 2025-07-09 23:50:52+00:00
This was your pitch, right? "product can shift from "give me an app that makes it easier to do my taxes" to "keep me current on my taxes and send me status updates"

How is that not Mint from 15 years ago? Actual integration into the US tax system is a government problem, not an LLM problem.

Now it sounds like you're suggesting more of a even-more-centralized Mint-replacement that aggregates everything for you to try to be a single AI assistant.

But do I want an LLM pulling the trigger on ordering new products for me based on what it thinks I'd want when? Or changing the investment strategy on my accounts? Not really.

"Personal assistant for keeping track of your receipts for when you need to return something" is mildly interesting except... if you're buying online, the receipt's already basically trivially to find 99% of the time. And if you're buying offline, are you scanning all the receipts by hand? And unlike a personal assistant, the LLM isn't driving to drop off those packages.

Booking transit at the same time as travel, also something that's existed for a long time. And a third party Google Calendar "hey, we see a flight here, and a hotel there, do you want us to pre-book an Uber between the two" feature would not require LLMs at all.

So what am I gaining from this super-Mint-app and how is it LLM-specific if I don't have financials that need super-heavy-oversight and I don't want to outsource my grocery and shirt shopping to a personal assistant?
by ashvardanian | 2025-07-09 23:51:13+00:00
It’s a very interesting benchmark (https://github.com/lemire/TestingMLP) — probably worth adding to the Phoronix or some wider suite.

Every couple of years I refresh my own parallel reduction benchmarks (https://github.com/ashvardanian/ParallelReductionsBenchmark), which are also memory-bound. Mine mostly focus on the boring simple throughput-maximizing cases on CPUs and GPUs.

Lately, as GPUs are pulled into more general data-processing tasks, I keep running into non-coalesced, pointer-chasing patterns — but I still don’t have a good mental model for estimating the cost of different access strategies. A crossover between these two topics — running MLP-style loads on GPUs — might be exactly the benchmark missing, in case someone is looking for a good weekend project!
by okanat | 2025-07-09 23:51:35+00:00
Every operating system, that's relevant in 2025, needs that concept. It is called NUMA. At some point you cannot model the system ignoring the memory affinity / closeness to the cores.

Modern AMD CPUs are literally consist of core groups on chiplets. It is better for an OS to make decisions / expose APIs for cores that are physically so far away from each other that moving data back-and-forth over the RAM, system bus or interconnect has significant time penalties.
by tzs | 2025-07-09 23:51:42+00:00
> If this $100 million in impact rule is the reason for the judgement, wouldn't that suggest that a scam that takes in more than $100 million would be protected?

No.

The $100 million rule doesn't say that things with more than $100 million in impact cannot be regulated. It just says that more analysis is required when regulating such things.
by greazy | 2025-07-09 23:52:23+00:00
Creating a biological weapon requires a whole bunch of unique and specialised skills, equipment, safety measures (so you don't infect/kill yourself/your people) and even multidisciplinary skill sets. Take for example the Kameido (Japan) incident by the Aum Shinrikyo cult/religious group [1]. Same group which committed the Sarin attack [2].

> The use of an attenuated B. anthracis strain, low spore concentrations, ineffective dispersal, a clogged spray device, and inactivation of the spores by sunlight are all likely contributing factors to the lack of human cases.

Now you may say, that's bacteria, what about viruses? A similar set of problems would arise, how do you successfully grow virus to high titers? Even vaccine companies struggle to do this with certain viruses. Then the issue of dispersal, infectivity and mortality arise (too quick, it kills the host without spreading and authorities will notice, too slow, same problem: authorities will notice). I haven't even mentioned biological engineering which requires years of technical knowledge and laboratory experience combined with a intimate knowledge of the organism you're working with.

What worries me the most is nature springing a new influenza subtype. Our farming practices, especially in developing countries, is bound to breed a new subtype. It happened in 2009 (H1N1pdm) and it is bound to happen again. We got lucky with H1N1pdm.

1. https://pmc.ncbi.nlm.nih.gov/articles/PMC3322761/ 2. https://en.wikipedia.org/wiki/Tokyo_subway_sarin_attack
by deathanatos | 2025-07-09 23:52:44+00:00
… and I think I'd argue that the parent's argument against the tooling would apply equally as well to those "other things", too.

The alternative here is something that manipulates the data structure directly. E.g., it might permit me to say:

my_config_map.data["key"] = some_string_value

(This is in some pseudo-imperative language, vs. the parent's Lisp, but that distinction isn't particular relevant to the core of their argument, I think.)

And then at the end, the thing itself takes care of converting the resulting objects to YAML, thus preventing me from inadvertently turning what is meant to be a string into something like an accidental YAML-injection that results in terrible errors because I miscounted the number of spaces to indent something.
by chromalchemy | 2025-07-09 23:53:00+00:00
This exists. https://yamlscript.org/blog/2025-06-24/how-does-ys-work/

https://yamlscript.org/about/ - YAMLScript (or YS) A graal pre-compiled Clojure environment, like Babashka, but uses a different, looser syntax (yaml based). Can run from command line.

Like a nicer Python?
by sheepscreek | 2025-07-09 23:55:27+00:00
Washroom vs. bathroom: I’ve always found it strange to call a room a “bathroom” if it doesn’t have a shower or tub. On the other hand, most single-family homes in Canada have a “powder room” where people can wash their face and hands. Although these facilities serve similar purposes, the former is used for public spaces, while the latter is found inside homes.
by godelski | 2025-07-09 23:56:54+00:00
I think you missed my point. I agree, being a machine doesn't mean you don't have free will. I agree, free will is orthogonal to being (or not being) a machine.

But that's not what my comment was about.

My comment was about *what the average person interprets*.

You asked why people take offense to being called a machine, and I'm trying to explain that. But to understand this we have to understand that there isn't a singular objective way to interpret statements. We can agree that language is fuzzy, right?

So let me try to translate, again.

You say: "People are machines"

(Many) People hear: "People are mechanical automata, running pre-defined routines"

I hear you, this is not what you are trying to communicate. That's not what you want them to hear. But if you want them to hear what you actually mean it is very helpful to understand that some people will hear something different.

Why do they hear the other thing? Because they don't have intimate familiarity with machines and how general that word is. *You have a better understanding of what a machine is than most people.* That's likely the cause for miscommunication.

When they think of a machine they think of things like a car, a computer, a blender, a TV, an oven, or a multitude of other similar things. Even if some of these use probabilistic programming, the average person is not going to know what probabilistic programming even is. They just see something mechanical. Deterministic.

I'm sure you know this, but it is worth reiterating. Communication has 3 main components: What you intend to communicate, the words/gestures/etc you use to communicate, and what the other person hears. Unfortunately (fortunately?) we can't communicate telepathically, so don't forget that the person you're talking to can have a reasonable interpretation that is significantly different from what you intended to say.
by jcelerier | 2025-07-09 23:57:15+00:00
> IIRC you could convert all 16M of RGB to CAM16 and L* in 6 seconds, in debug mode, in Dart, transpiled to Javascript in 2021, so I try to advocate for doing things with a proper color space as much as possible, the perf just doesn't matter.

Coming from the "real-time graphics" world, if I read that something which is going to be a minor part of your whole pipeline would take 6 seconds (or even 600 or 60 ms) it would be instantly disqualified so I don't really understand why you'd say "the perf just doesn't matter" ?
by eternityforest | 2025-07-09 23:58:20+00:00
I looked at a bunch of these tiny languages, and ported several of them to the ESP32, contributed some enhancements for CircuitPython.... but eventually settled on tinyexpr, and just... Not having any data types besides numbers.

TinyExpr is very fast, it's just an expression parser, and when you pair it with a state machine engine, you can do stuff like:

"While you are in state 4, if pin Y changes, set machines.foo.state5 to 1".

Which is perfectly sufficient for most "Add a bit of configurability" tasks, I can edit behavior from my phone and make small tweaks.

Anything beyond that I would much rather just do in C++, with access to all my nice dev tools and LLMs and debuggers and linters and version control.

I really like the idea of a full language on a microcontroller, but... You usually need so many bindings and application specific functions that you always wind up needing some C++ code anyway.

I also looked at ESPHome, which is super impressive, very nice to use, but light on runtime web UI configurability, the protocol is nonstandard, and the Python client libs used to have frequent breaking changes.

https://github.com/EternityForest/ArduinoCogs
by tgsovlerkhgsel | 2025-07-10 00:00:01+00:00
A good reason to do it (IMO, as someone who has done it) that it's a lot faster, easier, and often cheaper than designing a fully custom board.

Not only would designing a fully custom board require a lot of error-prone effort, getting a lot of components in tiny quantities can be prohibitively expensive.

Good engineering includes optimizing for cost (monetary and non-monetary), and I'd argue that for many hobbyist one-off projects that won't be manufactured at scale, dev-boards-on-PCB is good engineering.
by deathanatos | 2025-07-10 00:00:18+00:00
> What is the attack scenario here?

Given the details in the article, I think even something as simple a templating a chart from a repository might be vuln., but it likely depends on a lot of exact specifics.

> Where are the security boundaries?

I expect templating does not result in LCE.

> How does the attacker gets their repository with a symlink in it to the victim?

The attacker owns the repository. They can serve whatever maliciousness in it they want. But should templating a malicious chart result in LCE?

> Is Helm typically run as a privileged user?

Enough so, yes, because the rendered result is often pushed to a k8s cluster. "Privileged" here might not be "root", but it might be "this user has k8s API access".

Imagine, e.g., that the attacker's LCE here might be "push ~/.kube to attacker".

> And why doesn't the vulnerability description give answers to these questions?

Familiarity with the tools involved is an normal assumption.
by throw0101a | 2025-07-10 00:01:07+00:00
> And then eventually, water seeps in.

Not if it's below non-porous rock…

* https://www.nwmo.ca/who-we-are/how-were-governed/peer-review...

* https://www.nwmo.ca/Site-selection/Steps-in-the-site-selecti...

…below the water table…

* https://www.nwmo.ca/canadas-plan/canadas-deep-geological-rep...

…packed in non-porous soil/clay:

* https://www.nwmo.ca/-/media/Reports-MASTER/Technical-reports...

* https://www.nwmo.ca/Canadas-plan/Multiple-barrier-system

> When and how would nuclear waste become a problem.

Never. If there is ever "too much" of it we reprocess it as per OP article to remove the "non-usable" stuff and burn up the rest. It seems that there's an order of magnitude reduce by recycling (96% is usable fuel, so 4% is left over):

* https://www.orano.group/en/unpacking-nuclear/all-about-radio...
by rtpg | 2025-07-10 00:02:25+00:00
Right, it's hard to disconnect some of Clojure's niceties from the macro work (though I think Clojure's macros tend to do less inner inspection than macros you'll see in other lisp variants)

The link to Rhombus is very interested, I hadn't heard of this and it looks very well developed. Will mess around with it.
by _DeadFred_ | 2025-07-10 00:02:37+00:00
For the geeky non-serious sci-fi kid in me it's wild to live in the future, where there is serious talks of building independent from the grid nuclear power plants to power AIs. Because one of the big things from all the pre-thinking about AI was that we definitely DON'T want to be able to turn their power off remotely. Glad removing that capability is already in the plan. Totally doesn't seem sketchy.
by Flux159 | 2025-07-10 00:03:14+00:00
This is an interesting take since web developers could add mcp tools into their apps rather than having browser agents having to figure out how to perform actions manually.

Is the extension itself open source? Or only the extension-tools?

In theory I should be able to write a chrome extension for any website to expose my own custom tools on that site right (with some reverse engineering of their APIs I assume)?
by kofta | 2025-07-10 00:04:12+00:00
adding to the OP's: Ghazal is the romanization of the word غَزَل in Arabic, it almost means "flirting", and is a form of Poetry that dates to the Pre-Islamic time, usually a poem about love and romance.

The author seems to stress about the rules of "Ghazal" (and there is a lot more to it than just couplets rhyming the same) but these are just general poetic rules the Arabic poets used to adopt, and not exclusive to romantic poetry aka "Ghazal".
by crote | 2025-07-10 00:05:19+00:00
So you enhance the already-existing continent-scale grid and import your power from an area a few thousand km/mi away which isn't both cloudy and windless at the same time. Heck, there's probably plenty of opportunity for hydro storage in that range.

If all else fails: power up the backup natural gas power plants for a couple of hours. We're trying to minimize CO2 emissions as quickly as possible, getting to 0% immediately isn't the goal. Run a carbon capture plant during times of energy excess to compensate if you feel like it.
by josephg | 2025-07-10 00:06:06+00:00
“Obvious” to me is an appeal to ocham’s razor. Whether you’re conscious of it or not, we all deeply feel that our systems should obey the simplest theory.

If addition in rust worked normally except when you add the number 4, the program panicked, that would be ridiculous. But why? Because it is inconvenient for one. And it’s not obvious. You need a more complex theory to model language like that.

The question with derive(Clone) is “what is the most straight forward theory” and if the actual language is more complex, we have to ask ourselves if the extra complexity is worth the cost.

If you spend 2 minutes thinking about it, as the blog post author said, if you want to implement clone for Foo<T>, it should be totally irrelevant if T implements clone or not. What matters is if the members of the struct implement clone. And that’s a completely independent question. Maybe T is clone and the struct members are not (eg the struct stores Cell<T>). Maybe the struct members are clone and T is not (eg if the struct stores Arc<T>). It’s a very strange, idiosyncratic theory that derive should have an invisible trait bound on T: Clone. It was also pretty surprising to the blog post author.

Sometimes complex theories pay their own rent. Like the borrow checker. Or fixed size integers. But if the theory is hidden, hard to learn, and doesn’t seem to help programmers, I’d call it a bug. Or a kludge. It’s certainly not an elegant programming language feature. This is why bringing up obviousness is relevant. Because good language features are either simple (and thus obvious) or they help me program enough to be worth the complexity they bring. This is neither.

This seems like a kludge to me. Derive should either impl clone when the children impl clone, or be universal, or univeral with optional custom trait bounds specified by the caller. (Eg derive(Clone where Foo<T>: Clone).

The advantage of a universal implementation is that you’d get more obvious compilation errors. “impl Clone of Mystruct<T>(T) requires T: Clone. Fix by adding where T: Clone to derive or manually implementing clone”. Simple. Straightforward. Obvious.