<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-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"
      cite="mid:7ceff4c2-a80d-dcae-f9bf-6a0e6b831eff@jdpfu.com">
      <pre wrap="">On 10/29/18 7:33 AM, Simba via Ale wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">The DoD and any other government agencies should be using Debian.
</pre>
      </blockquote>
      <pre wrap="">
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 wrap="">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 wrap="">
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 wrap="">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 wrap="">
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 wrap="">To limit government systems to inferior operating systems because they
offer commercial support from the developers is very 1980s.
</pre>
      </blockquote>
      <pre wrap="">
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="moz-txt-link-abbreviated" href="mailto:Ale@ale.org">Ale@ale.org</a>
<a class="moz-txt-link-freetext" href="https://mail.ale.org/mailman/listinfo/ale">https://mail.ale.org/mailman/listinfo/ale</a>
See JOBS, ANNOUNCE and SCHOOLS lists at
<a class="moz-txt-link-freetext" href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a>
</pre>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>