<div dir="ltr">Fascinating insight.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 29, 2018 at 10:09 PM Jeff Hubbs via Ale <<a href="mailto:ale@ale.org">ale@ale.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="m_-5345280060224762135moz-cite-prefix">Wow, this sure exploded.<br>
<br>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
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 x86
hardware useful without having to open anyone's pursestrings.
Third: the sheer spread and democratization of computing in
industry, academia, and the home. Fourth: IT became like what <i>Frampton
Comes Alive</i> 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
On 10/29/18 8:35 AM, DJ-Pfulio via Ale wrote:<br>
</div>
<blockquote type="cite">
<pre>On 10/29/18 7:33 AM, Simba via Ale wrote:
</pre>
<blockquote type="cite">
<pre>The DoD and any other government agencies should be using Debian.
</pre>
</blockquote>
<pre>
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.
</pre>
<blockquote type="cite">
<pre>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.
</pre>
</blockquote>
<pre>
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.
</pre>
<blockquote type="cite">
<pre>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.
</pre>
</blockquote>
<pre>
IYO. Many people would disagree.
SELinux is a requirement for many DoD systems. How stable is that on
Debian? I honestly don't know.
</pre>
<blockquote type="cite">
<pre>To limit government systems to inferior operating systems because they
offer commercial support from the developers is very 1980s.
</pre>
</blockquote>
<pre>
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.
_______________________________________________
Ale mailing list
<a class="m_-5345280060224762135moz-txt-link-abbreviated" href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a>
<a class="m_-5345280060224762135moz-txt-link-freetext" href="https://mail.ale.org/mailman/listinfo/ale" target="_blank">https://mail.ale.org/mailman/listinfo/ale</a>
See JOBS, ANNOUNCE and SCHOOLS lists at
<a class="m_-5345280060224762135moz-txt-link-freetext" href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a>
</pre>
</blockquote>
<p><br>
</p>
</div>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="https://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">https://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div>