orisho

You know that before EVs were a thing, it was also not economic, and was seen as crazy. So was landing a rocket. And have tons of little satellites in LEO. Don't confuse the first prototype version with it being impossible to succeed.

What I do nowadays, for large changes, is have Fable create a HTML explainer for what we're gonna do with code snippets, which is not that fat from plan mode only much more convenient for me and modern models have no issue using that HTML artifact as the source of truth, and then before I get into execution - I interactively build an end to end test that also includes pieces of the plan.

When a test case fails, the relevant part of the plan is surfaced in the error. I find this helps Claude stay on track for longer - I've been able to do 12h most times and even up to 48h unattended (11h of API time) with good results.

Then whenever I do check in, I ask it to update the HTML with current state in an append only fashion (sort of like it's writing a blog), and then based on that, we iterate on the end to end test (I think of it as a "test harness") - update the test cases and error messages.

I've been able to build some truly large projects this way, both greenfield and up to spec (for example, a video game I've always wanted to play), and brownfield while staying within the conventions and design of the codebase, and with very little attention required on my part.

Vendor lock in is 2025. Porting became trivial with LLMs advancing like they have.

I have a contrarian take on this: if most people working on the codebase are using the same model, then these comments serve a very useful purpose: they tell the model's future self that despite its tendency towards this solution, it is incorrect and here's why. It encodes useful context right when the model needs it next to avoid making the same error.

I imagine this style of commenting is partially responsible for model improvement in SWE work, a trained trait through feedback, since it makes the comments actually useful. Not to you or me, but to an LLM.

Some of these errors are obvious to a human, that's why we find the comments unnecessary. But if everyone's using LLMs and said model tends to make this error, then they are very useful. It's like a comment you would leave for another human to help them avoid a footgun. It's just a LLM footgun, not a human one.

Shouldn't a senior developer strive to eliminate complexity while increasing velocity? The two do not contradict. Reducing complexity can increase velocity.

It's probably there not as a way to connect networks, but as a way to keep them separate, only allowing RDP between specific computers on different networks.

A 15 frame min anf max GOP size would do the trick, then you'd get two 15 frame GOPs. Each GOP can be concatenated with another GOP with the same properties (resolution, format, etc) as if they were independent streams. So there is actually a way to do this. This is how video splitting and joining without re encoding works, at GOP boundary.

You're right, but the way to achieve this is to allow the error to propagate at the file level, then catch it one function above and continue to the next one.

However, LLM generated code will often, at least in my experience, avoid raising any errors at all, in any case. This is undesirable, because some errors should result in a complete failure - for example, errors which are not transient or environment related but a bug. And in any case, a LLM will prefer turning these single file errors into warnings, though the way I see it, they are errors. They just don't need to abort the process, but errors nonetheless.

I believe it's because if you are easily replaceable, then screwing up means you're not worth the trouble. If you aren't easily replaceable (whether it's because you have demonstrated you're a good employee or you're working a high-demand role), you are worth the trouble and you'll get more chances. There are other reasons too, such as jurisdictions where suing after being laid off is more common, which makes more chances, PIP and severance packages more likely.

It's not just Israel. It's just not newsworthy if it's not Israel.

You may find yourself in that situation if you have a device that only supports SIMs, and you can't use any of the cheap travel esim providers with it. For travel, you would replace your local SIM with the 9eSIM, and be able to switch providers depending on destination. The difference can be huge in some countries, where a local provider's travel plan can be 30 to 50 USD, while a equivalent on an ESIM provider is just $4.

I live in such a country and have parents with older phones who can't use esims, so the value is obvious to me. :)

I don't recall what it was called in the menu, but it was definitely possible to assume a struct on a particular address. Muscle memory tells me the button is U, even though actual memory fails me.

The alternative is making it possible for developers to only think about code, not permissions, or at least specify the permissions in terms of what you want to do, not what permissions you need. Think iOS, you write "I need fine grained location access" into the manifest, you don't configure the permission system to allow you to call the API.

Another poster touched on another important point: it's important for this to be changeable independent of the code. The reason for this is actually kind of subtle. Obviously, you don't wanna have to need to rebuild in order to regenerate permissions. But the real reason, imo, is that it should be easy to parse for a human, easy to locate for a human, and also easy to parse and adjust for a machine, that might determine a permission is no longer necessary, or who is trying to build a dependency graph in order to determine who to wake up during an incident. That means it should go into configuration that is versioned and deployed alongside the code, but not in the code.

If you make this hard to understand and change, people will just copy it, and the you're back to square one. It's gotta be the easiest thing to do the right thing, because at scale, people are gonna do the easiest thing.

I feel like I'm kinda going on at length about this, so instead I'm gonna leave you with a link to a blog I wrote about the same concepts, if you wanna read more. It's about Kubernetes network policies, but really the same concepts apply to all kinds of access.

https://otterize.com/blog/network-policies-are-not-the-right...

In newer versions of Android, apps which are not opened by the user have their permissions automatically and periodically revoked. So they no longer have the permissions, and when reopened, the user needs to grant the permissions again interactively. Presumably to solve this.

See also: Network Mapper - low privileges, no-eBPF network observability tool for K8s

https://news.ycombinator.com/item?id=39761114

See also: Retina, eBPF-based network observability tool by Microsoft. https://news.ycombinator.com/item?id=39759627

The Network Mapper can export to Grafana Tempo (contributed by the community!), but doesn't have to. You can get its output as text, JSON, PNG or SVG using a CLI or an API (directly from the deployment in your cluster), and use it to auto-generate network policies.

Built while avoiding eBPF and reliance on a particular CNI with the intention to run on older nodes, with low privileges, a low performance footprint, and most importantly - zero config.

The problem with IAM systems is they tend to try to encompass so many different functionalities, and stay unopinionated, that there are just so many ways to achieve similar end results. This opens the way for endless bikeshedding, and unfortunately is inevitable to some degree in large enough organizations.

This is a bit of a shameless plug, but I hope since it's an open source project it's okay. I'm working on a suite of tools called Otterize (otter and authorize, get it, haha :) that automates workload IAM for Kubernetes workloads.

You label your Pods to get an AWS/GCP/Azure role created, and in a Kubernetes resource specify the access you need, and everything else is done by the Otterize Kubernetes operators so that your pod works.

It's a lot simpler than all the kungfu you normally have to do, but it's not magic, honestly, it's just the result of limiting scope and having an opinionated view of what the development workflow should look like. Basically, instead of maximizing on capabilities, it trades some capabilities to maximize on developer comfort.

Check it out if you're keen on contributing, or just think IAM has a tendency to devolve into a mess ridden with politics.

github.com/otterize/intents-operator and docs.otterize.com

Oh, I love this story! :D Always fun to read whenever I stumble upon it.

It has an option to "auto open", which you can deselect.

Why not try asking ChatGPT for this? It may work!

ChatGPT uses the model text-davinci-003, which was released alongside it. The previous model of the same kind was text-davinci-002, and in a comparison I read, seems to perform much less impressively. So it's not just the chat interface. It's genuinely more impressive in my opinion.

Henn na Hotel, literally "a strange hotel".

The answers are over complicating things though. There are built in libraries that make it trivial to do this. A waitgroup is relatively low level and gives you the function you can call in your defer to signal completion. An errgroup builds on the waitgroup and gives you start & wait primitives, similar to the nursery discussed in the HN post.