doodlesdev

   > at the very least prompt you if they suspect prompt injection.

That's currently not reliably done the way LLMs have been designed. Claude's rejection to modify the file comes directly from Anthropic's understanding that training the model for this kind of refusal prevents huge mishaps.

In a nutshell, every prompt sent to the LLM is just text + multimodal input (if it supports it) + some reserved tokens.

At first, you could, for instance, create a token (such as the ChatML ones) that indicates the start of a system prompt and attempt to RL-train the model to not obey things after the end of a system prompt. However, fundamentally, the way LLMs work, you cannot guarantee that it won't see the user part of the prompt and obey what's there even though the system prompt told it not to. There's no hard separation between the control plane and the data plane in the LLM's context, so it's not a matter of adding more parameters or more RL training.

Using a guard model, or something like the auto-approval system on Codex or Claude Code nowadays, _feels like it helps_, but it doesn't fix the problem entirely since OpenAI's and Anthropic's models still have alignment issues all the time. We're not sure what architecture they're using, though, and it's probably still liable to the same kinds of mistakes.

It makes a lot of sense for the model to not be able to do it, whether you like it or not. In fact, it shows that Anthropic, despite all of their issues, are paying some attention to the risks of malicious prompt injection and models attempting to bypass restrictions.

If it could do it whenever you ask it to, it could also do it unprompted or by finding a file in your directory that told it to do it, which would make the entire permission system useless...

   > If you’re all “ra ra ra JavaScript!” you’re going to be shocked to find out what evil one can accomplish (either now or at various points in the past due to since-patched browser exploits or web platform security oversights) with just HTTP, HTML and CSS.

There's such a thing as an attack surface. JavaScript with JIT enabled has an attack surface so much larger than HTML and CSS that I cannot believe you're saying this in good faith.

Craziest thing is the mixture of:

- A browser engine outdated by two years, with known-exploited CVEs

- Chromium sandboxing completely disabled [0]

- JavaScript V8 Engine with JIT enabled [0]

For me, it's surprising we haven't seen more of these yet.

[0]: https://github.com/obsproject/obs-browser/blob/f555da02b1d59...

Fucking absurd. I'll forever hate developers who allow for such _bizarre_ exploit chains to happen. OBS is an OSS project which I believe has received a lot of love throught the years, but having the Chromium sandbox disabled due to authentication with _certain services_ not working with it enabled is asinine. Don't even want to imagine the other problems the project might have waiting to be exploited.

Sure, if the plugin developer sanitized the comments before inserting them, this wouldn't have happened _this way_, but having a browser engine two years outdated (for a reason which IMO is absolutely reasonable compared to other situations before) and having the Chromium sandbox completely disabled with nothing to substitute it is crazy in a software onto which people insert random plugins from the internet to get random functionality.

Hopefully those two changes ship fast to OBS. I may be supporting the project financially in the future if they update their security posture, as I'm generally very fond of OBS.

   > 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

Big, if true.

From TFA:

   > 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.

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.

   > 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.

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.

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.

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 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.

While that's absolutely correct, you're arguing with a strawman. Take a look at the original quote:

   > I can still use my 12 year old MacBook Air. It’s not super current and not all apps work, but it’s actually still a decent Apple experience.

The point is I can run the latest Linux distributions and software on a 12 year old computer with no issues whatsoever.

You might be able to do that in Windows, if you bypass TPM and CPU requirements or if you stay with Windows 10 extended updates.

You won't be able to in macOS without OpenCore Legacy Patcher and a lot of faith in your God of choice.

   > stop pretending you have capable people that spend a day on discussing effects in react.

Figma uses React for the UI panels. Google Docs uses the DOM extensively too.

   > have pushed for manifest v3

I don't use Google Chrome.

   > since we have decided app distribution to be web based

No one has decided this, it just happened because web browsers were in the right place at the right time. It's not set in stone and developer tooling for the desktop could easily revert this trend in a decade or so.

There's friction to doing it this way right now, though. You lose out quickly on accessibility, SEO, performance and developer experience (you need developers that are more experienced).

Unfortunately, thinking about it in terms of game theory [0], I believe this is a good thing: I don't want most websites migrating to canvas-like APIs for rendering. My web browser is my agent and I'd like it to mostly render DOM-rendered pages with CSS styling and, perhaps, funny JavaScript that doesn't track me around.

Also, I wish Figma and Google Docs were just offline-usable desktop applications. Both are great _products_ and I use them, but using them on a browser tab makes me unhappy.

[0]: https://en.wikipedia.org/wiki/Game_theory

I'd argue that S3-compatible isn't exactly what you'd need though. You'd need S3-compatible with similar latency characteristics for read and write, with four nines of availability and 10+ nines for durability. [0]. Their metrics are, quite honestly, absolutely impossible for most engineering teams and companies to ever achieve, no matter how hard they work at it. In essence, what I mean is Cursor could migrate Origin out of Amazon's S3, but they'd lose a lot of reliability and/or performance in the process.

[0]: https://aws.amazon.com/s3/ (Click on Durability and availability)

Wow. I've been waiting years for this, ever since Modular first announced Mojo. To be entirely honest, I thought they would walk back on this promise and so I never really gave the language a chance. With this and the 1.0 release, it looks like a better time than ever to start taking a look into it.

I've made a huge critic towards Flutter in another comment of mine, but adoption isn't it: the biggest bank in Brazil, with 135 million clients, is a digital bank whose sole interface is their Flutter app. They are different regarding tech choices (they use Clojure on the backend too), but I think it's a huge testament of how far along Flutter adoption has come.

Also, Google dogfoods it quite a bit.

While I've used Flutter since Alpha, I've been away for a few years. A few things have shocked me in these release notes: how come Impeller still wasn't the default engine for all platforms? Also, why are they migrating to WASM if one of the core features of Dart is compiling to JavaScript? Finally, how come multi window support only get viable now, after four years having desktop support?

Honestly, Flutter is an extremely enjoyable development experience I would recommend anyone I care for to stay away from. The fact it's developed by Google doesn't help: it's a matter of time before they kill it like they did with so many UI libraries and frameworks already, specially with JetBrains developing Compose Multiplatform and the Android team going all-in in the Compose strategy.

I agree!

Indeed, the only advantage to Resident Keys (i.e., Passkeys) is the discoverabillity of them, so you can login without even using a username. It's a shame all of the terminology around WebAuthn/FIDO2 and Passkeys is so loose and badly defined.

Honestly, I think OAuth logins are still an ok option for the average user, unfortunately, as I would never recommend someone I love to use Passkeys and put them through the burden of having to understand and deal with all of this mess.

Yeah, they do. But what if you want to move from Android to iPhone or vice versa? That's the big problem regarding these keychains/password managers. Some of them didn't even allow you to export your Passkeys until a few months ago, meaning you were literally locked into their platform.

Remember that your average user has no idea what a passkey is, doesn't remember half of their passwords and has no idea what a password manager is.

> You don’t. You don’t store anything at all.

Yes, you do.

Whenever a website offers to create a passkey, it could end up in any of these:

- Samsung's Password Manager (if using a Samsung phone)

- Apple's Keychain (if using an iPhone)

- Google Password Manager

- Your operating system's keychain

- A bespoke password manager (e.g., Bitwarden or LastPass)

- Your hardware key

Most users do not have a security key fob. Instead, the proposal being mostly pushed is the idea that users can store keys on their own smartphones, making use of the modern TPM and chip security. Most of the discussion here revolves around that idea: "What if I lose my phone? What if I switch phones?" and that's why the problems seem so obvious to you.

I absolutely agree the best solution is to use hardware keys, but I'll admit it's cumbersome if I need them for hundreds of accounts (which I do have), having to register both for every website and praying that I never lose both at the same time in the case there's no viable recovery flow for some of the accounts. Also, most of these hardware keys are limited to 25 or 100 resident keys, which again makes them unable to substitute passwords. Observe the usage of the term resident keys: passkeys do rely on the private key being stored on the hardware key, as that allows discovery.

Chrome, Brave and Opera are as much WebKit as Safari and Kagi Orion are KHTML. I wholeheartly agree on the UX part, though.

That's a very low bar, though. Chromium is open-source too and has a bunch of privacy-focused forks such as Ungoogled Chromium, Brave and Chromite.

It's still online, but it's not anarchy anymore [0].

[0]: https://www.2b2t.org/terms/