Fascinating insight.
Post by Jeff Hubbs via AleWow, this sure exploded.
I did federal IT for the first twelve years of my career - starting in
1986 (DoD/DoE). I've been a federal contractor and subcontractor in the
years since, and for the past several years I've had a view from the
sidelines at how CDC IT goes.
1980s DoD was a place where IT feds were expected to know what they were
doing; we ran and worked with the systems. A guy I worked with identified a
bug in VMS and dug through the source code on microfilm (yes, we paid big $
to DEC for that) to run it down. I worked with the local DEC field office
to get repairs and updates done, but anything shy of what their techs *had*
to be called for, I was on the hook for figuring out and/or fixing. As an
aside, I think the most stunt-geeky thing I ever did was to troubleshoot a
dead disk controller (which was a unit the size of a mini-fridge) by
opening it up and discovering that a paper sticker on an airflow sensor had
worked loose and covered up the inlet hole, making it think the blower had
failed and shut down the power supply.
We had fulltime on-site contractors in DoD, but 1) we outnumbered them
overwhelmingly 2) they were there for specific reasons, like as tech
experts on their employer's arcane or bespoke products. In DoE, the
circumstances were totally reversed: the federal overseers were greatly
outnumbered by contractors and the contractors didn't necessarily
appreciate being overseen very much. The more of an SME you were as a fed,
the more you were actually rather perceived as a threat, by and large.
The biggest difference between the way IT went in 1980s DoD and later on
was that the hardware, the OS, the compilers, much of the application
software, and most of the peripherals were all yoked together with the
vendor. It made a certain sense to have local support offices and pay the
vendors tons of money because the IT vendors foisted that scenario on
everyone. Most of the time, your vendor would have been IBM, DEC, HP,
Control Data, or DG. Maybe some Pr1me. I was still at DoD when SGI/Irix
dropped.
Then IT changed in four vitally important ways. First, hardware became
more commoditized, first with vendor-agnostic hardware/comm standards
(e.g., ISA/EISA, SCSI, Ethernet, TCP/IP) and then x86 hardware that could
run completely different OSses (the first x86 server hardware I ever saw
was badged Banyan to go with their excellent network OS, which IIRC was
based on a Unix variant called Interactive); hand in hand with this was an
explosion of application software vendors. Second (and later), F/OSS made
the sheer spread and democratization of computing in industry, academia,
and the home. Fourth: IT became like what *Frampton Comes Alive* did to
the music industry; all of a sudden there was Procter-&-Gamble-grade money
to be made and perhaps more than any other firm, Microsoft amplified
revenue off their meager and creaky offerings to previously unthinkable
levels.
What I got pounded into me in federal IT was that you were supposed to -
actually, you were *duty-bound* to - do as much as you possibly can for as
little money as possible. This meant that if do to a given thing with IBM
cost X but to do that same thing with DEC cost 0.2X, then you darn well had
better go DEC...or, if yet another vendor could get you there for 0.1X,
then that's what you did. The federal competitive procurement system was
supposed to be designed to formalize that process so that the various
federal agencies were assiduously effective "stewards of Taxpayer money"
(yes, we'd capitalize that "T;" in recent years I have had to train myself
to stop capitalizing the "F" in "federal," which is in no layperson's style
guide anywhere but is routine within government). That was the ideal
anyway; the reality fell far short of that, especially after those three
big changes I alluded to above. For one thing, federal policies drove the
ever-increasing tendency to contract out more and more of federal work
across the board - generally at increased cost to the Taxpayer. The problem
is that the forces of democratization, commoditization, the F/OSS movement,
and standardizing on standards instead of standardizing on vendor products
run counter to the idea of corporations making cubic megawatt-meter-newtons
of money not just when you first buy something but every quarter
thereafter. And so even though *none of it is even the least bit necessary
to run good IT anymore*, the old pay-vendor-in-perpetuity model remains.
Fewer people would get to have memberships at the really nice golf clubs
otherwise and Jaguar franchisees would languish.
I'll tell you what spooks me: the trend to privatize/cloud-ize DoD
computing resources. One of the things we always had in mind in DoD was
that we still needed to be able to have our computing resources functional
and performing as expected *even if the US were at war or even under active
attack*. The systems I ran would have been good to go unless or until
someone delivered ordnance to my raised-floor. I needed no permission from
any outside entity to process, store, or receive data, and as long as we
had electrical power and telecomm to our crews, depots, etc. then we were
self-sufficient enough to hold up our little end of the nation's defense.
What's funny to think about is that I'd have about as much computing power
available to me now as I had then if I took a PCI-bus 486 server and put
Linux on it.
F/OSS was supposed to free us from being beholden to corporations (i.e.,
pay them once and having to keep paying them in order to obtain permission
to continue functioning) in order to create and run high-quality computing
resources. Some sectors of society have embraced that but others, including
government, by and large have not.
The DoD and any other government agencies should be using Debian.
DoD needs a throat to choke. They want 1 phone call to have someone
on-site, working the issue. This is a requirement for huge corporations
as well. They don't want to become experts in Linux. They want a
solution that someone else manages.
Support for the system does not have to be provided by the maintainers
of the software. Support could come from any trustworthy American
technology firm.
Who can support all the DoD locations? Simba's Linux Shoppe?
The only other serious option would be from Oracle. SuSE isn't large
enough.
Debian is the best choice because it is the most open and free, as well
as the most stable and mature, as well as offering full capabilities in
terms of applications and security. It's simply the best choice.
IYO. Many people would disagree.
SELinux is a requirement for many DoD systems. How stable is that on
Debian? I honestly don't know.
To limit government systems to inferior operating systems because they
offer commercial support from the developers is very 1980s.
What? It comes down to having an organization that can solve the issues
for the client. There are few other Linux support organizations with
the expertise across the entire Linux stack to solve issues.
Running a WP web server doesn't make someone an expert at kernel drivers
or the opposite.
In complex environments, understanding all the other complex moving
parts and those interactions is non-trivial. Tracking down some SAN
connection and compatibility issues isn't something most organizations
can handle.
Here's hoping that IBM doesn't do to Redhat like what Oracle did to Sun
Microsystems.
_______________________________________________
See JOBS, ANNOUNCE and SCHOOLS lists athttp://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo