WTF? Chromium (2016)
raeknowler.com
raeknowler.com
Field trials have long been a part of Chromium too: https://blog.chromium.org/2012/05/changes-to-field-trials-in.... They are used to experiment with different solutions or, sometimes, to allow a change to be quickly reverted in the field if it's causing a problem. You can manually enable/disable several of these on chrome://flags/ (although it's not advised).
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.
But that's true of shipping any bug and isn't guaranteed to happen with a field trial any more than any new feature.
(and the OP doesn't seem to establish that it has anything to do with the field trial, just that the processes were run with that option? Admittedly I don't know how they actually work :)
The difference is though, that I can choose the time I update Chromium myself.
However it was not established whether or not field trials (A-B testing) was even the problem merely that they existed on the chromium processes. Even the stable version of the browser will likely have these options on the command line.
I hope HN'ers push back against middleboxes at workplaces.
Getting the bad end of someone's unannounced feature testing is the kind of thing that makes me decide to use another browser for a few months, hoping that the problem disappears if/when I go back to it.
They run experiments in Canary, Dev, and Beta, then conduct a roll-out to stable to get a broader test (per the explanation here): https://textslashplain.com/2017/10/18/chrome-field-trials/
I'm just grumpy that we don't live in the perfect world, where confusion-inducing processes like this wouldn't be necessary. I've never been that comfortable with the "break a few eggs" method of progress.
Just be careful with using chrome://flags to enable/disable certain things. First not everything will have an appropriate flags option. Second even if you enable/disable it in flags chrome may actually ignore it for certain things unless you actually force the field trial on the command line (I'm not sure how common this is).
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.
It's actually almost slightly uncanny how well it's working.
Indeed, I've caught myself thinking "it's not supposed to render this fast" a few times myself. Really am enjoying the nightlies.
Edit: still checking out if it might be possible. i've just seen that the newer firefox has also some kind of flash player integrated. just the debugging is now strange.
Funny thing is Firefox Quantum is both faster and eats less memory compared with Chrome.
>not one that treats you as a pawn.
And sadly, Firefox is the only browser that doesn't treat you like a pawn. For MS, Google, Apple, that chinese company which owns Opera you are just a pawn.
(later edit : fixed the second remark).
Not any more, I recently discovered that my firefox at work got infected with Firefox Pioneer. I didn't install that, it just appeared on list of my addons, no warning or anything. I heard on Reddit about similar cases from a few months ago, people got Safe Browsing installed without their knowledge. Both are signed addons from Mozilla.
https://addons.mozilla.org/pl/firefox/addon/firefox-pioneer/
Is youre IT group policy doing this?
your
So it sounds like a bug or another case of non-malice. Tried reporting it at http://bugzilla.mozilla.org/?
> 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)
What about Safari? (May not be an option based on OS though)
I'm running nightly which in theory ought to have more chance at issues but more chances of fixes for said issues faster too.
With quantum, Firefox is performing well. Even if chrome catches up I will not give up Firefox until it becomes so slow that I'm unable to use it normally. I don't care about the performance delta, just that it be good enough.
Go Firefox!
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.
On Chrome however everything worked fine right away. Overall it was just a few images, some text and a search bar, so no matter the performances of the browser that should work everywhere, but since it was probably only tested on Chrome and Safari, it only worked in these browsers.
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 varying results.
If you add up all those little changes and always go with the option that's fastest in Chromium, in a reasonably complex SPA you could easily generate noticeable differences.
The array sorting is a great example where the length of the array chosen or the pre-sort ordering can affect which browser is faster. No single browser may be able to claim the fastest for every scenario.
1) Write browser-detection code and execute different code, with different performance characteristics, in different browsers. This happens, though less than it used to.
2) Write your code to hit the specific JIT heuristics in a Chrome particularly well, even if that requires contortions that slow it down in every other browser.
3) Write your code to effectively depend on Chrome bugs, where Chrome manages to be faster due to doing something that violates the standards.
4) Arrange the order in which you load your subresources/assets to play particularly well with Chrome's HTTP heuristics, even if it requires contortions that make the downloads slower in other browsers.
5) Write your code to rely on specific behavior in Chrome's HTML prescan, even if it requires contortions that break HTML prescans in other browsers.
That sort of thing.
Basically, if you just write some code, chances are it will run in times X, Y, Z in three different browsers, with the times closer or further apart depending on what features you're using and how the browsers optimized them, etc. But if you then set out to make it faster in X at the expense of any other considerations, you can get it to look like 0.9X, 2Y, 2Z. Or in some pathological cases 0.5X, 10Y, 10Z...
Anecdotally.. Firefox was always slower rendering pages compared to other browsers. On some sites that I visited regularly, using FF was depressing. Later on, it started to suffer from caching issues on my machine. This caused a massive system slowdown.
Tried Palemoon (non-blink\webkit, etc). It blazed through pages- even the heavy ones FF had problems with historically. The rendered results were spot on too. It was like getting a new machine.
What I'm saying is that we can't blame everything on pages being optimized for Browser X or Browser Y. Sometimes we need to call out our favorite browsing application and let them know this is an issue. Otherwise, they keep losing users based solely on performance.
Having said that, looking forward to Quantum.
I also switched to chrome back when Firefox was a lot slower, but now I'm tempted to switch to Firefox or Safari and I try to occasionally.
I've historically had to switch back partly because I (stupidly) rely a lot on chrome's omnibox autofill memory and also because we use the switchyomega plugin at work and I don't want to deal with having a non-standard setup.
From a developers standpoint it does. From a "health of the web" standpoint it does also.
But if I understood correctly that could be finally fixed in upcoming releases.
Chrome without the tracking
In fact, Firefox has increased in the amount of unwarranted telemetry and "experiments" a lot in the last years, a direction I'm really not happy with.
The main difference is that Firefox still gives you pretty liberal access to most internal settings, while Chromium is abysmal, if not ridiculous.
I can understand "experiments" (Pocket comes to mind), but what are you referring to wrt "unwarranted telemetry"?
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.
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)
I'm not being treated as a pawn, but it's still pretty rough.
Multiprocess had a significant migration period. Webextensions had "Well here's some APIs, we'll try to get you more before the day we switch. Some of the important ones are coming the version after, oops. And some are still missing but suck it up."
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 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 potentially buggy features - and yet they do not have "millions using browsers ridden with last year's vulnerabilities", because their alternative is to give users a choice to enroll in experiments. I do participate in experiments since I wish to improve Firefox, but I could switch to any time to no experiments at all.
(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.
Exactly. Apps shouldn't do that on Linux.
2. You get the browser for free. If everyone adopted this same attitude, Chrome would not be able to do real-world A/B testing on features; what should they do instead, just release it all or nothing? You might have been unlucky today, but perhaps tomorrow someone else's misery provides the needed data to prevent a bad feature from going out.
3. Vote with your "feet", and switch to Firefox? (or one of the other myriad of browsers out there…)
This is what I cannot grasp about modern software project management/ops. <s> The only relevant measure is time to ship. If the unit tests pass it is good to go. </s> So many times have I seen webapps so broken that core functions do not even load or by no means would pass simple "click here and there" usability test. In house QA sometimes seems to be abandoned. Automated testing is a good thing, but in my book shipping comes with implicit assertion that changes perform the task at least on a basic level.
Field A/B testing of experimental features is a good thing, which I am ok with even if I happen to get worse alternative. Shipping outright broken features if I am not on beta/testing/nightly release channel is unacceptable.
This will create serious issues in the future regarding how Google is caring about respecting the market, the standards and their users in general.
Hopefully Mozilla has done a quite impressive work on Firefox those past few months and I personally don't see any advantages anymore for Chrome.
I use nightly and it is pretty good. Quite a few things are broken in nightly in Android but I can use nightly as my main browser (besides for hangouts which Google has yet to implement). Edit, we have pocket on Firefox though so https://getpocket.com/blog/
Hopefully with Firefox's new improvements some of this will change.
HN discussion was https://news.ycombinator.com/item?id=15421708
Yet, even though it affects only a super small set of users, it's still a ridiculous thing for Firefox to do.
From the article: "One of Mozilla’s core privacy principles is No Surprises: we will use and share data in ways that are transparent and benefit our users. That is why we are telling you about this today. "
Which doesn't make sense. If one of your core privacy principles is to tell your users what you're using & collecting, why not just tell them before/while downloading? Or better yet, let this be opt-in?
This isn't big enough of a mishap for "the love" to be misplaced, but it is enough to always be wary of what even the most privacy-minded companies do with their products.
I know Firefox had a dark period on which it felt behind Chrome on most fronts, but those days are over, if you haven't used it on a while, give it try! you won regret it.
Not sure if Chrome still always does it, but back then it was because Chrome changed timer tick frequency to presumably 1 ms by calling timeBeginPeriod (https://msdn.microsoft.com/en-us/library/windows/desktop/dd7...).
On Windows, this affects whole system timer resolution and caused problematic timing code in the other process to function correctly.
Funny enough, earlier workaround was to only run this piece of software with a Chrome window open.
Bit off topic, but that guy experienced lagginess in UI due some rogue Chrome process. I remember some bug in VLC that slow down my computer to level, it was not even possible to type on keyboard.
And I wonder, why is this happening in era of multicore CPUs? Why there is no restriction (by default) for process, how many cores it can utilise? I mean the tooling is already there (cgroups on Linux), but they're not used by default.
I do realize this isn't the best answer but I thought that the closer you get to canary/dev branch the more variation you'll be subject to. You can force field trials on and off at the command line if you know the option name and how to format it correctly.
e.g. for some older ones:
--force-fieldtrials="EnableWin32kLockDownMimeTypes/Default/*EnableAppContainer/Enabled/"Chrome is always running multiple processes and they always have a very large number of arguments, including field trials. He's just describing normal behavior.
1. Chrome runs field trials. 2. At one point Chrome locked up the author's computer.
Does it ever connect the two points, or are they unrelated?
I think it just needs minor tweaks. I would replace the marquee with static text and replace the section title "Manifest" with something clearer like "Our Purpose" or "Our Ambition".
The Iridium website gives me the impression I'm downloading something akin to Comodo's browser.
And it's constructive criticism anyway.
Okay, I've seen worse desig--WHAT?! Wow, a marquee! Nice.