deitcher

Pretty cool. Is there a write up on architecture and usage models? I’d like to see it.

I was a happy couch 1.x user, but moved away with 2.0. Nothing specific about it, just needs and timing.

The primary focus is, indeed, archiving (and replaying and sharing, with ease) states of data. Merging has been explored, but nothing concrete on it yet. Even something relatively simple, like merging code, often requires a human to resolve (sometimes with real effort). Imagine trying to do that with filesystem snapshots of database files.

We are exploring it. We have some thoughts on higher level understanding of data that might make it possible.

But definitely starting with the basics, as you said.

Would you mind sharing more details about how they are confusing? Always happy to take feedback. Feel free to comment here or on the community Slack, although a GitHub issue may be the best place. Whatever works... and much appreciated.

I have seen a growth of such "vcs-like" databases, but I think the preponderance remains SQL stores like MySQL/MSSQL/Postegres or NoSQL like Mongo/Cassandra/Redis/Couch/etc. For those - or anything that has its own model of storage or processing and, in the end, is backed by filesystem-type storage, dotmesh provides a really nice solution.

I haven't used Relaxo itself, but personally, I like the fact that independent groups are thinking of version control semantics for data. Tells me it is heading in a positive direction.

This was a lot of fun. I don't care that it isn't hyper-practical, or a jQuery plugin may or may not exist. We aren't that serious about ourselves, are we?

Actually, it is an inconvenient insecure mess. It just looks good at first blush. Here is my take

http://blog.atomicinc.com/2015/03/16/yahoos-on-demand-insecu...

I wonder if they put a college intern in charge of authentication services...

CrashPlan since 2006, Mozy before that. Once every quarter or two, a full Time Machine to a USB drive.

Not that I am in love with "World Backup Day," but I think it is worth starting the conversation why people do not back up?

Personally, I am surprised Microsoft or Apple has not bought out CrashPlan or Mozy (from EMC) or Carbonite and made it standard on their platform. Apple especially, since it already has recurring services it charges for.

Come to think of it, great concept for my next article. But I wanted the discussion.

It was, I just didn't know it at the time! I was simply looking for some way to write emails and spec docs in a way that everyone would have a common frame of reference with zero extra work.

Yeah, in storage (as above), I use epoch all the way through and convert as needed. But as the thread above shows, not everyone likes this path...

I had not thought of that. Ha!

I would go for UTC, since that is what 99.99% of the people think of (and so few even know about TAI, except for the smart ones like @jameshart! :-) )

And JavaScript is milliseconds as well. I think either would be fine, as long as it is an agreed standard. Personally, I use ms, because most programming langs can instantly convert with any additional math. But it probably is wasteful. Then again, 1000 is just a few bits on each...

Fair enough @pimlottc. But most of the time I am far more concerned with accurately capturing a moment in time than I am with making it instantly readable. I also have helped some companies that ran into serious datetime management issues when they worked with strings that led engineers to assume a certain timezone, others to assume others, and chaos ensued.

Epochs may not be instantly readable, but they do force everyone onto the same page.

In any case, I tend to view a timezone as a separate piece of data than the actual moment in time (but I know others have a different paradigm): datetime = accurate moment in time; timezone = the timezone for which this should be viewed, or was captured or, etc.

Patent trolls are a major issue, especially for tech companies. I always am heartened to read stories of people standing up to these leeches.

Dunno, I always liked storing date/time as epoch. Every language under the sun seems to have a native method for working with it. Yeah, I need to deal with de/serialization, but it is a small price to pay, no?

I love it. When I first started in IT (1994, don't ask...) working with London and Tokyo and San Fran and Singapore and everyone wrote dates differently. I just started writing YYYY-MM-DD everywhere, and all of the questions went away.

All of these have the same problems. If the client encrypts, then the client can be subverted. With webmail, the client is downloaded every single time, and thus can be subverted on the server.

I don't like this. I would like to see a standardized html way to load html partials into other html, similar to ng-include. I think that is clean. But to start mixing logic? How are you supposed to render a JSON array loaded via ajax? How do you put in authentication information or headers? How do you do error handling? This is the stuff that is handled by angular or ember or knockout or aurelia or etc.

TextMate or SublimeText support anywhere in the future?

No debate, I agree with everything you have said. But sometimes you have to clean that garbage up because it does matter to the market.

Yes, but engineering is cheaper than running after real-time problems.

That is what I like about the cloud. Running in your own hardware lets you be, well, "lazy" about application architecture. Running in a place where it is shared and instances can disappear forces you to design a lot more robustly and nimbly.

Of course, that design discipline is great wherever you are running....

Oleksiy, can you share the economics? You said 50% savings. What was everything you had running in EC2 (easy to figure out the costs), what were your equivalents in softlayer? Would be very interesting to see the economics.

Amazon is not know for posting operating profits, because they plow funds back into new research and businesses. But they most definitely operate with gross margins on everything they sell.

Update: in FY2014, they sold $89BN ($70.1BN in products, $18.9BN in services), and their cost of sales was $62.8BN. I am pretty sure that their margins are razor-thin in retail, but the service side had higher margins.

If Yahoo really thinks that, they have issues with security... oh wait, they do! :-)