Control Group Blog

Author Archive

In The Beginning, There Was Just One Web Browser…

leave a comment »

In the beginning, there was just one web browser… and it was good. Mainly because there wasn’t another web browser to be “the bad one”.

Written for NeXTStep by Sir Tim Berners-Lee, WorldWideWeb was the first of many browsers to offer up their view of how web pages should be rendered for the end user. Although the world wide web is based on open standards that are interoperable by anyone, the browser community became a near monoculture during the mid to late 90s thanks to Microsoft’s inclusion of Internet Explorer with Windows. Even Mac OS X users were ensnared by Internet Explorer as it was not only the first browser for the then-new OS, but one of the very first 3rd-party applications as well.

Then, in 2003, Firefox (then called Phoenix) showed up on the scene. Although other web browsers such as Netscape Navigator and Opera Software’s Opera had established user bases, it was Firefox that captured the hearts of the alpha geeks by way of its altruistic goal to create a good open source web browser. No longer was browser functionality beholden to the whims of its parent corporation. Now the end user was king.

Initially this freedom brought a flurry of innovation in browser design. Things like tabbed windows, download managers, and an interface add-on architecture were created or borrowed to make Firefox a more useful browser. Companies such as Apple saw value in the open source browser effort and joined or started open source projects of their own. Soon the idea of a modern browser became so powerful that even Microsoft updated Internet Explorer to include these improvements.

As the browser grew up, the Internet continued to diversify in use, and discovered along the way that one browser layout does not fit all. Although interface hacks gave Firefox specialized capabilities, people started to wonder whether or not it would make more sense to design a browser for a specific purpose from the interface up. Now came the rise of the specialized browser.

Google Chrome

Google Chrome

Flock is probably the most well known of the specialized browser breed, which is to say that you’ve probably never heard of it unless you’re a geek or one of their unwitting testbed friends. Available for Linux, Mac OS X, and Windows, Flock is built around interacting with social networking sites, webmail, blogs, and more. Friend lists for sites like Facebook are readily available in a browser sidebar. Posting a link on your blog is as easy as bringing up special text edit panel without leaving the site you’re on. Overall the goal is to abstract services from their respective websites to make them more tool-like.

Some specialized browsers are reductions rather than additions. Google turned a lot of heads when they released Chrome, a web browser with a uniquely minimal interface. While the “get the browser out of the way” interface was warmly embraced by alpha geeks, the hoovering of personal web activity by Google through Chrome was not.

Enter Iron. Since Chrome is run by Google as an open source project, enterprising programmers took the Chrome source code and removed all the components that transmitted personal data to the Google mothership. The browser retains the look and functionality of Chrome while respecting the user’s privacy.

The Ghostzilla Browser

The Ghostzilla Browser

Other specialized browsers serve more subversive purposes. Based on the Gecko rendering engine, the now discontinued Ghostzilla allowed sneaky office users a chance to peek at the Internet without raising the suspicions of their over-the-shoulder glancing managers. Rather than display content in a traditional browser window, Ghostzilla masked its purpose by running inside the window space of a traditional Office app such as Microsoft Word. Web pages were rendered in black and white and images were not loaded unless moused over. The entire browser space itself disappeared when the mouse was moved away, making covering your tracks as simple as a gesture.

The specialization of web browsers shows that the world wide web is evolving in a way that is healthy and intended. Although he could have used closed, secretive code to instruct web browsers on how to display web pages, Sir Tim Berners-Lee chose to employ an open human-readable language called HTML. This even playing field has fostered a level of communication that is unprecedented in human history. Let the good times download.

https://developer.mozilla.org/en/Gecko

Written by Ivan Wright

June 1, 2009 at 10:37 am

Posted in general

Tagged with , , , ,

Multicasting with ASR – A Brief Overview

with 2 comments

Apple’s venerable Apple Software Restore (asr) tool includes the insanely useful ability to image a nearly unlimited number of network clients. It accomplishes this via a router’s ability to broadcast data to any number of clients simultaneously from a single IP address. Known as multicasting, this allows even a modest computer to image a hundred Macs with 35GB images in a single fell swoop.

An asr Restore Image in Disk Utility

An ASR Restore Image in Disk Utility

The disk images asr works with are the same format used by Mac OS X’s Disk Utility. This means you can do a rollout over the network and keep the master file on hand in your re-imaging kit, should one of your workstations run into trouble and need to be re-imaged over FireWire. To ensure the sanctity of the final result, disk images include an embedded checksum which is automatically verified during the deployment process. This can be a significant advantage in using asr over of Apple NetInstall, which requires its own folder-based setup of restore source files.

Disk images are also hardware agnostic for the most part. You can build your image on a Mac Mini and apply it to anything from a PowerMac G5, to an Macbook Pro so long as it can get on the same subnet as the asr host.

The usual caveats of disk imaging apply unfortunately. You’re going to have to sweat individual serial numbers if you don’t employ network or volume licensing. Settings like hostnames and non-ubiquitous local users will require individual workstation visits without centralized management. However, having asr around to do the heavy lifting means you may be able to turn a strenuous two day deployment into a breezy one day affair.

Written by Ivan Wright

May 26, 2009 at 8:30 am