Contents
After reading endless articles on
bug tracking,
using lint, and
software productivity
I decided to make it my personal mission to become more strict about using
these basic tools.
Like many developers, I work with a small, tightly coupled team of developers
that uses ad-hoc methods for source control, bug tracking, and code reviews. As
more developers are added to the team, the risk of forgetting about bugs or losing
code due to accidents in merging becomes too large to ignore. More formal
management methods are called for.
Like many developers, I find it hard to get support for formal methods
from management and other team members. Between the actual cost of commercial
tools and the soft cost of setting up a system and getting training, the chances
of getting this past the idea stage is slim to none.
Too bad, boo-hoo, cry me a river...
I'm going to do it anyways. I'm going to do it at home, using hardware I have
kicking around in the basement. I'm going to use free software so that the cost
argument is gone. I'm going to do the absolute minimum amount of work so that
the time argument is gone. And I'm going to write it up so that other developers
like you can do it too.
This series not so much about using FreeBSD to do the
actual editing, compiling, and debugging as it is about using FreeBSD to
manage the day to day activities that a typical software development team
must deal with. Most developers still need to use Windows-based systems to
compile and debug because that's what the tool vendors support.
I don't want to give you the impression that setting up an embedded firmware
development environment using FreeBSD is a piece of cake.
It's not. You'll need to spend some time and effort learning how to use and manage
a *nix computer effectively.
That being said, the best general resource I've come across lately is
Æleen Frisch's Essential System Administration.
I use this book as a bible for many of the tasks outlined here. The section on
users, groups, and how the filesystem permissions are assigned is especially clear.
If you decide to go with FreeBSD for your server, the next book you'll need
is Greg Lehey's The Complete FreeBSD. During the
first install process you will refer to this book often. Once you become familiar
with your FreeBSD box, it will help you optimize things for speed, reliability,
and security.
Each of the articles in this series describes one step that will help you
build an embedded systems project management server. These articles will have
a Resource section with links to helpful essays on the Web. Read and think about
these essays along with the article before you actually sit down to make
changes to your server.
A little thought before making changes can go a long way to preventing
disasters. Make sure that you back up any important files before you touch
anything on the server, and that you really understand why things are being done.
Finally, I'm assuming that your server is behind a corporate firewall, or is
connected to the internet through your router. My own system is behind a wireless
modem/router that uses port forwarding so that external Internet acess can be
done easily. I use a dynamic DNS service to make all of this work seamlessly, but
that's really for another chapter...
Essentially, you're going to be setting up a FreeBSD server that will
manage your source code for each project in its own CVS-like archive. You'll also
learn how to set up Gnats to manage a bug list. Finally we'll discuss
how to use your FreeBSD server to run some common utilities like lint, as well
as finding out about other great software you can use to make your embedded
programming life easier.
Before any of that can happen, you'll need set up a bare-bones box with
FreeBSD, and find a way to communicate with that box from your regular Windows
or FreeBSD workstation.
What do I mean by barebones? I was using an old HP Pavillion 3260 with
a Pentium MMX 233 and 64 MB of RAM. It doesn't even have any L2 cache!
The initial setup used a hardwired Ethernet card, but I've since upgraded
it with a wireless card. I had a spare 13GB hard drive kicking around, but
anything bigger than 4 GB should be fine for now. The CDROM is still an old
4x drive - slow, but we only need it for the initial setup.
My more recent systems are built around the excellent HP eVectra
computer chassis. It's a really small box with a Celeron 566 or 700 and
128 MB of RAM. I make these little boxes even quieter by putting in a
40GB Seagate Barracua and a Panaflo fan.
You don't need the latest and greatest hardware to make a decent server, and
part of the goal here is to initially do things on a shoestring budget. Once you
see the benefits, it might be worth your while to move on to more modern
hardware that includes RAID and maybe a DVD burner.
You'll need a standard monitor and keyboard to set the box up. I hate
noisy PCs, which is why the Pavillion was retired from active duty in the
first place. Once FreeBSD is up and running and we can communicate with it, the
box will be moved to a closet or shelf somewhere in the basement where I
don't need to listen to it.
Eventually, we'll want to upgrade the hardware to something a bit more
dependable, but this will get us started. You'll want to run a decent
hardware test suite, or at the very least burn in the machine for a few days
before doing anything. The very best thing for this is to get yourself a copy
of the Ultimate Boot CD, a collection
of memory test, disk test, and generally useful programs that will let
you check out your system before you commit time and trust your valuable data
to it.
The final thing you'll need is some time to read and think about what we're
doing, so don't try to squeeze it all into a marathon all-nighter. Spend
30 minutes or an hour a day at the most on this project. You've been working
for years using ad-hoc methods - so spending a few weeks and getting comfortable
with your FreeBSD box isn't going to hurt.
