Google Chromebooks: Some Helpful Tips

When I was considering the purchase of a Chromebook, I was looking for a device that could fulfill several different usage cases.  I had in mind the ability to take the device on vacation and perform the ordinary tasks I usually perform when I’m not at my desk.  These include:

• Document production, primarily blog post composition and editing.
• Photo management.  As I take a lot of pictures when I travel, I need to view and upload my photos to my SmugMug account where my photography site is hosted.
• Media viewing.  Like my editor and her iPad, I sometimes want to view some video and listen to a little music.
• System administration.  After all, this is LinuxCommand.org, so I have to be able to log into a remote system now and them and get some real work done.

Due to where I live and the places I hang out, I am almost always bathed in the soft, warm glow of Wi-Fi, so lack of Internet connectivity is rarely an issue for me.  This makes a Chromebook a good fit for what I had in mind.

This post will cover some of the interesting things I discovered when I starting using my Chromebook and attempted my usage cases.  There is a nearly secret little switch next to the SIM slot that is used to put the system into “developer mode” which affords the user nearly complete control of the machine including installing a replacement OS, however, everything I will discuss here can be accomplished in regular user mode.

Getting Help

Out of the box, the Samsung Chromebook comes with almost no documentation aside from a very concise quick-start guide.  It relies instead on web-based help.  The Chromebook on-line help can be accessed by typing Ctrl-/.  Chromebooks also have an extensive set of keyboard shortcuts.  A list of key assignments can be displayed by pressing Ctrl-Alt-/.

File Management

Many of my usage cases involve manipulating files in some way or another.  The Chromebook concept of cloud computing does not encourage local storage and this is reflected in the limited number of file operations available to the user.  A rudimentary file manager is invoked by typing Ctrl-m.  There are two directories that may be accessed.  These are the “File Shelf” (the default downloads directory for the browser) and the “External Storage” directory containing the mount points for an SD card or USB mass storage devices.  Chrome OS supports a variety of file system types including FAT, VFAT, NTFS, ISO9660, and Ext3/4 making the system quite Linux-friendly.

Since a Chromebook does not provide local application programs that process files,  a Chromebook supports uploading and downloading files and little else.  The file manager, in its present incarnation is limited to deleting and renaming files.  Copying and moving files between directories and devices is not yet supported.

Fortunately, the web browser does support the file: URI scheme allowing access to the File Shelf and External Devices directories.  No other directories are accessible unless the system is operating in developer mode.  The URLs for the accessible directories are listed below:

Directory	URL
File Shelf	file:///home/chronos/user/Downloads/
External Storage	file:///media/

To copy a file from one directory or device to another, use the URL listed above to locate the target file, then right click on the file and select “Save link as...” to copy the file to a new location.

Media Viewing

The file manager allows a few file types to be viewed.  It can display JPEGs, and play both MPEG-4, and MP3 files.  As a bonus for Linux users, both Ogg Vorbis and Ogg Theora files are also supported.  Strangely, while the web browser incorporates a PDF viewer, the file manager cannot launch it.  The file manager can launch a media player for video playback.  It is limited to either thumbnail size or full screen, however full screen performance is quite poor.  Using the URLs above to have the web browser directly play the file yields a much better result,  I found that m4v files transcoded for playback on an iPad played fine in the browser.

Chromebooks do not, as of yet, have a full featured media player.  I understand that having one might “pollute” the cloud-only idea behind the Chrome OS, but mobile device owners expect this functionality in portables.

Photo Uploading

Uploading photos from an SD card is very easy.  Modern HTML5 uploaders such as the ones at SmugMug and Google+ work great.

The Terminal

One of the really unexpected features on a Chromebook is the terminal.  Typing Ctrl-Alt-t opens a new full screen window (as opposed to a tab) containing the Chrome OS shell, called “crosh.”  The shell is very limited.  It supports just a few commands, mostly network diagnostics, but it also supports an SSH client so you can open a terminal, launch SSH and get access to remote systems.  Since it is possible to open multiple terminal windows you can perform some useful work.  Chrome OS uses the X window system for its underlying graphics, and the usual middle click (3 finger click on the touch pad) will paste text on the terminal.  Even though the SSH client is present, there are no scp or sftp commands available in crosh.  In fact, no file system access is possible from the shell.

One problem I have with the terminal is the small font size.  I think its probably fine for many people, but old folks like me will find it difficult.  Unfortunately, the text size is not adjustable.

**UPDATE** August 13, 2011
Version 13 of Chrome OS was pushed out a few days ago (Google touts that they will update the OS about every 6 weeks) and among its improvements are speedups for video playback in the file manager. The bookmarks suggested above are still useful but now you can realistically watch a video in the file manager, unlike before.


Further Reading

• Google Chrome OS on line help
• Official Chrome blog
• Chrome Web Store

Google Chromebook: The Computer You Can't Screw Up

I’ve had my Samsung Chromebook for a couple of weeks now.  

A lot has been written about the Chromebook concept, so I won’t go into it in detail here, but in a nutshell, a Chromebook is a specialized small form-factor computing device that is designed to act as an Internet terminal which can rapidly connect the user to network-based services.  It provides a software platform for web-based “apps”  which can be as simple as links to web sites, or as complex as browser extensions using the scripting facilities provided by the Chrome web browser.

My editor has an iPad and I admire its mobility and, more importantly, feeling of immediacy.  A touch or two and you are ready to go.  I have a netbook (actually two) and a netbook is certainly mobile, but it’s still a full-blown computer and that is not always an advantage.

While I understand some of the appeal of the iPad (especially as a media consumption device), the one thing that I can’t understand is how people tolerate its miserable web browser.  Slow and incapable of multitasking, the iPad has the bulk of a computer while unable to perform any better than a smartphone.  To my mind, a Chromebook has many of the desirable attributes of iPad (mobility, immediacy, long battery life) without its limitations.

The tech pundits have weighted in on the Chromebook and I have been quite surprised by the number of negative opinions that this product has spawned.  I guess that I shouldn’t have been surprised given how many negative things were said about the iPad at its introduction.

They Are Missing The Point

Let’s look at the main criticisms being leveled at the Chromebook:

1. “They are too limited.”  The problem many people have is that Chromebooks look like laptops but they don’t do  as much.  Yes, they look like laptops, but they are not laptops.  It is better to look at them as iPads with an actual keyboard, a real web browser, and USB ports.  True, you can’t run Photoshop on a Chromebook, but you can’t run it on your phone either.

2. “They don’t have enough local storage.”  While 16 GB may not sound like a lot, I have noticed that on my netbooks (both of which have 16 GB SSD drives), I don’t store anything close to that much data locally.  I’m always transferring it to other larger machines (Hint: Ubuntu One is your friend).  Besides, unlike an iPad, you can attach USB mass storage devices to a Chromebook.  So, if you want to download that massive video collection, just whip out your 3 TB external drive and go for it.

3. “They are useless without an Internet connection.”  As far as I’m concerned, in this day and age all computers are useless without an Internet connection.  Don’t believe me?  Disconnect your network for a while and see how much you can really get done.  Check your email?  No.  Update your Facebook status or send a tweet?  Nope.  Post to your blog?  Nah.  Conduct research?  Go shopping?  Read the news?  Manage a remote server?  Forget it.

4. “They cost too much.”  For the same money you can get a “real” laptop or netbook,  but name a $430 laptop that will boot in 8 seconds and has 8 hours of battery life.  You also have to consider your definition of “cost.”  Sure, you could buy a lovely Windows 7 netbook for about the same price as a Chromebook, but then you would be confronted with what I call the “money pit of maintenance.”  How much time and money will you spend keeping that machine secured and maintained?  For businesses, the cost of support far exceeds that of the machine itself.  Google uses the slogan “Nothing But The Web,” but they should have called the Chromebook “The Computer You Can’t Screw Up.”   I consider this to be the killer feature of Chromebooks.  There is almost nothing to manage.  Imagine what a business spends maintaining its fleet of PCs each with its own copies of programs and local storage.  With Chromebooks (as with any kind of “thin client” computing model) administration becomes centralized and vastly simplified.  Yes, you may be vulnerable to a possible single-point-of-failure scenario, but I think that many businesses would find this to be an acceptable trade-off.  Oh, and did I mention that a Chromebook is at least $100 less expensive than an iPad.

5. “The Cloud is insecure/unreliable.”  I guess you haven’t suffered a hard drive failure lately, or  had your laptop stolen.  I don’t trust the cloud, but I don’t trust hard disks either.  That’s why I keep backups.

The Philosophical Issue

RIchard Stallman, as you may know, has come out strongly against cloud computing, the model that the Chrome OS so vigorously promotes.  He calls it “stupid” and “careless.”  I think that if you are careless and stupid with anything, you will likely get what you deserve, but I don’t see the cloud as intrinsically evil the way Mr. Stallman does.  I would point out that most free and open source software is developed in the cloud.  Likewise, I don’t see Chrome OS as particularly evil, any more than I see the firmware built into a terminal as particularly restrictive to my freedom.

Where freedom is endangered is with the software that the cloud sometimes provides.  Just like many kinds of proprietary software, cloud-based services have the potential for abuse, particularly by locking your data into a particular vendor’s service.  Also, many of the services provided by cloud vendors are closed-source violating the fundamental tenet of software freedom.

However the concept of cloud computing creates an opportunity for free software and personal liberty.  While the Chromebook demonstrates a certain bias towards Google services, it is not bound to them  You are free to use any cloud service of you want, including your own.

Chromebooks Seem Fine To Me

I, for one, am enjoying my Chromebook.  It fills my need for rapid, lightweight web access without having to support another computer in my “fleet.”

New Discount Offer For The Linux Command Line

I recently got a notice from Lulu stating that, for a limited time, you may receive a 10% discount when you order a printed copy of The Linux Command Line.  Details from the notice are as follows:

Disclaimer: Use coupon code SUMMERREAD305 at checkout and receive 10% off The Linux Command Line. Maximum savings with this promotion is $10. You can only use the code once per account, and you can't use this coupon in combination with other coupon codes.  This great offer ends on June 30, 2010 at 11:59 PM so try not to procrastinate! While very unlikely we do reserve the right to change or revoke this offer at anytime, and of course we cannot offer this coupon where it is against the law to do so.

My Top 5 Bash Resources

Over the course of writing The Linux Command Line and this blog, I've had frequent need of good reference resources for command line programs including the shell itself, bash.  Here is my list of the ones that stand out:

1. The Bash Man Page

Yeah, I know.  I spent nearly half a page in my book trashing the bash man page for its impenetrable style and its lack of any trace of user-friendliness, but nothing beats typing "man bash" when you're already working in a terminal.  The trick is finding what you want in its enormous length.  This can sometimes be a significant problem, but once you find what you are looking for, the information is always concise and authoritative though not always easy to understand.  Still, this is the resource I use most often.

2. The Bash Reference Manual

Perhaps in response to the usability issues found in the bash man page, the GNU Project produced the Bash Reference Manual.  You can think of it as the bash man page translated into human readable form.  While it lacks a tutorial focus and contains no usage examples, it is much easier to read and is more usefully organized than the bash man page.

3. Greg's Wiki

The bash man page and the Bash Reference Manual both extensively document the features found in bash.  However, when we need a description of bash behavior, different resources are needed.  The best by far is Greg's Wiki.  This site covers a variety of topics, but of particular interest to us are the Bash FAQ which contains over one hundred frequently asked questions about bash, the Bash Pitfalls which describes many of the common problems script writers encounter with bash, and the Bash Guide, a useful set of tutorials for bash users.  There are also several fun to read rants. 

4. Bash Hackers Wiki

Like Greg's Wiki, the Bash Hackers Wiki provides many different articles relating to bash, its features, and its behavior.  Included are some useful tutorials on various programming techniques and issues with scripting with bash.  While the writing is, at times, a little chaotic, it does contain useful information.  Heck, they even trash my Writing Shell Scripts tutorial (Hmmm...I really ought to fix some of that stuff). 

5. Chet Ramey's Bash Page

Chet Ramey is the current maintainer of bash and he has his own page.  On this page, you can find version information, latest news, and other things.  The most useful document on the Bash Page is its version of the Bash FAQ.  The NEWS file contains a concise list of features that have been added to each version of bash.

There you have it.  Enough reading to keep even the most curious shell user busy for weeks.  Enjoy!

Using Configuration Files With Shell Scripts

If you have worked with the command line for a while, you have no doubt noticed that many programs use text configuration files of one sort or another.  In this lesson, we will look at how we can control shell scripts with external configuration files.

Why Use Configuration Files?

Since shell scripts are just ordinary text files, why should we bother with additional text configuration files?  There are a couple of reasons that you might want to consider them:

1. Having configuration files removes the need to make changes to a script.  There may be cases where you want to insure that a script remains in its original form.
2. In particular, you may want to have a script that is shared by multiple users and each user has a specific desired configuration.  Using individual configuration files prevents the need to have multiple copies of the script, thus making administration easier.

Sourcing Files

Implementing configuration files in most programming languages is a fairly complicated undertaking, as you must write code to parse the configuration file's content.  In the shell, however, parsing is automatic because you can use regular shell syntax.

The shell builtin command that makes this trick work is named source.  The source command reads a file and processes its content as if it were coming from the keyboard.  Let's create a very simple shell script to demonstrate sourcing in action.  We'll use the cat command to create the script:

me@linuxbox:~$ cat > bin/cd_script
#!/bin/bash
cd /usr/local
echo $PWD

Press Ctrl-d to signal end-of-file to the cat command.  Next, we will set the file attributes to make the script executable:

me@linuxbox:~$ chmod +x bin/cd_script

Finally, we will run the script:

me@linuxbox:~$ cd_script
/usr/local
me@linuxbox:~$

The script executes and by doing so it changes the directory to /usr/local and then outputs the name of the current working directory which is /usr/local.  Notice however, that when the shell prompt returns, we are still in our home directory.  Why is this?  While it may appear at first that the script did not change directories, it did as evidenced by the output of the PWD shell variable.  So why isn't the directory still changed when the script terminates?

The answer lies in the fact that when you execute a shell script, a new copy of the shell is launched and with it comes a new copy of the environment.  When the script finishes, the copy of the shell is destroyed and so is its environment  As a general rule, a child process, such as the shell running a script, is not permitted to modify the environment of the parent process.

So if we actually wanted to change the working directory in the current shell, we would need to use the source command and to read the contents of our script.  Note that the name of the source command may be abbreviated as a single dot followed by a space.

me@linuxbox:~$ . cd_script
/usr/local
me@linuxbox:/usr/local$

By sourcing the file, the working directory is changed in current shell as we can see by the trailing portion of the shell prompt.  Be aware that, by default, the shell will search the directories listed in the PATH variable for the file to be read.  Files that are read by source do not have to be executable, nor do they need to start with the shebang (i.e. #!) mechanism.

Implementing Configuration Files In Scripts

Now that we see how sourcing works, let's try our hand at writing a script that uses a the source command to read a configuration file.

In part 4 of the Getting Ready For Ubuntu 10.04 series, we wrote a script to perform a backup of our system to an external USB disk drive.  The script looked like this:

#!/bin/bash

# usb_backup # backup system to external disk drive

SOURCE="/etc /usr/local /home"
DESTINATION=/media/BigDisk/backup

if [[ -d $DESTINATION ]]; then
    sudo rsync -av \
        --delete \
        --exclude '/home/*/.gvfs' \
        $SOURCE $DESTINATION
fi 

You will notice that the source and destination directories are hard-coded into the SOURCE and DESTINATION constants at the beginning of the script.  We will remove these and modify the script to read a configuration file instead:

#!/bin/bash

# usb_backup2 # backup system to external disk drive

CONFIG_FILE=~/.usb_backup.conf

if [[ -f $CONFIG_FILE ]]; then
        . $CONFIG_FILE
fi

if [[ -d $DESTINATION ]]; then
        sudo rsync -av \
                --delete \
                --exclude '/home/*/.gvfs' \
                $SOURCE $DESTINATION
fi

Now we can create a configuration file named ~/.usb_backup2.conf that contains these two lines:

SOURCE="/etc /usr/local /home"
DESTINATION=/media/BigDisk/backup

When we run the script, the contents of the configuration file is read and the SOURCE and DESTINATION constants are added to the script's environment just as though the lines were in the text of the script itself.  The

if [[ -f $CONFIG_FILE ]]; then
        . $CONFIG_FILE
fi

construct is a common way to set up the reading of a file.  In fact, if you look at your ~/.profile or ~/.bash_profile startup files, you will probably see something like this:

if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
fi

which is how your environment is established when you log in at the console.

While our script in its current form requires the configuration file to define the SOURCE and DESTINATION constants, it's easy to make the use of the file optional by setting default values for the constants if the configuration file is either missing or does not contain the required definitions.  We will modify our script to set default values and also support an optional command line option (-c) to specify an optional, alternate configuration file name:

#!/bin/bash

# usb_backup3 # backup system to external disk drive

# Look for alternate configuration file
if [[ $1 == -c ]]; then
    CONFIG_FILE=$2
else
    CONFIG_FILE=~/.usb_backup.conf
fi

# Source configuration file
if [[ -f $CONFIG_FILE ]]; then
    . $CONFIG_FILE
fi

# Fill in any missing values with defaults
SOURCE=${SOURCE:-"/etc /usr/local /home"}
DESTINATION=${DESTINATION:-/media/BigDisk/backup}

if [[ -d $DESTINATION ]]; then
    sudo rsync -av \
        --delete \
        --exclude '/home/*/.gvfs' \
        $SOURCE $DESTINATION
fi

Code Libraries

Since the files read by the source command can contain any valid shell commands, source is often used to load collections of shell functions into scripts.  This allows central libraries of common routines to be shared by multiple scripts.  This can make code maintenance considerably easier.

Security Considerations

On the other hand, since sourced files can contain any valid shell command, care must be take to make sure that nothing malicious is placed in a file that is to be sourced.  This holds especially true for any script that is to be run by the superuser.  When writing such scripts, make sure that the super user owns the file to be sourced and that the file is not world-writable.  Some code like this could do the trick:

if [[ -O $CONFIG_FILE ]]; then
    if [[ $(stat --format %a $CONFIG_FILE) == 600 ]]; then
        . $CONFIG_FILE
    fi
fi

Further Reading

The bash man page:

• BUILTIN COMMANDS (source command)
• CONDITIONAL EXPRESSIONS (testing file attributes)

The Linux Command Line:

• Chapter 35 - Strings And Numbers (parameter expansions to set default values)