Chromium, Homebrew and Command Line Developer Tools

I wanted to have a look at the Chromium browser and went through a number of steps that appear with hindsight somewhat odd. What do people think where I went wrong or at least sub-optimal?

To install Chromium you need MacPorts, Fink or Homebrew. These are package managers or, in simple terms, tools that allow you to install software (packages). Not exactly a Mac-like interface, but it is what it is. I went for Homebrew after reading up on the pros and cons of the others.

To install Homebrew you need a command line tool “xcrun”, this is offered as part of the Xcode Command Line Developer Tools. We’re deep into developer stuff already, but macOS Sequoia offers to install what’s needed, using an otherwise invisible app that is already part of macOS.

25 mins on a fast line and ~2.9 GB later, you can install Homebrew, another few hundred MBs.

Eventually a command in Terminal installs Chromium, refreshingly just 335 MB in size.

Now for the surprise: I uninstalled Command Line Developer Tools and Homebrew. Chromium still runs, I had expected it to die, but not so. All this effort just to install a software?

Where is my thinking warped?

Removing those things just stopped your ability to add new apps and update existing apps using Homebrew. It doesn’t remove the applications that you install with it. I’m not sure about the Chromium browser, whether it has its own update mechanism (I believe it does not), but many apps that you install with Homebrew need to be updated also using Homebrew, and you can also use Homebrew to install an app

I did some searching - it looks like you can download and install Chromium without Homebrew here: Download Chromium (see the “not as easy steps”.)

1 Like

@ddmiller Thanks for searching and indeed for your comments.

What I’m doing here is dabbling around without any REAL need, but I was curious (about Chromium). I never had the need to install in this cumbersome way any other apps, by that logic Homebrew and the Command Line Developer Tools were not needed any longer, if that changes in some distant future, I can always get it again.

I had seen the links as shown in the first “not as easy steps” by normal googling before, albeit not on the Chromium website under “get involved” because that sounded like contributing to coding. What threw me off course was that said link goes to googleapis .com, so wouldn’t that be Chrome, not Chromium?

Chromium is an open-source project managed by Google, so it makes sense that it would be there.

I know that I installed Chromium a long time ago, shortly after both it and Chrome appeared, but if I want to use a Chromium browser I’m more likely to use something like Microsoft Edge or Opera. Plus, of course, Chrome, which I use when I am doing something specifically with one of my Google accounts. That’s not all that often for me - I’m far more likely to use a Profile in Safari, though there are things that Safari doesn’t do well with Google sites (like Google Drive). And I think I prefer using Firefox to Chrome or any other Chromium-based browser for anything I can’t use with Safari.

I do, however, use Homebrew a bit. It’s what I used to install (and keep updated) Tailscale on my Mac minis, so that the Macs stay connected no matter which user account I use; I also used it to install Handbrake’s command line interface, but I don’t use that too much anymore. In the past, though, I had a Homebrew bundle that I would use to automate loading a new Mac install from scratch. See Automate installing apps and utilities with Homebrew bundle | amanhimself.dev for more info about that.

1 Like

What you’re missing is that these tools were necessary to install Chromium, but not to run it.

What Homebrew and the Command Line Developer Tools are doing is assembling (or “building”) the app from its constituent parts. Once they’ve done that, it will run just fine without them continuing to be present. You’d probably have to reinstall them to install any updates, as @ddmiller pointed out, but switching to the straight download method will probably be simpler.

When you get into installing open-source projects, you’re frequently going to encounter apps that aren’t necessarily pre-built and downloadable directly as installers or ready-to-run binaries. There are multiple reasons why this might be the case, but this is why the extra tools like Fink, Homebrew, and MacPorts get called in to do the heavy lifting. They know how to do all the fussy steps that turn source code into runnable apps.

I’ve used both Fink and Homebrew off and on for several years. Fink has a lot of problems keeping up with the newest macOS versions since Apple Silicon came out, so it’s probably not the best choice if you’re running Tahoe, or even Sequoia.

1 Like

Thanks @Quantumpanda

If I may, how do normal apps then manage just to be copied from some “transport image or volume”. Am I wrong or do OpenSource developers leave out an important step of finalising their apps before they can be used? Why?

IMHO it’s because the concept of signing and notarizing an app for secure distribution (one true binary whose origin is verified, but you can’t see inside) is at odds with the open source philosophy (build it yourself from source code).

BUT in the OP you chose the path of building Chromium from source code. Hard work, and perhaps unnecessary for your use case. If you just wanted the app to try, you can indeed download a prebuilt version as a zipped app (see “Easy Point and Click for latest build” at the download chromium page).

1 Like

By the way, just to provide a useful link, I hacked Microsoft Edge to make my ideal Chromium web browser. (It’s not my definition of a hack - it’s just using a documented profile feature to set specific options.)

1 Like

Very interesting link. Funnily enough, my main use of Edge is to read TidBITS and a couple of other sites. (I use several browsers, all open at the same time, for very different tasks, and I command-tab between them to switch tasks.) I look forward to experimenting with some of the tips in the linked article.

One nice thing is that the developer can make one source code that can be distributed by package managers on Linux, Windows and MacOS and only have one of the computer platforms to develop on.

Not so much at odds with the concept, but many of these open source projects are run by very small development groups (possibly by individuals).

In order to sign an app with an Apple-generated certificate, you need a paid-up Apple developer account. That costs $100 per year, and if you let it lapse, your certificate gets revoked, invalidating all the apps you’ve signed with it.

You need to do this in order to be listed in the App Store or to use certain OS features, but if you’re not doing this, then it isn’t necessary - unsigned apps will simply force users to jump through a small hoop in order to authorize the app.

If you’re not making money off of the app, you may find it hard to justify the cost.

1 Like

So, there are multiple steps and stages involved in creating an app.

What the developer writes is “source code”. If the programming language is “interpreted”, that means that the written code is executed in that form. The venerable language BASIC is one of the most famous interpreted languages, but there are others. The biggest problem with interpreted languages is that they are slow to execute, because every piece of the code has to be translated into the computer’s internal language at time of execution, every single time that line is executed.

Most languages are “compiled” languages. Before the code can be executed, it has to be run through a program called a compiler, that takes the written source code and translates it into the computer’s language all at once, so that when the app is run, it doesn’t have to translate those instructions on the fly. This makes it run much faster.

Pretty much every modern app is compiled. Interpreted languages are primarily for small-scale scripting these days.

After the code is compiled, it is packaged into what’s known as a “binary” (because that’s all that computers actually know at the heart of things). This is the kind of app you can simply drag-install or run a simple installer for. The installers are usually for apps that have to put things on your system somewhere other than inside the app package in /Applications, though an increasing number of apps are bypassing the separate installer and simply doing these tasks when you run them the first time.

So, an app can be distributed as source code or a binary. Commercial products are pretty much always distributed as binaries. It saves the user the time and hassle of compilation, which requires having developer tools installed.

Open source, however, is frequently distributed as source code. There are many reasons for this, including the ones others have cited. An important one is the fact that binaries are extremely platform-specific. While commercial projects have the resources to build into their code provisions for multiple platform variations (running on an Intel or Silicon Mac, for example), open source projects are largely volunteer work. The developers will compile their code for their own machines, because that’s how you test your code, but those binaries are just for them.

Until an “official” release (open source projects are frequently eternally in beta), the intended audience is mostly tinkerers who are comfortable with the Terminal. The hope is that people who try the software can contribute to the development, not necessarily by adding actual code but by submitting detailed bug reports. Good bug reports require a certain level of understanding of how things work under the hood, one that the average user just doesn’t have in this day and age. (Back in the early ‘80s, when I cut my programming teeth on Applesoft BASIC, just using a computer frequently required this level of understanding. That changed with the original Macintosh, and then Windows.)

What package managers like Fink and Homebrew do is act as an intermediary between source code and binary. Compilation normally requires a number of additional actions, including setting particular parameters for the compilation, ensuring that certain other libraries or apps are available to draw upon (these are called “dependencies”), etc. A package manager has access to the “recipes” to compile a wide variety of apps, so you can simply tell the package manager to install such-and-such app, and it will set up the compilation without you having to know the recipe. In most cases, a package manager will even find and download the source code for you, installing needed dependencies on the fly. All you have to do is tell it what app you want, and it fetches the parts, puts it together, and leaves you with a completed app.

Some others have brought up the cost of an official Apple Developer account as a reason for open-source software to not be distributed as binaries. This may be a reason for some projects, but it’s a very minor reason. Apple’s blessing is needed only to have a signed developer certificate and to distribute on the App Store. (App Store distribution is still necessary on iOS/iPadOS unless you live in the EU, but it’s not required on a Mac.) Not having paid the Apple Tax does not prevent one from distributing a Mac app as a binary. It does add an extra step for the user to initially run it, but that’s all.

3 Likes

They’re bigger-scale than you might think. Popular languages like Python and JavaScript are interpreted languages, but the interpreters typically implement some form of just-in-time compilation to compile the code at the time of execution. This allows the benefits of interpreters (no dependency on CPU or even operating system architecture), but most of the benefits of a compiled language.

Java and Java-like languages (like the Kotlin language used for most Android apps) blur the line even further. They compile source code into machine-independent bytecode (effectively a high-efficiency interpreted machine language). This byte code may be executed by an interpreter or (more commonly, these days) may be just-in-time compiled to the platform’s native machine language.

Yes, but:

  • If your app isn’t signed, Apple pops up a big scary warning implying that the app may be dangerous malware. This may scare off non-technical users who don’t understand what the warning really means.
  • Some APIs (e.g. iCloud integration) are unavailable to apps that aren’t distributed via the App Store, which as you wrote, requires a paid-up developer certificate.
1 Like

I don’t typically put just-in-time compilation in the category of “interpreted”. It’s more of a halfway step between interpreted and compiled. What I would consider a “true” interpreted language doesn’t compile at all. But that’s all semantics and not material to the actual discussion here. Neither is bytecode. I mentioned interpreted code only to distinguish it from compiled code.

Neither of those are typically going to be concerns of open-source projects until they have a commercially viable product. If those APIs are necessary to the project’s functioning, then they’re going to plan for that in the first place.

And I think you may be severely overestimating the importance of avoiding “scary” warnings in the typical open-source project. Again, until you have an official release, your target audience isn’t non-technical users. Heck, an awful lot of open-source projects out there don’t even have sufficient non-technical documentation to be usable by non-technical users. The people they’re expecting to run these apps will generally know how to deal with that warning, or at least are intelligent enough to research it instead of being scared away.

But most important of all, you are forcefully injecting technical nitpicks into what I’ve deliberately constructed as a layman-level explanation. That happens a lot on TidBITS-Talk—technical detail arguments taking over more general discussions—and I think it’s detrimental to a lot of discussions here. I consider it akin to mansplaining, something I’ve become quite attuned to as a trans woman, and I think we all (myself included) need to become more aware of it and resist the impulse to aggressively correct nitpicky details that don’t make a difference to the point of the discussion.

2 Likes

Thank you @Quantumpanda for taking all this time to explain.
Blimey (a chiefly British term used to express surprise, excitement, or dismay) what have I started here? I have learned a lot here, including stuff about topics that, well, had not very much to do with the initial topic.

I doubt that the contributors to Chromium are worried about any notarization fees. There are very big OpenSource projects, and tiny small ones. My impression about OpenSource often is that developers seem to live in a very technical bubble.

If you want to run SuperUsefulSofty, just compile it from scratch, very easy to do.
Oh it can’t print? Don’t you know that EasyPrint500 would do that for you? Everybody knows this. Oh, it can’t show the main window properly on a screen less than FullHD? How dare you to not know that DriverPAK200 introduced this already 20 years ago for all screens above VGA resolution.

Ok I’m overdoing it a bit for dramatic effect, but some should not forget what a certain Steve Jobs once said: “Begin with the user experience, everything else follows.”

For Chromium, there is a certain irony in finding downloadable Install-with-1-step software under their “Not as easy” steps.

1 Like

Trust me, this isn’t an exaggeration at all.

Geeks-upmanship is endemic in the tech world. Not knowing something is a sign of weakness in many tech circles. I’ve encountered statements functionally identical to the ones you’ve presented, just with actual software names.

I’m an oddball. I’m part of the tech world, but I keep one foot firmly in the “normal” world. As one of my T-shirts proudly states, I’ve at times been employed as a “geek-to-English translator”—meaning I write non-technical end-user documentation. So I have a good sense of when the technical details matter and when they don’t. I do occasionally fall into geeksplaining, but I try very hard to be aware of it when I’m writing so I can edit it out.

I don’t share a lot of the tech world’s disdain for non-technical people. Yes, they can be very stupid sometimes, but most of the time it’s just ignorance and lack of self-awareness. Your question actually broke through the barrier of self-awareness to recognize that there was something here that didn’t make sense to you, and you were curious enough to ask about it. Most people don’t know technical details because they have no compelling reason to learn them. They just want to do their thing, and tech is supposed to make that easier. It all too frequently doesn’t, and part of that comes from the techie superiority complex with regard to those with “inferior” knowledge.

4 Likes

Yes. I’ve always agreed with an old saying from the Wall Street Journal’s former lead tech columnist, Walt Mossberg: “Just remember: you’re not a ‘dummy,’ no matter what those computer books claim. The real dummies are the people who-though technically expert-couldn’t design hardware and software that’s usable by normal consumers if their lives depended upon it.”

3 Likes

I don’t think they expect people to use it for everyday browsing at all. It’s the basis for much of Chrome, and Google benefits when other companies who have browsers based on Chromium help develop the code.

I think that’s the intention - open source all but the proprietary things that Google wants to do with Chrome, just as Microsoft can use it and add proprietary bits for Edge, etc.

1 Like