Conversion to Linux

Sean Crago cragos at gmail.com
Fri Oct 31 11:11:27 CDT 2008


You want gradual, system by system? Okay: Can you give us a couple of
examples of the systems you run and which are the most problematic?
Also, you say that you're the only person in your firm with deep
experience in the Lunixes - How many other people might end up
responsible for these systems if you were to take leave? Feel up to
the task of training 'em and documenting everything?

I lucked out, the one time I was able to make this transition. I was a
one man shop, working for a firm where my predecessors had failed to
talk the previous generation of management into paying for a legal
license for anything. Despite this, they replaced a couple of OpenBSD
machines with a handful of new homemade Celerons running a proprietary
operating system boxes and another firm's proprietary mail server. I
walked in after everyone involved in those decisions had left, and was
picking up the pieces. The mail server was incredibly crash prone,
partly due to it being a Celeron with 512MB of RAM, partly due to the
poorly maintained Windows install, and partly due to the lack of
updates and support for any of it. Dug out the old Pentium III Xeon
machines that these new Celerons had replaced and build a normal old
Gentoo server. Moved over the easy stuff first - DNS, Apache (they'd
moved the old webserver onto a Win32 build of Apache to save them from
having to rewrite their configs - Made my life a lot easier, moving it
back.) Given that proof of concept and the clear win of having
replaced proprietary unlicensed software with open and freely licensed
software, it was easy to talk the boss into plunking some money down
to reverse engineer parts of the proprietary mail server and cut it
over to something open source.

I've never been in a position where I could do this since then,
however. Working in a sizable department in a medium-large
organization makes it a lot harder to find time to put together a
proof of concept, train old employees on the new systems, and move
away from deeply embedded Microsoft contracts.

Good luck, but you've probably got a tough slog ahead of you, unless
you're fortunate enough to either be in charge of your department or a
member of a 1-3 man "department." Without that, you might just find
that you're taking too big a first step. What open source tools can
you roll out in your current proprietary environment that might ease
the way?

Again, good luck,
Sean Crago
Kathmandu


More information about the Kclug mailing list