IT Infrastructure and Software Development from the Customer's Perspective
I’m back to doing a bit of Rails. As always, the world has moved on. Rails is at 4.0.2, and Ruby 2.0 is out. The Rails folks are recommending rbenv to manage different Ruby versions and their gems. I knew I still had some learning to do to be using rvm properly, so I decided to invest the learning time in learning rbenv, since that’s what the mainstream was using.
First, I had to remove the lines at the end of my ~/.bashrc, ~/.profile, and ~/.bash_profile, and restart all my terminal windows.
I followed the rbenv installation instructions here: https://github.com/sstephenson/rbenv#installation, including the optional ruby-build installation.
Then, I did:
rbenv install -l
that shows 2.0.0-p353 as the newest production version of MRI. So I did:
My son wanted Team Fortress 2 for Christmas. So far we’ve been mostly blessed with not having to feed a relentless video game appetite (aside from Minecraft). But I looked into it, and the game was free, with a very recently released Linux version. So I thought, “what the heck. It would probably only take me a few hours of fooling around to make it work.”
Well, it was more than a few hours, but mostly because of my insistence on doing things “right”.
TF2 is an interesting game. It runs in an environment, or framework, or something, called Steam. Steam supports many other games. In fact, it appears to be a whole ecosystem of games and communities around the games. There’s a .deb to install Steam on Debian-derived LInuxes, and that’s the first thing I installed.
I followed the Ubuntu forum for the installation, specifically using the experimental nVidia driver. I have a 9300, which is less than the forum says I need (9600 and above). Using the experimental driver allowed me to get Steam to run.
You have to sign up to the Steam community to use it. You can do so in
the game.
To install TF2, I started Steam and found it in the on-line store. It’s
a long download. I think it took five or six hours on my reasonably
fast ADSL. (I usually get 250-300 KB/s).
Finally, I could run the game under my user.
Here’s where my insistence on doing it “right” first caused issues. My son has his own Linux user on his computer, which is not the user that installed Linux. His user was created as an ordinary non-admin user. My son doesn’t have any special privileges on his computer, which is fine for me at his age. I don’t want him to be able to mess up the configuration of his computer.
TF2 gets installed under the user’s home directory, so I had to download again for my son. (You could probably just copy the appropriate directory or directories from one user to the other, but that would make the problem of getting the game running even harder if it didn’t work the first time, which it didn’t.)
Trying to run the game from my son’s user name caused some disk activity and a few progress dialogues to appear, but then I’d just end up staring at the Steam home page after a few minutes. Running Steam from the command line allowed me to see all sorts of output, including the report of a “Segmentation fault” at the time the disk activity stopped.
Many hours of thrashing about and googling followed. Finally, it dawned on me that the only real difference between the users (mine and my son’s) had to be the groups that they were in. (The Linux security model allocates some privileges to “groups” rather than directly to users. You then assign the user to a group to allow them the privileges of the group.)
Some trial and error fairly quickly determined that the user running TF2 has to be in the “sambashare” group. I logged in as me, the user who installed Linux. Then, in a Terminal, I could have typed:
sudo adduser user sambashare
However, I got intrigued that I couldn’t find the GUI do manage users and groups. I discovered that it doesn’t come installed by default on Linux Mint 13. So I installed the Gnome system tools:
sudo apt-get install gnome-system-tools
With the Gnome system tools installed, I:<ol><li>Went to Menu->
Administration-> Users and Groups</li><li>Selected my son’s user
name</li><li>Clicked “Advanced Settings”</li><li>Entered my
password</li><li>Clicked the “User Privileges” tab</li><li>Checked the
box beside “Share files with the local network”</li><li>Clicked OK all
the way out again.</li></ol>
Note that I did all the above as myself, the user who installed Linux,
not as my son.
Now I logged out of my session and logged in as my son and TF2 ran. Woo hoo!
Note that the LInux version of Steam and/or TF2 is very new right now (end of December, 2012). I found a lot of info on the net was no longer applicable, because of the evolution of the game and the platform. Even the contents of the Ubuntu forum for Steam changed drastically in the few days that I was working off and on to get the game running.
Off topic, but of interest to my geek friends: Here’s a blog post about how the Steam effort is contributing to better graphics support in the Linux world.
I’ve written lately about my struggles with sluggish Ubuntu and Mint desktops. Finally, I discovered that Chrome was the problem. At one point in my ramblings, I recommended using Mate instead of Cinnamon. Well, I’m happy to report that my slow Dell Vostro 1440 runs Cinnamon just fine, as long as I’m not running Chrome.
Long fat networks are high bandwidth, high latency networks. “High latency” is relative, meaning high latency compared to a LAN.
I ran into the LFN phenomena on my last data centre relocation. We moved the data centre from head office to 400 kms from head office, for a round trip latency of 6 ms. We had a 1 Gbps link. We struggled to get a few hundred Mbps out of large file transfers, and one application had to be kept back at head office because it transferred large files back and forth between the client machines at head office and its servers in the data centre.
I learned that one can calculate the maximum throughput you can expect to get over such a network. The calculation is called the “bandwidth delay product”, and it’s calculated as the bandwidth times the latency. One way to interpret the BDP is the maximum window size for sending data, beyond which you’ll see no performance improvement.
For our 1 Gbps network with 6 ms latency, the BDP was 750 KB. Most TCP stacks in the Linux world implement TCP window scaling (RFC1323) and would quickly auto tune to send and receive 750 KB at a time (if there was enough memory available on both sides for such a send and receive buffer).
SMB 1.0 protocols used by most anything you would be doing on pre-Windows Vista are limited to 64 KB blocks. This is way sub-optimal for a LFN. Vista and later Windows use SMB 2.0, which can use larger block sizes when talking to each other. Samba 3.6 is the first version of Samba to support SMB 2.0.
We were a typical corporate network in late 2011 (read, one with lots of Windows machines), and they were likely to suffer the effects of a LFN.
I’ve been struggling for some time with poor performance of Ubuntu, and now Mint, on my Dell Vostro 1440. Admittedly it’s a cheap laptop, but in this day and age a Linux desktop should run decently on pretty much anything, as long as you’re not using a lot of fancy desktop effects.
Running top I was seeing a lot of wait time. When the performance was really bad, I’d see over 90 percent wait time. Typically I’d be dipping into swap space when performance was bad, but it would be bad without swapping (I “only” have 2 GB of RAM). I would see this when running only Thunderbird and Chrome, although Chrome with a lot of tabs open.
I spent many frustrating hours Googling for performance issues on Ubuntu or Mint and didn’t find anything really promising.
Finally, last weekend I was dropping off some old computer gear for recycling at our local Free Geek and saw a pretty sweet Dell laptop for sale. I started playing with it, partly to see how it performed. They sell used computers with Ubuntu, and Ubuntu comes with Firefox. Firefox was snappy as all get out, and on a lower powered CPU than mine at home.
So I went home and tried Firefox. It works great. So I started Googling performance problems with Chrome on Linux and got all sorts of hits. This one looks like it’s turning into a bit of an omnibus bug report, but has some good info and links to other places.
A few months after my last post about installing Ruby on Rails, and much has changed. There was an issue with zlib so I had to flail around a bit. The following instructions are what I think I should have done:
rvm install 1.9.3-p194
rvm --default 1.9.3-p194
gem install rails
sudo apt-get install sqlite
sudo apt-get install libsqlite3-dev libmysqlclient-dev
sudo apt-get install nodejs
Now create an application to test:
rails new testapp
cd testapp
rails server
Browse to localhost:3000 and you should see the Rails default page.