justinsb

95 ms·

751.
by justinsb 17y ago
OK, serious question to you as a security guru: Shouldn't we always assume that every host outside of our control is compromised? So why should I care how long it takes someone to shut down a compromised host? I think there are lessons we
752.
by justinsb 17y ago
Ah - sorry! I hope Slicehost was simply going through their own process; notifying the customer and helping them to resolve the issue: the server may have been running a business that is multiple peoples' livelihoods. Those processes take
753.
by justinsb 17y ago
There are hosting providers who openly advertise servers for sending spam illegally. The idea that you can achieve security by shutting down your attackers is ridiculous. Had slicehost acted more rapidly, Atlassian would have been hacked
754.
by justinsb 17y ago
Wow - you're certainly living up to your username :-) Shutting down a server doesn't stop the hackers using one of the other thousands of servers they have compromised. In this regard, trying to respond to an attack by shutting down the se
755.
by justinsb 17y ago
I dislike the implicit presumption that people on the Internet owe it to you to shut down their server if (you say) they're attacking you. I strongly feel that you should presume that your servers are always being attacked, and it's not he
756.
by justinsb 17y ago
I didn't mean to criticize. There were mistakes made - there always are. But amongst the list of mistakes, I would not put Slicehost's slow response anywhere near the top, and I'm surprised that anyone (particularly someone whose opinions
757.
by justinsb 17y ago
Really? * Passwords hashed with SHA-512 _unsalted_ * No lockout / notification after hundreds of thousands of failed logins * XSS vulnerability * Able to change the configuration to upload executable scripts * SSH password authentication en
758.
by justinsb 17y ago
A good idea. Perhaps we should also invent some form of Structured Query Language so that we can express these data operations.
759.
by justinsb 17y ago
My iPad already has a nasty looking scratch on it, so it definitely needs a case. I've seen these cases (they're made by an awesome guy who's a friend of mine) and they're really beautifully made - the sort of hand-craftmanship you just do
760.
by justinsb 17y ago
But last year, CouchDB was the future. Today it's Cassandra. In a few months, it could well be MongoDB or Redis. Even if Cassandra ends up the NoSQL winner, I'm pointing out that you'll have your hands full dealing with 'must have' featu
761.
by justinsb 17y ago
They're certainly fairly big reasons not to use Cassandra, and as such I'd put them in the objections bucket. If you're objecting to the fact that I phrased them as questions, just pretend we're on Jeopardy :-)
762.
by justinsb 17y ago
It's you that pointed out that we're on the cusp on NoSQL convergence. I'm sure the end result of that will be better than NoSQL today, but any project merge or convergence of this kind is going to be pretty painful for those using the pro
763.
by justinsb 17y ago
Perhaps not, but this doesn't make them unimportant, and again this is why it's clever marketing. Frame the discussion in terms of things that you do well, even if they're not the most important considerations (e.g. "one keyspace per insta
764.
by justinsb 17y ago
I'm not going to treat a cosmic ray corrupting one single network packet the same way I treat a hurricane cutting off power to a datacenter for 2 weeks. I do see the intellectual appeal in doing so, but we'll just have to agree to disagree
765.
by justinsb 17y ago
I meant this comment in a positive way: I genuinely think this is smart marketing. I think the real objections would be things like (and I'm not necessarily saying these are true/false, just that they're the ones that people should really b
766.
by justinsb 17y ago
You choose your quorum trading off cost/complexity vs risk-tolerance. You ensure that not forming a quorum is impossible in scenarios that you care about. e.g. You may decide it's OK not to form a quorum if the entire USA power grid goes
767.
by justinsb 17y ago
Clever marketing: include the objections which are false, ignore those are true.
768.
by justinsb 17y ago
Quorum protocols are the simple mechanism he's talking about. The argument he's making is that you shouldn't be so binary about saying 'well this subset of nodes is unavailable, so the system is not available'. That's why CAP is so overa
769.
by justinsb 17y ago
Agreed, but he's addressed WAN partitioning very well. Editing: "[Consider] a partition in a WAN network. There is enough redundancy engineered into today’s WANs that a partition is quite rare ... the most likely WAN failure is to separate
770.
by justinsb 17y ago
I think Stonebraker is right: CAP has been dramatically over-applied.
771.
by justinsb 17y ago
Well, if you promise it won't annoy you: Yes, Yes, Correct, Yes (for non-pathological workloads), Choice is good
772.
by justinsb 17y ago
It might seem to you that we can answer these questions without revealing secrets, but consider that (1) I've not been answering them and (2) you're asking whether we can do what was thought to be impossible, so real answers will necessaril
773.
by justinsb 17y ago
Ouch - aren't you getting a little bit personal here? I'll try to remain professional, and I'll accept the fact that you're quoting things you didn't say, as the re-write was clearer as to your intention. When it comes to scaling, there's
774.
by justinsb 17y ago
Just because Oracle isn't using the exact same techniques as Cassandra, that doesn't make Oracle's ability to scale fictitious.
775.
by justinsb 17y ago
Actually, in the distributed database field, 'partitionable on the fly' makes a lot of sense. I used this to infer the poster wasn't really familiar with the CAP theorem (which is only formally expressed in the proof), but it seems this wa
776.
by justinsb 17y ago
I think your performance here stems more from configuration than from MySQL vs Redis. If you're using Redis in-memory, if you dedicate the same amount of memory to your database, you should get roughly comparable performance between MySQL/
777.
by justinsb 17y ago
The reason why I mentioned Oracle in the demo is precisely because of the whole CAP debacle. So many people talk about CAP as if the SQL database was itself an impossibility, much less Oracle's scalable offering - but you can pick up the p
778.
by justinsb 17y ago
We're looking for early-adopter customers with hair-on-fire problems with their database that would also make good reference customers in a few months. If you fit the bill, please contact me! Otherwise, sorry, but you'll just have to wait
779.
by justinsb 17y ago
No - the scalable database is our own technology. We looked at writing a MySQL/Drizzle storage engine, but there's a lot of pieces that are different that stretch up through the stack, and I was a bit concerned over the MySQL licensing now
780.
by justinsb 17y ago
Very interesting - obviously your employer is considerably ahead of the curve compared to where the rest of the market is right now! Care to introduce us to the right person on the AppEngine team? Imagine AppEngine with full SQL support...

More ›