I believe that's usually caused by a lot of random software deciding to hook the Windows Explorer right-click menu so it can decide whether to add menu items to it, possibly doing slow file IO and running serially with every other hook. (I blame Windows for allowing this and not making it more apparent to users what software is slowing it down.)
In theory though the new context menu should fix that since it hides shell extension options behind another submenu. Whether it's actually well optimized, I don't know
It's loaded with it to my eyes. (Pangram also agrees and flags the whole post as AI generated.)
# 2014: rqlite
The need was concrete.
# Before 2014, and alongside it
Two things deserve mention for honesty’s sake.
(the above line is extremely typical of Claude Opus 4.8 and 5.0)
[...] and the main difference is of one of packaging:
# What the twelve years show
Three things, I think.
The core was right. [...] Nobody has found a reason to stop doing it.
The design space has three corners, and they appeared in order.
(What order? The corners of this design space, which aren't spelled out until the following sentence, don't have any other natural ordering. This type of misapplied flourish feels very typical of LLMs.)
The comparisons between various projects, including between rqlite and Litestream, were interesting. (rqlite uses a consensus algorithm between nodes to keep them synced and allow changing the primary node, while Litestream just syncs itself to S3 so another node could take over with the data from there.)
I fully expected the article to get into D1 shortly and mention how that's about the same relationship between Cloudflare Durable Objects (which D1 is based on) and celld, an open source reimplementation of Cloudflare Durable Objects which writes to S3. But then the article treats D1 with a very sudden snarky disinterest, and then the final section feels very awkwardly defensive of rqlite and defeatist.
I don't think Aaronson's post is swiping at AI doomers at all. The post's one use of "doom" is to call the position that math doesn't matter and that AI will never breach the realm of true human creativity as a "doomed worldview". The post later praises Scott Alexander's argument (for taking AI x-risk seriously, a position associated with "AI doomers") against Pinker.
Deno is still an easy pick for me because of its built-in test-runner (deno test), linter (deno lint), and type checker (deno check). I've used many different npm packages for these things in previous projects and I have no idea what the new hotness and proper configuration is for all of these things in a new node project, so I really value the simplicity of Deno for it all. Also JSR and Deno for publishing Typescript libraries is still so much easier than setting up a Typescript node project and configuring it to publish compiled code, and it gets you documentation pages generated from your tsdoc comments too, which I never knew how to do outside of JSR.
The new hot lint (for me) is Oxlint. Literally a 300x speed improvement on our monorepo compared to eslint for the same ruleset. It’s amazing, especially in combination with Oxfmt instead of prettier.
Honestly I forget now, as I first played around with it months? years? ago when it was pretty new.
But one thing that stood out was .only(). In every major testing framework IT'S ASSUMED the dev is going to want to run one test at a time (sometimes). They make it super simple: you throw a ".only()" on the test, and the test runner only runs it.
In Node, you instead need to pass some special command line flag or add .only to every describe above the test ... which just makes a basic operation (run one test) much harder than it needs to be ... for zero benefit whatsoever (again, just do it the way every other test runner does it).
While I'm at it, I forgot to mention the built-in formatter (deno fmt) is great too. I use Prettier in other projects and it's also great in those projects, but it's tiring that it's yet another dependency to remember to add and configure in a new node project.
That would likely require copying the image data in and out of the wasm instance's memory, while a pure Rust solution could have safety with less overhead.
Can you explain the scenario where Anthropic getting to “aligned” superintelligence first blocks their competitors from creating unaligned superintelligence?
Today we prompt software developers to "think about ways to improve AI's architecture" and it results in AI getting better. AI over the last year has made very rapid gains in filling the role of a software developer.
> 4. After knowing that the server was hacked, the internal team finds the message board and does nothing with the information. They caught their AIs swarming and did not even inform management.
I believe Sam Altman or someone else from OpenAI clarified on Twitter that they did not find the message board at this time. When the artifactory server stopped working, they archived its contents, reset it, resumed training, and only later noticed that it had been used as a message board after they finally discovered the hacking going on.
I remember that clarification, but it's either wrong or narrowly worded, because the linked post says the message board found before Artifactory stopped working:
> In short, an internal team observed an agent engaging in message board activity and instances of disallowed internet access in late May.
reply