3 ms·
>In particular: updating. If a single app controls the whole VM, you can drastically improve the likelihood that a single update mechanism will work properly. Y
by lsc 13y ago
>In particular: updating. If a single app controls the whole VM, you can drastically improve the likelihood that a single update mechanism will work properly. You can even automate it.
This is interesting. I mean, if you can get it to work. I'm bringing up the point and click admin tools, though, because that's the best comparison I can come up with that actually exists that I've seen.
The thing of it is, I think that most things do eventually break. (I mean, like the kids in this thread talking about how easy an 'apt-get update; apt-get upgrade' is - it works great most of the time, then it breaks something horribly.)
There are things you can do to reduce the chance of that breakage, but eh, at some point you have to login and fix the goddamn thing.
Not that this breaks your model; I mean, if you are distributing, say, a blogging application; my dad is paying you $5/month and giving you login credentials on a standard VM of some type, he installs using the kernel/script you gave him, and the system uses your repos to upgrade nightly. If something does break horribly, you can login and fix it.
I still think that model is easier if you include the VM in that $5/month, and you run that VM on something you control.
- jacques_chester 13y agoThat said, there are millions of copies of unpatched systems running on VPSes across the internet. I think that the lesser evil is automation. Possibly the upstream can borrow from continuous delivery and only "announce" the upgrade progressively, testing as it goes. I'd also be interested in the upgrade system itself. Systems which have atomic snapshotting would be more un-borkable, for example.