nessence's comments

Hi, I'm the author of RLPx. Great post and thank you for sharing! Looking forward to more.

On iOS9, iPhone6: The comment box and comments overflow which require horizontal scrolling or zooming out. It worked better before simply because zooming in (double tap) is easier than zooming out (pinch).

Hyperledger's home page talks about a protocol, pools, consensus, security, and decentralization, however, none of those features exist in the codebase. Proof of work and distributed networks are why bitcoin and others are more complex than a list of node URLs and a simple database model.

After looking through code, a number of concerns are also raised:

- key pairs use RSA - identities are based on MD5 of RSA public key - no p2p protocol for nodes - lack of proof of work (more on that below)

As-is, the project is a rails application which references accounts by MD5 of the public key, a postgresql database, and a REST client. In other words -- basic rails ledger app plus some PKI.

I see a significant issue with hyperledger, in that the pools are, by nature, private. The only verification a client can perform is the SSL certificate. A pool owner, if they wish, could change the account balance on all of their private nodes and there would be no public record of the change or the previous history. Yes this would require collusion of some kind, but even for 10k nodes, such data can be changed in seconds. Without a blockchain, how could anyone prove otherwise?

I see the potential for companies like quickbooks, paypal, or even banks, to create public REST interfaces for their account ledgers. This seems inexpensive for a bank to do (compared to a p2p network), and, we'd have the trust of the bank. This is money after all, so, I'd trust the bank over a psuedo-private network.

Looking forward to see how hyperledger will approach the problems described above. I would be surprised if the end-result isn't similar to bitcoin.

Perhaps this could be good to introduce a little at a time. Like musical instruments (drum kits) or building blocks (legos). As a parent, I agree, that surrounding children with technology all the time can distract them from learning more important social skills. At the same time, I know my son is going to be asking me all the time "How does this work? How does that work? etc." And, unlike a software program, this provides a tactile experience which I think he'll be able to relate to when I say "Self driving cars work like your little robot".

LiveJournal doesn't route messages. It performs database queries which renders to HTML. As a result twitter will broadcast what you say to all of your followers, immediately, to their cell phones. This isn't something LiveJournal's architecture supported.

IRC has no such long-established functionality. You can MSG a #channel or a user and that's it. User's can't follow each other and there are no lists. These followers and lists are how twitter routes messages, not a channel.

Such a simple difference makes all the difference. In this case, enough to file a patent.

If they didn't file a patent someone else would have.

The patents involves routing messages with emphasis on followers. Everything previous I'm aware of has been multicast based or address based, like email or mailing lists. Most internet and application-layer protocols are destination based. Where is a protocol that says "Route this message based on who is interested in the source."? All I find is "send this message there, based on X, or, send that message here, based on Y"; both destination based. Would be interesting to know or hear of past protocols which are more similar to twitter's patent.

This doesn't help adoption like the article suggests; what it does do is shave a few milliseconds and overhead off the initial connection which is great for thin or long pipes (low bandwidth or high latency). Otherwise, in contrast to the article's statement about SSL not being implemented because of the encryption overhead, false start doesn't change much.

The bigger picture is that false-start will make google's upcoming SPDY handshake faster too; then, because SPDY is a more aggressive with the initial connection (CWND, push support), the packets saved by false start are used to push content. Without false-start, an initial SPDY connection would be encumbered.

Ask your investor.

As for the title of your question, sure, PHP/MySQL are stil practical. If the answer to your question were no, then that would mean companies like Facebook and Yahoo aren't practical.

With regard to your future decisions, you might strongly consider another language and framework, not because one is more practical than another, but because the developers behind that framework may have more of a propensity towards the context of your startup. So, for example, Ruby has a large web application community, Python has a large scientific community, and Java enterprise.

The primary contention behind PHP has largely been it's limited OO and speed, as compared to it's brethren interpreted languages. You can, creatively, do advanced things in PHP which are done in other languages, but it's not as straight forward and often clumsy or not supported. That said, PHP is simple enough that large implementations can easily modify PHP for their own use; considering how slow PHP's codebase moves, forward compatibility is far less of an issue.

All together I wouldn't base your decision on speed. Computing power is cheap now and all of them are feasible as far as speed is concerned. If you need to build something NOW, strongly considering going with what you know. If you have more time, consider writing something cliche like a multi-user blog or twitter platform with each framework -- you'll be exposed to patterns you haven't seen before and can also figure out what you like and don't like.

Unfortunately, this is a common response from upper management.

In larger companies, one way to get around this, is to go to Human Resources instead of your chain of command. Let them anonymously handle this issue. If your company doesn't take action then you can continue discussing the matter with HR until it's resolved.

If the company isn't large enough to have an employee handbook and HR then could report to an officer of the company and note that you wish to remain anonymous and that you're genuinely concerned about company security.

You could also consider requesting a meeting with officer+manager or HR+manager and disclose to both at the same time.

I don't see any company in their right mind firing you if you do this -- and are genuinely concerned for the security of your employer and it's clientele.

The chart excellent for visualizing one's contributions against and general activity. Would it be possible to generate a similar graph for other mainstream languages, gcc, and linux?

Wonder if the post-2005 spike would be similar for all interpreted languages, or just python.

Last line is great:

"If you take out the 20 best transactions, our record is a joke," he admitted. "The 20 best transactions occurred over some 40 years — that's one every two years. And we work at it all the time. Life is not just bathing you in unlimited opportunities, even if you work at being able to find them and seize them."

Nice and clean look. Have you considered lexical parsing to generate a list of trending phrases?

I suppose there are several possibilities to track trends this way.

Great job.

That's a much better way of looking at this post.

I suppose, I could've phrased the post: Is a link full of SEO spam, aa links, and ad networks a legit HN post?

I guess from the upvotes and comments, it is. I was strangely curious.

Is HN really the new place for book spamming aa links?

Which books don't matter. Half those are outdated or will be by the time they're read.

That sounds like a more expensive long-term process than finding an applicant who is better qualified.

Maybe the OP is better finding a startup or open source project where he can learn at a faster pace. I suspect facebook maybe a tad too busy to help him along.

I don't think interviewing for highly technical positions at Facebook could be "prepared" for, not especially, by reading so many books about high-level subjects (ex: Visual Basic).

A better approach would be books involving POSIX standards, implementations of all (current) OSI layers, compsci algorithms, how compilers work, and how various runtimes work for various interpreted languages and how to debug them (PHP, Ruby, Python, Obj-C, Java). None of these have anything to do with unix system administration, user permissions, shell scripting, or web servers.

"What I slowly understood while I was talking with Tom Cook was that this was not a discussion on scalability on a macro scale, however it was it was discussion of scalability on a micro-scale."

You maybe misunderstanding macro and micro; scale is a function of both, not one or the other.

I can't help but notice the circles; they remind me of (the late) OpenSolaris logo.

I'm working on a system which is similar but higher volume.

Have you done any benchmarks to test thousands of updates per second?

Same, but on the front-end. What is the impact of generating 10 reports per second for 2 hours? Do the writers get behind?

You won't have scaling issues in until the front-end hits some threshold of x queries per y updates, with x servers.

Good presentation on another application of mongo.