polvi

A new spec, TPX, which is meant to enable building SaaS where the user brings their own inference:

https://tokenpony.dev/

It has a few potentially interesting side effects:

- enterprises can plug their preferred LLM into the SaaS they use.

- self hosters can extend their rigs into the web.

- simple SaaS products can offer LLM integrations without their entire pricing model being upended by LLM hosting and infrastructure.

- we can all live like Ender in Xenocide and have a personal AI that has context on everything we are doing.

- have a no op provider for people who are anti llm.

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.

https://github.com/docker/docker/blob/master/trust/trusts.go...

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.

Links to docs, etc, here: https://coreos.com/blog/digital-ocean-supports-coreos/

Sounds like a good time to use the equity equation:

  http://paulgraham.com/equity.html

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:

http://coreos.com/blog/coreos-beta-release/

Lots of people playing with it... it is in a similar state as Docker, in that it is "pre-production" but people ignore that...

OK. We'd love to get your help getting a special use address: alex.polvi@coreos.com

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.

Which certs are most important these days for govt use? Or does it depend on which department you're going for?

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.

CoreOS is like dom0 and your containers are domUs. Shared kernel, but LXC for isolation.

We need a better way to explain this...

The project is pretty young, but we are already seeing a pretty strong community coming together:

http://coreos.com/docs/etcd/#libraries-and-tools

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.

Not at the moment. That said, we will be publishing raw images that should be portable to just about anything.

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.

Sorry for the confusion, you don't need to register for anything.

SDK (roll your own) docs here: http://coreos.com/docs/sdk/ Our EC2 images: http://coreos.com/docs/ec2/ 46 repos worth of source here: https://github.com/coreos

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.

I'm curious what type of deployment APIs people want. It is the docker rest API + git push for your own code? Should we be using heroku APIs? Are we going to invent something new like OpenStack did?

Rackspace is investing heavily into the cloud. The Cloudkick acquisition was part of that. I am extremely happy to hear that the CP was one of your major pain points, because it is one of (if not the top) priority to improve. The team that is based in San Francisco is working directly on that project. If these sorts of problems are interesting to you, please let me know!

I'm one of the co-founders of Cloudkick (YC W09) and now part of the Rackspace. I wanted to reassure everyone that this is a migration, not "killing" off your slices. The Rackspace Cloud is based on the Slicehost technology, but has the full support and momentum of Rackspace behind it.

If you have any questions, concerns, or would like to discuss this with anyone at Rackspace - please do not hesitate to reach out directly to me: alex.polvi@rackspace.com

Congrats guys!

Another cool trick: Integrating Cloudkick tags with Fabric. Using the Cloudkick API - you can express things like "run certain_func on everything tagged 'loadbalancer'".

https://support.cloudkick.com/Integrating_Fabric_with_Cloudk...

We dog food this for all of our production deployments. For example, when we ship a new version of cloudkick.com, we just run "fab ship", which looks for all servers tagged "cloudkick.com" and runs the appropriate deployment script on each of them.

Tagging can be done through the CK UI, automatically with the agent, or with things like puppet or chef. This allows you to fully automate deployment and other tasks around groups of servers.

Sorry - deleted my comment because it sounded too rude.

We're on the same page. My argument (for those interested!) was to spend your money once you know what to do with it! No reason to wait. This is not directly related to this idea - which is about not losing check where your cash came from.

Yes, we were afraid that we would push the thing over its limits... thus smoking the turkey at 200-250F. For a little while (and you'll see it in the graph in the post) the thermometer registered 32F because we pushed it too far. Once we got the temp below 300F, it seemed to work just fine.

Why would google do this?

I feel like we should give the moderators benefit of the doubt on this one. HN has been gradually shifting away from quality content, so any effort to correct that is kindly appreciated. Like any process, mistakes are occasionally made.