Quick Tip: Moving Chrom[e/ium]’s Buttons

So if you’re an Ubuntu user and you use Unity for your desktop and Chromium (or Chrome) as (one of) your browser(s), maybe you’ve been bugged by the placement of the window buttons when you don’t have the window maximized. If you want some consistency, there’s an easy fix that you can run from the command line. If you want to change the placement or order of your window buttons in Chromium, just open up a terminal window and enter

gconftool-2 --set /apps/metacity/general/button_layout --type string "minimize,maximize,close:"

Before

After

 

Note that the code above will move the buttons to the left but won’t put them in the right order. If you want to put them in the same order as the window buttons on all your other programs, change the order so “close” is the first item in the above command. The colon in that string indicates the placement of the buttons, so if you want to move the buttons back to the right, move the colon to the beginning of the string (and of course reorder the buttons, unless you like a little bit of inconsistency just to screw with other users on a particular machine).

Credit goes to Leet Tips for the command, though not the explanation (that was me).

Chromebooks in an Enterprise/Education Environment

We recently deployed a new cart containing 20 of Samsung’s new $250 Chromebook.  If you haven’t been able to get your hands on one of these new machines, let me just say that they’re really quite nice, especially for the price.  Yes, the build-quality is a bit, well, plastic-y, but what can you really ask of a machine that costs that little?  We’re a Google Apps campus, so Chromebooks are a great choice for a lot of things, and if we need some software that doesn’t run on them, we have other laptop carts.

A day or so after we first deployed the cart, though, we ran into a pretty major (but avoidable) hiccup–they were killing our network.  Some students were able to log in but unable to get to the site they needed, while others weren’t even able to log in.  Worse, students with their own laptops were also unable to get online, or their connection speeds were about what you would expect if you dialed into AOL with your Pentium 2 PC.

Why did this happen, and how can it be avoided in the future, you ask?

These machines shipped with Chrome OS version 23-point-something, and the current production release of Chrome OS is 25-point-something.  The machines also needed a firmware update.  This accounted for something on the order of 300MB of data that each machine needed to pull down.  That would kill just about any AP.  While our machines are enterprise-enrolled and thus had gone on the network at least once before they were first used in class in order to get them enrolled in our domain, none of them had been online for more than 30 seconds.  In our domain management dashboard, we were able to set our machines to scatter automatic updates over a period of days to prevent this problem from recurring (the available range is 1-14 days), but, as a preventative measure before we did this, we pulled out the new machines two or three at a time and forced them to update.

As of this writing, I have received reports of 16 of the 20 Chromebooks being used at the same time by a class with no abnormal slowdowns in the network.

I must acknowledge the help and advice offered by members of the Chromium OS dev team who came to our aid quickly and helped us solve this issue in an afternoon.