trekkin

GWT generates very performant code, even in high-CPU scenarios like hashing/encryption (and please don't spam the Matasano article about dangers of encryption in JS - it is not relevant here).

I implement high-performance software systems in C++ as my day job. The software has to compile and run on Linux, Solaris, and AIX. The same code is 2x slower on AIX (Power) and 3x-5x slower on Solaris (Sparc) than on Linux (x86). So say whatever you want about theoretical differences in architectures, but in the real world Sparc and Power systems are absolutely not competitive, both on price (absolute $$, and per CPU) and performance (per CPU - they do have more cpu cores, usually).

check AES.io

Most consumers want convenience first, security second. Evernote just targets the mass market.

That's why client-side encryption is useful - even with the company (Dropbox) not leaking/selling their users' data on purpose, it is easy to inadvertently leak it.

Proper client-side encryption, while often not appropriate in critical environments, is useful to protect against this type of situations.

Disclosure: I run AES.io

Non-technical co-founders should take care of the business side of the start-up equation - marketing/sales/PR/community building/fundraising/etc.

The problem with GWT is that it appears to be a low-priority product at Google - it took them more than a year to release v 2.5 vs 3-4 months for 2.4 and earlier. And we all know what happens to low-priority products at Google...

Sorry, by "proprietary" I meant "custom". I admire people who have skills and dedication to built OSS, this was just a wrong word to use.

I completely agree that for specific uses Riemann is great. Your post was, though, about the performance/throughput, and so my comment was about the performance/throughput. Streaming messages/events over the network is an old problem, with well-known limitations, and this was what my comment was about.

You can put as many "events" in the body of an HTTP POST request as you wish. What really matters in distributed messaging systems, from the performance point of view, is the number of distinct messages per second.

And if a system designer wants to send a stream of "events" to another system to be acted upon, and if this designer cares about throughput (which is assumed here, given the title of the post), then this designer is likely to choose a faster messaging system, especially if it is more flexible, due to its ubiquity and universal support, protocol (e.g. HTTP) over a custom protocol.

Well, I'm sure there are specific use cases where Riemann would be preferable to a generic web server. But for most developers in most situations, it is a no brainer to choose an HTTP-based protocol with off-the-shelf HTTPD server over a 10x slower proprietary system.

>> Throughput here is measured in messages, each containing 100 events, so master is processing 200,000–215,000 events/sec.

So in reality it is ~ 2k messages/sec. This is a rather poor throughput, as even off-the-shelf generic web servers (e.g. nginx) have the throughput an order of magnitude higher, and proprietary systems can reach 500k messages/sec over the network.

I have the same impression.

Many start-ups are built by well-meaning people who have no formal CS or even engineering background and thus are somewhat out of touch with what it means to build a robust system. It's natural for people to focus on "what's important" and ignore boundary/edge conditions, while in reality 90% of sound engineering is getting boundary/edge cases right.

And as most of such start-ups use Ruby/Rails due to the easiness of "getting it up and running", and thus they inject the Ruby/Rails ecosystem with this "focus on what's important" mindset, important boundary issues, including security, are neglected.

I'm not saying timing attacks against interpreted code are impossible. I'm just saying they are easier to execute against native code, and thus have nothing to do with JS crypto being less secure than native crypto.

Exactly - interpreted code is harder to do timing attacks against because interpreters add a lot of timing "noise", while native code is much more consistent re: time taken to execute a specific routine.

Mega is not the first one. AES.io (my company) and several others have been available for some time. Mega is the first one to bring client-side JS crypto into public discussion.

> timing attacks don't necessarily need access to the actual machine to work. his point is valid because a timing attack may arise from the differences in time it takes to receive a response from the server.

That point of yours actually points to a potential vulnerability in server-side (possibly native-code) encryption, not client-side encryption, which we discuss here.

I completely agree with you that anything can be cracked, and JS crypto more so than _some_ native-code cryptosystems. My point is that using JS crypto for some non-critical applications (e.g. as an alternative to corporate IM/email) can be useful and convenient.

As there can be backdoors and bugs in OSes and hardware, any crypto code done on generic-purpose computers with standard OSes (Windows, OSX, Linux, BSD) is not safe. That does not mean it is useless.

The same is true for JS crypto - yes, it is not as safe as crypto in native code, but it can be used to add an additional layer of security in certain (non-critical) use cases.

[Disclosure: I run AES.io]

For example, AES.io

Investors are probably more guilty here - entrepreneurs, most of the time, are trying to "create value", in PG/HN speak. Investors who swindle entrepreneurs are just making money off others' efforts.

Try AES.io, or SilentCircle, or HushMail. There are encrypted communication services available, the problem is that most Internet users don't think they need encryption, or do not trust it.

If your system is hacked, _using_ any password manager is insecure. Some password managers also have poor encryption, so even read-only access to your password database can be bad.

KeePass (KeePassX in Linux) is one of the best, but a simple keylogger can get your "master password" when you enter it, and thus access to your password database.

Nothing is absolutely secure, there are just degrees of relative safety.

>> No one comes close to Google's reliability and ability to scale.

Absolutely not true. Google AppEngine (one of the core technologies the link refers to) has issues almost every week, not even close to the stability and reliability of AWS, for example.

Very true. XFCE & LXDE are the cleanest DEs by far (among the top five)

Publish a video review (preview?) of your game, post a link here, and you may find the person you need. "It's a cool game" is not enough, most of the time.

Let me try to make my point by a "soft" analogy, in your terminology.

If a fiction book has a great, gripping plot and interesting, relatable, wonderfully done characters, then weird spelling and heavy sentences are not a big deal and can be easily fixed by a competent editor. But nothing can save a very grammatical and clean-written text that is just flat, boring, or makes no sense at all. Ask any publisher - which kind of books they prefer?

Similarly in software, getting the big picture right is much much more important than "elegance" in each individual line.