All YC companies build technology, however many (most?) are building technology for markets that traditionally have not used technology in a modern way. These are things like cleaning (HomeJoy), flower delivery (Bloomthat), t-shirts (Teespring), etc etc. Theses technology enabled businesses are the ones that primarily use web/mobile, and thus all the jobs.
Really impressed with their openness on the terms of the deal. He disclosed valuation ($865mm-post) / dilution (7.5%) and their balance sheet ($22mm). Very impressive terms for that matter. Congrats on the round and success with the business.
As far as I can tell, the current implementation of signed images hardcodes the Docker, Inc cert-- effectively locking in users to only Docker, Inc's trusted images.
Ideally docker users could sign their own images and provide their own keys to do signature validations. What is the timeline on this work? With out this, "digitally signed images" means "locked into Docker, Inc- otherwise no security", and is very misleading.
A very basic implementation would be to read certs out of a directory on the filesystem and is how all other package managers handle this.
Edit: I missed the part in the post that even if the signature fails, the container still runs. The signatures do nothing. Got it. Preview.
MiniLock looks like a great option to introduce encryption to my non-technical friends. The alternative to minilock right now, for these users, is to do nothing.
Even if we do not like it, right now state of the art on file sharing (for most of the non-technical world) is an unencrypted email attachment. MiniLock looks like it might be something I can install on my mothers (non-technical) computer so that I can send her a sensitive doc (copy of my tax return, for example). This crypto system is sufficient for that use case, and the alternative is to do nothing at all. The alternatives are not GPG, or RSA, or whatever, because outside of the technical community people have no idea how to use these things.
(CoreOS eng here) We no longer have a Chaos Monkey. Since the beta release, the "Chaos Monkey" can be disabled via configuration. See the "reboot-strategy:" in this post. This is the recommended way to do that:
You'd actually setup it all up as you would if everything was on your localhost or dev environment. Meaning you'd need your master on 3306, slave1 on 3307, slave2 on 3308, etc. You'd still need to setup a configuration for each of these services, pointing to one another, but the configuration would be fixed.
Optionally, by giving the container direct access to the nic. Docker will do more iptables/veth-pair magic, but if you need direct access you can use other methods. We like systemd-nspawn, since it integrates nicely with systemd.
We intend to make it a primitive in CoreOS, so plan on it to just get faster (although we recently hit 20k atomic writes/s, so it is pretty fast) and more reliable.
Alex from CoreOS here: This only supports virtualbox at the moment, but we are actively working on adding VMware. Fill out the form on this page if you want us to spam you when we have the vmware image (or others): http://coreos.com/
We're based on the ChromeOS SDKs... which use emerge to build the binaries required to assemble the distro. You can think of emerge/gentoo as the toolchain used to build all the binaries. We also pull base system packages from upstream portage, then compile them all together in out image.
The form is mainly to send t-shirts to the people that try it out for us. We do have a profit motive, because we want this project to be sustainable. Similar to Ubuntu and Redhat.
These guys might consider allowing people to pay for more requests. Even with the source, it would be easier for some people to just pay you, and you can still keep everything open source.
I feel like we are early enough into all of this that we might have a chance at standardization... vs the IaaS APIs which have all diverged at this point.
co-founder cloudkick.com (YC W09)
https://news.infinitelogic.org/user?id=il_32f74db8