xmodem

If this is true then why did Anthropic bother to update their privacy policy when they first launched Fable?

If you can reproduce it reliably and doing so generates some form of telemetry, then just set up some automation to keep doing that in a loop. From as many machines as possible.

No comment is offered on if I have ever gotten a bug noticed this way.

Hell, I've hand-written a large PR as a single commit and then asked claude to break it down for me at least once. But I think the fact doing this task by hand is a tedious, time-consuming hassle is not because it inherently has to be but because the tooling for doing it has barely changed in the past 15 years.

What percentage of CVEs can be used to obtain a shell, but can't otherwise be used to obtain some other form of code execution in a distro-less container?

I am aware, thank you :). I responded to a sibling dupe-comment over here [1].

To summarize, in my experience there is immense value to having basic shell tools available in the environment where you need them with zero extra friction. Stripping those out provides a security benefit only in specific nebulous and niche scenarios.

1: https://news.ycombinator.com/item?id=48561605

Nope, not my position at all. I want to have a minimal OS environment with rudimentary tools available with zero extra friction. FROM alpine:latest adds less than 10MB and covers 95% of use cases. Typically depending on the container I will often throw in curl and some other QoL tools too.

For the rare cases where you find yourself needing to attach a debugger to your pods running in staging/prod, a debug container is absolutely the right tool to reach for.

Yup! They are a good solution to the massive problem you caused for yourself by implementing a different "solution" to a non-problem.

And even that's only true if you assume kubernetes is the only place your container runs where you might want to also debug it.

FROM scratch just reduces the surface.

The actual attack surface of your application? Or the attack surface of you and your team's attention from a busybody security org.

It's important not to confuse the two.

The cool part about FROM scratch images is that you'll never have to update your base image to address CVEs. Only your software and its (compiled) dependencies.

What's the benefit really, though? If you still need to be able to rapidly deploy a new image in response to a dependency CVE, what have you gained?

More than one ~500 employee company I've worked at has had security policies either encouraging or requiring the use of "distro-less" images - images with no OS components other than the absolute minimum required to run the application. For go binaries this meant literally nothing in the container apart from the executable.

In theory it has a couple of benefits. You don't have to re-deploy your image to patch CVE's in OS components if you don't have any OS components. And it provides some measure of defence-in-depth - one could certainly theory-craft a scenario where an attacker gains some limited control over your application and then uses some OS component to escalate.

These days if a security engineer is proposing my team adopt distro-less containers to receive these benefits, I would point out that we need to weigh them against the very real drawbacks of not having standard debugging tools available where and when we need them. And also to consider the relative impact of other defence-in-depth measures they could be pursuing instead - such as any sort of network policy to limit network traffic.

I see a lot of commentators in this thread who are aggressively critical of volunteer maintainers for making a decision about how to maximize the value of the free labor they donate to the world.

And yet none have offered to volunteer their time to maintain a downstream fork or otherwise rectify the perceived problem.

Strange.

Rather than have complexity centralised and managed, let's generate the same vulnerable code across millions of apps. Great plan.

TUIs suck and the only reason they are seeing a re-surgency of relevance is because everything else sucks more along one or more critical metrics. Given the truly incomprehensible amount of CPU and GPU power we have available, this is truly a blight on our industry.

I just want a button that says "approve and merge these 3 commits now but these two need re-work"

Don't anthropomorphize the language model. If you stick your hand in there, it'll chop it off. It doesn't care about your feelings. It can't care about your feelings.

So it's only wrong in a technical and pedantic sense. A better phrasing might have been along the lines of "There are many sequences of tokens that will destroy your production database that are within the set of possible outputs"

It's an objection to adding a new dependency, not an attempt to remove an existing one. If we can't stop adding new dependencies, we are certain to be stuck with the status quo forever.

It's almost as if comments on a website called "hacker news" are written by individuals with differing and varying opinions, and not by some nebulous hive-mind that purports to be internally consistent.

The problem is that the well you are drinking from has in fact been poisoned. Maybe you think you can tolerate it but some projects are taking a policy decision that any exposure is too dangerous and that is IMO perfectly reasonable.

The fact that the AI agent will just go and attempt to do whatever insane shit I can dream up is both the most fun thing about playing with it, and also terrifying enough to make me review its output carefully before it goes anywhere near production.

(Hot take: If you're not using --dangerously-skip-permissions, you don't have enough confidence in your sandbox and you probably shouldn't be using a coding agent in that environment)

An engineer recklessly ran untrusted code directly in a production environment. And then told on himself on Twitter.

The A-series has supported virtualization since long before the M-series existed. iOS disables it in early boot, though.

On the other hand, how much virtualization are you really going to be doing with 8GB of RAM?

Unless your strategy is to create a photo-lab-like screen in pure black and red, or wear deep-red-tinted glasses, it’s unlikely that a pure colorshift strategy will cut out that big of a chunk of the spectrum.

The writer is dismissing this out of hand but to me this sounds like a great idea.

And I'm guessing that the reason macOS doesn't give more details is because macOS is likely not involved in the step that fails

And I guess because of the wide variety of third-party hardware macOS has to support, it's not practical to write a pre-flight check into the update process either.

I've never tried it myself, but it's oft-repeated folk wisdom in Apple circles that enabling filesystem case-sensitivity breaks all manner of third-party software that has only ever been tested on the case-insensitive default.

No.

A lot of devs delayed their launches:

https://www.gamespot.com/articles/silksong-release-date-has-...

Those that didn't or couldn't think it hurt them pretty badly:

https://www.dexerto.com/gaming/hell-is-us-boss-slams-silkson...

In general I think you are probably right. But there are definitely exceptions and this is one of them.

Are you hosted on cloud platforms that are SOC2 compliant? Or have you achieved and been audited for SOC2 compliance yourself? I'm going to have to assume it's the former because if it was the latter you would directly say so. To me that type of sleight-of-hand inspires distrust, which is fatal to any prospect of me evaluating the product.

Beyond that, a key risk that has been brought into focus more and more lately is data portability and vendor lock-in. At this point I do not deploy a new vendor without documenting the exit strategy.

The best exit strategy you can offer is an open source, self-hostable version of the product with a simple migration plan. Some of the other existing competitors in the enterprise chat space already offer this. Even if no-one uses it, by offering it you keep your priorities aligned with your customers.

The point is that no indie dev was able to plan around the surprise release of Silksong, precisely because it was a surprise.

I have not been as aggressive as GP in trying new AI tools. But the last few months I have been trying more and more and I'm just not seeing it.

One project I tried out recently I took a test-driven approach. I built out the test suite while asking the AI to do the actual implementation. This was one of my more successful attempts, and may have saved me 20-30% time overall - but I still had to throw out 80% of what it built because the agent just refused to implement the architecture I was describing.

It's at its most useful if I'm trying to bootstrap something new on a stack I barely know, OR if I decide I just don't care about the quality of the output.

I have tried different CLI tools, IDE tools. Overall I've had the best success with Claude Code but I'm open to trying new things.

Do you have any good resources you would recommend for getting LLM's to perform better, or staying up-to-date on the field in general?

Your post sent me down a rabbit hole reading about the history of computers playing chess. Notable to me is that AI advocates were claiming that a computer would be able to beat the best human chess players within 10 years as far back as the 1950s. It was so long ago they had to clarify they were talking about digital computers.

Today I learned that AI advocates being overly optimistic about its trajectory is actually not a new phenomenon - it's been happening for more than twice my lifetime.