[ale] IBM is buying Redhat!

[Jeff Hubbs]

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 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/20181029/1fae473a/attachment.html>