"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.
Looks like they are running on AWS -- you can see in the video "xlarge" and other systems types that are named the same in AWS. Interesting how they are playing some "tricks" to enable some cool capabilities. I am willing to bet they have a AWS box running of each type and using Docker or something like that. Probably spinning up instance types as they are used up. I am also willing to bet that if they got some non-significant traffic, that 5 sec will be 5-10 min. Don't mean to throw cold water on it but over all looks cool -- not sure what I would use it for. I would love to see the architecture for this product.
Your explanation is clever and could account for most of the behavior of the product. Certainly the environments, rapid booting, and even hot resizing.
What's missing, however, is how they do machine state snapshots (not supported in any container system afaik). I know Xen/VMWare support these, but if they are running atop AWS they will not have access to the hypervisor. I can imagine kludgily running another hypervisor atop AWS, but there would appear to be a more clever solution.
Runnable provides containers across high-performance AWS virtual machines. We launch millions of containers every month. Publishing your own image is as simple as installing packages in our terminal and hitting "publish"
It will be great to support iOS. I've ended up buying apps that allows writing and running code on iPad and they are not even close to what this site does. Also, if you can support C# and Python, you would have covered a lot of ground.
Quick feedback: when you change the filtering on the left hand nav, you scroll to the top of the page. I really don't need to see the huge masthead (on my small Macbook Air, in Chrome, the masthead is over 2/3 of my vertical screen) again on every click. Just scroll to the top of the list/filter section, not the top of the page.
I would like to see some info on how they're counting CPUs in their pricing. 50 CPUs for $30/mo is too good to be true unless the CPU is not very powerful. Also, most apps that could actually use 50 CPUs would be hurt by only having 800 MB of memory. I think they should just price CPUs and RAM independently.
So someone turned Docker into an online service. Interesting. It seems promising, though not yet mature. For every day computing the cost still seems high however, and I worry about security. Still, it smacks of the future.
You are right that we don't use Docker, but we also don't use hypervisors which are too slow.
We are a lot faster than a hypervisor. Our machines start in 5 seconds. Neither can resize a machine up and down live without a reboot. None of them can do RAM snapshots.
Your demos show impressive speed in booting, machine resizing, and snapshotting. Kudos.
With that said, several hypervisors do support hot-resizing, snapshotting, and cross machine migration. Xen has excellent hot resize support, where VMWare has pushed hard for live migration and proper snapshotting over the years.
I'd love to learn more about the tech stack. Any blog posts I can refer to? How come you decided not to use Docker for something like this? Seems perfectly suited.
Thanks for the feedback everyone! We didn't expect this. If you are in SF, we have a meetup for data scientists tomorrow evening in SoMa at ThoughtBot offices.
I currently use http://nitrous.io for ad-hoc linux terminal sessions with an integrated editor, and it looks like this does pretty much the same at what will be (for me) a fraction of the price.
I like nitrous, so am unlikely to move away - but I will be checking this offering out.
The editor could probably do with some polishing, and I'd need an obvious way to create and set environment variables.
There's some confusion for me as to what it is you're selling. Is it an adhoc terminal people can spin up when they need - or is it an application server? If just the former, then why have gitlab, and ghost in your images list. If the latter, then why the auto-shutdown on sessions, and what is relatively a high price for hosting.
I, for one, love the name. (I'm impressed they were able to get the domain.) "Terminal" seems like a perfectly natural name for this sort of product.
Very excited to see this tech used for online computer science education. When I took CS classes (and TA'd them) it was always a royal pain in the ass to configure everything right on every student's personal computer / OS / etc. Being able to pre-install all the libraries, code, and data once and then blast it to everyone seems like a huge win. Not sure how the pricing would work for a large CS class (or even an online version) but hopefully they can figure that out.
I really like the idea of being able to take a snapshot of my scalable computing environment and sharing it with others. Everything looks slick - will definitely try it the next time I'm building/tweaking a ML model. Are there other solutions which enable the same ?
I participated in a user study for terminal, although it was a modified version marketed toward a specific use case. We came away quite disappointed in the product, primarily because it didn't include most of the community-provided features/functionality provided here on their full site.
Needless to say, we all walked away from the meeting, hit terminal.com and were puzzled as to why they didn't show us this version of the site. Our opinions/feedback would have been drastically different.
I'm looking forward to giving this version of terminal a proper run through. The overall concept I found very interesting.
If a process refuses to give up allocated memory (which is usually the case), ballooning will cause the app to swap. If the app's heap is fragmented it will thrash to death.
Xen/VMWare also support hot resizing of CPU and RAM.
What's interesting is that neither LXC nor Docker support memory snapshots (machine state), which Terminal.com has demonstrated. Xen, KVM, and VMWare do, but I can't really imagine people running these atop AWS infrastructure (Xen underneath).
This is a name quite worthy of the Hall of Shame. Yes, I fully admit that I have an extremely negative gut reaction. Why? Certain terms (like terminal) should not be abused, mangled, appropriated, or pilfered by a private organization.
Here are some logic-based criticisms:
1. A terminal (look at the root of the word) is not a computer -- it is an "end point" through which you can access a computer.
2. I don't think you can get a trademark on the name. If I'm wrong, then someone at the USPTO got bamboozled.
3. People like me are going to express negativity about your name. (But, hey, maybe any PR is good PR? Shameful, again.)
4. Where is the creativity? For shame, people.
So, please find another name, for your sake and ours. Groan.
P.S. I put CNN's "State of the Union" in roughly the same circle of hell.
Overloading a fundamental term within our industry is questionable. You can make something up, or use something from outside the industry, but please don't redefine a common and essential industry term.
For instance, you could call your computing product Hammer, or call a rocket Hammer, or call a person Hammer (Mr. Martel or Mr. Burrell), or you can make a carpentry tool called the "Martel Hammer" or the "Burrell Hammer" or the "Rocket Hammer" or the "Lambda Calculus Hammer". But if you invent a new carpentry tool that is not a hammer, you don't get to call it "Hammer".
It's completely overloaded with a generic tool that has been around for the last 40+ years and will continue to be around for another 40+ years. I can't imagine a worse name, other than maybe 'operating system' or 'computer'.
For context I was teaching a 'Girls Who Code' class last week introducing using command line tools to people that have never used them before. It's already hard to explain 'terminal == command line == console == shell'. I'd really hate if this company caught on and just confused the whole thing even more.
When dealing with any new and unfamiliar system, the best way to troubleshoot unclear features or generic errors is usually to hit up Google for those who ran into the same thing. Making your product ungooglable is a great way to ensure developers never touch it.
This was my first thought as well. This product name is the sure way to failure because it describes all kinds of things. Their product is one of the least significant items called Terminal, due to being the new kid on the block. They hide in plain sight.
No, it does not sum up what it does. "Terminal" is from "terminalis" meaning an endpoint to connect to a computing device. (The terminal itself does not do significant or interesting computation.)
From French terminal, from Late Latin terminalis (“pertaining to a boundary or to the end, terminal, final”), from Latin terminus (“a bound, boundary, limit, end”); see term, terminus.
6. (computing) In the context of computer hardware, a device for entering data into a computer or a communications system and/or displaying data received, especially a device equipped with a keyboard and some sort of textual display.
7. (computing) A computer program that emulates a terminal (6).
Does it not emulate a terminal and therefore qualify for number 7? It seems that when you start up one of the snapshots, it provides a persistent terminal session, in the browser. And isn't the browser itself a terminal for controlling a remote computer?
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.