MurphyA/hacker-news huggingface dataset:
by atleastoptimal | 2025-07-15 07:44:39+00:00
AI is being framed as the future because it is the future. If you can't see the writing on the wall then you surely have your head in the sand or are seeking out information to confirm your beliefs.

I've thought a lot about where this belief comes from, that belief being the general Hacker News skepticism towards AI and especially big tech's promotion and alignment with it in recent years. I believe it's due to fear of irrelevance and loss of control.

The general type I've seen most passionately dismissive of the utility of LLM's are veteran, highly "tech-for-tech's sake" software/hardware people, far closer Wozniak than Jobs on the Steve spectrum. These types typically earned their stripes working in narrow intersections of various mission-critical domains like open-source software, systems development, low-level languages, etc.

To these people, a generally capable all-purpose oracle capable of massive data ingestion and effortless inference represents a death knell to their relative status and value. AI's likely trajectory heralds a world where intelligence and technical ability are commodified and ubiquitous, robbing a sense purpose and security from those whose purpose and security depends on their position in a rare echelon of intellect.

This increasingly likely future is made all the more infuriating by the annoyances of the current reality of AI. The fact that AI is so presently inescapable despite how many glaring security-affecting flaws it causes, how much it propagates slop in the information commons, and how effectively it emboldens a particularly irksome brand of overconfidence in the VC world is preemptive insult to injury in the lead up a reality where AI will nevertheless control everything.

I can't believe these types I've seen on this site aren't smart enough to avoid seeing the forest for the trees on this matter. My Occam's razor conclusion is that most are smart enough, they just are emotionally invested in anticipating a future where the grand promises of AI will fizzle out and it will be back to business as usual. To many this is a salve necessary to remain reasonably sane.
by Joker_vD | 2025-07-15 07:45:21+00:00
The tl;dr is that Postgres, as any long-running "server" process (especially as a DBMS server!) does not run with SIG_DFL as the handler for SIGTERM; it instead sets up the signal handler that merely records the fact that the signal has happened, in hopes that whatever loops are going on will eventually pick it up. As usual, some loops don't but it's very hard to notice.
by idiocrat | 2025-07-15 07:45:45+00:00
Do we still need program source code?

One idea would be not to have the code as the result of your prompt, but the result itself.

Why not to let the environment do everything integrated, according to your prompt?

Else you have the disconnect between the prompt and the generated code. The generated code need to run somewhere, need to be integrated and maintained.

That stringdiff function is a part of the bigger environment.

So ultimately you should just be able to request your assistant to make sure all the work assigned to you is done properly, and then the assistant should report to the original requestor of the work done.
by tankenmate | 2025-07-15 07:46:03+00:00
I have a parallel to suggest; I know it's the rhetorical tool of analogous reasoning, but it deeply matches the psychology of the way most people think. Just like getting to a "certain" number of activated parameters in a model (for some "simple" tasks like summarisation) can be as low as 1.8 billion, once that threshold is breached the "emergent" behaviour of "reasonable", "contextual", or "lucid" text is achieved; or to put this in layman's terms, once your model is "large enough" (and this is quite small compared to the largest models currently in daily use by millions) the generated text goes from jibberish to uncanny valley to lucid text quite quickly.

In the same way once a certain threshold is reached in the utility of AI (in a similar vein to the "once I saw the Internet for the first time I knew I would just keep using it") it becomes "inevitable"; it becomes a cheaper option than "the way we've always done it", a better option, or some combination of the two.

So, as is very common in technological innovation / revolution, the question isn't will it change the way things are done so much as where will it shift the cost curve? How deeply will it displace "the way we've always done it"? How many hand weaved shirts do you own? Joseph-Marie Jacquard wants to know (and King Cnut has metaphorical clogs to sell to the Luddites).
by Qwertious | 2025-07-15 07:46:58+00:00
https://www.youtube.com/watch?v=zhr6fHmCJ6k (1min video, 'Elon Musk's broken promises')

Musk's 2014/2015 promises are arguably delivered, here in 2025 (took a little more than '1 month' tho), but the promises starting in 2016 are somewhere between 'undelivered' and 'blatant bullshit'.
by kukkeliskuu | 2025-07-15 07:47:24+00:00
This has been my experience as well with almost all frameworks.

It goes like this: the framework helps with the initial progress, because framework works with the more typical use cases. This allows you to "prototype" the solution and show progress to potential users etc.

But then you have a specific use case that does not fit the model of the framework, and you will end up going around the limitions of the framework. You often end up spending more time that you saved with the initial implementation.

My experience with core Django is that it has so many hooks and ways to inherit functionality, that it is extremely rare to end up with such problems. But it still means you need to learn when to use what feature, and how to structure your solution. I had to learn this through painful experience. I am still making mistakes, such as the "single-file status page app", a mistake which cost me several hours of productive coding. That might not sound like much, but when working full-time and running several side projects, few productive hours is extremely costly.

Most third party Django apps, even the popular ones, suffer from the framework problem, however. For example, I have have had to rewrite django-ads and django-distill, because their structure was limiting me from implementing features I needed. I just ditched django-formset as well.

I believe the reason for the limitation is that these third party apps have not been exposed to enough use cases and users to overcome the framework problem.
by QRY | 2025-07-15 07:48:12+00:00
The culpability we share for "churning out shitty code" is spot-on imo. There's been so much incentive to shipping "good enough", that even the definition of "good enough" has been backsliding. Sometimes even to the point of "whatever we can get away with", in the name of speed of delivery.

That friction has always been there, in my experience. But this is the first time I'm seeing it happening around me. LLM's are so divisive, and yet the more extreme positions on either side seem to be digging their heels in, as if the tech is not in flux.

Maybe we need a little Cave Johnson energy: https://www.youtube.com/watch?v=Dt6iTwVIiMM
by iamflimflam1 | 2025-07-15 07:48:13+00:00
I will tend to do make the schematic. I’ll use labels for most connections from the mcu to any peripherals.

On the PCB, the most critical thing to my mind, is component placement. I’ll do that before any wiring up and then use that to determine the most sensible GPIO pins to use.

For the routing I’ll modify the pins used to make it easier/simpler.

It’s definitely an iterative process with a lot of back and forth between schematic and PCB.

The nice thing with the flexibility of the GPIOs is that I don’t need to do much upfront design. I’ll just label pins up in the schematic and if needed tear it up and redo.

The real trick in the schematic is not “wiring” all the connections up. Just use labels that are easy to move around.
by MaxikCZ | 2025-07-15 07:48:16+00:00
The thing is that the spacetime around blackholes get curved to the actual extremes.

When we imagine flying "at nearly the speed of light" towards something thats traveling the same speed towards you, we tend to imagine a collision at high speeds.

But for blackholes that turn space into time and time into space, they can see the other blackhole slowing to a complete stop as its about to touch. Or it can look differently, it all depends on the position and speed of an observer.

We cant even agree on the basics like: "It doesnt matter how it looks, but they must collide", since if we look at something falling into a blackhole (which I pressume could be another blackhole just as well), we see it slow towards 0 at the edge and fade away in redshift instead of seeing it actually fall trough.

Its just all very weird and unintuitive stuff.
by blixt | 2025-07-15 07:49:22+00:00
Yeah ultimately it depends on the problem. Reading an article like this, it's easy to conclude that the context should always be reduced, all context relegated to a vector database[1], and retrieved on demand such that the context is as small as possible. Seeing it makes me want to refer to situations where conversely growing the context helps a lot to improve performance.

It really depends on the task, but I imagine most real world scenarios have a mixed bag of requirements, such that it's not a needle-in-a-haystack problem, but closer to ICL. Even memory retrieval (an example given in the post) can be tricky because you cannot always trust cosine similarity on short text snippets to cleanly map to relevant memories, and so you may end up omitting good data and including bad data (which heavily skews the LLM the wrong way).

[1]: Coincidentally what the post author is selling
by 6P58r3MXJSLi | 2025-07-15 07:50:18+00:00
> Just because the rules are complex and full of exceptions doesn't mean there's no sense

That's exactly what "makes no sense" means, actually.

> demonstrated that English is compressible

of course it is

> which means there must be some patterns

Of course there are. Patterns are (almost) everywhere - even PI is normal, but not random - but patterns in English make little or no sense for a language born and developed among, in the same era and having close contact with, a lot of other much more regular languages. The two facts are orthogonal.

Even Sumerian is more regular than modern English...
by fzeroracer | 2025-07-15 07:50:59+00:00
> However if you can quickly read code, see and succintly communicate the more optimal solution, you can easily 10x-20x your ability to code.

Do you believe you've managed to solve the most common wisdom in the software engineering industry? That reading code is much harder than writing it? If you have, then you should write up a white paper for the rest of us to follow.

Because every time I've seen someone say this, it's from someone that doesn't actually read the code they're reviewing.
by eru | 2025-07-15 07:52:02+00:00
I don't know about VBA, but spreadsheets actually delivered (to a large extent) on the promise that 'everyone can write simple programs'. So much so that people don't see creating a spreadsheet as coding.

Before spreadsheets you had to beg for months for the IT department to pick your request, and then you'd have to wait a quarter or two for them to implement a buggy version of your idea. After spreadsheets, you can hack together a buggy version of your idea yourself over a weekend.
by aaron695 | 2025-07-15 07:53:49+00:00
The flocking is interesting.

This is how Vantablack (OMG evil) and the funny cunts like Black 4.0 who fought back works... in my head. They are carbon nano-tubes.

I bought Musou Black from Japan online, it wasn't a crazy price. They do get damaged if touched and do have some hazards .

Any who, cool video, I sent it to my telescope nerd friends. It's nice to be iteratively improving things. It's a great way to save money and understand the tech before you might buy a more expensive model.
by 6P58r3MXJSLi | 2025-07-15 07:55:08+00:00
> "somewhat similar but different"

about accents, see my examples. they are used to disambiguate, which is a bonus in itself.

> If "ch" always meant the same thing, it would be just fine.

that is my take too: in German you have ss and ß, for historical reasons, but both sound the same and have a predictable pronunciation, always.
by therealpygon | 2025-07-15 07:55:36+00:00
In a code editor or the website? Coding using the website has distinct disadvantages, imo.

But yeah… Arguing with an LLM is never worthwhile. If it doesn’t (mostly) work the first time, roll back and start over with a better prompt. This is because there is a big element of randomness (seed) that causes every run to potentially be different, ranging from slight to drastic. Basically, you can get junior dev who should be fired one time, and a senior engineer the next. Start over, improve the prompt/context/plan, run it again. E.g. there is a reason the Copilot in-line editor has that little try again button right there; because you should use it, same with entire prompts—hence the reason the up arrow in VS Code Copilot gives you back your last prompt.

Also, lots of times it means it just doesn’t have the right context to pull from (or too much, or not useful, depending on the model). Small well-defined tasks are almost always better. Documentation in an LLM readable/searchable format can be highly beneficial, especially API references for libraries that are well organized, or things like Context7 MCP if the library is recent or can be parsed correctly by C7. Expecting a general knowledge LLM to be an expert in every language/library or to just intuit correctly from the library sources hasn’t ever worked out well in my experience (unless it is a small library).

At least that’s my 2 cents if you’re interested. Hope it is helpful (to someone).
by cess11 | 2025-07-15 07:56:44+00:00
People aren't generally able to keep up the discipline to time when to pass on tickets to hide changes in their ability, unless it's forced by a constant anxiety.

Developers are also not very good at estimating how long something is supposed to take. If there was even a 10% jump in profitability in the software department it would have been obvious to bean counters and managers. You'd also see a massive recruitment spree, because large organisations ramp up activities that make money in the short term.
by vidarh | 2025-07-15 07:56:53+00:00
Proper coding agents can easily be set up with hooks or other means of forcing linting and tests to be run and prevent the LLMs from bypassing them already. Adding extra checks in the work flow works very well to improve quality. Use the tools properly, and while you still need to take some care, these issues are rapidly diminishing separately from improvements to the models themselves.
by dwattttt | 2025-07-15 07:57:41+00:00
It depends on how much of a program actually triggers the failure case, so you can't answer in the abstract.

In the worst case, ~every memory access causes the kernel to need to fix it, causing every memory access to be several orders of magnitude worse (e.g. a hot cache hit vs trapping into kernel, wiping caches, at the very least hundreds more accesses).

EDIT: I see you suggested remapping the page permissions. Maybe that helps! But maybe it adds the cost of the remapping onto the worst case, e.g. the first 4kb are instructions that write into the second 4kb.
by Cipater | 2025-07-15 07:58:21+00:00
The FDA approved an average of 47 new drugs annually from 2015 to 2024.

A few notables.

Ekterly (sebetralstat) – Treats hereditary angioedema (approved July 3, 2025)

Zegfrovy (sunvozertinib) – For NSCLC with EGFR exon-20 insertion mutations (July 2, 2025)

Widaplik (amlodipine + indapamide + telmisartan) – Single-pill hypertension therapy (June 5, 2025)

Tryptyr (acoltremon ophthalmic) – First in class dry-eye treatment (May 28, 2025)

mNEXSPIKE – Next-gen Moderna mRNA COVID-19 vaccine (May 30, 2025)

Emrelis (telisotuzumab vedotin) – Lung cancer (NSCLC) targeted therapy (May 14, 2025)

Yutrepia (treprostinil inhalation) – For pulmonary arterial hypertension (May 23, 2025)

Brekiya (dihydroergotamine autoinjector) – Acute migraine and cluster headache therapy (May 14, 2025)

Gomekli, Journavx, Grafapex, Datroway – Novel agents in oncology and pain management (early 2025)

Opzelura (ruxolitinib cream) – For vitiligo and atopic dermatitis (2022–2023)

Cobenfy (KarXT) – New schizophrenia medication targeting cholinergic receptors (Sept 2024)

Tarlatamab (Imdelltra) – First in class BiTE immunotherapy for small-cell lung cancer (May 2024)

Pegcetacoplan (Empaveli/Syfovre) – First complement C3 inhibitor for PNH & geographic atrophy (May 2021)

Leniolisib (Joenja) – First treatment for APDS immune deficiency (March 2023)

Nedosiran (Rivfloza) – siRNA therapy for primary hyperoxaluria (Sept 2023)

Retifanlimab (Zynyz) – PD-1 antibody for Merkel cell carcinoma (March 2023)

Are you aware of any of these?
by 20k | 2025-07-15 07:58:56+00:00
These kinds of simulations inherently cannot model the singularity accurately whatsoever. At the singularity, the numerical technique used becomes knowingly invalid

In fact, the entire interior of the event horizon is actually physically invalid in these simulations. The formalisms used trap the errors inside the event horizon, as the errors turn out to be strictly causal. And because of that, theoretically they can't escape

Of course that analysis breaks down in the face of discretisation, so errors tend to leak out a bit under low resolutions, so you have to handle things pretty careful. Either way, you shouldn't draw any conclusions about the interior

Source: I've done a lot of these simulations
by Someone | 2025-07-15 07:59:28+00:00
IP infringement, not copyright violation.

A clean room reimplementation of cuda would avoid any copyright claims, but would not necessary avoid patents infringement.

https://en.wikipedia.org/wiki/Clean-room_design:

“Clean-room design is useful as a defense against copyright infringement because it relies on independent creation. However, because independent invention is not a defense against patents, clean-room designs typically cannot be used to circumvent patent restrictions.”
by nosianu | 2025-07-15 08:00:12+00:00
Funny you use something the author of the linked post talks about at the start. This is one of those debate methods. Reframe what was said!

I don't remember that the OP claimed that all problems are solved, perfectly. Do you think by showing examples where AI struggles you really show their point to be wrong? I don't see that.

I use AI only sparingly, but when I do I too experience saving lots of time. For example, I'm only superficially familiar with MS Excel or Power Query scripting APIs and function names. Too bad I've become the got-to point for little mean problems for colleagues. Instead of having to read lots of docs and do lots of trial and error, I now formulate what I want to ChatGPT, give it the file, and thus far I have always received the solution, a transformed file. Sure, anyone regularly using Excel/Power Query could have written the few lines of code easily enough, but since I don't, and don't plan to, being able to use plain language and let the AI do the actual coding is a huge time saver.

For SOME problems in this world it works. Nobody claimed anything you seem to be trying to argue against, that it solves ALL problems, so that finding one or a few counter-examples where it fails invalidates the argument made. And the problems it does solve are not trivial and that it works is quite miraculous and was not possible before.
by TeMPOraL | 2025-07-15 08:01:27+00:00
> It doesn't mean “AI is the new electricity.” (actual quote from Andrew Ng in the post).

I personally agree with Andrew Ng here (and I've literally arrived at the exact same formulation before becoming aware of Ng's words).

I take "new electricity" to mean, it'll touch everything people do, become part of every endeavor in some shape of form. Much like electricity. That doesn't mean taking over literally everything; there's plenty of things we don't use electricity for, because alternatives - usually much older alternatives - are still better.

There's still plenty of internal combustion engines on the ground, in the seas and in the skies, and many of them (mostly on extremely light and extremely heavy ends of the spectrum) are not going to be replaced by electric engines any time soon. Plenty of manufacturing and construction is still done by means of hydraulic and pneumatic power. We also sometimes sidestep electricity for heating purposes by going straight from sunlight to heat. Etc.

But even there, electricity-based technology is present in some form. The engine may be this humongous diesel-burning colossus, built from heat, metal, and a lot of pneumatics, positioned and held in place by hydraulics - but all the sensors on it are electric, where in the past some would be hydraulic and rest wouldn't even exist; it's controlled and operated by electricity-based computing network; it's been designed on computers, and so on.

In this sense, I think "AI is a new electricity" is believable. It's a qualitatively new approach to computing, that's directly or indirectly applicable everywhere, and that people already try to apply to literally everything[0]. And, much like with electricity, time and economics will tell which of those applications make sense, which were dead ends, and which were plain dumb in retrospect.

--

[0] - And they really did try to stuff electricity everywhere back when it was the new hot thing. Same with nuclear energy few decades later. We still laugh at how people 100 years ago imagined the future will look like... in between crying that we got short-changed by reality.
by junon | 2025-07-15 08:01:30+00:00
Performance, safety and IO critical code must care, because the page size affects TLB caching and is the finest granularity for security flags such as read-only, no execute, etc. which are critical for e.g. guard pages.

If your code that created two guard pages sandwiching a security critical page to make sure that under/overruns caused a page fault and crashed that assumed the boundary was at 4KiB, but is really now at 16KiB, that means that buffer overruns now will not get caught.

Further, code that assumed it was on a page boundary for some reason, for performance reasons, will now have only a 25% chance of being so.

It also means that MMIO physical pages that were expected to be contained within a 4KiB page such that when mapped into a sensitive user space driver context, neighboring MMIO control blocks wouldn't be touched, might be affected too since you'll get up to 3 neighboring blocks in either direction. This probably doesn't happen so often, I don't know Android internals much, but still something to consider.

This is in large part because PAGE_SIZE in a lot of C code is a macro or constant, rather than something populated at runtime depending on the system the code is running - something I've always felt is a bit problematic.

That being said, code that's hard coding PAGE_SIZE won't run anyway if using e.g. mmap() because it validates the page size and will error on mismatch.

This is going to wreak general havoc for a while no matter how you spin it.
by remram | 2025-07-15 08:01:54+00:00
I don't know what you are talking about. Many licenses don't mention trademark issues at all, that doesn't mean they grant you the right to use the trademark.

"Not mentioned at all" does not mean you can do it. Licenses do not restrict, they permit, from a default of "you may not use my stuff".

The license text could also say "you may not break into my house". That would not make it a "narrowing of rights", and that doesn't mean other licenses implicitly grant you the right to break into the software author's house if you use their software.