If You Knew Sushi…

November 21, 2009

Although the idea of eating raw fish is still off-putting to some people, the worldwide demand for the Japanese delicacy has been growing rapidly.  An article in Wired indicates that some sloppiness in processing at least, and possibly deliberate deception, is happening in the market for the most coveted species of fish:

The article reports on a new research paper, published in the online journal of the Public Library of Science, in which researchers, from Columbia University and the American Museum of Natural History, obtained samples of tuna sushi from various vendors, and then used DNA “bar codes” to identify the species of each sample.  This kind of identification is of considerable interest in conservation, since it would make enforcing bans against fishing for endangered species (such as the southern bluefin tuna, Thunnus maccoyii) more effective.

Unfortunately, the researchers found that you can’t necessarily tell the sushi from the menu:

“A piece of tuna sushi has the potential to be an endangered species, a fraud or a health hazard,” wrote the authors. “All three of these cases were uncovered in this study.”

The sushi as bought was labeled from the very general (“tuna”) to very specific (“White tuna – albacore”).  Some of the samples turned out to be from the endangered southern bluefin; five of the samples advertised as “white tuna” were not in fact albacore, but a totally different fish called escolar (Lepidocybium flavorunneum), which is banned from sale in Italy and Japan because of health concerns — eating it can cause moderate to severe intestinal distress.

Hopefully, the further development of these techniques will help protect endangered species, and will also make having a sushi lunch a little less potentially troubling.


Google Talks Chrome

November 21, 2009

Starting back in July, I have posted a few notes here about Google’s project to develop the Chrome operating system.  There has also been a great deal of speculation in the press, some of which I’ve mentioned before. So when I heard that Google was going to release a bunch of information about the Chrome OS this past Thursday, I was quite eager the hear what they had to say.

The first part of the message was that the Chromium OS open-source project is now set up and running.  (As with the browser, Google uses the name “Chromium” for the open-source project, and “Chrome” for those versions that it releases as a product.)   The site contains a lot of explanatory material, including:

  • An introductory YouTube video that gives an overview of the project concept
  • Design documents, including descriptions of the software architecture and the security model
  • Information on getting involved in the project
  • Notes on user interface design
  • Links to Chrome OS discussion groups

And, of course, there are links to browse or download the source code.

A great deal has already been written about the announcement, including articles at Ars Technica, Technology Review, and Wired.   What I’d like to do here is to touch on a few technical aspects of the OS design that seem especially interesting or notable, and then talk a bit about what this announcement indicates, or confirms, about Google’s overall strategy.

To state the most obvious point first, the Chrome OS is not a conventional OS like Windows, Mac OS-X, or Linux (although it uses a Linux kernel).  It is very much focused on the Web; and, in fact, client applications in the traditional sense (like Microsoft Word or Lotus 1-2-3) won’t really exist.   Applications on Chrome will run in “the cloud”, and the user interface will be within the context of the Web browser (Chrome, natch).   The client machine will not have a traditional hard-disk file system as such (in fact, at least in the initial implementations, there won’t be a hard disk, just flash memory), although the OS will have tools to browse file systems located on external devices, such as a USB stick.  The code and files for the OS itself will be stored in a read-only file system, and Google is also developing custom firmware (like the BIOS) so that booting a Chrome OS machine will be, comparatively, very fast.  (Google claims a seven-second boot time currently.)   When the machine is booted, the firmware will automatically check the cryptographic signatures of the OS image for integrity.

The following diagram (by Jed Hartman, from the Chrome OS Software Architecture document) gives an overview of the system structure:

Chrome OS Architecture Overview Diagram

Google is using existing Linux system  components as a base: the Linux kernel itself, system libraries, and the libraries for graphics and the X Window GUI sub-system.  Above those layers, they are adding the Chrome browser, and a windows manager (which runs on top of X, just like Xfce or GNOME).   Web sites, and whatever applications they offer, are of course accessed via the browser.  Although there is provision for local caching of user data to improve performance, all data is ultimately stored in the cloud.

What is perhaps more interesting, and more unusual, is the inclusion of the customized firmware and hardware layers.  As I mentioned earlier, Google has worked on streamlining the firmware to reduce boot times, and to provide additional security assurance.  Google also will, in its “official” Chrome OS products, require certain hardware facilities (and require others, such as a hard disk, to be absent).   At least in the beginning (which Google says should be late next year), the Chrome OS will be a package deal, pre-installed on hardware somewhat similar to current netbooks.  (Apple fans will be familiar with this as a concept).  The Chrome OS  will differ from a conventional Linux distribution, like Fedora or Ubuntu, in that it will not be available as a package to be installed on any machine.

(The underlying Chromium OS project is, of course, open source, and there is nothing that would stop Google, or anyone else, from getting the source code and building a version that would work on a standard PC.  I expect this to happen, probably with Google’ cooperation at some point.  In fact, there is a report at Slashdot that a group of geeks  has already got a version of the current OS code running in a virtual machine.)

What Google is proposing, with its focus on specialized Chrome OS machines, is really a different model of personal computing from the traditional one embodied in a Windows PC or a Mac.  The traditional model grew out of the idea of the personal computer: a machine that belonged to the user, that was under his control, and that freed the user from the clutches of the corporate IT department.  (Remember that the IBM PC was introduced in 1982, when the Internet for most people simply did not exist.)  Access to the Web, and to its evolution into the “cloud”, has been added on to that basic structure.

Google’s proposition is quite different.  It accepts the primacy of the cloud as the place where data storage and most computation resides; the PC becomes a client specialized for access to the cloud.  As the gentle old cynic in Ecclesiastes observed, there is nothing new under the sun.  This structure is very similar to one that we used successfully in a local network context almost 20 years ago.  In that case, the clients were UNIX workstations, run “dataless”: the local disk was used only to hold UNIX OS files, X Window binaries, and swap space.  All applications and user files were stored on servers.

This kind of approach has some significant benefits:

  • End users need not, and in fact cannot, install applications.  This removes an enormous exposure to malware, and helps reduce the risk of data loss or compromise.
  • Valuable data is stored on servers in a controlled environment, which makes backups, disaster recovery, and physical security much easier.
  • The software “patch  treadmill” is largely eliminated as far as the user is concerned.

Whether or not the approach will be commercially successful is a matter of some debate.  It will depend significantly on whether there is a market segment composed of users who are willing to give up traditional desktop applications in exchange for faster, easier use of the Web. It will also depend on the continuing expansion of broad-band Internet access; at present, I suspect the Google Chrome approach will be a lot more attractive in Manhattan and San Francisco than it will be in North Dakota.

Still, Google makes its money from selling advertising on the Web.   If it can develop a new model that entices more users to spend more time on the Web, Google’s business will benefit.  The Chrome OS project is an attempt to do just that.


%d bloggers like this: