trekkin

6 ms·

1.
by trekkin 12y ago
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).
2.
With Big Data Comes Big Responsibility(hbr.org)
3 points by trekkin 12y ago|0 comments
3.
How one man's private files ended up on Apple's iCloud without his consent(washingtonpost.com)
7 points by trekkin 12y ago|0 comments
4.
by trekkin 12y ago
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 wh
5.
Most Millennials Would Throw Work Friends Under the Bus for a Promotion(businessweek.com)
10 points by trekkin 12y ago|11 comments
6.
Stephen Colbert to succeed Letterman(bloomberg.com)
1 points by trekkin 12y ago|0 comments
7.
Paco de Lucia, Renowned Flamenco Guitarist, Dies at 66(nytimes.com)
70 points by trekkin 13y ago|16 comments
8.
by trekkin 13y ago
check AES.io
9.
by trekkin 14y ago
Most consumers want convenience first, security second. Evernote just targets the mass market.
10.
by trekkin 14y ago
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 envi
11.
by trekkin 14y ago
Non-technical co-founders should take care of the business side of the start-up equation - marketing/sales/PR/community building/fundraising/etc.
12.
by trekkin 14y ago
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...
13.
by trekkin 14y ago
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 performan
14.
by trekkin 14y ago
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
15.
by trekkin 14y ago
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 10
16.
by trekkin 14y ago
>> 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 s
17.
by trekkin 14y ago
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 focu
18.
by trekkin 14y ago
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.
19.
by trekkin 14y ago
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.
20.
by trekkin 14y ago
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.
21.
by trekkin 14y ago
> 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
22.
by trekkin 14y ago
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
23.
by trekkin 14y ago
For example, AES.io
24.
by trekkin 14y ago
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.
25.
by trekkin 14y ago
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.
26.
by trekkin 14y ago
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 simpl
27.
by trekkin 14y ago
>> 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 reliabilit
28.
by trekkin 14y ago
Very true. XFCE & LXDE are the cleanest DEs by far (among the top five)
29.
by trekkin 14y ago
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.
30.
by trekkin 14y ago
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 b

More ›