thadeus_venture

The fact that it's called the "talk back bot" automatically puts the author in the victim's chair. To think that a TWSS joke in a chat room not directed at you personally is offensive to you smells of deep irrational insecurity to me. A suspicion supported by the project name. I know women who wouldn't like that joke directed at them, and I don't direct it at them, and I know some who drop more twss jokes than I do. If you overhear someone on street say one though and your first reaction is to be offended to the point of writing a bot that spews quotes of famous women in the chat room, that seems pathological to me.

What makes it beneficial for ripping/distribution groups to coordinate like this? I've previously seen them agree on a common standard for the number and size of rar files a release is to be broken up into, and other things i can't remember the specifics of. Why do they do it?

PS: About time with dropping xvid for h264.

I don't give a shit.

"You're" instead of "your"? Really?

fn-arrow left/fn-arrow right is a pretty pathetic substitute for actual home and end keys. I've never used a Mac for a prolonged period of time so can't speak to other points, but I am baffled at how people can do anything without those keys. When I try to debug some code on one of my coworkers' Macs I feel like I suddenly can't type anymore because of their absence, not bs'ing or exaggerating.

What are the options for using pypy with wsgi?

Meh, who cares, TC was always yellow press to begin with. An added perceived conflict of interest doesn't change anything in my eyes, just adds to the drama of it all which is what the site thrives on in the first place. On a more practical note, whether the content of the site will be affected with Arrington leaving - that's to be determined by time only. My guess is it won't. On a personal note, I briefly met Arrington at one of TC conferences and he's an arrogant asshole, I would even say douchebag (he wasn't an asshole to me, that's just his demeanor), so if he doesn't get exactly what he wants that sounds fine to me.

Everyone keeps framing this as a competitor to the iPad, but it's going after a market that is not currently buying tablets at all. People who can't afford an iPad or don't want one at the current price:features ratio. If this means anything for the iPad, it's that it may expand the android tablet market enough to attract app developers, making it more sensible to produce an android tablet with high quality expensive hardware in the future, when the app eco system is more mature.

That is definitely plausible, but I'm more referring to the feature set, i guess i would clarify as the contract between them and the developer. That is basically memcached, from what i understood from their blog posts. As far as memcached itself goes, i hear it does what it does quite well, but that's ot.

So this is just a simple way to get some memcached instances running. I guess it makes sense for amazon to target memcached since it's still the most popular caching system in use, and probably the easiest for newbies to get into, but it is very old technology at this point. There is no built in support for clustering, replication, or durability. There are solutions out there that provide a much better feature set. Heh, where did the original dynamo paper come from? All in all, underwhelming.

EDIT: I guess i forgot to mention the most obvious reason of all to go with memcached - what they have rolled out is by far the easiest caching system to implement. Not trolling, just stating the facts..

I think one point has been ignored so far - this will be a really boring place to live compared to an average city. Can you imagine being stuck on a boat or a tiny island for years? That sounds like punishment to me.

Am I the only person who thinks this is a stupid question to ask? Either you are talking about a huge corp where you have employees that you can't trust to be honest about the amount of time they dedicate to the company, or a smaller company where if you can't trust your employees, you hired the wrong ones and just need to let them go. No naps in the former case and sleep whenever the hell you feel like it in the latter.

Have you ever heard Guido speak about the issue? He and a number of others don't think it's one worth solving. Really.

Yea it may be a lot of work to create a new GC implementation and change the threading model, but if you want the language to progress that's the way forward.

The most frustrating thing about Python is its community's complete denial about what a joke their concurrency situation is. Truth is python is not truly multi-threaded, and no, claiming that multi-process is the way to do parallel computation across the board is not a sane argument at all. It's religious zeal. My company is currently using it for web apps, and that's proving a pain (i.e. having to use proxy servers for database access to minimize connections across all the python process instances). Using python for anything more serious, like a message queuing system for example is even more prohibitive. People in charge should wake up and start taking serious steps about it. I guess PyPy is the biggest hope. Meanwhile in the JVM world..

Agreed with previous posters that there won't be one system to rule them all as there are a ton of use cases. Having said that every single system out right now sucks badly. Every one has some serious flaw or flaws. I'm not knocking anyone here, just this particular market is in its infancy at this point. It'll be a while before there is a truly good choice even if you are willing to pay money.

On a mostly unrelated note, the title of this post used to have the phrase "leading nosql database" in it, which is definitely marketing hyperbole :).

Does anyone by any chance know if there is a version of the riak python driver that does not use google's protobuf implementation? I'm looking into using riak and hearing this does not exactly instill confidence, as riak uses google's protobuf implementation and http as its two communication protocols.

Frankly, even a developer relations position can be a technical position. I personally think a developer relations person who does understand the inner workings of the code base he represents, or at least demonstrates the ability to understand it given time, will be much better at his job than someone who doesn't. So really, I agree with Google here in their decision.

There are a number of jobs at google that although do not involve writing code, are closely coupled with the technology google is working on - developer relations actually being a very good example. I think they are keeping the bar high in these instances for valid reasons. I'm sure there are positions where technical background is less crucial, graphic design comes to mind, but that's to be judged on a case by case basis. Everybody wants to work there, so they can demand very high standards, but in most instances i've heard about the standards are not incorrect, just high.

EDIT: And probably another reason is they simply want to keep the particular technical culture throughout the company.

From the article:

"However, no attempts have been made to optimize the Java VM, the SQL queries, etc"

Emphasis being on optimizing the sql. We have run tests comparing neo4j and postgres, and postgres comes out with greater throughput for our data set, where our database implementation was done people who know postgres extremely well. Where you will see especially great differences is aggregate queries, such as if you want to count the number of a certain type of connections coming into a set of nodes, and then sort these nodes by that number. A sql database is much better at stuff like that.

Funny thing though, a well designed relational database will execute your graph queries faster. It won't do generic graph queries faster, but if your sql data model and code are optimized for the type of graph data you are storing, sql will almost always be significantly faster, orders of magnitude in some cases. Obviously not a data model argument, but a real world argument nevertheless. If you then need to scale further you will probably end up putting up the same caching layer between your database and the front end, but at least all your data will be in once place (the sql database).

This article is so full of such silly generalizations I'm not even sure where to begin, or whether i should.

"I did an informal survey of different Los Angeles based Information technology companies. One common theme: although espousing a culture of innovation, and although some are very profitable, most are simply not cutting edge, and some are very behind the times."

An informal survey of LA start ups.. awesome. Any word on how exactly you went about conducting said survey? My guess is it was based on recalling random techcrunch articles read over the past couple years, but please correct if I'm wrong. LA has a ton of start ups that have all kinds of products, working environments and compensation levels, most of which I would guess the author never heard of.

"In most Silicon Valley Startups, coders know SQL, a major scripting language as well as HTML and CSS. However MySpace had positions solely for just HTML/CSS, a trend that harkened back to the 90s when web pages were manually created."

So basically, no one needs to know js and css/html anymore because they are all magically generated by some server side fairies. So facebook, twitter and google do not have people who specialize in js or css/html because that's just way too simple. Totally. For a product the size of what MySpace had, I think it would be shockingly incompetent to not have people who would specialize in that tech.

"Another Los Angeles great, eHarmony.com, uses 40 to 50 engineers for its matchmaking algorithm and servers, whereas OKCupid.com uses only 10."

In your survey, did you happen to ask them why they had such a discrepancy? Because i'm pretty sure it's not because eHarmony's employees are 5 times dumber than okCupid's. There could be a ton of reasons why these numbers are what they are besides lack of skill.

Anyway, I think this is an attempt to rationalize some failure the author has experienced at his previous job. But frankly I think this was a pretty bad attempt at generalizing something as big as the LA and SF job markets. Start ups exist everywhere and come in all shapes forms and sizes, LA has lots of them. To say that an entire city's worth of start ups is one way or another because of myspace, eharmony and your last work place is just way too simple. Anecdotally, I have friends in several LA start ups that are doing just fine, have working environments as good as their peers in SF, if not better, and are using the same range of technology people in SF use.

I don't always invest, but when I do, it's in gold and Swiss francs.

It's tiring because it's unjustified. There is a spectrum of users, not two separate sets. Scoble is saying what he is saying because it's emotionally satisfying for him to feel like he is part of some elite, while basically he is just a well known blogger. The tone in this article reinforces my prior suspicion that he is a douche. Such hubris also clouds his judgement apparently, as I disagree with him on who will adopt this. G+ currently has the potential to be a completely mainstream product.

Different strokes for different folks i guess. I know a lot of people will be fans of this, but

>we pair program to write all of our software. We work on Mac Pros with two keyboards and two monitors. We work in an open team room; no cubicles or private offices. 

No thanks, if I'm the developer. And if i wouldn't do it, why would i make my employees.

What kind of impact would having used something like sha-512 with a 128 bit salt have had over md5? How many more cycles do those take to generate? I assume the attacker had to brute force the salt from a known password as well, if that's sufficiently random that should provide some security as well shouldn't it?

OT: There another comment here by trotsky here and now it's gone without a [deleted] placeholder, and I have show dead on. Just curious, I guess there is a perm delete admin functionality? Also didn't seem worthy of deletion..

That's a question I would really like to know the answer to. I'm not so sure that's the case.

Wonder if the spelling mistakes are strategically placed then. Or does Mr. Barr really spell that way. He's like a 40+ year old married guy.

Thank you, that's very interesting. "Going nuts" with MongoDB is exactly what I'm contemplating right now at my start up, and this is something I haven't quite heard before.

Is there more info on the double update issue anywhere? It sounds like a really bad race condition.

It seems that the main criticisms are:

a) Lack of online compaction (causing data set to be much bigger than necessary)

b) Broken auto sharding (complicating horizontal scaling)

c) "Scary" durability and scaling stories with auto sharding

Looks like auto-sharding has had a lot of work done, while online compaction still isn't there.

But in particular I'm curious about (c). What exactly is so scary durability wise with auto-sharding? Is it just the fact that it didn't work in 1.5/1.6?

1. They launched in NZ, but the service was for everyone worldwide.

2. Akamai might have played a part, but wasn't the main target of the load test.

3. See 1.. the MySpace data center is in the states.