Yes, that's exactly what I want. I want to know what is done with a high level why, NOT a paragraph explaining each line of code modified.

A frequent tweak I've made on coding work with Claude in the last month is asking it to restrict its comment length to 1 line/sentence max. I just want `// This happens because XYZ upstream`, not `// Historically from ticket blahblah there was some dummy code where we discovered ancient runes and that led us to looking into your birth records and then triangulated an issue in XYZ upstream that we compensate for here`.

The model's "most information dense representation" is very similar to how we compress data in the first place: most of it is redundant or unnecessary for the purposes of storage. I'll "decompress" the 1-liner context myself when I read it again in 6 months. But I can't stand reading just so much slop commentary when we're all writing more code at once and having to review more than ever.

There's competition in the other TCGs, and of course a 2-sided marketplace is one of the hardest things to seed. So this is mostly just a project that I can put any fresh ideas into that I wouldn't be able to at my dayjob.

I've worked on both stacks in the last few years across several clients. Honestly like with anything in tech it seems to mostly fall apart with half-regarded usage of the tools in growing teams that don't care about their quality in favour of "get ticket done".

Lo and behold, the EXACT person I had in mind when making the rule, moaned about it.

Works as intended.

Maybe my attention span is truly stuffed, but I really can't stand it when a video essay is the most succinct source on a topic - waiting for someone to express their thoughts in speech, with sometimes slow cadences or their own waffling, combined with sponsor segments (yes I use SponsorBlock, but sometimes or on other devices ads get through), etc.

So I use AI summary for a lot of informational videos now unless I actually am watching it for the entertainment and production value. I don't need 10 minutes on "this will change the way we look at XYZ" that has only 1 minute of real information in it.

If nothing else, using the smart model for planning to hand off to the previous gen for implementation still seems like a useful pattern.

My plan is to make hay while the sun shines: get some planning in over the next week or so, and just let Opus take care of it when I get to actual implementation.

So much of our lives is now digital. Important accounts of all kinds, banking, etc.

Waiting on several giant corps to grant your loved ones access after they go through the bureaucratic hole of documentation is... rough.

Putting my master password in my will feels the same as just writing it on a note on my desk. Putting it in a note in a safety deposit box is high effort and cost.

Anyone got a better alternative way to set this up if self-hosting and not going with Vaultwarden?

You shouldn't be looking at just various kinds of earplugs as options for this. You can get custom made earplugs for your ears for differing use cases (sleep, concerts) at an ENT.

Fair enough, that buys a little bit of time to not break deployments I supose.

> When the build process completes, it tears down the overlayfs

Ah okay, I misunderstood you then - I was referring to Docker-less servers and my build steps running there, not building the images on the machine.

Thanks for the info!

"Builds" are the same as deploys, so when working with server(s) instead of larger scale deployments, I'm not seeing the benefit of the whole "build image, pull on server" pipeline when I can just ditch the registry and added layers by doing those steps on the server as I would normally in other kinds of scenarios.

But I have seen this in action, which is why I'm wondering if I'm missing something.

The clearer benefit to me seems to be in this scenario to use it as a fast environment provisioning tool.

> disk, i/o exhaustion

This is why I mentioned specifically for ecosystems like PHP, which are interpreted. I'm specifically asking for that use case.

I'm not building binaries, my "build" steps are actually deployment steps (npm build, composer install, etc) that I'd be running in exactly the same way on the host. The image I'm deploying by definition also contains my source code because I'm not deploying anything compiled.

How? What I'm describing is using Docker less.

> The build process can exhaust resources on the host

Maybe, but I've yet to have a host where that's the case for usual CRUD fare.

> The advantage is simplicity, and it's often worth the risk.

That's basically what I'm evaluating for here.

For bog standard LAMP or similar stack applications, I've not understood the advantage of going through the build-image-then-pull-on-host rigmarole. There's more layers involved there than something like provisioning with Ansible and just having a deploy script to run the usual suspects.

But I have seen that done fairly often, hence was wondering what the point was.

Is using Docker/Compose "just" as the layer for installing & managing runtime environment and services correct? Especially for languages like PHP?

I.e. am I holding it wrong if I run my "build" processes (npm, composer, etc) on the server at deploy time same as I would without containers? In that sense Docker Composer becomes more like Ansible for me - the tool I use to build the environment, not the entire app.

For the purpose of my question, let's assume I'm building normal CRUD services that can go a little tall or a little wide on servers without caring about hyper scale.

There is no truly good, independent, feature complete browser out there right now if you want to avoid Chrome and have something that a) works and b) isn't hostile to the userbase.

Brave at the very least said they'd keep supporting Manifest v2 extensions, though not sure how you'd acquire them anymore unless Chrome web store has kept the listings up.