Great Rack Mount Mistakes #6

A long time coming, here's another story from my days long past, this one takes me to my very first serious role in an IT department, I was however just the dogs body.  The company ran many old PC's (which I actually was around to see mostly be updated to nice Compaq Pentium III's) and they had a couple of high spec Silicon Graphics workstations in the design department.

The main manufacturing control and purchasing system, as well as payroll and a bunch of other services ran on a dual 386 based mini computer, which had a custom cut of ScoUnix and a bunch of bespoke C programs comprising the actual system stack, this was accessed by a whole host or Gandalf multiplexers combining the serial connections down from a hundred or so Wyse brand terminals (I wish I'd have nabbed one of those before I left).

Anyway, it was time for this back end stack to be updated, and so a pair of Compaq Proliant servers were brought in, these were dual Pentium III class with a dedicated storage unit and a large; and importantly heavy; UPS unit.

The problem?  The IT manager I worked for (Hi Dave) didn't get on at all well with the manager at the co-location this unit was to be installed in.  Therefore in a dual effort to maintain any vestige of control and avoid the guy he didn't like, my boss ordered all the equipment to be delivered to our office... In central Nottinghamshire.... Yet its final destination once configured was to be outside Peterlee in the North East, near Newcastle.

So after around a day of setting up the equipment and (as far as I recall) three days solid compiling time - yes it took that long - the system was ready to go.

However, no-one had kept the boxes, yes it was all out of the box spread on a floor and then hand hauled over to a fire-exit and precariously piled into the back of a Hyundai estate.

Yes, that's how tens of thousands upon thousands of pounds worth of top notch equipment (for 1998) made it's precarious way 120 miles, bouncing and jostling all the way.

At the time I never questioned this, I was a lowly minion, I would of course council against such a move ever again, the installation of the physical equipment should have been done at the remote site, and they definitely should have kept the boxes and packaging in full!

Updated Tutorial - Installing SVN (Subversion) on Ubuntu 14.04 Server

Back in May 2012 I posted a pretty complete tutorial on how to create a virtual VMware machine image for ubuntu, install apache2 and svn upon it, and configure it for access over your LAN.

Tonight, I've just migrated that very installation to a new Ubuntu Server 14.04 installation on a new XenServer.

And I noted I needed to add an extra line of configuration, therefore, I've added a little video note, which also shows the server working for me locally on my LAN:

The original tutorial can be found in it's full glory here: http://megalomaniacbore.blogspot.co.uk/2012/05/virtualizing-installing-and-using.html

Like, Subscribe, Tip if this helps!

GNU C/C++14 Installation & Codeblocks 16.01 from Source (Command Line)

In yesterdays post I explained a C++14 user was having instant issues with the vanilla install of gcc/g++ on Ubuntu 14.04 LTS.

Getting a C++14 Compiler
So, here today are my command-line steps to update the GNU Toolchain v5.x.

sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-5 g++-5

If you already have compiler alternatives you may need these lines.

sudo update-alternatives
sudo update-alternatives --remove-all gcc
sudo update-alternatives --remove-all g++

But, everyone will need to swap the default gcc and g++ command-lines to the new paths to make them the defaults.

sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-5 20
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-5 20
sudo update-alternatives --config gcc
sudo update-alternatives --config g++

These last two --config commands are only needed if you have multiple alterantives, so don't worry if it tells you it's failed as you only have the one.

Now, if you perform g++ --version, you should see it's a version 5.x series compiler.

Codeblocks 16.01
Older versions of Codeblocks may start to error on the code completion with some of the C++14 specific commands.  So, we need install some prerequisites, and then build the latest 16.01 version from source.

sudo apt-get instal gtk+-2.0 automake libtool libwxgtk2.8-dev libwxbase2.8-dev

wget http://sourceforge.net/projects/codeblocks/files/Sources/16.01/codeblocks_16.01.tar.gz

tar -xvf codeblocks_16.01.tar.gz

cd code*

The next step is interesting, we need to iteratively check:

./bootstrap

Running this will show you anything wrong with your machine environment, any missing dependences etc... However, once bootstrap runs cleanly, you can continue below.

./configure
make
sudo make install

The make step takes quite a time, the more cores & RAM you have the better, on an 4 core (8 thread) machine with 8 GB of ram, I've found it takes about 10 minutes.  On a single core machine as the poor VM I had was assigned, it took a lllooooottttt longer.

Once complete we needed to use the text editor of our choice, in sudo mode....

sudo nano /etc/ld.so.conf

And to this we need to add the line:

include /usr/local/lib

Save the file, exit the editor and run:

sudo ldconfig

Once this was complete, we can run up Codeblocks, and see it's version 16.01.

And we can further see the nice new C++14 options in the build options:

Even the code highlighting recognises the make_shared operation:

Voila, if this helped, do check out my other posts, and code, leave a tip with my new tip jar!  And I'll be making a video of this one soon, as it's so useful.