othermaciej

Apple very rarely takes positions on technologies that we don't currently support. Here is a past comment conveying a personal opinion from a WebKit engineer though: https://mail.mozilla.org/pipermail/plugin-futures/2010-April...

Coal mines still employ a great deal of human laborers, even the few that are highly mechanized. And it's still difficult, dangerous and not very pleasant work. Most coal mining is still done underground and even surface mining is quite dangerous. See e.g. <http://en.wikipedia.org/wiki/Coal_mining>;

It's also usually not a good idea to act condescending when you think you have superior knowledge, as then you may look foolish when it turns out you are misinformed yourself.

I have a different writing style from Brendan, but I don't think there is any significant substantive difference between what he said in this thread and what I said almost 2 years ago.

(Although, the fact that PNaCl is still an experiment and not the mainstream of NaCl nearly two years after I wrote my comment should be further cause for concern.)

Seems like a bad idea to me. How will my browser do things such as autofill usernames and passwords, allow links to be opened in new tabs, block third-parties from tracking me with cookies, or allow me to globally change my font preferences if each web page actually uses a different "browser" that it downloaded, and whose only connection to the outside is IP and a framebuffer? Or how would a browser be able to give me crisper text on a Retina display with no change to web pages, or provide hardware-accelerated threaded scrolling, or let me play video with hardware-accelerated decoding?

(These are a few of the things that, as a browser engineer, I expect could not be done in this model.)

Also as a Mac user, I expect this would result in many forms in web pages giving me controls that look and act like Windows.

Against these likely disadvantages, the advantages seem slim. We already have good ways to distribute sandboxed native apps. The Web doesn't need to become one of them.

I've expressed my personal opinions about NaCl here on HN before too: http://news.ycombinator.com/item?id=2057611

Safari also completely disallows keyboard input in fullscreen mode, which majorly mitigates the vulnerability.

I believe you are committing the "Yes Minister" fallacy:

"Politician's logic: We must do something. This is something. Therefore we must do it."

Direct government subsidies create deadweight loss, and by hurting the competitive position of companies and technologies that don't get the subsidy, they can actually make the negative externality worse. You can't justify a bad intervention just by pointing to the magnitude of the externality.

1) I read a lot of economics blogs and I see many economists who are against "government picking winners and losers" in the form of subsidies; but favor, e.g. revenue-neutral carbon taxes. There are strong economic reasons why the two are not at all the same.

2) Direct government subsidies for favored corporations is likely less economically efficient than doing nothing in cases. Subsidy decisions are not guided at all by the info encoded in the price system, and are instead likely to be based on rent-seeking by favored interests groups. See <http://en.wikipedia.org/wiki/Economic_calculation_problem...;

Your original comment cited "basic economics" and implied that the government would be better than the market at "picking winners and losers" in the face of negative externalities. But that is not a consensus view among economists.

Most economists do not accept that direct government subsidy to businesses leads to an economically efficient outcome, even in cases of negative externalities. Many economists would say that Pigovian taxes or creation of markets in the externality are likely to be more efficient. Bottom line: market failure does not mean that government solutions are automatically better. Government failure exists too!

And that is why the concept of "derailing" is BS. The position of the speaker as member of an oppressed class means that you must accept their claims on faith. To question them in any way is "NOT ok". Adopting this policy means that no rational person should believe anything that comes from a group with such ground rules.

FYI, we already have bugs tracking this. It can't hurt to file dupes but it's also not required.

Speaking as one of the people who worked on adapting khtml into Wbkit, no, it was no comparable with Mozilla or IE at the time. It took a major effort to get to shippable performance, web comparability, standards compliance, and quality. Check out the first 2 or 3 years of WebKit commits on trac.webkit.org and you will see some incredibly basic stuff.

Safari does have a 'readability'-esque relayout engine - that's what the 'Reader' button does.

Yeah, achieving many of the scrolling effects they want often requires sites to do scrolling entirely "by hand", which degrades the quality of scrolling.

First amendment law is pretty clear that there is no "heckler's veto" - the angry reaction of others does not make speech unprotected (except in the case of "fighting words" that are intended to and likely to cause imminent violence).

A judge will only overrule a jury verdict for proven gross misconduct (mere incompetence or confusion is not enough) or because they judge that no reasonable jury could have decided as the jury did, given the evidence put forward. It does not matter if the jury came to the decision in a way that may not be reasonable, if a reasonable jury could have reached the same verdict.

OS X apps are not generally statically linked. They are dynamically linked. But Apple almost never breaks binary compatibility of the public APIs.

Her apparent point was that there is no way to design around it, which is false. The claim was not about obviousness or validity of the design patent, but rather that it's really dangerous because there is no way to design around it. Which is clearly false. You may well have a valid point, but it's not what the Groklaw post said.

Let me give you some examples from the current post that strike me as BS:

"But, in contrast, here's the Apple design patent, D504889, about those rounded corners -- how do you code around it? A tablet in the shape of a parallelogram?"

But the jury found Samsung's actual tablets, which are rectangles with rounded corners, do not infringe this patent. So her analysis that it's impossible to design around this is false.

Here's one from another recent post:

"Apple's lawyers are still clueless that the public is for the most part repulsed by Apple's IP aggression."

This isn't supported by any evidence and is almost certainly made up. I'm not aware of any survey supporting this claim.

At this point, I'm unable to tell which information about the case on Groklaw is factual and which is made up. As far as I can tell, the quotes from actual court documents are accurate, but I can't really tell about the rest.

I saw the same factual coverage of post-trial jury interviews on, e.g., The Verge, without GrokLaw's implausible legal analysis that this would cause the verdict to be thrown out.

Does anyone see groklaw as a credible source any more? They used to have good reporting, but all I've seen since the Apple v Samsung verdict is spittle-flecked ranting.

This reminds me why I hate comments. They tell you what someone once thought the code did. They don't actually tell you what the code does. You should always trust actual code and actual measurements above comments.

The original author of this comment (not me, I just imported the code) believed that it improved performance on a given server-side workload.

The person who removed the sleep, Geoff Garen (a colleague and a friend), is a good programmer. I am confident that he read the comment before deleting it. However, his actual performance measurement trumps the comment.

BTW, here is Geoff's snarky response on reading the posts here that mention the comment above the sleep() call: <http://www.quickmeme.com/meme/3qqgwz/>. I agree with him.

This code is actually not that specific to GC - this particular spinlock is used by our custom malloc implementation. It's just that our GC creates a different concurrency pattern than most other workloads for the allocator.

I am the one who originally added this sleep call to WebKit, when we first imported TCMalloc to use as our custom allocator. It was indeed there for a reason, but that reason is not applicable to WebKit's allocation patterns. TCMalloc was designed for a server workload, over time we have adapted it more to the unique needs of a browser engine. This change may help other operations, but probably not as much as the GC benchmark in question.

I am skeptical that this is actually a true story and not a parable. The alleged regular people consumer statements do not ring true.

Key phrase of your comment:

> This means where an argument comes from has a lot of bearing on its validity.

That's a more polite way of saying what I said.

As of Safari 6 on Mountain Lion, scrolling is threaded and nonblocking on Mac, but it doesn't yet work for all pages. So yes, you can scroll ahead of what is painted. The most common exception is pages with fixed positioning.

The concept of "privilege" as used in social justice speak is merely a tool used to discredit people who are in the wrong demographic/social/cultural categories without having to address the content of their arguments. And pointing this out is labeled "derailing", to avoid having to address that line of argument either.

Why are people so much more willing to give Google a pass for this kind of stuff than Apple? Whenever the Apple app rejection story du jour makes the rounds, I rarely see anyone taking the "two sides to every story" angle.

At least with Apple you can appeal to a human. With Google all you can do is appeal to the press and hope someone there cares.

They are usually being tossed to the pagefile (except in the case of read-write non-anonymous file mappings, which are not super common on OS X and which are functionally equivalent to paging to the page file anyway).