[nSLUG] Possible Berwick Migration

Robert Ashley rb.ashley at gmail.com
Fri Mar 2 01:19:52 AST 2007


Hi Jim,

Appreciate your very thoughtful, comprehensive response. Lots of
super-sized food for thought.

On 3/1/07, Jim Haliburton <jim at on-site.ns.ca> wrote:
> Hello All:
>
> Robert Ashley Of Berwick was musing about a migration to Linux.  He was
> not clear if he was thinking Desktop or Server Migration.

Well actually both. I was considering a small redundant server and two
or three desktops to start. A zero risk proposition, to experiment.

> I have used in one form or another, sometimes successfully and sometimes
> not, Linux as a server.  I have struggled as have other users, with the
> Linux desktop scenario and cannot afford to waste time on it.
>
> I have several clients using Linux as a file and print server on a daily
> basis, without being aware of the OS.  For file and print services that
> is the way it should be.
>
> For any other than basic file and print service, specialized,
> complicated, and hard to find would be the way to describe support for
> the server.  If Berwick was to contemplate a move to Linux as a server I
> would suggest some very careful study of the entity's needs and user
> expectations.

Yes. I can tell you that the needs occupy two poles. One is very
basic, mainly email, word processing and a little else. The other pole
is tricky, utility and tax billing and accounting. I don't even want
to go there yet. But eventually, you bet. I'd love to find an OSS
municipal billing or accounting application. Conceivably, we could try
a completely redundant system in that area, make errors on purpose to
see what happens.

> Let's start with e-mail.  How is their mail currently handled?  Do they
> use Outlook? Outlook Express?   Are the users mail files stored on a
> server or the local PC?  Are all the systems using the same version of
> Outlook / Outlook Express so a user can move from desk to desk, login and
> see their own Outlook files??  Are some users popping their mail and
> others getting it from an Exchange server?  If they use Exchange, and the
> calendering and appointments system, what will they use in the future?
> What will the training cost be?  Will there be functionality
> shortcomings?

Outlook for email. Mail files on a Windows server. I think most are
using the same versions, but I'm probably wrong. We can move around
from one desk to another, but not all desktops, just some. Some of
share Outlook calendars, tasks.  I think retraining would be minimal
because most staff are not advanced users, so the bar is very low in
that respect.

>  What feature loss or gain will be a deal breaker or maker for the users?

I'm envisioning huge gains and nominal losses, through access to huge
libraries of OSS software, less downtime, and bragging rights.

> How will the Blackberry's be handled?  No BlackBerrys, what about syncing
> to the 10 different PDAs they have?  ( He did indicate they have about 10
> users. So 10 different PDA's would not be out of the question.)

None of these. We're primitive in this respect.

> Do they run a small database??  Maybe they run a host based app that runs
> on a Windows box.  When I say host based, I mean a Windows OS of some
> sort running an app that all (most) users use in a Workgroup setting.
> How will this app be handled in the future?

No database, although I'd love to set one up. This is virgin territory.

> Are all the versions of Word Processing they use, the same??  I have a
> client with 4 different versions of MS Office on only 7 computers.
> Outlook handles mail and appears differently on each of the 4 versions
> and their respective patch levels.  And their mail goes back 4 years and
> they have some 5000+ messages and attachments.  In some cases they have
> had to split up the mail as the mail store has exceeded 2Gb for each of
> several users!  They all have individual contact lists, and Address
> books, as well as the system wide.

No, different versions of Word/Excel. There are some jitters about
Vista, though, like Whoa! it's expensive, a resource hog, and well,
how good is it, really?
I think I'd order a massive house-clean on the emails, perhaps
archiving them off-site.

> >From a support point of view it is a nightmare, yet they are all
> reasonably happy and don't want change.
>
> Now lets look at mission critical apps.  Is there a municipal billing
> package that is common among municipal units?  Are they all expected to
> use it?  What if a Berwick strays from the mold.  They would have to
> develop their own support system, or pay dearly.  How would they access
> historical data if the old system is on one platform and OS, and the new
> and improved is on another?  Can a small 10 user entity afford
> virtualization and to maintain OS licenses and support for legacy apps?

No shared package for billing. Ours is custom, developed for a
municipal electric utility. It's problematic at times, but the bills
do get out. We can use whatever we want, no Provincial mandate or
policy.

The legacy question is a good one. Most of our crucial records
(minutes, contracts, etc, are duplicated in hard-copy, put in
binders...millions and millions of binders. You've dug up another
major issue for us, records management and archiving. We're probably
typical, relying on antiquated systems.

> Lets say Mr. Ashley develops and configures a new Linux server system
> with all the attendant unique configurations and apps for the municipal
> unit and they are happy.  What will  happen, and I am not meaning to
> imply that I want it to happen, but if the notorious highway through the
> valley claims his life and the laptop with all the carefully developed
> system tools and documentation??

I want some redundancy built it somewhere. The risk you describe would
have to be managed and minimized.

> If they had a non-Linux box with a corporate vendor, they would call up
> the vendor and find another experienced support admin.  As they are
> generally similar in operation, support would continue with a new name
> attached to the support role.  Now if it is a Linux box, who you gonna
> call??  Do they support that flavour and version of the OS?  Debian, oh
> well we only support XYZ Linux.

Yeah, that's it. That's my question.

> I have worked with the RedHat / Centos releases since RedHat 4.x (not
> RHEL 4.x but those versions before Fedora).  At one point we tried to
> change to SUSE.  The OS was the same right?  Wrong.  File locations,
> functionality, tools, all usually different, located in what we regarded
> as weird points in the directory.  But it was Linux right?  We gave up
> and continued with RedHat / Centos.  Much of the difference is that the
> cultural difference and thought processes of the creators, are not the
> same.  A manual written by an English speaker in the UK will have much
> less readability for a North American English reader.  Now just make it
> German thinking translated from English to German and back into English.
> There is as much difference from SUSE to RedHat as from a Mercedes to a
> Toyota.  They are both cars right?

Good point. Needs to go the list!

> So what is Berwick to do?  As a responsible admin, and I find it hard to
> believe that a group with 10 users even needs an admin person, the
> foremost task is to satisfy the needs of the users.  IT is a support
> function and an enabler of the task.  "IT" is not the reason that the
> Berwick Municipal unit exists.  One finds the needs, both legal, and
> operational of the users.  Find / develop a solution at the right cost in
> dollars to acquire, administer, and support that municipal function.
> Find best in class software solutions that meet their needs, from both a
> server and desktop perspective, and go with that.  If linux can provide
> the solution then go with it.  If another solution is better, then the
> admin is obliged to do what is best for the entity being served.

We have no person in charge. When we have problems we call the support
firm. All in all we get pretty good service.

Your analysis is right on, but not quite sufficient. We occupy a
political realm and political feasability is as necessary to consider
as anything else. For example, I've heard arguments coming from the
states, mainly, that electronic voting machines should provide free
and open access to source code. We MUST be able to audit the
application itself, so they say. Another is higher level, concerning
monopoly or virtual monopoly and how this comes to loggerheads with
procurement policies promoting fair and equitable competition between
suppliers and that govs should resist dependency on this or that
single firm. You can bet that politicians would take every opportunity
to make political hay. The politicians drive the administrations in
turn.

> Now I am in favour of an e-demo of a potential solution for small
> municipal units.  But before that is attempted the real needs of serving
> the community must be defined.

Spoken like a responsible citizen.

One of the possible services could be an initiative to reduce the
"digital divide" by treating the Town Hall as a distribution point for
free OSS, available to those who can't afford the high-priced
soft/hardware...and for that matter, to those who can afford it.

Another is to initiate support to help grow an indigenous application
development community, a form of local economic development.  If for
example, someone in Bridgewater developed some billing software, we'd
encourage anyone/everyone to work on the code and to share it with
everyone else.

And the idea of an OSS Foundation, an org targeted to the public good,
could only happen with OSS.

Bob

!DSPAM:45e7b3fc313711529212415!




More information about the nSLUG mailing list