[ale] IBM is buying Redhat!

Rich Roberts orngwip at gmail.com
Tue Oct 30 09:51:56 EDT 2018


Fascinating insight.

On Mon, Oct 29, 2018 at 10:09 PM Jeff Hubbs via Ale <ale at ale.org> wrote:

> Wow, 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
> 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 *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.
>
>
> On 10/29/18 8:35 AM, DJ-Pfulio via Ale wrote:
>
> On 10/29/18 7:33 AM, Simba via Ale wrote:
>
> 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.
>
> _______________________________________________
> Ale mailing listAle at ale.orghttps://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists athttp://mail.ale.org/mailman/listinfo
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> https://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20181030/c9b0f440/attachment.html>


More information about the Ale mailing list