oefrha

If AI coding isn’t lowering your code quality, you have a low starting point.

I want to take this seriously, but eight (slop?) rehash of the story on the blog isn’t helping with credibility. Pro tip: don’t do that, however triggered you are, it definitely doesn’t help.

I don’t use Google AI Studio so can’t verify, good luck.

I’ve also seen people put a lot of effort and love into poster and stuff because that interests them (doesn’t mean they’re good at it either), then the event is utter crap because they didn’t spend much time on the actual event.

I fail to see how I’m “dissing AI”. I use it almost every fucking waking hour after all, both professionally and personally. I just don’t pretend it’s free/cheap (especially when you mention it in the context of “everyone only the planet”), or even more ridiculously, some charitable gift from Big (AI) Tech to the world. And if you look into my comment history I’m pretty clear I support IP free-for-all; cat’s out of the bag, just don’t talk two-faced nonsense like “distillation attacks” and I’m fine with it. And as a prolific open source contributor with popular projects, including at least one under GPL, they definitely stole from me—again, fine with it.

I’m paying $200/mo for non-crap versions of said “general-purpose problem-solver tool”, which is not far from the median income of “everyone on the planet with Internet connection”. And I’m told I’m already getting a huge discount by using thousands of dollars of compute by raw API pricing. That just doesn’t sound like peanuts at all.

Btw there are so many "critical" vulnerabilities in libheif I can't even tell if I have them all patched. Just awesome.

https://github.com/strukturag/libheif/security/advisories?qu...

https://ubuntu.com/security/notices/USN-8649-1

https://ubuntu.com/security/notices/USN-8683-1

https://ubuntu.com/security/notices/USN-8774-1

They did say how:

> We then placed Claude in an autonomous /goal loop against our own Discourse Cloud instance, proxied through rce.ee/ctf-forum to make it look like a CTF target as Opus refused write exploit for remote instances.

Unsandboxed ImageMagick is known for being a security nightmare even back when PHP ruled the world (not saying sandboxing is a panacea either, it just requires a different and potentially harder exploit to develop a full chain). Difference is it's easier than ever to turn vulnerabilities into full compromises. At some point we'll have to replace all parsers with something at least as safe as https://github.com/google/wuffs right? Otherwise ImageMagick and co. will just keep giving.

Kudos for at least admitting upfront that it’s pure slop, I guess.

The quota consumption is based on the upfront possible number of connections given the query, not actual connections, so deeply nested queries can be very expensive if not aware and careful about it.

Got acquired => got paid. CSS-Tricks the entity (up to the point of acquisition) got paid the money. If and how the money was divided between the people involved doesn’t seem be public info.

In this case CSS-Tricks got paid $4m first, so probably the wrong entity to be complaining about funding. But maybe the lead editor in question who’s not the creator didn’t see much of that?

This is certainly not just affecting interim releases. Ubuntu 26.04.1 has been released but is currently held back from do-release-upgrade for the LTS channel (which IIRC is unusual for a LTS's .1 release) due to rust-coreutils issue:

> Users of Ubuntu 24.04 LTS will be offered an automatic upgrade to 26.04.1 LTS via Update Manager a couple of weeks following this release after some planned backports to address regressions in a recent version of rust-coreutils.

https://discourse.ubuntu.com/t/ubuntu-26-04-1-lts-released/8...

Given that Safari needs the most debugging and automation tooling for Safari was hardest to come by, this is a welcome change. I wonder if it works with pages on a connected iPhone though? Anyone tried it? Because debugging on iOS Safari is the most maddening. (No, responsive design mode doesn't cut it, iOS Safari has its own special bugs that don't manifest in desktop Safari merely emulating a phone viewport.)

Not to mention my $299 total Tailwind Plus lifetime license (was TailwindUI, then paid the difference for the Plus bundle) has like 100x more stuff in it than $90/yr or $149 lifetime for—check notes—11 UI transitions...

Alternatively, it's all made up bullshit. It's not like they're gonna be sued for libel, so they can say whatever they want as long as it suits whatever narrative they're pushing at the moment. "Look at all this scary stuff! (But we definitely didn't do any real damage!)"

Flash => HTML5 was a travesty for creative little games on the web. It never recovered. Even today the authoring tools are crap for the average person with an idea, if you ignore AI vibe coding for a minute, which overcomes the tooling deficiency by being experts at the difficult tooling. (But I guess Flash => HTML5 was only a part of it, the rise of IAP everything, which was also pioneered/popularized by Apple, may have played an equal or larger role in the demise of that game genre.)

It means my mother will have it on, at least, if they use the same pattern.

So far Apple has been using default-checked checkbox during onboarding process for OS-level “help us improve…” diagnostics collection. Not sure about this specifically.

That’s fine, just let it die. But they gotta milk the goddamn IP dry.

Hear me out: if they actually worry so much about the hypothetical of AI mass killing, maybe they should first do something concrete about the reality that their models are deployed right now to kill people in a certain war-torn region of the Earth.

Whether it’s intentional requires a legal investigation to establish. Since when is “hey we didn’t mean it!” in a corporate press release enough to establish lack of intent in a criminal matter?

It's pretty damn obvious to anyone who ever bothered to look at rtk gain output, no benchmark needed at all. Agent runs

  rtk command-that-prints-100k-tokens | tail -5

costs 5 lines, maybe 100 tokens without rtk, but rtk will report 100k savings. Of course it doesn't know about that tail -5.

Worse, since rtk defaults to persisting that savings stat, it breaks sandboxing. Prefixing with rtk leads to random auto-mode denials from time to time too (this is independent of disabling savings stat persistence).

Honestly have no idea why anyone who knows the first thing about CLIs would take rtk gain seriously. I guess clueless vibe coders who has hardly ever worked in a terminal before will look at the stat and feel good about it?

That said, rtk is still mildly useful for compressing repeated test run outputs and stuff, but you should only ever use it on whitelisted commands; wrapping everything like they suggest you to do is just stupid.

These are utter bullshit that breaks every norm, but may be convincing enough for some non-academic OpenAI cheerleaders who post dozens of comments on these topics.

It’s quite amazing that in a support doc for normies, they’re literally linking to https://developers.yoti.com/identity-verification/supported-... for supported IDs which opens with

  GET https://api.yoti.com/idverify/v1/supported-documents?includeNonLatin=true

Can’t spend $10 to set up a Claude workflow to sync relevant parts of that page to a first party doc page?

> You obviously need humans

Try to contact Anthropic or Google support, they clearly don’t think so.

Have you ever counted the number of times Claude fucked up quoting/escaping and had to issue a corrected tool call? Or get stuck in some tricky quoting situation for two minutes, throwing a couple piles of shit at the wall to see what sticks. IIRC I’ve even seen it eventually using the edit tool out of frustration once.

HN is notorious for armchair <insert-topic> experts for <insert-topic> you actually know, outside of software, computing/computing-adjacent electronic hardware and startups. “Fucking wild” “confidently incorrect nonsense” is likely the norm on most fringe topics, judging by the few I know about.

No, they asked one guy to do a joint publish conditioned on leaving the other collaborator out, with veiled threats. The joint publish part smells awfully like admission of guilt given there’s absolutely no reason to do it if you believe you independently arrived at the result using only public prior work. The leaving out collaborator part is outright academic malpractice. Disclosure: I was an academic once.

This "quadratic-time performance" is incredibly disingenuous. First, it's doing n operations that are each O(n), so it's more like "can have linear time performance, but done n times so I can give you a scary title".

Edit: A charitable take is constructing a set/dict from a list is indeed a common operation so it's worthwhile to think about its complexity, but it's not really one of the standard operations when discussing the performance of a hashset/hashmap, so really shouldn't be this handwavy.

And instead of attacking some straw man "It is indeed widely believed that ..." claim (widely believed by who?), why not attack what's literally on docs.python.org? https://docs.python.org/3/library/time-complexity.html:

> dict

> The times listed for dict objects are average-case times, as they assume the hash function for the objects is sufficiently robust to make collisions uncommon. They also assume the keys are well-distributed among the set of possible keys. In the worst case, when every key hashes to the same value, each of the O(1) operations below instead takes O(n) time. They also assume that hashing and comparing a key is O(1). For more detail on the implementation, see How are dictionaries implemented in CPython?.

> ...

> set, frozenset

> See dict as the set and frozenset implementations are similar, and the same caveats apply. In the worst case, O(1) operations instead take O(n) time, and operations that look up every element degrade accordingly.

  +--------------------------------------+------------+
  | Operation                            | Complexity |
  +--------------------------------------+------------+
  | x in s                               | O(1)       |
  | Copy (s.copy()) [6] [7]              | O(n)       |
  | Add (s.add(x)) [1]                   | O(1)       |
  | Discard (s.discard(x), s.remove(x))  | O(1)       |
  | ...                                  | ...        |
  +--------------------------------------+------------+

You explicitly construct a list of ints that are all multiples of sys.hash_info.modulus and hence all hash to 0, no shit you get that well documented O(n) behavior.

The discussion of CPU cache is good though, so why hide that behind this clickbait.