> Opus 5.5 communicates more naturally than prior models. Early testers found its writing clearer and easier to follow, which addresses some of the common feedback we heard about Opus 5
> CrowdSec source code consists of two parts: a private one and another that hosts our Free Open Source Software (i.e., the Security Engine), which is public by design and therefore out of scope.
Well, the Turing test involved a _human_ evaluating whether it was talking to a machine or not. In this case, another AI is necessary, which means, in its strict form, the Turing test has indeed been beaten.
In my personal experience, GitHub Copilot is pretty weak. Maybe it's just that I've used smaller models on it, but it just felt like the worst available harness, even behind Google Antigravity's.
Is there any redeeming quality to it nowadays? I'm curious what those eight hundred thousand lines of Rust actually do.
From what I understand, this runtime is used across a bunch of other Microsoft products with the "Copilot" naming. Does anyone understand Microsoft's current naming scheme regarding these products? I couldn't get even GPT 6 Astra to explain it reasonably to me.
Well, I guess I'm not even going to comment on my personal experience with Microsoft Copilot, or whatever bs that dashboard that launches the Office apps with an integrated AI chat is called.
Lastly, but not least:
> During the port, the runtime took in ~300,000 production lines of TypeScript and shed ~430,000, while ~1,200,000 production Rust lines entered and ~365,000 left. In other words, the apparent stability of the TypeScript line in the above graph was actually hiding significant amounts of TypeScript churn.
This is the part I find really interesting. The resulting runtime is ~830k lines of production Rust. Even using their estimate that ~430k lines of production TypeScript passed through the port, that's still nearly twice as much production code.
They also say that agents wrote most of the Rust. Given how verbose LLM-generated code tends to be, I'd really like to see some analysis of why the implementation grew that much. How much of it is Rust and the new architecture, and how much is simply code the agents generated because generating more code is cheap?
The article points at the hidden TypeScript churn, but to me the much more interesting number is that ~1.2 million lines of Rust entered and ~365k were subsequently removed.
I use copilot as my daily driver and haven’t seen much difference with it and Claude code’s output.
I think your answer is you’ve been using weaker models, that’s comparing apples to oranges. Have to try the same model on both harnesses. Also have to remember that GHCP harness is model agnostic, Claude and OpenAI can tightly couple their harness to their model so they will always have a slight edge initially. Making agnostic harnesses is much harder to do imo and if successful is much more valuable to customers.
my experience has been great with copilot cli, but yeah there is some memory leaks here and there and slowness which i hope this rust port can help with
Gemini's Live Mode is already much better than GPT Voice in my personal experience, even though it was much dumber. It really does feel like talking to a real person. ChatGPT keeps humming to whatever I say and has some weird voices.
Excited to try this out! Shame on Google for not releasing Gemini 3.8 for Google AI Plus users yet, though.
Agreed. I've been using GPT-Live-1 this week, with Claude as the backend brain. It's amazing, feels like working with Jarvis. It certainly made me feel there's no point in human telephone support now - but I'm sure I'd find edge cases if that really was something I wanted to build out myself.
So, the way GPT-Live-1 works, the Live model just handles the conversation layer in a lightweight manner. For any deeper thinking (and I think tool calls) it will delegate to the Backend. It's like how Fable can delegate tasks to Opus while it keeps going. The Live voice can keep chatting to you while it waits for results from the Backend.
The default for the Backend is a Responses Delegation that just sends it to another OpenAI hosted model. But you can set the API up to use Client Delegation instead, and have your client/harness receive the delegation request. At that point, your client can delegate it to a Claude instead, and have Claude do the deeper thinking. Unfortunately you're not actually talking to a Claude, even if it identifies as one, but you can at least talk to something informed by Claude.
As for how to build that - I just had Fable build/vibe the whole thing for me. I used Go for the language, and SDL 3 to handle the audio & microphone side, even though it's just a command line app for now. I've previously been working on SDL3 bindings to Golang, and a personal AI harness with tool-calling & local MCP stdio support, so it's possible my Fable re-used some of that code. But Fable can whip something together, and the most basic tools (read,write,edit,datetime) are all really easy to add to a harness as built-in tools that you can let it call.
The main downside is that Anthropic probably wants you to run it as API, so costs can blow out. And depending how you setup the harness, either every backend call is a fresh new Claude window (to which you're sending a LOT of context), of you need a way to maintain a persistent Claude conversation that you queue requests to, but at least then the context is all in one window & you can benefit from caching.
But if you get it running, and play with it a bit, you'll realize this is obviously the future interface. Typing into a terminal window feels archaic. Even if we're not quite there yet, we're tantalizingly close... and anyone who has a 3D-printer & a robot arm connected via MCP/tool calls, well, this gives them Iron Man's Jarvis right now.
I knew about the lossless JPEG to JPEG XL compression story before, but had no idea that it was a two-way road. That's truly f* impressive. Boggles my mind even more the fact this format hasn't been adopted widely yet.
JPEG is a lossy frequency-space compression stage followed by a lossless Huffman coding stage. The second stage is quite generic as such, essentially compressing a stream of bits.
So you can relatively easily replace the second stage with something better. And since it's lossless you can easily go back.
Dropbox[1] and others have exploited this for reducing storage requirements, converting back on-demand so the client doesn't notice.
Do you? I just tried it locally, and decoding a 4.9MB, 6000×4000 JPEG with djpeg took about 400ms; decoding its losslessly-recompressed JXL (4.15MB) single-threaded with djxl took 300ms.
Well, I said “with djxl”, and Chrome/Firefox use jxl-rs which happens to apparently be currently somewhat slower for that use-case (but libjxl being faster shows it doesn’t have to intrinsically be the case), and Safari uses libjxl but multithreaded (so it’s 800 ms for the JPEG and 137 ms for the JXL).
That's fair, at really high resolution, the JXL decoders in browsers do better than JPEG decoders. I'm pretty sure this is a weakness in the JPEG decoder rather than the format, but it's still a meaningful result.
At smaller sizes (more typical on the web), the results are opposite, the JPEG decodes much faster.
jxl-rs will presumably get much faster in time. The work on it started much later than work on libjxl (because it took years for anyone to say they had vested interest in it), and if my understanding is correct, it hasn’t been production-ready until recently. Once it behaves correctly, speed improvements are next in line, presumably.
There is indeed an issue with the JPEG format that makes parallelization difficult: the lack of a 'table of contents' with offsets to tiles.
Various workarounds (for example RST markers or self-sychronizing properties of Huffman) have been proposed, but these are not great and do not work for all images.
JPEG XL ensures this information is always available.
I guess my surprise is mostly that it hasn't been adopted elsewhere. For instance, it still boggles my mind I can't store my JPEG XL images on Google Photos nor take photos as JPEG XL images directly on my Samsung smartphone, but can use HEIC for some fruity reason.
So is sudo... And that's not "too risky" for the entire industry.
That's not to say bus factor is irrelevant (I personally think about it a lot when choosing software projects), but truthfully the bus factor here especially doesn't matter much, as mise is an easy tool to replace (with asdf, for example) if something goes wrong with it eventually.
I highly recommend trying it out. I resisted using it for some time, but it solved some pain points I had with NodeJS, Ruby, and Python regarding installation.
> So is sudo... And that's not "too risky" for the entire industry.
Sure it is, and that's why I'm looking forward to systemd's Run0 -- but for now, there's just no way around the sudo package. That's different for Mise, though, because there are a lot of ways to work productively without it. I'm not fond of consciously adding supply chain vulnerabilities to our stack when I don't have real pain to do so.
> Sure it is, and that's why I'm looking forward to systemd's Run0 -- but for now, there's just no way around the sudo package.
Regarding Run0, I'd prefer to not rely so much on Polkit authentication after crazy vulnerabilities such as PwnKit (a pkexec vuln, but a good reminder that moving the security boundary won't magically solve issues).
> I'm not fond of consciously adding supply chain vulnerabilities to our stack when I don't have real pain to do so.
I SUPER agree with you on that, btw. It's just likely that mise solves a problem which is much bigger for me than it is for you. Honestly, I'd prefer if I could manage everything with my distro packages, but, for a multitude of reasons, they're rarely enough for development tooling with multiple versions and environments.
So it's not native anymore. One of the coolest things Audacity had, at least for me, was the fact it was built using wxWidgets.
I also wonder how is the Muse group perceived nowadays? I remember them acquiring Audacity was a huge mess when it happened due to them introducing telemetry. Never used Audacity since then.
Adaptive reasoning is known to be an extremely hard problem to solve, though. It requires you to predict whether a certain LLM, with a certain effort level, with a certain prompt, will give you the right answer.
If diskutil actually did everything OP looks for that was available in hdiutil, that's correct. If you read the post though, you'll see that diskutil has many limitations compared to its predecessor.
reply