All 1,400 Google Chrome CLI flags
peter.sh
peter.sh
--0 No description
--1 No description
--10000 No description
--100000 No description
--1000000 No description
--2 No description
--3d-display-mode[1] No description
--4 No description
--50000 No description
--500000 No description
--5000000 No description
--7 No description
--?
--10000 is a single flag
--memlog-sampling-rate=10000 is uh, well, also a single flag
according to these docs both flags should be valid?
See the comment https://source.chromium.org/chromium/chromium/src/+/main:bas...
Also see how the flag is actually parsed: https://source.chromium.org/chromium/chromium/src/+/main:com...
There's absolutely no reward for scouring the system and getting rid of the 90% of the flags that serve no purpose anymore. All you would do is annoy people and risk breaking something. So no one does it.
In fact, as I recall, you could either "list the flags" for a system, or "list all the flags AND all the included systems' flags." Hardly anyone wants to do the latter.
I seem to recall there is some automation that proposes changes to remove flags that has not been set to non-default values for a sufficiently long time, but maybe that's not done for binaries that run outside of Google's network.
[1] Knight Capital's $440 million glitch:
However...
I didn't measure it, but switching tabs in an Asus C201 Chromebook sure seemed to have a much lower latency than tab switching (or clicking on a different app in a menubar) for any Linux distro I've ever used on any piece of hardware. That includes this Dell XPS laptop running Ubuntu, which is fast and well-supported with firmware.
I speculate without measuring because switching browser tabs on that Chromebook feels uncanny. It's as if there's some ahead-of-time trick that utilizes the camera to guess my impending trackpad click or keystroke. That makes me think I've gotten used to a fairly high floor of latency on my Linux machines.
Add to that the long battery life while browsing in Chrome. Add to that the fact that I open and close that Chromebook at will with the browser in nearly any state, and it never got hot, crashed, or failed to come back up when I reopened it[1].
Those things being true, it makes more sense from a performance standpoint to use Linux from within Chrome than the other way around. That is-- as long as you spend non-trivial time in a browser, it's more efficient to do Linux-Inside-Chrome than Chrome-Running-Inside-Linux. (And I have never found a Linux Firefox config on any piece of hardware that can reliably play videos on Reddit, which makes me think it's not handling video acceleration properly.)
1: The one exception: when I was running a low-latency audio app on that Chromebook which grabbed exclusive control of ALSA.
“It's an operating system (pretending to be a browser).” [1]
1: https://news.ycombinator.com/item?id=14737739 from a past discussion of building Chrome “24-core CPU and I can’t move my mouse”
[1] https://source.chromium.org/chromium/chromium/src/+/main:ash
Yes? With just flags, the only artifact that you depend on is the program. With a config file, now there is a separate artifact to maintain for every distinct configuration, which could be a lot. I'm not saying its not solvable, but it does strike me as more complicated.
There must be some kind of config system where the flags are being driven from though, unless someone is manually typing them out each time.
- open some descriptor on the system
- write the file content
- execute the command
- get rid of the file
Of course you'll also need to deal with the constraints/failure of any of these steps (write the file in a location the program can access, take care it still exists or is not overwritten when you run the command, so have pseudo random names and/or lock the file, etc.)
In comparison, passing it all as args is one single step.
+ Another artifact to ship and deploy
+ What file format to use? Obviously different teams will use different formats too. This compounds as you add engineers.
+ How do you find the initial file? Whichever mechanism you use besides hardcoding it is another gateway to configuring the program. It will be used in addition to the config file and compose in weird ways.
I think the limitations of the command line actually make it scalable especially in the Google context.
With restraint and thought you can make the 2 equivalent from a data perspective. That's a ton of effort and if you get it wrong it is pretty hard to change it later on because someone is going to start relying on previous semantics.
Esr even contradicts himself at the end of that link when he says that site wide configs may be immutably set in the system directory.
I think people are overly focused on how crappy Unix tools from the previous millennia are (ls, sendmail, dd, etc…) but I do truly believe that cli tools can be ergonomic because I have used and built tools which feel ergonomic.
I've lost count of the numbers of times I've straced commands to see where they pull configuration from or grepped thru codebases looking for getenv calls. Any unix consensus for configuration is in theory only not practice.
File location is actually pretty germane to precedence. A more "global" configuration cannot be applied if the program is looking for it in the wrong location in the first place. Let's not even discuss the horrible state of where to store local configurations in a users home directory. As long as it starts with a . it's fine :).
I've used Linux exclusively for nearly 20 years - but not because I loved its configuration management story.
We are arguing over whether the glass is half empty or half full. I can also come up with plenty of examples of poorly designed programs, but I can also bring up examples of programs which are not perfect but much more usable than ls. I’m sure you could have also picked a program which is better designed than ls as well.
I arrived at this solution after getting tired of both having to track down where the value for a particular setting originated at runtime, as well as having multiple implementations of the same kinds of argparse/os.environ/file-based settings systems across our internal tools and scripts.
Problem solved.
Plus I have the full programming language available, not some textual subset with Yet Another Dependency to read it.
I made my hacks open-source, so if you have a Click-based Python CLI, try click-extra, contribute back, and help me solves this problem once and for all: https://kdeldycke.github.io/click-extra/config.html
Flags at command line time can be equivalent to flags in file from a data perspective.
If you work on it they can behave with similar semantics too.
If you work even harder you can ensure you deploy the config file atomically with the binary. You can also make sure that the file is properly secured, and config values from it are observable and auditable.
Or you can just mandate that programs are configured by the command line flags passed to them and not have to do all that extra work.
But when the command line invocation is so big that you can barely even copy/paste it any more, and it exceeds the max command line length on a stock Linux kernel, you’re way past the point of convenience being the important factor. All the normal places you’d want to see the flags (set +e in a bash script echoing them back to you, etc) are suddenly overloaded with megabytes of text for a command line invocation… who’s gonna look at all that? Who is this serving any more?
“Flags for everything” would seem like a good idea taken way too far to me.
Googler, opinions are my own.
Sometimes we use flags on my team for controlling experiments and whatnot, flags tend to be used for more static settings, like the name of other jobs we call.
We have a few configuration languages at Google, and many of them will push to production very quickly. We tend to use these for experiment controls.
The problem with flags as experiment controls, if you need to roll back quickly. It's a lot slower because you have to wait for all the jobs to restart.
Also for us, we can't SSH onto hosts, and the scheduler that actually knows about args/pids/etc is fairly deep behind the curtain, but HTTP access is easy. But you could see different companies having different constraints.
a) log the entire config at startup.
or
b) create a specific file with config used, if logging is too messy.
or
c) make an API to return the running config.
or
d) use envvars in a container, that you can just dump from 'env' at will.
All of which would be cleaner and saner than browsing top.
--js-flags="--jitless"
https://searchfox.org/mozilla-central/rev/57527d50ef5d3df412...
https://chromeenterprise.google/policies/#DefaultJavaScriptJ...
And this existed before SDSM... in fact SDSM depends on the code landed in Chrome that backs this policy.
I've suffered it when working for engineering companies where the PMs understood the logic but didn't understand why it's a bad idea to just create branches for everything.
Not sure why programmers would inflict this "methodology" on themselves. And no, sorry, I'm not going to read the article. Too soon.
is this part of the Google culture?
Also, good hygiene is important and implementing some kind of tracking ("no more than N flags older than X") is IMO a good practice. I wonder how Google does this?
Now removing them is another thing entirely -- but some teams do have code cleanup fixits.
Yes it does make source code smaller and simplier to read. But if you're referring to binary code size - well it pales in comparison to what protobuf contributes to generated code size. I'd say that proto code makes up >60% of Google binary size.
It also doesn't include many "undocumented"/experimental flags, which are hidden in release notes or only mentioned in the source code.
E.g I know in just one client-facing app there is well over a thousand flags, all individually owned and monitored by various individuals and teams wishing to either experiment or launch features.
Some, like "--zygote", have no description and also are totally unclear.
Love it.
https://chromium.googlesource.com/chromium/src/+/HEAD/docs/l...
> A zygote process is one that listens for spawn requests from a main process and forks itself in response. Generally they are used because forking a process after some expensive setup has been performed can save time and share extra memory pages.
With that background, --zygote isn't actually a flag at all. If you click on it it takes you to a string constant, but that string is actually a value for the --type flag. e.g. anzygote process would have `--type=zygote`.
`--type` is itself an internal flag, explaining it's lax description of "Flags spied upon from other layers.". However it is briefly described in the documentation I linked above.
[0] Programming Language Q&A, December 2022 - Jonathan Blow https://youtu.be/OAIqCpqszVw?t=3974
Yes flag hygiene is a bit of a problem too :)
Fun fact about Linux's now-unlimited, demand-paged argv: the JVM was a bit behind the ball on that one. As soon as Linux systems with enormous args limits appeared, `xargs` happily adapted. But the JVM at that time had quadratic command line parsing. So anyone using `xargs java` suddenly had cron jobs (or whatever) that never finished.
Edit: Although there's arguably security implications to letting me push a file from my workstation, but that wouldn't have been an issue in 2006.
For regular Unix folks, imagine issuing a remote ssh command. You can't easily do that AND bundle an auxiliary data file at the same time.
As someone else stated, most of the app oriented flags are ChromeOS specific, so I didn't have much success. I tried a lot of different combos and scrolled through Chromium's .h headers to see what I could find. It was a good way to waste an afternoon and learn a bit more about the browser. Kiosk modes, dummy profiles, full screen, single window, security flags, etc. Lots of interesting features you don't run across regularly.
[Desktop Action Edit]
Name=Edit
Exec=/usr/lib/chromium-browser/chrome --profile-directory=Default --app-id=idjenohckefppahppaeclfgpbfkfppaf --app-launch-url-for-shortcuts-menu-item=https://www.hypertext.plus/editor/ Bugs
Cdrecord has even more options than ls.
I personally like to use `-` in filenames and flag names because it's one less shift key to press. But it leads to the requirement to translate the `-` into `_` in the code. Eg, `resource-filename.json` becomes something like `resource_filename` in the code.
There was a recent Chrome on macOS beachballing problem related to dragging a tab. Multiple users noticed it at MAANG megacorp.
Resolution:
Running from the CLI changed some state that eliminated it, so logging in verbose mode was impossible. Instead, a SWE sent a spindump over to Chromium attached to an opened issue.
I have come across more flags during my occasional use of Chrome.
Firefox's configuration flags are unified in `about:config` page. It has a whole bunch of configurations too, but they are neatly named (e.g `browser.ui.something.enabled`) and I prefer configuration options than flags.
Maybe they would benefit from a project aimed at reducing this to a more manageable list?
Seems like they got themselves into a tech debt situation now
Browsers are complex these days, and it's good that we have options to change behaviour that is problematic for us. I run chrome/firefox as part of a batch job on a virtual linux display, so I really need to turn off all the crap like first-start wizards, bookmarks and the like.
Actually: No. Well, at least not in the ridiculous way that Chrome or Firefox do it. Command line options or config files are both fine - when used in moderation.
The problem here (at least in part) is that it is extremely easy for devs to just add a configuration option. But it is much harder to think about whether a user would actually ever want to change the setting, if it had a good default value.
In fact, I think maybe about 20 command line options would cover 99.9% of all usecases for chrome. - And it would be so much more understandable. - Both for the actual developers and the users.
I absolutely despise it when a software product pushes effort downstream this way.
---
Note: I fully understand that in Chrome these flags at least partially leak out of their "trunk-driven development". - But this is no excuse: In no way should the development environment leak out into a released product this way! - And it would be exceptionally easy to stop this too: Just disable all development flags in the release build.
I guess it's a tribute to what you can get if you throw enough money and effort at something! They must be running flat-out just keeping the project going and the ever-changing product running.
Just imagine what they could have done with that money & effort, if it was spent on clear, focused projects.
Chrome is clearly the most popular browser out there but, for me, popularity counts for little. Chrome is also extremely heavyweight by most measures (installed size, memory usage, cpu usage, build time!)
Re popularity: Imagine you're at a retail store buying a coffee maker. They tell you "this model is very popular". For something that people purchase/install occasionally, popularity isn't a good indicator of quality, though it might be a good indicator of price, advertising, feature-list, or sales commission!
Personally, I want my coffee maker to make great coffee, and to keep doing that for a long time. And I want my browser to be fast, lightweight, and minimally intrusive.
Counter counter counterpoint: I like command line flags and you can take them from my cold dead hands.
For all sorts of testing reasons, there has to be a way to disable the JIT. There has to be a way to disable sandboxing. There has to be a way to bypass the GPU acceleration blacklist, and there has to be a way to launch without GPU acceleration on non-blacklisted hardware. Thank god the options exist!
I mostly wish the documentation was better. It would be great if I could filter by platform. And, um, the definitive source probably shouldn't be some guy's personal website.
The reality is that 99.5% of users have perhaps 10 or 20 actual usecases/requrements. - You named a few of the most prominent ones. These need to be supported (e.g. with flags) and documented properly. Everything else is excess can be removed.
The problem with this is: You need to find out what users want to do. But many software projects are just too lazy and push all the effort downstream.