VSCode will be used by plenty of non-AI-using developers, and the credential harvester is not specific to AI API tokens, but that 3/4 of the targets are AI coding tools is I assume where the claim comes from.
> It's fairly clear that the current design (by which I mean the entire concept of the deep neural network) has its limits
Maybe, but people have been saying deep learning is about to hit a wall since 2012, and many reasonable-sounding "machines fundamentally can't do X" have since fallen.
Feels like we're standing on a roof with floodwater up to our ankles - maybe it stops rising now, but we didn't foresee it getting anywhere near this high in the first place.
I do agree that progress will probably be more slow/gradual than others seem to predict, no "hard takeoff", but even being decades away is still relevant to someone starting a career in software development.
Price of the current frontier may vary, but price for a given level of capability tends to drop pretty fast.
April of last year you'd get 1431 ELO[0] from o3-2025-04-16 for $8.00 per million output tokens. April of this year you can get 1436 ELO from deepseek-v4-flash for $0.2 per million output tokens.
Sure, but i don't think it's reasonable to hold given level of capability constant in a landscape where a give consumer of AI also has competitive pressures.
I can't use last year's SOTA model when my competitors can use the current SOTA model.
This is also baked in the eye watering valuations of model companies.
> I can't use last year's SOTA model when my competitors can use the current SOTA model.
Lots of people can. Tools don't need to be top of the line to be useful. Snap-on may exist, but they don't put Harbor Freight out of business.
Advanced IDEs exist but complex projects were still built in vim.
The more capable the budget models get, the lower the marginal gains from using the frontier models, even if the frontier models always stay 6 months ahead.
etiam's right that "in Israel and possibly other middle east countries" wouldn't fit onto the HN title, which is relevant to raincole's clickbait accusation. The original Github issue title fits, but that doesn't specify "Valve" or the timeframe.
Not that it'd be particularly hard to reword to fit all information. Feel like things are getting unnecessarily agitated ("You've been here long enough to understand", "you can't stand to be wrong", "Bro was never more glad there's anonymity on the internet", etc.) for no real reason.
I can only assume that mob of fresh accounts is sockpuppets meant precisely for trying to stir up conflict and detract from discussion of the actual topics raised by a story like this. Sorry if I accidentally gave them opportunity for more oxygen than necessary.
smlen would be 0 for both if there are no small numbers, so end result of both is an empty array.
For the first version small_numbers[0] will contain an arbitrary value at the end, and for the second version it happens to contain the last number read, but that address is outside of the 0-length array being returned.
Performance, clipboard behaviour, and file browser persistence seem like fairly typical OS-specific issues. Obviously not great if they're not properly testing macOS, but I don't think it's an "even bigger red flag" for those to be OS-specific.
Grouping close-together changes of the same control for undo sounds probably intentional to me, like how Ctrl+Z in a textbox doesn't go one character at a time, and if I move something with arrow keys I'd expect that to be one "movement" once I stop rather than one per key repeat. Whether it's grouping too aggressively to the point of being recognized as an issue is probably down to personal preference, though I would lean towards agreeing that less grouping would be better.
> Grouping close-together changes of the same control for undo sounds probably intentional to me
I explained how it happens. Intentional or not, it just takes us between buggy software and poorly designed software and even then losing changes (not all of what is undone is redone and you are left in an inconsistent state) remains a bug.
> Ctrl+Z in a textbox doesn't go one character at a time
Retyping text is not comparable to readjusting different fine color controls on different pages of the UI across different nodes.
By comparison, the aforementioned RawTherapee (despite being powered by Qt and looking pretty barren) in fact works more reliably with no such issues, and it’s also cross-platform software that is free to boot.
> The aforementioned RawTherapee has no such issues
I don't mean to claim that the mentioned issues are unavoidable or that some piece of software is more likely than not to have these issues, just that when there are OS-specific issues it's this kind of thing I expect. Clipboard handling is pretty much an entirely different implementation on each platform unless you're using something like Electron that already handles it for you, for instance.
There’s no use case for system clipboard, given it’s a monolithic piece of software that doesn’t allow multiple projects to be simultaneously open in different instances. There’s nowhere else to paste except the same window.
Meanwhile, open-source, non-Electron, multi-platform software that handles copy-paste via system clipboard exists just fine (VCV Rack comes to mind).
There are many things it makes sense to copy/drag-drop between applications. There are cases where you might not need to, but using the system clipboard is still common.
> Meanwhile, open-source, non-Electron, multi-platform software that handles copy-paste via system clipboard exists just fine (VCV Rack comes to mind)
VCV Rack seems to just use GLFW to handle it, but again I'm not claiming these issues are unavoidable or more likely than not to occur. For any given issue with some software, 99% of other software will not have that same issue.
This starts to look like a waste of time and not a useful discussion. There are frameworks and libraries that handle 100% of clipboard OS specifics, and the app in question has no use for system clipboard in the first place. In my experience the app is buggy and a pain to use relative to other software, that’s the entirety of my point.
> There are frameworks and libraries that handle 100% of clipboard OS specifics
They're sufficient in many cases, but you'll still sometimes need the control of working with COM/etc. directly, and those libraries don't fully save you from platform-specific bugs (e.g: https://github.com/glfw/glfw/issues/2644).
> the app in question has no use for system clipboard in the first place
What do you expect to happen when you copy some text from an external editor into a text field?
The big water usage numbers are always from including hydropower (as this report does, mentioned on page 34), so most of the water just continues on into the sea.
> Except that the same shit happens on ubereats/instacart/doordash driver apps where basically everything is self-serve [...]
That the password-reset was self-serve yet made up 80% of calls was Sohcahtoa82's point. Users that only call in unusual/exceptional circumstances can, by their nature, make a small minority of calls despite being the majority of users.
I don't think you read my comment correctly, or misunderstood something.
The entire experience of fulfilling an instacart batch is a series of self-serve interactions; anybody who struggles with the basics won't be finishing the background checks to get started with the app, let alone completing enough batches to get out of new-user jail.
It is not an uncommon occurance for someone to order a single thing, and that thing to be out of stock, but such a scenario requires dancing with the llm every time before finally getting to a human where you can start the process of getting an impossible-to-complete order cancelled.
Security scanners won't be "manual in-depth analysis of all new code" or "Just running and seeing it do things", but somewhere in-between - utilizing static analysis/machine learning. It's a cat-and-mouse game, but the attacker adding code that waits X days to run something obfuscated would be another pattern that they could look for.
I think these attackers are unlikely to add a delay in the first place because the chance of their attack being found out before it activates would be too high. They seem to generally work on the assumption that they have a day or so before the package is yanked (e.g: from maintainer noticing their account is compromised) so need to move fast.
Security scans and authors realizing an unauthorized version was pushed will generally happen regardless of whether regular users updated. Even for compromises that are found by users updating, it'd generally be better to reduce the number of people affected with a slow roll-out rather than everyone jumping on at once.
VSCode will be used by plenty of non-AI-using developers, and the credential harvester is not specific to AI API tokens, but that 3/4 of the targets are AI coding tools is I assume where the claim comes from.
reply