I'm not saying the HN crowd didn't miss a $10B opportunity, but they also weren't exactly wrong.
2,579 karma · joined December 14, 2010
I'm not saying the HN crowd didn't miss a $10B opportunity, but they also weren't exactly wrong.
Just a minor note on this: Org-mode was created in 2003 (the syntax a bit earlier) and Markdown in 2004, so I think this was a case of parallel evolution, each unaware of the other, not intentional deviation.
Edit: And the use cases were different. Org was designed as a syntax for an outliner, and Markdown was designed as a syntax for prose. Both are plain text and optimized for readability in their pre-processed form, but maybe it's the fact that they are so similar that's remarkable.
https://github.com/knative/serving/blob/master/docs/spec/ove...
Or a little higher-level:
https://docs.google.com/presentation/d/1CbwVC7W2JaSxRyltU8CS...
There are a lot of technical docs in the individual repositories. You can get started, for example, with the serving docs under:
https://github.com/knative/serving/tree/master/docs
Same for the other repos, like build and eventing.
Thanks for asking!
These are early days of course, but given that the goal is to codify the commonalities (the 80% we all do roughly the same anyway) and to improve customer workload portability overall, I hope to see new products built using Knative, and existing products re-base on Knative as well.
Good questions, btw!
We decided to announce this first thing with the blog posts just to get the word out as soon as possible and give our amazing partners (Pivotal, SAP, RedHat, IBM, and more) a chance to share their news as well.
And frankly, it's just more fun to run an open source project out in the open, so we were pretty keen to flip the git repo bits to public as early as we could. : )
I expect that some of this will end up upstreamed into Kubernetes proper if it's broadly useful (autoscaler work, to pick an example), but this is still super early so let's see what people want.
And yes, we're documenting the control plane APIs, the data plane requirements, and the contract for serverless container environments, with the hope that they can be reimplemented consistently wherever needed.
One of the explicit goals is workload portability, so separating spec from implementation is critical.
Pynchon. DeLillo. McCarthy. Roth...
Edit: Morrison. Updike. Mailer...
There was some interesting commentary in this thread about cultural appropriation and whatnot, which seems to me to be beside the point. My intent was only this: if there are other people rightly upset by something, it doesn't matter if you're not, it doesn't even matter if the majority are not, it's still valuable to have empathy for those those that are. That's all.
I think this research is spot on, and can't wait to have it on my phone. And I love taking photos the old fashioned way, too.
(Sorry I upset you, btw.)
As a CEO he just associated his company with poor decision making.
If this guy has a lawyer, he should consider listening to them.
But IANAL, so who knows.
As an emacs user, this single issue has been the show-stopper that prevented me from investing in bash on windows, even though I would like to.
[1] https://superuser.com/questions/1088250/windows-10-linux-bas...
https://cloud.google.com/free/docs/always-free-usage-limits
They are (IMO) quite generous. Definitely sufficient to get a good feel for the platform and run some personal workloads.
Disclaimer: Nothing to do with this launch, but I do work on GCP.
https://cloud.google.com/free/
"Use these products for free up to the specified usage limits during and past the free trial. These usage limits do not expire, but are subject to change."
Includes gratis usage of App Engine, Compute Engine, Cloud Datastore, Cloud Storage, Container Engine, and much much more.
https://research.googleblog.com/2016/09/image-compression-wi...
Here's the paper:
https://arxiv.org/abs/1608.05148
(No connection to the authors, just found it super cool when I read it a few months back.)
The question to me is this: can we make it better for people who can't be there? (I.e., raise the foundation, not debate the ceiling.)
It feels to me that there's an incredible untapped potential of talent that simply can not relocate or even come to an office on a regular basis (due to disability, economic reasons, visa status, age, family obligations, etc).
If we can unlock that potential then there is so much more we can do as a society.
If anyone at YC (or anyone else) is interested in talking, please reach out.