MurphyA/hacker-news huggingface dataset:
by trenchpilgrim | 2025-11-02 18:42:42+00:00
https://xkcd.com/2501

I know a lot of professional, highly paid SWEs and DevOps people who never went to college or had any formal CS or math education beyond high school math. I have a friend who figured out complexity analysis by himself on the job trying to fix up some shitty legacy code. Guy never got past Algebra in school.

(If you're about to ask how they can get jobs while new grads can't - by being able to work on really fucking terrible legacy code and live in flyover states away from big cities.)
by borntyping | 2025-11-02 18:43:02+00:00
> Can someone explain why anyone would want non-squashed PRs? > > For the 5% of engineers that diligently split each PR into nice semantic changes, I suppose that's nice. But the vast majority of engineers don't do this.

I think cause and effect are the other way around here. You write and keep work-in-progress commits without caring about changes because the history will be discarded and the team will only look at pull requests as a single unit, and write tidy distinct commits because the history will be kept and individual commits will be reviewed.

I've done both, and getting everyone to do commits properly is much nicer, though GitHub and similar tools don't really support or encourage it. If you work with repository history a lot (for example, you have important repositories that aren't frequently committed to, or maintain many different versions of the project) it's invaluable. Most projects don't really care about the history—only the latest changes—and work with pull-requests, which is why they tend to use the squashed pull request approach.
by aeve890 | 2025-11-02 18:43:59+00:00
Strictly speaking, it should work. We don't have a _real_ RNG yet and with the same seed any random function becomes deterministic. But behind the blackbox of LLM providers who know what's tunned processing your request.

But my point stands. The non-deterministic nature of LLMs are implementation details, not even close to physical constraints as the parent comment suggest.
by throwaway894345 | 2025-11-02 18:45:24+00:00
It feels like we’re saying similar things. We both agree that its architecture makes it difficult to run with high availability, although I’ll point out that the issues documented in the article apply to single nodes and even on a single node it has pretty specific hardware requirements. I think we just disagree about whether “you have to hold it very carefully and it works just fine” is a good thing or not.
by thaumasiotes | 2025-11-02 18:45:28+00:00
> This feels a bit like saying that putting a wall in a room makes it non-euclidean since there's now a barrier in the way.

Maybe that's what H. P. Lovecraft meant about non-Euclidean architecture in R'lyeh. ;D

(It probably isn't - the quote from The Call of Cthulhu says "the geometry of the dream-place he saw was abnormal, non-Euclidean, and loathsomely redolent of spheres [...]".)
by blueg3 | 2025-11-02 18:46:17+00:00
I don't think Google is expecting anything here.

They run Big Sleep to find security vulnerabilities in projects they care about. It seems -- mostly from reading this issue's details -- that the finding is pretty high quality. Once a vulnerability is found, there's a duty to disclose the existence of the vulnerability to the project maintainers and, eventually, to the public within a reasonable timeframe.

The alternatives here are: not searching for the vulnerabilities in the first place; keeping the knowledge of the vulnerability secret; or notifying the public without the project maintainers having the opportunity to fix the vulnerability first. All of these are worse.

It's unlikely that Google cares about a vulnerability like this -- ffmpeg is probably run sandboxed and probably with a restricted set of codecs. So they're unlikely to spend engineering resources fixing it.

The project maintainers are under no obligation to actually fix the bug. The deadline is simply that the vulnerability will eventually be made public, even if it is not fixed. That's standard responsible disclosure and, again, is better than the alternatives.
by fjdjshsh | 2025-11-02 18:46:26+00:00
I get your point, but I don't think your nit-pick is useful in this case.

The point is that you can't abstract away the details of back propagation (which involve computing gradients) under some circumstances. For example, when we are using gradient descend. Maybe in other circumstances (global optimization algorithm) it wouldn't be an issue, but the leaky abstraction idea isn't that the abstraction is always an issue.

(Right now, back propagation is virtually the only way to calculate gradients in deep learning)
by dontlikeyoueith | 2025-11-02 18:46:40+00:00
> Still the fact that LLMs can do well in things like the maths olympiad have me thinking there must be some way to tweak this to be more brain like

That's because you, as you admit in the next sentence, have almost no understanding of how they work.

Your reasoning is on the same level as someone in the 1950s thinking ubiquitous flying cars are just a few years away. Or fusion power, for that matter.

In your defense, that seems to be about the average level of engagement with this technology, even on this website.
by Youden | 2025-11-02 18:46:45+00:00
I'm an EV owner and homeowner and looked into V2X when planning my solar/residential battery system.

On the home side, the hardware is largely there. The charger I'm buying and many others support it - though many need a future software update. On the vehicle side though, it's very inconsistent; there are only a few vehicles that support it and even for those, what my installer told me is that the manufacturer warranties typically either void the warranty entirely if V2(G/H) is used or harshly limit the amount of energy that can be used. They're concerned that it will lead to excess wear on the battery, the main component of an EV.

And I think I agree with them. With current battery technology, I don't think using EVs as a grid-scale storage system for renewables is viable. For grid-scale or residential storage, you want a battery that can be as heavy and physically large as it needs to be but it needs to deal with a lot of charge/discharge cycles. Your best option here right now is LiFePO. For the kind of EV people are generally willing to buy right now, you need to cram as much range into the car as you can, which means the battery needs to be as energy-dense as possible and charge/discharge cycles are less of a concern. That means LiPo.

I think the most realistic use of EVs for grid-scale integration is what they're calling "virtual plant", where they're treated like a separate source of energy that the grid can tap into in exceptional situations.
by ungreased0675 | 2025-11-02 18:46:47+00:00
This seems really inefficient, everyone transporting around a bunch of excess capacity? Smaller, lighter, cheaper electric cars paired with a properly built and resilient grid seems like a better goal to me.

They’d wear out roads less, use less resources to make, be safer to others in crashes, etc. I dislike the trend of increasingly larger vehicles just to move a single person around 87% of the time.
by hunterpayne | 2025-11-02 18:48:13+00:00
> If you had you wouldn’t conflate memory safety with a lack of memory manipulation.

We are all aware of unsafe. We are also aware that all those assurances of safety go away in those circumstances.

This is cherry-picking. I didn't say all research papers, just most. This is a very specific circumstance. Under specific circumstances these ideas will work.

This example is one where the replaced code wasn't that old, on a very specific set of hardware and in a rather specific case. Its basically the ideal set of conditions for a rewrite. But there are plenty of cases where attempts to swap in Rust aren't being done in ideal conditions like this. I doubt switching to Rust is never a good idea. I also doubt switching to Rust is always a good idea.

PS The problem is partly the way you write. I criticize ideas. You criticize me. That's a big part of why you get pushback.
by Someone | 2025-11-02 18:48:46+00:00
I think you remember that slightly wrong. https://en.wikipedia.org/wiki/History_of_Apple_Inc.#Apple_I_...:

“The two Steves made a last trip to the Homebrew Computer Club and demonstrated the Apple I (AKA: The Apple Computer). Paul Terrell, who operated the computer store chain Byte Shop, was impressed, and gave the two Steves his card, asking them to keep in touch. The next day, Jobs visited Terrell at the Mountain View Byte Shop store, and tried to sell him the bare circuit boards for the Apple I. Terrell said he was only interested in purchasing the machine fully assembled, and that he would order 50 assembled computers and pay US$500 each on delivery (equivalent to $2,800 in 2024). Jobs took the purchase order from the Byte Shop to national electronic parts distributor Cramer Electronics, and ordered the components needed. When asked by the credit manager how he would pay for the parts, Jobs replied, "I have this purchase order from the Byte Shop chain of computer stores for 50 of my computers and the payment terms are COD. If you give me the parts on net 30-day terms I can build and deliver the computers in that time frame, collect my money from Terrell at the Byte Shop and pay you." To verify the purchase order, the credit manager called Paul Terrell, who assured him if the computers showed up, Jobs would have more than enough money for the parts order. The two Steves and their small crew spent day and night building and testing the computers, and delivered to Terrell on time. Terrell was surprised to receive a batch of assembled circuit boards, as he had expected complete computers with a case, monitor and keyboard. Nonetheless, he kept his word and paid the two Steves the money promised.”

I guess you were thinking of Steve Wozniak trying his earlier design to HP and got rejected (https://en.wikipedia.org/wiki/History_of_Apple_Inc.#Pre-foun...: “Wozniak originally offered the design to Hewlett-Packard (HP), where he worked at the time, but was denied by the company on five occasions”)

So, Wozniak got rejected trying to see his design to a computer company, but the two Steve’s did manage to sell machines via a computer shop (possibly the only computer shop in the world, at that time).
by exasperaited | 2025-11-02 18:49:19+00:00
> Bonus points if you have any Tcl/Tk apps running, where you can simply transmit commands for the program to run via the X server.

Back in 1996 the level of X integration in Tk was awesome; I had a shell tool that could make Netscape do stuff by firing MIT magic cookies at it.

In a contemporary setting, it's pretty horrifying.
by riskable | 2025-11-02 18:49:32+00:00
I find the "slop" thing interesting because—to me—it looks like laziness. In the same way that anyone can tell ChatGPT to write something for them instead of writing it themselves and just having it check the work... Or going through multiple revisions before you're satisfied (with what it wrote).

Code is no different! You can tell an AI model to write something for you and that's fine! Except you have to review it! If the code is bad quality just take a moment to tell the AI to fix it!

Like, how hard is it to tell the AI that the code it just wrote is too terse and hard to read? Come on, folks! Take that extra moment! I mean, I'm pretty lazy when working on my hobby projects but even I'm going to get irritated if the code is a gigantic mess.

Just tell it, "this code is a gigantic mess. Refactor it into concise, human-readable files using a logical structure and make sure to add plenty of explanatory comments where anything might be non-obvious. Make sure that the code passes all the tests when you're done."
by thesz | 2025-11-02 18:49:44+00:00
From the topic starter: "I've posted a graph showing nearly 9000 microbenchmarks of Fil-C vs. clang on cryptographic software (each run pinned to 1 core on the same Zen 4). Typically code compiled with Fil-C takes between 1x and 4x as many cycles as the same code compiled with clang"

Thus, Fil-C compiled code is 1 to 4 times as slow as plain C. This is not in the "significantly slower" ballpark, like where most interpreters are. The ROOT C/C++ interpreter is 20+ times slower than binary code, for example.
by njacobs5074 | 2025-11-02 18:49:52+00:00
I'm not certain that I agree with this because a URL makes no claims about idempotency or side-effects or many other behaviors that we take for granted when building systems. While it is possible to construct such a system, URLs do not guarantee this.

I think the fundamental issue here is that semantics matter and URLs in isolation don't make strong enough guarantees about them.

I'm all for elegant URL design but they're just one part of the puzzle.
by Espressosaurus | 2025-11-02 18:49:54+00:00
Seriously.

Binary search is one of the first things you learn in algorithms, and in a well-managed branch the commit tree is already a sorted straight line, so it's just obvious as hell, whether or not you use your VCS to run the bisect or you do it by hand yourself.

"Hey guys, check it out! Water is wet!"
by firstplacelast | 2025-11-02 18:49:55+00:00
Might be wrong about this, but being so far removed and seemingly immunologically resistant is exactly what makes it a dangerous combination. Viruses mutate and recombine at an astonishing rate, so 99.9999% (?) of viral entities won't be able to make the jump between these species, but the one that can might have devastating consequences as it will be wildly different from anything that has infected rats before (and from there it's more likely to infect other mammal populations).

The more exposure between these populations the higher the likelihood that a crossover event occurs.
by carbonguy | 2025-11-02 18:50:14+00:00
This post resonated with me, as it seems to have done with many of us. My way out of the prison was giving up on "cattle not pets" - I had to acknowledge that I will never, ever need the ability to spin up or spin down a herd of containers or automatically configure a thousand of anything or whatever is understood by the "cattle" archetype. I've got the handful of services that I care about, running based on manual configurations, which I don't even bother to back up - and the hobby has remained fun!
by hammock | 2025-11-02 18:50:20+00:00
> I think you're forgetting to control for the fact that the former would be severely punished for doing so, and the latter would be severely punished for not doing so?

That’s interesting and I think it’s more complicated. Here are some half-finished thoughts:

I imagine a grunt soldier would indeed be more likely to follow an order to nuke the world than a general would be to issue the order/push the button- and part of this is because the punishment for the grunt would be much greater, where the general is afforded more latitude in decision making.

However, the grunt may have volunteered to submit to the potential punishments, having signed a contract with the army. He made a choice in that regard.

If you want to be able to make your own decisions (e.g. choose NOT to drop the bomb when ordered) you have to have power to defend against “punishment” or unwanted consequences imposed by others. For a grunt, this might look like physical ability to defend themselves (2nd amendment comes to mind) , or economic independence via a homestead, or something else.

Interesting to think about.
by pantalaimon | 2025-11-02 18:50:22+00:00
I just upgraded my Ubuntu to the new version with Rust written Coreutils - this is insane

% size /usr/bin/ls text data bss dec hex filename 10086795 731540 2104 10820439 a51b57 /usr/bin/ls % ls -sh /usr/lib/cargo/bin/coreutils/ls 11M /usr/lib/cargo/bin/coreutils/ls % du -sh /usr/bin 1.5G /usr/bin
by QuercusMax | 2025-11-02 18:50:22+00:00
Reviewing individual changes that may not even build properly is a waste of time; reviewing thousands lines of lines at once is also a bad idea.

Each unit of code (PR, commit, CL, whatever you want to call it) you send for review should be able to stand on its own, or at the very least least not break anything because it's not hooked into anything important yet.
by lrvick | 2025-11-02 18:50:58+00:00
Efforts pop up every once in a while, usually with no results. As I said elsewhere, if they actually pull it off this time then my tone changes to one of willingness from my team and I to put in the work to use these efforts to support deterministic multi-signed builds in stagex.

It would make GHC (and pandoc) something we could have in tree which would be awesome. I am just annoyed it seems like such a low priority.
by matthewdgreen | 2025-11-02 18:51:00+00:00
With due respect, that problem is on CBP. I am somewhat (albeit decreasingly) sympathetic to the unique challenges that immigration enforcement agencies face in the US. We live in a country where the citizens have decided democratically that no US citizen will ever have to carry proof of US citizenship, and moreover, that national ID and standardized proof-of-citizenship passports should not even be mandatory for citizens to possess, let alone carry. We even decided that the Federal Government should be explicitly banned from creating those forms of ID.

We made these decisions for various reasons, but broadly because the voters felt that US citizenship and lawfullness should be presumptions, rather than something you had to prove in order to enjoy your rights as a citizen.

For an immigration agent, this is really tough. You have to identify unauthorized immigrants in an environment where you can't just require lawful citizens to carry ID or proof of citizenship. You legally can't arrest or (more than briefly) detain a US citizen for failure to carry citizenship documents. You have to walk on eggshells even with actual unauthorized immigrants, to avoid violating the law. And our proof-of-identity document systems are deliberately decentralized and unreliable, so you can't just check a master database. It's a tough problem!

But that's the way the cookie crumbles. We designed our society to make this kind of "papers please" enforcement difficult, which means that immigration enforcement needs to be smarter and more savvy, or else we need to actually change the laws. What ICE and CBP are trying to do now is just to ignore the law, and that doesn't work. Citizens' built this law to protect their rights; you can't just take away those rights because CBP have a tough job.
by throwaway894345 | 2025-11-02 18:52:11+00:00
> But as I mentioned above, that makes the system more complicated for people who don't need it to be distributed. Setting up separate db software, configuring the connection, handling separate updates, etc. is a lot more work for most users than Jellyfin just using a local embedded sqlite database.

You can package a Postgres database with your app just like SQLite. Users should not have to know that they are using Postgres much less configuring connections, handling updates, etc.

> And it would probably make the application code more complicated as well.

Not at all, this is an article about the hoops the application has to jump through to make SQLite behave well with parallel access. Postgres is designed for parallel access by default. It’s strictly simpler from the perspective of the application.
by rectang | 2025-11-02 18:52:45+00:00
You're in luck! For you, there is `git diff`.

(And for me as well — both the individual commits and the PR-level summary are useful.)

So, those of us who prefer commit-sized chunking don't have to do anything special to accommodate your preference.

It doesn't go the other way, of course, if you present one big commit to me. But so long as your code is well-commented (heh) and the PR isn't too huge (heh heh) and you don't intersperse file renamings (heh heh heh) or code formatting changes (heh heh heh heh) which make it extremely difficult to see what you changed... no problem!
by Esophagus4 | 2025-11-02 18:53:09+00:00
There is no alternative.

So you may not think they’re predictive of success, but you should see how much less predictive everything else is.

Hiring is always a risk. It will never be a perfect science.

That’s why it’s important to have a quick off-ramp for those who aren’t working out.

Edit: BTW, where did you see Google saying their interview process doesn’t work? Other than some a few anonymous devs venting on HN, the company still uses coding interviews as critical to their process. You will always find a few complainers, but the fact that one of the world’s top software shops still uses it says what needs to be said.
by lukan | 2025-11-02 18:53:13+00:00
"And my evidence for it is that the trendline clearly shows the rate of improvement for pictures is happening at a rate which clearly shows it will produce pictures that will be indistinguishable."

Are you aware of the advancements in Astronomy for example? Made possible by ever increasing sensor tech.

So ... if you say, AI pictures might get soon to the point, where they are indistingushable from a ordinary mobile phone camera - then I would say maybe, but I really doubt it will be in 5 years.

But when you say sensor data in general will be indistinguishable from AI generated ones, then I disagree.
by neom | 2025-11-02 18:53:39+00:00
high mutation rate != high crossover rate, and immunological resistance != susceptibility to novel evolution. (it's actually the other way around)

Also to be super clear, I'm not saying rats are immune to bat viruses, I'm just saying in reality it's is too divergent for functional crossspecies transmission and both rats and bats already have their own established, evolved coronavirus ecosystems that solve the same problems (like furin cleavage above). It seems to me near impossible it could actually happen.
by bigbadfeline | 2025-11-02 18:54:04+00:00
> Energy prices have risen roughly at the rate of CPI since 2022, perhaps we got used to the relatively flat prices for the previous decade:

That statement seems to be upside-down. Energy factors into the cost of almost every other product, that is, the rise of energy prices causes much of the inflation elsewhere, which is then reflected by the CPI.

Also notice, 2022 is when the data-center and AI boom started, that too fits the premise of their culpability.

But then we live in a bizarre world where inflation is good, and the price of everything rising together is just wholesome and natural.
by bigyabai | 2025-11-02 18:54:27+00:00
One really has to wonder where their hundreds of billions of dollars go, if not researching and designing replacements for their weakest products.

- Give iPad basic windowing capabilities, but still don't let it do anything more than an iPhone

- Design rackmount Apple Silicon Mac with PCI, but don't support Nvidia cards or datacenter software

- Redesign Siri with a modern Apple Intelligence facelift, but run the inference on Google TPUs

It's like they have an allergy to competitive markets or something. I'd expect this behavior from Microsoft, from Apple it's just pathetic.
by ethmarks | 2025-11-02 18:54:44+00:00
You've convinced me. I did not consider the human cost of producing training data, I did not consider whether or not LLMs were actually saving effort, and I did not consider the extra effort to verify LLM output. I have nothing more to add other than to thank you for taking the time to write such a persuasive and high-quality reply. The internet would be a better place if there were more people like you on it. Thank you for making me less wrong.
by throwaway894345 | 2025-11-02 18:55:46+00:00
Maybe that’s what most users want, but that’s not what the software was designed to target, judging from all of the documentation and marketing. But yes, clearly the software wasn’t designed to run in a distributed fashion, and that’s kind of the point of my criticism—they had to go out of their way to couple their application in a way that precludes distributed execution. Well designed server software is trivial to distribute, and even if you never run it in a distributed configuration it makes it easy to do the basic parallelism described in this article.