But - the context changes from room to room? Clean shared flat- messy druggy room with collapsed overdose person in it? This.. this whole situation makes no sense.. Have helper boots with a "condom-wrapper" if you are afraid of cleanliness - but keep the boots on at all times.
I guess you missed my "containerisation" point: if not restricted, every rogue package or agent has access to your full $HOME too. A secret is there to protect access to data you care about. If that data is there, well, not much achieved.
Eg. imagine there's the source code for a service you deploy to AWS — rogue sw can modify it letting you unknowingly update it the next time (or why do you have those AWS keys anyway?).
But not if they are part of non-classic Snap on Ubuntu or properly containerised Flatpak (on Linux, at least), or in a VM or LXC/Docker/Podman container.
> I guess you missed my "containerisation" point: if not restricted, every rogue package or agent has access to your full $HOME too. A secret is there to protect access to data you care about. If that data is there, well, not much achieved.
There can be multiple processes that might need access to a project root and thus you might still find utility in something like these even inside a container.
In security, we call this "defence in depth".
> Eg. imagine there's the source code for a service you deploy to AWS — rogue sw can modify it letting you unknowingly update it the next time (or why do you have those AWS keys anyway?).
Sure, but then you also wouldn't be using version control either. Nor checking the dryrun plans before applying your new IaC. So it sounds like you're not following any form of rigour at all in such a hypothetical scenario.
> But not if they are part of non-classic Snap on Ubuntu or properly containerised Flatpak (on Linux, at least), or in a VM or LXC/Docker/Podman container.
Nice word soup there but you're misunderstanding the technologies.
- Snap and Flatpak target different problem spaces (application packaging for distribution).
- VMs by themselves wouldn't achieve much because you'd need mounted paths eg if you want one agent to manage code and not also have Terraform to run inside that same VM. While you could manage mounted paths manually, it's really not worth the effort when Docker gives you an easy UI out-of-the-box
- LXC is pretty barebones. It would be like creating a VM in the effort to build repeatable ephemeral environments from it. You can do it, but why would you when OCI has an easy-to-use ecosystem already?
- Docker/Podman, if you wanted to make the distinction, then why not just say "OCI"?
---
I do think scepticism in tech can be healthy. But what you're doing isn't that. It's just dismissing the tech without any effort to understand it. And thus your arguments against it contain a multitude of flaws.
reply