Fairhaven, The River

Chromebook C7 Experience (Initial Review)

Summary: The Acer Chromebook C7 works as an ultralight Linux system and I will continue using it.  There are plenty of annoyances and it is not for everyone.  It is for people who can tolerate annoyances and who like to tinker with things.  The $200 price compensates for a lot of annoyances.  If you can't handle annoyances or don't want to tinker with things, get an Ultrabook ($800+) or Mac Air ($1300+).

I got a Chromebook C7 and have replaced the ChromeOS with Ubuntu linux.  It will replace my aging Mac Pro laptop.  This began as an experiment.  I was willing to risk $200 on this.  It's working and I'm now committing to it.

I evaluated my needs by examining all the applications on my Mac Pro and on my corporate laptop.  This established what I want from a travel machine.

• I rejected the tablet plus keyboard alternative.  An Android tablet plus keyboard could do about two thirds of what I want.  I'm not willing to give up the other third.  One thing that I really want is the ability to browse the web, refer to PDF, Word, and other documents, all as part of writing another document (using either emacs or an office system).  That's the one thing that tablets can't do easily.  They are really limited to showing one application at a time.
• The Mac Air and the PC Ultrabooks can do everything that I want.  These cost about $1400 or $800 respectively.  If the Chromebook experiment failed, I would have gone to a PC Ultrabook.
• The Chromebooks have the option of replacing ChromeOS with Linux.  The $200 model is the better choice for this than the $250 model.  The two deciding factors were storage space and CPU.  The $200 model has 320GB disk and an x86 CPU.  The $250 model has 16GB static RAM and an ARM CPU.  For the non-tinkering user, the $250 is a much nicer machine.  But if you want to install Linux on it you need to put linux onto a separate 16GB microSD, and you're very storage limited.  The ARM means a lot of cross-compiling of software because there are relatively few Linux packages compiled and configured for the ARM family.  There are many different incompatible instruction sets among the ARM family, so you need to target machine types, not just ARM.

Physically the C7 looks like a Mac Air designed and built by a PC vendor.  It's clunky, boxy, a bit heavier, a bit thicker, slower, and much shorter battery life.  On the plus side, it has intelligent security protections, 320GB storage, and many useful connectors (like VGA and wired Ethernet).  It's flimsy, which does lead to some annoyances.  I haven't broken anything, but it feels fragile.  The battery life is only 3-4 hours, but you can buy additional batteries and swap batteries if you want.

Installing the software is straightforward but requires following a lot of instructions carefully.  (Instructions with pictures, and the real instructions). You can't just boot from a CDROM or Flash stick.  You need to get the machine into developer mode, download and run ChrUbuntu as an experimental OS, repartition the disk, sign it, and get Linux stored onto disk.  The first download is 1.5GB which takes a long time even with a fast Internet connection.  Then, the first update to bring it up to current versions will download another 400 MB.  And forever you must accept warnings at boot time that you are running an experimental OS in developer mode.

I do expect other distributions to follow Ubuntu's path and configure versions that can be installed in this way, but they haven't done it yet.  For other versions you are much more on your own.  You get to go read the ChromeOS developer documentation and figure it out yourself.

I've installed another 500MB of software downloads for

• emacs
• truecrypt
• Skype, and
• XCFE4

These first three are because they are core applications that I want to use.  They were the highest risk of failure on this system.  The other missing applications are going to work if Linux works.  (Most of the 400MB is dependencies pulled in by Skype.  Skype is only available in 32-bit mode on Linux.  ChrUbuntu is 64-bit mode.  So the Skype package pulls in a mass of 32-bit mode library and compatibility support.)

I installed XCFE4 because this system needs a lightweight windowing system.  I tried Canonical's preferred Unity system that comes with ChrUbuntu.  I replaced it because:

• It places too many demands on the 1.1Ghz Celeron.  The clickpad was highly erratic.  Other features were slow or erratic.  Unity really needs a beefier CPU and GPU.  It's full of demanding eye candy.
• It interferes with my doing multiple things at once.  It's like the tablets.  It's set up to show one application at a time.  If you fight hard you can have multiple applications at once, but it was easier to switch than fight.

An example of the kinds of annoyances you must face and fix is a conflict between Unity login manager and XCFE4 over access to the power system controls.  These are known bugs.  They leave it unpredictable whether power status will be shown and whether lid closure will trigger standby or not.  I dealt with the first by installed "xosview" to show me system status.  Further examination of comments on the bug reports showed how to configure XCFE4 to not use the power control daemon.  Now power management works much better.  But there are still occasional glitches where the system powers up from standby despite the lid being closed.  I haven't figured out how to stop this yet.

I've got plenty of software installing and customizing to go, but I'm confident it will work.  The high risk stuff is working and indicates that the rest will work.  It's just going to take time to do.

It's got lots of annoyances and limitations, but for $200 I can accept them.  (Extra:  I've just added 8GB of RAM ($40) and it's doing fine.  Instructions are here.)

One reason DICOM succeeded

DICOM is now a highly successful standard, and I occasionally think about why this is.  I was first involved in 1991, and have been involved on and off ever since.  It is different from most standards in that participants tend to be highly pragmatic, and willing to compromise for the sake of making things work.  I think that this is part of why it has succeeded.

One reason for this pragmatism is the original forcing function for DICOM.  In the late 1980's and early 1990's hospitals were "owned" by the MR vendor.  Each vendor had its own proprietary networking system for imaging systems.   The MR system was the really big ticket purchase for a hospital.  So the effect was that a hospital with a GE MR system would have GE for all the rest.  A Siemens MR owner would have Siemens for all the rest.  And this was a tremendous problem for the hospitals.  They wanted to be able to buy from a variety of vendors without suffering from network problems.

They laid down a nuclear threat.  They threatened to disqualify any product that did not interoperate with imaging equipment from other vendors.  The threat was to officially label that product as not suitable for medical use.  The NEMA standard that preceded DICOM had failed to be widely accepted (for a variety of good reasons) but there was a lot learned from attempts to use it.  It was clear that a standard was needed in order to accomplish interoperability.

But this is different from most standards processes.  The goal was not creation of a standard.  We were going to be put out of business if our products did not interoperate.  The standard was merely a step on the road toward that goal.  Most of us involved with creating the standard were engineering managers or product managers.  We would be failures if all we did was write a standard.  Success required product integration and successful interoperation with products from other vendors.   The standards consultants, standards experts, and the like were not welcome unless they contributed toward our success.

This did establish a tradition of pragmatism.  Making the system work was far more important than following any particular theory or standards practice.  Academic and theoretical purity was of value only to the extent that it helped ensure that things worked when we were done.  The "fad du jure" (e.g., SOA) was unwelcome.  We had products with long lifespans, strict regulatory requirements, and tight pricing pressures.   Technology fads had no influence on medical buyers.  They were influenced by medical fads.  So, as engineering and product managers who needed to sell products we stomped out the technology fads, unless they could show pragmatic value as enhancing our chances of success.

This is very different from many SDOs.   In many SDOs the development team reaches their goal with the successful balloting of the standard.  That is the target.  That is what they get paid for.  We knew that we were not done until we had a cost effective implementation of the standard, working in our product, selling to our customers, and acceptably interoperating with the other machines on the customers network.  Having this different goal and different staffing made a difference in our practices, attitudes, and traditions.

This is one reason that DICOM succeeded.

Managing Volunteer Organizations

Doc  notes that charities are poorly run.  This is old news.  It is very hard to run volunteer organizations, etc.  When people are donating their time they have a very different attitude toward their job when they are not being paid.  There is a pernicious feeling of entitlement and often self-righteousness.  The donator is much more sensitive to even the mildest criticism, because they are donating their time.  It's not like they were getting paid.  (This attitude infects even the paid staff.)