Microsoft Edge on Chromium: First Impressions

I recently saw a Slashdot article that Microsoft just released the first "dev channel" build of its new Chromium-based Edge browser, and figured that I would give it a try and document my first impressions of this "new" browser.

Looks

Visually, the two browsers are very similar. In the screenshot below, Google Chrome is on the left, and Microsoft Edge is on the right. As you can see, the window chromes - the title bars, address bars, etc. - are not very different between the two.

The situation is similar when you click the menu button in the top-right corner of each browser. Microsoft has altered Edge's menu so that it is not exactly reminiscent of either Google Chrome or the old Edge browser, but combines the styles and functionality of the two.

The biggest visual distinction from Chrome that I've seen in my very brief trial of the new Edge is in the settings page. Edge's settings page hardly resembles Chrome's; in fact, it reminds me much more of Firefox's settings page.

The big functionality difference here is that Google Chrome allows you to sign in with a Google account, while Edge allows you to sign in with a Microsoft account. Once you get past the visual differences, though, both settings pages actually work pretty much the same - for example, the "Site Permissions" portion of both offer the same choices of plugins or parts of pages that can be enabled or disabled, and the "About" portion of each shows the version number and automatically tries to install available updates when opened.

Extensions

As you may be able to see in the screenshots above, I have already installed uBlock Origin into the new Edge browser. The interesting and exciting thing is that I did so from the Chrome app store. 

Microsoft provides an extension store for Edge, which in the past would've been the only way to get them. Now, on the new Edge's Extensions page, there is a button in the bottom corner labelled "Allow extensions from other stores." The "Learn More" link gives instructions on how to enable this setting, and how to go to the Chrome Web Store to install extensions. These extensions ask for exactly the same permissions, etc., as in Chrome (of course), and otherwise work identically in both browsers.

Performance

As expected due to the fact that both browsers use the Chromium engine, their scores on the Basemark Web 3.0 test are basically the same: 344.67 for Google Chrome, 354.78 for the new Edge browser. The score breakdown shows that the two are close enough that the point difference doesn't really mean anything, and practically, they (and most web browsers) work well enough that you won't really notice any differences anyway.

Summary

Google Chrome and the new Microsoft Edge web browser, at first impressions, are the same thing. What works in Chrome should work in new Edge, and vice versa - pages will render the same, they will be about as fast as each other, and extensions from Chrome will work in Edge (and, presumably, vice versa with new Edge extensions.)

I'm not sure how I feel about this. On the one hand, as an IT person, it would be great if a clean install of Windows gave me a usable web browser, which will now be available with the new Edge. It's also great that I can use the same extensions in both browsers, and that webpages should look and work the same in both. Microsoft Edge, as hard as it is to believe, is now a good browser.

On the other hand, I don't know if it's good for the web - which is supposed to be a decentralized, diverse system - to lose out on one if its major rendering engines (Edge's EdgeHTML engine is/was a fork of Internet Explorer's Trident.) We all remember the bad old days when it was IE6 or nothing, and webpages employed a lot of not-exactly-standards-compliant techniques to make themselves look and feel right, which caused issues when Firefox and other new browsers came on the scene. Will we see a return to that world when every browser, or at least most, are really just copies of Chrome? Sure, Chromium is open-source, but if everyone uses the same open-source base, the biggest contributors essentially decide the direction of the web. I just hope that Google and its contributors stick to the motto of "don't be evil."

Mac Administration with Jamf, Part 5: Composer Package Scripts

As I mentioned in my last post in the "Mac Administration with Jamf" series, Composer not only allows you to package applications for deployment by including files and folders, but also gives you the ability to run scripts at certain points in the install process to achieve various things. 

This only works with .pkg-based installs - .dmg installers don't include any scripts, so if you want to do work other than copying files and folders, you will need to create a .pkg installer. Unfortunately, this also means that installers that use package scripts cannot be indexed and made uninstallable by Jamf, so you will need to create uninstallers yourself if they are needed.

According to the Jamf documentation for Composer, there are a number of triggers for which you can enter scripts. Rich Trouton, on his blog Der Flounder, explains when each of these triggers actually occur, and what can be done with each:

• Preflight - runs before any files are installed
• Preinstall - runs before files are installed, but after preflight, and only if this package has never been installed before
• Preupgrade - runs before files are installed, but after preflight, and only if this package (or an earlier version) has already been installed on the system
• Postinstall - runs after all files are installed, only if this package has never been installed before
• Postupgrade - runs after all files are installed, only if this package (or an earlier version) has already been installed on the system
• Postflight - runs after all files have been installed, and after other postinstallation tasks have occurred

At any stage, if the script does not return with an exit status of zero, Installer will display a message that the installation was not successful, and will exit.

With the new flat-package format for installers, only two of the above triggers are available: preinstall and postinstall. This means that the installer will not automatically detect whether an older version of the package has been installed, so you will need to do any such checks manually.

To add a script to a package in Composer, click the triangle next to the package source name to expand its subfolders. Right-click on the subfolder labelled Scripts, then hover over Add Shell Script (unless you prefer Perl), and select the type of script you wish to add. For this example, I'm adding a postinstall script.

Click on the newly-created script name, and you will be given an editor window into which you can type your script. Enter your script, or copy-and-paste an existing script, then save it with Cmd-S or File > Save. In this screenshot, you can see a script that we use to automatically download, install, and customize the latest version of Google Chrome, which frees us from the need to manually download and package each and every new version as it is released. I will discuss more details about this package, as well as those for Firefox and Adobe Flash Player, in future posts.

Once your scripts are created, build the package as a .pkg installer, and upload and deploy using Jamf like normal. Now, when Jamf runs the installer package, any scripts you entered will run at the appropriate times during the install.