Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
othermaciej
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
6 ms
·
1.
▲
by
othermaciej
13y ago
Manually specifying different HTTP ranges of the same resource is more verbose, more error-prone and more confusing than just specifying different resources. Other than that, I guess it would work.
2.
▲
by
othermaciej
13y ago
When it comes to page load speed, extra network round trips are really bad. Even if you're loading the same total amount of data.
3.
▲
by
othermaciej
13y ago
That's not so great for high-latency networks (like most cellular networks). If you use range requests, you add round trips. If you cancel the load partway, you're too late because your pipe is already filled with bits you don
4.
▲
by
othermaciej
13y ago
It matches the CSS equivalent feature, image-set().
5.
▲
by
othermaciej
13y ago
SVG is fine for assets that can easily be described in vector form, but it's not the best choice for all image types. For example, photographs (where you might have an ultra high resolution original that you're scaling down) are n
6.
▲
by
othermaciej
13y ago
In the case of Web standards in particular, you can usually see the checkins in our public source tree well before we ship it. But per policy we will rarely publicly commit to shipping something or not ahead of time.
7.
▲
by
othermaciej
13y ago
WebKit did fine before Google ever joined the project, and I'm sure it will do fine with them gone.
8.
▲
by
othermaciej
13y ago
In WebKit, we have macros to always inline or never inline for our target compilers, so we can force the issue if the compiler won't take the hint in a place that matters.
9.
▲
Unusual speed boost: size matters
(webkit.org)
142 points
by
othermaciej
13y ago
|
72 comments
10.
▲
by
othermaciej
13y ago
Do you have any specific feedback about things you have problems with?
11.
▲
by
othermaciej
13y ago
Try the version in WebKit nightlies and the OS X Mavericks developer preview. It's much improved from Safari 6.
12.
▲
by
othermaciej
13y ago
I expect other browsers could greatly improve JSBench performance if they focused on it. But I would be quite surprised if they matched Safari's current results in a month. It took a lot more than a month and significant architectural
13.
▲
by
othermaciej
13y ago
It's not in the keynote, but if you get the Developer Preview you can see what's new.
14.
▲
by
othermaciej
13y ago
Other JS benchmarks are not based on highly-trafficked real-world sources at all, so perhaps "real" is relative.
15.
▲
by
othermaciej
13y ago
Its's real. You can try the benchmark yourself here, and learn how it is different from other JS benchmarks < http://jsbench.cs.purdue.edu/> .
16.
▲
by
othermaciej
13y ago
I looked up th case you cited, a copy of the opinion of the court may be found here: http://law.justia.com/cases/california/caapp4th/30/943.html As far as I can tell, it doesn't say what you claim it does. There is no mention of burden of
17.
▲
by
othermaciej
13y ago
Correct that truth is a defense. But, as I understand it, the defendant does not at any point have a burden of proof in a civil case, even if the plaintiff has made a prima facie case. That's just not how burden of proof works for any tort
18.
▲
by
othermaciej
13y ago
> As in all defamation cases, it is Ms. Allen's job to prove that the allegedly defamatory statements (the accusation of rape) were true and the photo is a significant obstacle for her to overcome. That's not the case under US libel and
19.
▲
by
othermaciej
14y ago
1) The answer wasn't "we'd like to do this but we're super busy right now, how about later" or "that's super complicated, will you guys put in a lot of the effort". It was a pretty direct no. We would have been willing to do much of the wor
20.
▲
by
othermaciej
14y ago
My interest in this thread was only to report on some history that I knew about personally, to correct what I thought was an incomplete version of events. I think a bunch of people found that information useful and interesting. I regret tha
21.
▲
by
othermaciej
14y ago
Thanks, Mike. And sorry also if my reply was too lengthy or pedantic or otherwise out of place. I feel bad for getting into a back-and-forth about this.
22.
▲
by
othermaciej
14y ago
You're right that Chrome's multiprocess architecture is more mature than the WebKit2 design. I wish we hadn't ended up in a position where we felt we had to make our own. But stay tuned - we have some great stuff coming up.
23.
▲
by
othermaciej
14y ago
>> We talked privately with particular Chrome folks before we started (as described upthread), in the middle, and shortly before landing to mention that we were landing soon. > Yes, I'm aware of that, but the work had been under
24.
▲
by
othermaciej
14y ago
If we took Chromium's multiprocess code and put it in the WebKit tree after the Chrome folks specifically said they did not want to do that, that would have been super rude. Don't you think? That's why I say "hostile fork". I am judging our
25.
▲
by
othermaciej
14y ago
We talked privately with particular Chrome folks before we started (as described upthread), in the middle, and shortly before landing to mention that we were landing soon. I don't know if the contents of these conversations were ever shared
26.
▲
by
othermaciej
14y ago
As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, maki
27.
▲
by
othermaciej
14y ago
The Constitution uses the word "privilege", but it does not mention the concept of privilege as you are using it. "Privileges" in the constitution aren't distinct from or weaker than rights - they are considered fundamental rights. The Supr
28.
▲
by
othermaciej
14y ago
These uses of the word "privilege" are all defining rights, not privileges in the sense you mean. Here is an example of Supreme Court jurisprudence on the Privileges and Immunities Clause (from the landmark Slaughterhouse Cases ): [P]rivi
29.
▲
by
othermaciej
14y ago
Keep in mind that MPEG (which defines codecs) and MPEG-LA (which gives you one-stop shopping for some of the patent licnses) are completely separate entities. MPEG-LA even arranges patent licensing for some codecs not developed by MPEG, suc
30.
▲
by
othermaciej
14y ago
MPEG-LA doesn't claim to have all possible H.264 patents in their patent pool. Nokia has an FRAND obligation for H.264, so it's obligated to license on fair, reasonable and non-discriminatory terms, but it has chosen not to be part of the p
More ›