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.

The author completely misses here - probably due to limited exposure to real-life third-party code in real life production systems.

Code auto-grading, at least at Coursera, is usually done by running comprehensive unit tests, which extensively test border cases as well. These test suites are often 5-10 times larger than the actual submitted code, and it is difficult to imagine anybody outside of this type of environment spending so much extra time designing (and testing!) test suites with 100% coverage.

Moreover, code submissions have to comply with (or implement, in case of Java) predefined interfaces. And some courses (e.g. Scala) have style checker output taken into account (20% of grade is decided by the style checker in the Scala course).

In summary, well-thought-out test suites and interface specifications demand well-designed code submissions; in real life, poor comments or sloppy expressions are a very minor nuisance compared to poorly designed interfaces and forgotten border cases.

I keep my ideas in https://AES.io - one of the reasons I created the service.

Honestly, Udacity seems to be losing it. It has only had 14 courses for a while, while Coursera has 200 courses, and counting. And the universities represented at Coursera have better recognition/ranking that at Udacity.

Why would somebody invest in Udacity now?

Maybe. Or maybe this is just another plug - something accelerators are increasingly good at. It's becoming hard to figure out when an article, even in wsj or nytimes, is a hidden ad ("PR"), or genuine journalism.

It's almost impossible to reach 1000 req/sec in Ruby/Rails. It's relatively easy to reach 50000 req/sec in C++. Assuming V8 is about 3x slower than C++, it is not surprising that a move Ruby/Rails->node.js gets 10x throughput improvement.