Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WTF? Chromium (2016)

raeknowler.com

Post reply on HN
Print view View original

51–60 of 112 posts

Re: WTF? Chromium (2016)

#51

Post by xg15 »

agl wrote: post #12

The fact that Chromium runs multiple processes is unrelated to any field trials. Chromium has always been multi-process; that's why individual tabs and plugins can crash without taking down the whole browser. Additionally, multiple processes are needed in order to implement sandboxing on Linux. Field trials have long been a part of Chromium too: https://blog.chromium.org/2012/05/changes-to-field-trials-in... . They a…

And? All that is written in the article. The question is whether or not forcing users to partake in field trials is a good idea.

Re: WTF? Chromium (2016)

#52

Post by noncoml »

dfee wrote: post #17
noncoml wrote: post #14

Earlier quoted context omitted.

>> not one that treats you as a pawn. > And sadly, Firefox is the only browser that does this. Do you mean to say Firefox treats you as a pawn? How so?(Genuinely interested)

I read it as a typo, where the author intended to say: FireFox is the only browser that does [not do] this.

OK, makes sense.

Re: WTF? Chromium (2016)

#53

Post by yongjik »

CapacitorSet wrote: post #48
yongjik wrote: post #30

Would the author be happier if Chrome/Chromium didn't do these "field trials", and instead just enabled whatever feature they were testing for all users, and the author was hit with the same problem, along with everyone else? When you cut through the rhetorics, the author is basically complaining that Chromium decided to update itself. Well, maybe it warrants complaint, but I fail to see what's such a big deal. (The…

>the author is basically complaining that Chromium decided to update itself. Well, maybe it warrants complaint, but I fail to see what's such a big deal. (The alternative is millions using browsers ridden with last year's vulnerabilities.) You're misrepresenting mandatory enrolment in A/B testing with plain software updates. Firefox is an example of a browser that does software updates, but does not force you to use…

A/B testing is not some nefarious scheme to harm users. When Google or Mozilla wants to add a new feature, there are basically three choices:

(1) Opt-in: Add the feature to the new version. Users must choose to upgrade.

(2) Opt-out: Roll out the new version automatically, unless the user actively choose not to.

(2a) Opt-out with A/B test: Roll out the new version to a small portion of users first, and proceed if nobody catches fire.

Once you decided to use opt-out, there aren't that much difference between (2) and (2a). The major difference is that with (2a), a smaller number of users are hit when an unforeseen bug inevitably finds itself into release process.

And of course we know what happens when something like a web browser relies on the users to actively click "Upgrade". I'm sure there are some people still using IE6.

Re: WTF? Chromium (2016)

#54

Post by Anderkent »

CapacitorSet wrote: post #48
yongjik wrote: post #30

Would the author be happier if Chrome/Chromium didn't do these "field trials", and instead just enabled whatever feature they were testing for all users, and the author was hit with the same problem, along with everyone else? When you cut through the rhetorics, the author is basically complaining that Chromium decided to update itself. Well, maybe it warrants complaint, but I fail to see what's such a big deal. (The…

>the author is basically complaining that Chromium decided to update itself. Well, maybe it warrants complaint, but I fail to see what's such a big deal. (The alternative is millions using browsers ridden with last year's vulnerabilities.) You're misrepresenting mandatory enrolment in A/B testing with plain software updates. Firefox is an example of a browser that does software updates, but does not force you to use…

All features are potentially buggy. There's no particular reason to allow users to opt out from trials, same as there's no reason to allow opt out from upgrades. The chance that you will be impacted negatively is minimal.

Re: WTF? Chromium (2016)

#55

Post by cortesoft »

laurent123456 wrote: post #20
tardygrad wrote: post #4

Or just use Firefox, even if it is slightly slower than Chromium it's at least a browser that works for you not one that treats you as a pawn. A Chrome monoculture is harmful, even if Google has the best intentions which I don't think they do - they definitely value their profits over an open web.

Firefox is not slower, it's just that most websites are optimised and tested only or mainly under Chrome. We are slowly getting back to the way things were with IE, but I hope that Mozilla won't give up and switch to blink or webkit like everybody else.

If most websites are faster on chrome than on firefox, why does it matter that the reason is people optimize for chrome? An end user doesn't care WHY chrome is faster, just that it is for their usage.

Re: WTF? Chromium (2016)

#56

Post by yuhong »

The funny thing is that it is not difficult to prove the exact cause with a debugger and symbols in cases like this either. I wonder if doing what Process Explorer does (quickly suspend/resume threads and display call stack) would be easy in Linux though.

Re: WTF? Chromium (2016)

#57

Post by agl »

xg15 wrote: post #51
agl wrote: post #12

The fact that Chromium runs multiple processes is unrelated to any field trials. Chromium has always been multi-process; that's why individual tabs and plugins can crash without taking down the whole browser. Additionally, multiple processes are needed in order to implement sandboxing on Linux. Field trials have long been a part of Chromium too: https://blog.chromium.org/2012/05/changes-to-field-trials-in... . They a…

And? All that is written in the article. The question is whether or not forcing users to partake in field trials is a good idea.

The piece seems to suggest that a) multiple processes were the performance problem and b) that a field trial was causing that and "mak[ing] my computer unusable".

Multiple processes do take more memory, but there's a good reason for them. While it's possible that it was a field trial that was causing issues here, there's no evidence to support that. Sadly, it was probably just excessive resource usage independent of any trials: Chromium did have a period where memory usage especially was allowed to drift and that was an oversight that Speed team are correcting (https://chromium.googlesource.com/chromium/src/+/lkcr/docs/s...).

On the other hand, field trials produce important feedback. One example just from today: TLS 1.3 draft 18 had significant issues with middlebox bugs to the point where it wasn't viable to deploy it. Chromium has been using field trails to test variants of TLS 1.3 intended to work around these issues and allow TLS 1.3 to be used for real. This has resulted in concrete changes to help TLS 1.3: https://www.ietf.org/mail-archive/web/tls/current/msg24908.h...

These sorts of things require large-scale testing. We brought all the middleboxes that we could find for local testing, but that cannot account for the variety of firmware versions and configurations used in the wild.

Re: WTF? Chromium (2016)

#58

Post by cortesoft »

ballenf wrote: post #50
GordonS wrote: post #27

Earlier quoted context omitted.

I'm curious as to how you can optimise a site to be faster specifically for Chrome?

A trivial example is that a 'for' loop vs. 'while' loop can be faster on one browser compared to another. These differences are even starker if you use newer features without polyfills. For example, 'forEach' implementations as of a year ago varied by orders of magnitude. Native array sorting is another obvious one. Chrome, Firefox and especially Safari use quite different algorithms each based on array size with var…

If 'for' and 'while' loops vary in speed that much between browsers, isn't that a defect in the browser? If one way is faster in chrome than firefox, why doesn't firefox change how it is doing the slower version?

Re: WTF? Chromium (2016)

#59

Post by rhelmer »

usernam wrote: post #47
CapacitorSet wrote: post #46

Earlier quoted context omitted.

>In fact, Firefox has increased in the amount of unwarranted telemetry and "experiments" a lot in the last years I can understand "experiments" (Pocket comes to mind), but what are you referring to wrt "unwarranted telemetry"?

I'm not talking about Pocket. I'm talking about A/B testing internal features exactly like Chrome, such as ip v4/v6 path preference, pipelining support, TLS faststart (and so on) according to a random cohort selection.

While you can certainly turn off these sorts of features, I just want to emphasize that these are intended to make the product better, and Mozilla abides by a fairly strict privacy policy (when comparing to most tech companies at least):

https://www.mozilla.org/en-US/privacy/firefox/

The intention is to ship features that people actually want, and to ensure that Firefox is actually working for people (not everyone can/will file bug reports or post on twitter or hackernews etc)

Re: WTF? Chromium (2016)

#60

Post by trafficlight »

agl wrote: post #57
xg15 wrote: post #51

Earlier quoted context omitted.

And? All that is written in the article. The question is whether or not forcing users to partake in field trials is a good idea.

The piece seems to suggest that a) multiple processes were the performance problem and b) that a field trial was causing that and "mak[ing] my computer unusable". Multiple processes do take more memory, but there's a good reason for them. While it's possible that it was a field trial that was causing issues here, there's no evidence to support that. Sadly, it was probably just excessive resource usage independent of…

The point of the post is that there is no way to opt out. We all understand more datapoints the better. But I also need to not be fucked with when I'm trying to work.
Post reply on HN