gthank

When I'm researching new tools/libraries, the first thing I read is the README. If it's worthless, then it's a fair bet the tool/library is, as well, and I won't be using it by choice. After that, I look at the official documentation. If all it has is auto-generated API documentation, that's another strike against it. Then I look at the API documentation. The tests are somewhere way in the back after all of this.

What amazes me is that this is presented as somehow novel. Quotes about power corrupting have been floating around for 100s of years. The most famous, "…absolute power corrupts absolutely", is from 1887 (see http://www.phrases.org.uk/meanings/288200.html), but similar quotes go back to at least 1770.

Being forced to accept a fair(ish) compensation is way better than just getting disappeared by the government and/or mafia.

I wouldn't call them stars, but I know at least two programmers (assuming one hasn't moved on to managing programmers) that play in rock bands. Does that count?

I appreciate the work you're doing. I'm not sure I've worked on a system that would really benefit from Mongrel2, but I think it's a pretty interesting concept, and there's always a chance I work on something more interesting in the future. Even if I don't, I almost always learn something or gain a different perspective from reading your stuff, and that's reason enough to be thankful.

Having followed most of the comments on both these threads, I don't think it's fair to characterize Zed's position as saying "epoll is always bad". I think a better characterization would be: "epoll is not automagically better under every imaginable scenario".

You may argue that nobody is making any such claim, but I can tell you that the sections of the blogosphere I skim via HN, reddit, etc. do imply it. Maybe the authors just assume everyone can infer that every decision has tradeoffs and there's no need to discuss them in depth for this particular case, or maybe—and the nature of the blogosphere leaves me inclined to think that this is the case—most of those authors never consciously thought about those tradeoffs because epoll happens to be a good fit for their particular problem. Either way, Zed is the first person I've seen trying to explicitly identify and quantify those trade-offs for poll vs. epoll. As such, I think he's doing the community a service.

If this research leads to a better implementation of epoll, or a server that requires less tuning to do well under a particular load, that is great for everyone. Even if it doesn't lead to any great improvements, a better-educated developer population that makes more informed decisions is still a net win for the world.

What about NetBSD? Zed has already said he uses NetBSD, so if kqueue is there, he might add it to the mix.

Was I looking at the wrong screenshots, or something? Why are they comparing a calendar view with a list view?

If Apple can design, build, debug, manufacturer, and market a tablet 2 years faster than any of their competitors, how is that NOT a credit to them?

Because you want to do arbitrary queries on the data? Because the data needs to be exposed to other applications?

If I could upvote you a hundred times, I would. Almost every comment disagreeing with the article fails to understand the economic definition of "competitive advantage." He didn't say none of those things was an advantage, he said it wasn't a competitive advantage.

That's largely because Java aims for cross-platform compatibility. It doesn't have to deal with nearly the rats' nest the autotools do. Note that I still think they suck and would probably use CMake if in the futuer I find myself working on a C or C++ project of any size.

Trolling they may be, but they got a snicker from me. There's something to be said for an actual, well-executed troll—as opposed to the senseless asshole tactic that most "trolls" on the internet use these days.

HTML/CSS is portable across all browsers, but you aren't guaranteed absolute control over the final rendering. This is by design, and there are a lot of good reasons for it. Most of these abstraction layers sacrifice all of that so you can get more control on the 2 or 3 supported browsers instead of the giant universe of alternate user agents.

HTML/CSS as machine code is a horribly flawed metaphor. Machine code is at the "absolutely no abstractions" level; it's what the computer executes. HTML/CSS, on the other hand, are massively abstracted declarative languages. It describes the data you want to display, and some basic style information. Java -> HTML/CSS/JavaScript is actually compiling up in many, if not most, cases.

Re: help networks -> poor people might not have a network that can make a house payment for them, but their networks are (IME) more likely to give a hand via couch-surfing and the like.

As a person who grew up poor and made it out of the bottom quintile, I can tell you that the number of my poor friends who had the talent and opportunity to do the same but didn't actually do it is probably an order of magnitude larger than the number who did.

So why don't they actually make it out? The theory in the article sounds interesting, and I hope to see more research done to test it.

I agree with you, but I'm still sad that I don't get a 300dpi screen.

I couldn't quite tell: was that a "news item" or an editorial?

Chrome is built on WebKit, so it's not a Google-from-scratch the way search, etc. are.

You can't have a touchscreen phone without OS support.

Actually, Mac development required a Lisa for quite some time.

In addition to the standard WebKit developers' tools, there is [SpeedTracer](https://chrome.google.com/extensions/detail/ognampngfcbddbfe...), which is pure awesome.

@endtime wrote Opera Mobile, not Opera Mini; they're different products.

Sorry - that was aimed at the comment that appears to have been deleted, not at you. Based on your blog, etc., I was pretty sure you actually meant "Hey, if you get me a working patch, it will get in". The comment, OTOH, was pretty clearly an indictment of Brandon for not writing a patch.

Whether you meant it to be rude or not, it pretty much came off that way.

When somebody takes the time to point out a legitimate shortcoming, much less do so in a way that isn't snarky or mean-spirited, criticizing that person for not also solving the problem is a net-negative response.

There are any number of reasons that someone might not solve the problem. In no particular order, here are some off the top of my head:

* they don't have the resources for testing (not everyone has a copy of Windows, much less every supported version of Windows)

* they don't have the expertise

* they don't have the time

* they don't care enough, but thought it would be useful to write it down someplace for the next time they come across the problem

Asking for a patch every time somebody provides useful feedback is a fantastic way to make sure you don't maximize the community around your project.

Orin Kerr (http://en.wikipedia.org/wiki/Orin_Kerr) has posted about this. He doesn't take a firm position, but notes that the California law doesn't explicitly carve out such an exception, but the close federal parallel does mostly allow such warrants. He also notes that no court has ruled on this point in CA. He also explains the context around the original passage of the law: "This law was passed in response to Zurcher v. Stanford Daily, in which the U.S. Supreme Court ruled that the Fourth Amendment allowed the government to obtain a warrant to search a news office for evidence of crime that the news source was gathering in the course of reporting the news."

Source: http://volokh.com/2010/04/27/thoughts-on-the-legality-of-the...

This part is my own interpretation, but I think it's reasonable: given the lack of direct precedent, the CA court that considers this matter will probably consider the legislative intent behind the law (Gizmodo is out of luck) and look to how similar laws have been interpreted (again, Gizmodo is out of luck).

Under CA law, the finder of a lost item, if they can reasonably find the owner of the lost item, is required to make "reasonable and just" efforts to return the lost item to the owner.

The claim by Gizmodo (and presumably the finder) is that the finder called the Apple customer service line and didn't get anything useful, thereby fulfilling the requirement.

The claim by those who say this was theft under CA law is that this did not fulfill the requirement, since it was found in a bar, and it is extremely reasonable to contact the bartender about a lost item that was found in the bar.

If you concede—for argument's sake—the group claiming theft is correct under CA law, and Gizmodo knew the backstory—which they presumably did—then they purchased stolen goods.

One of the people at Gizmodo (Nick Denton? memory fails right now) even admitted it was stolen when offering to return it to Apple, although the page containing the admission has since been edited.

I've seen more than one lawyer who seems to think that the exception is implicit, which would mean the search is not invalid on its face.

My theory is that they intentionally burn the coffee during roasting to make every cup consistent. Also, relatively speaking, the various espresso drinks are much better than the plain coffee. The sugar and cream do wonders to cover up the over-roasting.

In all likelihood, Apple would argue—successfully—that the market should not be defined as the "iPhone software" market but as the "smartphone software" market, at which point they no longer have a monopoly and are no longer subject to anti-trust scrutiny.

What gets interesting is when/if Apple's dominance continues to grow to the point that the "iPhone software" market is effectively the "smartphone software" market. At that point, the DoJ and/or FTC will almost certainly decide that many of these policies are anticompetitive and initiate some sort of action to remedy the situation.

So in some sense, Apple needs to worry about becoming too successful: it is only because they haven't achieved total dominance that they can get away with being so ruthless.