The Msys Toolkit
The City Toolkit
Last updated: Nov 9, 99.
Maintained by Systems.
At MCS, our group's primary responsibility is to build and maintain
the computing and network environment. We're Systems and Network
But, ask any systems administrator - with the demands of holding
together a computing system, it's nearly impossible to find time to design
and code a system. It's even harder to build something that other people
can use in other environments.
However, we have a number of core beliefs that have helped to shape
our software design and release strategy.
In other words - you're welcome to the tools we've built. Please tell us
what you think. They may not be perfect yet, but we're happy that we can
build them and get them to you at all. Hopefully you'll feel the same way.
- A computing environment should be designed and operated as a
coherent unit, not as pile of individual machines. Our software is
built around the philosophy of driving the entire network from one spot,
and of having a way to describe the environment and then force the systems
to conform to that description. We use databases and central repositories
to help implement this philosophy.
- The State of Systems Administration and Systems Software must be
improved. We believe that one of the best ways to do this is to build
and release tools that help push the state of the field, or at least make
people think about the issues. (Another good way is to write papers about
tools, techniques and issues. Thanks to USENIX for creating a forum that enables
this to happen.)
- Release first, clean up second.
Systems administrators have three major reasons not to release
the tools they build.
Unfortunately, this means that most admins don't release code.
- Systems administrators are all too busy to find time to code, and
typically it's not part of their job description. Thus a lot
of code that admins write is thrown together.
- Every site is different, and every tool is built with the
requirements of that site in mind. Making the tool more widely
useful takes a lot of extra work.
- It's very hard to find the time to support the code once it has
been released if that's not what you're really supposed to be doing.
Many times, though, someone else has a tool that we would love to use even
if it took us half an hour of grepping through the code changing hard-coded
paths before we could try it out. That's ok, we don't mind doing that,
and we wouldn't complain.
Thus we believe that it's better to get the code out there and let people
stomp around on it than to keep it hidden internally and never let it out.
And, while we can't commit the time to officially
support our code at other
sites, we've find that doing what we can to address issues helps to improve
the quality of the code.
- Open Source is Good. For many, many years, we've been using
free software from the net. We could not have built the environment
we have now without it, and we could not run our computers without it.
We believe in the communities that open source helps to nurture and
we believe we should do our part to contribute.