"Publish a fully functional working machine with your project on it
Don't worry about complex package management systems, or what environment a consumer of your program might have.
Just give them a copy of your environment: it will always work in the future."
I'm not convinced that a virtual machine snapshot is an adequate replacement for wrestling with a package manager. If all you distribute is a VM image, then:
- Users can't easily run your software without provisioning an entire virtual server and, as far as I can tell, giving Terminal money and their email address.
- Without active maintenance on your part, the other software on the image will get out of date. Security holes will be discovered in the versions of nginx and openssl that your image uses. Have you ever tried to upgrade a Linux box that hasn't been touched in a few years to the latest version? After a few years, every potential user of your software will have to go through that first.
- If Terminal goes out of business or pivots, your image will no longer work (I think?).
- Your software will not fit naturally into your users' deployment environments. It will not by default show up in their administration tools, know about their VPNs, integrate with their logging infrastructure, or appear on their graphs.
I think this makes a lot of sense as a low-friction way to distribute software, but if you're writing code that people will care about in a few years it shouldn't be the only way.
In my opinion, web apps and mobile apps are steps in the direction of Desktop Apps. In my view, the only practical way we will achieve both the convenience and security that users expect (and no one on the desktop delivers) is to package applications as Xen/Qemu-style images running distros in the spirit of Damn Small Linux where each VM is completely specialized to run (and keep updated) one and only one application.
Every other implementation I've seen requires both too much security/administration expertise from my Mother and also, at the same time, too much expertise from the millions of random, BS developers around the world.
Certainly one could just create a tar ball of a terminal when logged into it and download it, so the data is exportable, right? Terminal could make that more convenient for sure, and probably will do so.
Software updates could be done the same way it always is: Run a script in a terminal that updates all packages. One could snapshot first, and verify that the updates do not break things.
After a few years, it's a safe bet that updating will break something. At that point, assuming you even notice the brokenness, you've got to either fix it manually (without necessarily knowing how to distinguish a working system from a somewhat-broken one or where to start debugging) or give up. I'd expect most users to give up.
Yea single point of failure oriented around this one vendor most likely. Proper build processes should always be followed so it will work in any environment.
Also this seems VERY expensive compared with other VPS hosts. I'm using vultr and it seems a lot cheaper. $15/month vs $116.80 for rougly similar spec.
Don't worry about complex package management systems, or what environment a consumer of your program might have.
Just give them a copy of your environment: it will always work in the future."
I'm not convinced that a virtual machine snapshot is an adequate replacement for wrestling with a package manager. If all you distribute is a VM image, then:
- Users can't easily run your software without provisioning an entire virtual server and, as far as I can tell, giving Terminal money and their email address.
- Without active maintenance on your part, the other software on the image will get out of date. Security holes will be discovered in the versions of nginx and openssl that your image uses. Have you ever tried to upgrade a Linux box that hasn't been touched in a few years to the latest version? After a few years, every potential user of your software will have to go through that first.
- If Terminal goes out of business or pivots, your image will no longer work (I think?).
- Your software will not fit naturally into your users' deployment environments. It will not by default show up in their administration tools, know about their VPNs, integrate with their logging infrastructure, or appear on their graphs.
I think this makes a lot of sense as a low-friction way to distribute software, but if you're writing code that people will care about in a few years it shouldn't be the only way.