yid

Seems like its more geared towards matching relatively small template-based subgraph patterns rather than doing arbitrary walks efficiently. From page 9 of the user manual:

> Below is an example query matching a triangle over the employee-client graph:

    SELECT En1.Name, En2.Name, Cn.Name
    FROM EmployeeNode AS En1, EmployeeNode AS En2, ClientNode AS Cn
    MATCH En1-[Colleagues AS Cg]->En2-[Clients AS C1]->Cn,
          En1-[Clients AS C2]->Cn
    WHERE En1.Name = ‘Jane Doe’ AND C1.credit > 1000

S3 is more of a simple key-value store than a full filesystem (and for good reason). I suspect the reason their docs push the filesystem metaphor so much is because filesystems are more familiar to many people, and most filesystem semantics can be implemented using a key-value store. In that sense, there is no update() or append() in S3, just a simple set().

Your `friendship` table is a simple adjacency list representation for an undirected graph. As you point out, the main trouble in using a relational database for a true graph model is to process graph traversals, which you can do with nested inner queries, joins, or Postgres' WITH RECURSIVE. A graph database, for that reason, is usually optimized as a very efficient sequential JOIN machine, where you can imagine successive JOINS as connecting the endpoints of edges along a graph path.

By the way, if you're interested in graph representations for efficient querying, check out TripleStores [1], and the Wiki list on subject-predicate-object databases [2].

[1] https://en.wikipedia.org/wiki/Triplestore [2] https://en.wikipedia.org/wiki/List_of_subject-predicate-obje...

From TFA:

> The t2.nano offers the full performance of a high frequency Intel CPU core if your workload utilizes less than 5% of the core on average over 24 hours.

This means you get the full CPU if you have a bursty workload, and really is no different from what DO's policy is:

> We do not set a cap on CPU usage by default but we do monitor for droplets doing a consistent 100% CPU and may CPU limit droplets displaying this behavior.

In the EC2 case, the CPU throttling policy is just explicit.

[1] https://www.digitalocean.com/community/questions/cpu-usage-a...

> spread and Vsync/ISIS both struck me as perfect examples of the meme of poor quality academic code.

I was about to say that academic code is almost always poor quality, but that should never, ever apply to distributed systems code. If there's one thing we should see from academic distributed systems research, it's principled, well-constructed, solidly tested libraries, rather than wannabe commercial databases written by graduate students.

> In so much as a solution depends on "cleverness" rather than raw computing power, it'll have room for competition.

Unfortunately, it's looking more and more like it's going to be a competition on training data and raw computational power, and it's hard to compete with Google's corpora from the web, gmail, captchas, maps, etc. -- not to mention Google's tremendous number crunching resources.

> Running ECS is cool and all, and I know they do some container-specific VM optimizations, but I still know I'm running a kernel on a kernel, even if my VMs happen to share a host.

The cloud is great for distributed systems, and for these the "kernel on a kernel" cost becomes insignificant with the additional power allowed by the horizontal scalability of letting multiple computers talk over a network (not to mention network latency).

I'd be willing to bet that running on absolute bare metal is a sort of niche market in cloud computing that Amazon considers too small to get into.

> They pride themselves in fancy, fast, optimized graph storage and querying. But they don't seem to manage to implement a flag like that.

There are massive organizational worlds between optimized graph storage and the operations/customer support processes that lead to a bit like this being introduced and maintained. So it's not really ironic at all, because it's almost certainly not a technical issue.

But if the hypothesis is that thousands of little local functions can learn to recognize feature vectors, that's been a well-tested assumption in discriminative machine learning models for decades. Is there a biological twist to this finding?

That preprint seems to be missing every single figure. From the text,

> The key feature of the model neuron is its use of active dendrites and thousands of synapses, allowing the neuron to recognize hundreds of unique patterns in large populations of cells.

"active dendrites" and "thousands of synapses" sounds an awful like abstracting away a complex mathematical model to fit a particular definition of "single neuron".

> Unfortunately, I think Google people know and they just don't care.

If this is the case, then it probably means that a majority of people find the less-dense layout easier to read. It would also explain why Reader didn't have enough usage to keep Google interested.

> However the stakeholders simply don't care enough to do anything about it,

Perhaps that's a sign that "it" (smtp) now works well enough with the decades of engineering investment put into spam detection, access, standardization and inter-operability that have been put into it to not justify the massive investment that an "SMTP update fit for 2015" would involve.

> Are you drunk?

Your comment would have been upvote-worthy had you simply left this bit of snark out. How on earth do you think this is a decent thing to say to someone you do not know?

This is fairly simple to answer: $0. ACM does not pay royalties. In fact, most publications do not -- you grant a royalty-free license in order to be published.

Touche!

> I'm not sure what age has to do with anything.

I wasn't trying to be snarky, but a lot of exciting things have happened in PL design since 1988.

Is there a point to posting this (quite old) paper?

The blockchain (proof of work) is for voting.

> Does the business turn a profit? Is the profit greater than their payroll? How many founders know their EBIDTA?

The first two questions are considerably more important than the third. That many founders do not know answers to the first two is less excusable than knowing a fairly specific accounting metric.

You can build an https Cloudfront distribution from your S3 bucket -- faster delivery as well.

https://aws.amazon.com/cloudfront/custom-ssl-domains/

> Are you suggesting that WhatsApps business model was based on annual revenue?

Since WhatsApp was a revenue-generation corporation with a board of directors, like any other corporation, before their acquisition, and since I don't like to indulge in conspiracy theories, I'm going to assume that yes -- their business model was based on annual revenue.

> They're nowhere near relevant.

This doesn't mean that there aren't teams of people trying to constantly make those ads more relevant. And since not everyone at a Twitter can statistically be incompetent, I'm going to assume that the problem is actually quite difficult, and perhaps requires a large team.

In 2014, WhatsApp reportedly made $14 million in revenue. By comparison, Twitter made $479 in revenue in just Q4 2014. I think company size generally scales super-linearly with revenue, so a total staff in the thousands seems reasonable for a post-IPO company.

Are you suggesting that WhatsApp's model of organization is the norm for a sustainable organization? I think it's a clear outlier in many respects.

> 4100 employees for a service dedicated to moving around 140 character messages? Yeah, there might be a little fat to trim there.

Absolutely! You could probably get a single rack to handle storage and broadcast of millions of tweets per minute, perhaps hook it up to a Teradata appliance to handle search and storage at that throughput. Throw it in a nice distributed database indexed by user. Then just another couple of indices for the hashtags and mentions, and the follows/follower graph. Throw in another few tables for handling API permissions, managing schema migrations while ensuring that data from day 1 is still as transparent as yesterday's logs, a highly replicated ad server hooked up to a realtime recommendation engine that analyzes an active user's current stream and recommends the most relevant ad (to maximize revenue of course), set up a few staffed policy teams to comply with the differences in global regulations, handle lawsuits and legal requests, and of course keep competing for more revenue with the likes of Facebook and Google.

It's pretty trivial.

> if you want to capture any potential upside from your options, you're required to execute them, paying your own money for actual shares.

If you want to capture upside, then you must believe that there is upside, so then surely you can offset the cost of buying the options into your expected return?

See the part of the comment I quoted.

Well now you've changed the goalposts with "a reasonable amount of time" and self-study rather than industry experience. More to the "experience" point, I can't think of many jobs that will expose you to the sheer breadth of a good undergrad CS curriculum: think a solid foundation in algorithms, networking, calculus, linear algebra, databases, advanced algorithms (randomized, approximation), programming languages, compiler design, ai of various sorts, numerical methods, theory of computation, to name the big ones.

> There's just nothing in the field of computing that I believe couldn't be better learned by experience.

The rest of your post makes sense, but you lost me at this sentiment. There is a lot more to computing that information systems and programming. I'm glad your career worked out, but there is certainly much in CS that you will simply never learn in the field.

> you start to realize that the setup of a problem which can be solved by machine learning is actually worth more than the learning.

This is a fantastic point, but I'd like to also caution readers that they should spend some time understanding the elements of statistics and machine learning before jumping into theano or Weka tutorials. Lately, I've seen a lot of voodoo ML in the valley, starting with billboards on Highway 101 that pretty much just say "Artificial Intelligence & Machine Learning" along with the name of some company, like its some sort of panacea.

> Maybe more of us need to dream bigger, risk everything, and be willing to work just as hard.

What a curious take-away. I read it as even a hardened workaholic like Musk will crack a little without taking a break.