As a 25yr+ vet of IBM, I can confirm that this article is spot-on true. IBM used to be a proud and transparent company that clearly
demonstrated that it valued its employees as much as it did its stock performance or dividend rate or EPS, simply because it is
good for business. Those principles helped make and keep IBM atop the business world as the most trusted international brand and
business icon of success for so many years. In 2000, all that changed when Sam Palmisano became the CEO. Palmisano's now infamous
"Roadmap 2015" ran the company into the ground through its maniacal focus on increasing EPS at any and all costs. Literally.
Like, its employees, employee compensation, benefits, skills, and education opportunities. Like, its products, product innovation,
quality, and customer service.
All of which resulted in the devastation of its technical capability and competitiveness, employee engagement, and customer
loyalty. Executives seemed happy enough as their compensation grew nicely with greater financial efficiencies, and Palisano got
a sweet $270M+ exit package in 2012 for a job well done.
The new CEO, Ginni Rometty has since undergone a lot of scrutiny for her lack of business results, but she was screwed from
day one. Of course, that doesn't leave her off the hook for the business practices outlined in the article, but what do you expect:
she was hand picked by Palmisano and approved by the same board that thought Palmisano was golden.
People (and companies) who have nothing to hide, hide nothing. People (and companies) who are proud of their actions, share
it proudly. IBM believes it is being clever and outsmarting employment discrimination laws and saving the company money while
retooling its workforce. That may end up being so (but probably won't), but it's irrelevant. Through its practices, IBM has lost
the trust of its employees, customers, and ironically, stockholders (just ask Warren Buffett), who are the very(/only) audience
IBM was trying to impress. It's just a huge shame.
I agree with many who state the report is well done. However, this crap started in the early 1990s. In the late 1980s, IBM offered
decent packages to retirement eligible employees. For those close to retirement age, it was a great deal - 2 weeks pay for every
year of service (capped at 26 years) plus being kept on to perform their old job for 6 months (while collecting retirement, until
the government stepped in an put a halt to it). Nobody eligible was forced to take the package (at least not to general knowledge).
The last decent package was in 1991 - similar, but not able to come back for 6 months. However, in 1991, those offered the package
were basically told take it or else. Anyone with 30 years of service or 15 years and 55 was eligible and anyone within 5 years
of eligibility could "bridge" the difference. They also had to sign a form stating they would not sue IBM in order to get up to
a years pay - not taxable per IRS documents back then (but IBM took out the taxes anyway and the IRS refused to return - an employee
group had hired lawyers to get the taxes back, a failed attempt which only enriched the lawyers). After that, things went downhill
and accelerated when Gerstner took over. After 1991, there were still a some workers who could get 30 years or more, but that
was more the exception. I suspect the way the company has been run the past 25 years or so has the Watsons spinning in their graves.
Gone are the 3 core beliefs - "Respect for the individual", "Service to the customer" and "Excellence must be a way of life".
IBM's policy reminds me of the "If a citizen = 30 y.o., then mass execute such, else if they run then hunt and kill them one by
one" social policy in the Michael York movie "Logan's Run."
From Wiki, in case you don't know: "It depicts a utopian future society on the surface, revealed as a dystopia where the population
and the consumption of resources are maintained in equilibrium by killing everyone who reaches the age of 30. The story follows
the actions of Logan 5, a "Sandman" who has terminated others who have attempted to escape death, and is now faced with termination
himself."
The USA isn't annoyed at Huawei spying, they are annoyed that Huawei isn't spying for
them . If you don't use Huawei who would you use instead? Cisco? Yes, just open up and let
the NSA ream your ports. Oooo, filthy.
If you don't know the chip design, can't verify the construction, don't know the code and
can't verify the deployment to the hardware; you are already owned.
The only question is, but which state actor; China, USA, Israel, UK.....? Anonymous
Coward
" The Trump administration, backed by US cyber defense experts, believes that Huawei
equipment can't be trusted " .. as distinct from Cisco which we already have backdoored
:]
How is it that that can be a point of contention ? Name me one country in this world that
doesn't favor local companies.
These people company representatives who are complaining about local
favoritism would be howling like wolves if Huawei was given favor in the US over any one of
them.
I'm not saying that there are no reasons to be unhappy about business with China, but that
is not one of them. 60Reply
..and we're all going to be poorer for it. Americans, Chinese and bystanders.
I was recently watching the WW1 channel on youtube (awesome thing, go Indy and team!) - the
delusion, lack of situational understanding and short sightedness underscoring the actions of
the main actors that started the Great War can certainly be paralleled to the situation
here.
The very idea that you can manage to send China 40 years back in time with no harm on your
side is bonkers.
You can put backdoor in the router. The problem is that you will never be able to access it.
also for improtant deployment countires inpect the source code of firmware. USA is playing dirty
games here., no matter whether Chinese are right or wrong.
They're not necessarily silos. If you design a network as a flat space with all interactions
peer to peer then you have set yourself the problem of ensuring all nodes on that network are
secure and enforcing traffic rules equally on each node. This is impractical -- its not that if
couldn't be done but its a huge waste of resources. A more practical strategy is to layer the
network, providing choke points where traffic can be monitored and managed. We currently do
this with firewalls and demilitarized zones, the goal being normally to prevent unwanted
traffic coming in (although it can be used to monitor and control traffic going out). This has
nothing to do with incompatible standards.
I'm not sure about the rest of the FUD in this article. Yes, its all very complicated. But
just as we have to know how to layer our networks we also know how to manage our information.
For example, anyone who as a smartphone that they co-mingle sensitive data and public access
on, relying on the integrity of its software to keep everything separate, is just plain asking
for trouble. Quite apart from the risk of data leakage between applications its a portable
device that can get lost, stolen or confiscated (and duplicated.....). Use common sense. Manage
your data.
"... The real issue is the semiconductors - the actual silicon. ..."
"... China has some fabs now, but far too few to handle even just their internal demand - and tech export restrictions have long kept their leading edge capabilities significantly behind the cutting edge. ..."
"... On the flip side: Foxconn, Huawei et al are so ubiquitous in the electronics global supply chain that US retail tech companies - specifically Apple - are going to be severely affected, or at least extremely vulnerable to being pushed forward as a hostage. ..."
Internet, phones, Android aren't the issue - except if the US is able to push China out of
GSM/ITU.
The real issue is the semiconductors - the actual silicon.
The majority of raw silicon wafers as well as the finished chips are created in the US or
its most aligned allies: Japan, Taiwan. The dominant manufacturers of semiconductor equipment
are also largely US with some Japanese and EU suppliers.
If Fabs can't sell to China, regardless of who actually paid to manufacture the chips,
because Applied Materials has been banned from any business related to China, this is pretty
severe for 5-10 years until the Chinese can ramp up their capacity.
China has some fabs now, but far too few to handle even just their internal demand - and
tech export restrictions have long kept their leading edge capabilities significantly behind
the cutting edge.
On the flip side: Foxconn, Huawei et al are so ubiquitous in the electronics global supply
chain that US retail tech companies - specifically Apple - are going to be severely affected,
or at least extremely vulnerable to being pushed forward as a hostage.
"... The British aerospace sector (not to be confused with the company of a similar name but more Capital Letters) developed, amongst other things, the all-flying tailplane, successful jet-powered VTOL flight, noise-and drag-reducing rotor blades and the no-tailrotor systems and were promised all sorts of crunchy goodness if we shared it with our wonderful friends across the Atlantic. ..."
"... We shared and the Americans shafted us. Again. And again. And now *they* are bleating about people not respecting Intellectual Property Rights? ..."
"Without saying so publicly, they're glad there's finally some effort to deal with longstanding issues
like government favoritism toward local companies, intellectual property theft, and forced technology
transfers."
The British aerospace sector (not to be confused with the company of a similar name but more Capital
Letters) developed, amongst other things, the all-flying tailplane, successful jet-powered VTOL flight,
noise-and drag-reducing rotor blades and the no-tailrotor systems and were promised all sorts of crunchy
goodness if we shared it with our wonderful friends across the Atlantic.
We shared and the Americans shafted us. Again. And again. And now *they* are bleating about people not
respecting Intellectual Property Rights?
And as for moaning about backdoors in Chinese kit, who do Cisco et al report to again? Oh yeah, those
nice Three Letter Acronym people loitering in Washington and Langley...
A claimed deliberate spying "backdoor" in Huawei routers used in the core of Vodafone
Italy's 3G network was, in fact, a Telnet -based remote debug interface.
The Bloomberg financial newswire reported this morning that Vodafone had found
"vulnerabilities going back years with equipment supplied by Shenzhen-based Huawei for the
carrier's Italian business".
"Europe's biggest phone company identified hidden backdoors in the software that could have
given Huawei unauthorized access to the carrier's fixed-line network in Italy,"
wailed the newswire.
Unfortunately for Bloomberg, Vodafone had a far less alarming explanation for the deliberate
secret "backdoor" – a run-of-the-mill LAN-facing diagnostic service, albeit a hardcoded
undocumented one.
"The 'backdoor' that Bloomberg refers to is Telnet, which is a protocol that is commonly
used by many vendors in the industry for performing diagnostic functions. It would not have
been accessible from the internet," said the telco in a statement to The Register ,
adding: "Bloomberg is incorrect in saying that this 'could have given Huawei unauthorized
access to the carrier's fixed-line network in Italy'.
"This was nothing more than a failure to remove a diagnostic function after
development."
It added the Telnet service was found during an audit, which means it can't have been that
secret or hidden: "The issues were identified by independent security testing, initiated by
Vodafone as part of our routine security measures, and fixed at the time by Huawei."
Huawei itself told us: "We were made aware of historical vulnerabilities in 2011 and 2012
and they were addressed at the time. Software vulnerabilities are an industry-wide challenge.
Like every ICT vendor we have a well-established public notification and patching process, and
when a vulnerability is identified we work closely with our partners to take the appropriate
corrective action."
Prior to removing the Telnet server, Huawei was said to have insisted in 2011 on using the
diagnostic service to configure and test the network devices. Bloomberg reported, citing a
leaked internal memo from then-Vodafone CISO Bryan Littlefair, that the Chinese manufacturer
thus refused to completely disable the service at first:
Vodafone said Huawei then refused
to fully remove the backdoor, citing a manufacturing requirement. Huawei said it needed the
Telnet service to configure device information and conduct tests including on Wi-Fi, and
offered to disable the service after taking those steps, according to the document.
El Reg understands that while Huawei indeed resisted removing the Telnet
functionality from the affected items – broadband network gateways in the core of
Vodafone Italy's 3G network – this was done to the satisfaction of all involved parties
by the end of 2011, with another network-level product de-Telnet-ised in 2012.
Broadband network gateways in 3G UMTS mobile networks are described in technical detail in
this Cisco (sorry)
PDF . The devices are also known as Broadband Remote Access Servers and sit at the edge of
a network operator's core.
Plenty of other things (cough, cough, Cisco) to panic about
Characterising this sort of Telnet service as a covert backdoor for government spies is a
bit like describing your catflap as an access portal that allows multiple species to pass
unhindered through a critical home security layer. In other words, massively over-egging the
pudding.
Many Reg readers won't need it explaining, but Telnet is a routinely used method of
connecting to remote devices for management purposes. When deployed with appropriate security
and authentication controls in place, it can be very useful. In Huawei's case, the Telnet
service wasn't facing the public internet, and was used to set up and test devices.
Look, it's not great that this was hardcoded into the equipment and undocumented – it
was, after all, declared a security risk – and had to be removed after some pressure.
However, it's not quite the hidden deliberate espionage backdoor for Beijing that some
fear.
Twitter-enabled infoseccer Kevin Beaumont also shared his thoughts on the story,
highlighting the number of vulns in equipment from Huawei competitor Cisco, a US firm:
For example, a pretty bad remote access hole was discovered in some Cisco
gear , which the mainstream press didn't seem too fussed about. Ditto hardcoded root
logins in Cisco video surveillance boxes. Lots of things unfortunately ship with insecure
remote access that ought to be removed; it's not evidence of a secret backdoor for state
spies.
Given Bloomberg's previous history of trying to break tech news, when it claimed that tiny
spy chips were being secretly planted on
Supermicro server motherboards – something that left the rest of the tech world
scratching its collective head once the initial dust had settled – it may be best to take
this latest revelation with a pinch of salt. Telnet wasn't even mentioned in
the latest report from the UK's Huawei Cyber Security Evaluation Centre, which savaged
Huawei's pisspoor software development practices.
While there is ample evidence in the public domain that Huawei is doing badly on the
basics of secure software development, so far there has been little that tends to show it
deliberately implements hidden espionage backdoors. Rhetoric from the US alleging Huawei is a
threat to national security seems to be having the opposite effect around the world.
With Bloomberg, an American company, characterising Vodafone's use of Huawei equipment as
"defiance" showing "that countries across Europe are willing to risk rankling the US in the
name of 5G preparedness," it appears that the US-Euro-China divide on 5G technology suppliers
isn't closing up any time soon. ®
Bootnote
This isn't shaping up to be a good week for Bloomberg. Only yesterday High Court judge Mr
Justice Nicklin
ordered the company to pay up £25k for the way it reported a live and ongoing
criminal investigation.
(20 of which on Debian, before that was Slackware)
I am new to systemd, maybe 3 or 4 months now tops on Ubuntu, and a tiny bit on Debian before
that.
I was confident I was going to hate systemd before I used it just based on the comments I
had read over the years, I postponed using it as long as I could. Took just a few minutes of
using it to confirm my thoughts. Now to be clear, if I didn't have to mess with the systemd to
do stuff then I really wouldn't care since I don't interact with it (which is the case on my
laptop at least though laptop doesn't have systemd anyway). I manage about 1,000 systems
running Ubuntu for work, so I have to mess with systemd, and init etc there.
If systemd would just do ONE thing I think it would remove all of the pain that it has
inflicted on me over the past several months and I could learn to accept it.
That one thing is, if there is an init script, RUN IT. Not run it like systemd does now. But
turn off ALL intelligence systemd has when it finds that script and run it. Don't put it on any
special timers, don't try to detect if it is running already, or stopped already or whatever,
fire the script up in blocking mode and wait till it exits.
My first experience with systemd was on one of my home servers, I re-installed Debian on it
last year, rebuilt the hardware etc and with it came systemd. I believe there is a way to turn
systemd off but I haven't tried that yet. The first experience was with bind. I have a slightly
custom init script (from previous debian) that I have been using for many years. I copied it to
the new system and tried to start bind. Nothing. I looked in the logs and it seems that it was
trying to interface with rndc(internal bind thing) for some reason, and because rndc was not
working(I never used it so I never bothered to configure it) systemd wouldn't launch bind. So I
fixed rndc and systemd would now launch bind, only to stop it within 1 second of launching. My
first workaround was just to launch bind by hand at the CLI (no init script), left it running
for a few months. Had a discussion with a co-worker who likes systemd and he explained that
making a custom unit file and using the type=forking option may fix it.. That did fix the
issue.
Next issue came up when dealing with MySQL clusters. I had to initialize the cluster with
the "service mysql bootstrap-pxc" command (using the start command on the first cluster member
is a bad thing). Run that with systemd, and systemd runs it fine. But go to STOP the service,
and systemd thinks the service is not running so doesn't even TRY to stop the service(the
service is running). My workaround for my automation for mysql clusters at this point is to
just use mysqladmin to shut the mysql instances down. Maybe newer mysql versions have better
systemd support though a co-worker who is our DBA and has used mysql for many years says even
the new Maria DB builds don't work well with systemd. I am working with Mysql 5.6 which is of
course much much older.
Next issue came up with running init scripts that have the same words in them, in the case
of most recently I upgraded systems to systemd that run OSSEC. OSSEC has two init scripts for
us on the server side (ossec and ossec-auth). Systemd refuses to run ossec-auth because it
thinks there is a conflict with the ossec service. I had the same problem with multiple varnish
instances running on the same system (varnish instances were named varnish-XXX and
varnish-YYY). In the varnish case using custom unit files I got systemd to the point where it
would start the service but it still refuses to "enable" the service because of the name
conflict (I even changed the name but then systemd was looking at the name of the binary being
called in the unit file and said there is a conflict there).
fucking a. Systemd shut up, just run the damn script. It's not hard.
Later a co-worker explained the "systemd way" for handling something like multiple varnish
instances on the system but I'm not doing that, in the meantime I just let chef start the
services when it runs after the system boots(which means they start maybe 1 or 2 mins after
bootup).
Another thing bit us with systemd recently as well again going back to bind. Someone on the
team upgraded our DNS systems to systemd and the startup parameters for bind were not preserved
because systemd ignores the /etc/default/bind file. As a result we had tons of DNS failures
when bind was trying to reach out to IPv6 name servers(ugh), when there is no IPv6 connectivity
in the network (the solution is to start bind with a -4 option).
I believe I have also caught systemd trying to mess with file systems(iscsi mount points). I
have lots of automation around moving data volumes on the SAN between servers and attaching
them via software iSCSI directly to the VMs themselves(before vsphere 4.0 I attached them via
fibre channel to the hypervisor but a feature in 4.0 broke that for me). I noticed on at least
one occasion when I removed the file systems from a system that SOMETHING (I assume systemd)
mounted them again, and it was very confusing to see file systems mounted again for block
devices that DID NOT EXIST on the server at the time. I worked around THAT one I believe with
the "noauto" option in fstab again. I had to put a lot of extra logic in my automation scripts
to work around systemd stuff.
I'm sure I've only scratched the surface of systemd pain. I'm sure it provides good value to
some people, I hear it's good with containers (I have been running LXC containers for years
now, I see nothing with systemd that changes that experience so far).
But if systemd would just do this one thing and go into dumb mode with init scripts I would
be quite happy.
"Shadow files" approach of Solaris 10, where additional functions of init are controlled by XML script that exist in a
separate directory with the same names as init scripts can be improved but architecturally it is much cleaner then systemd
approach.
Notable quotes:
"... Solaris has a similar parallellised startup system, with some similar problems, but it didn't need pid 1. ..."
"... Agreed, Solaris svcadm and svcs etc are an example of how it should be done. A layered approach maintaining what was already there, while adding functionality for management purposes. Keeps all the old text based log files and uses xml scripts (human readable and editable) for higher level functions. ..."
"... AFAICT everyone followed RedHat because they also dominate Gnome, and chose to make Gnome depend on systemd. Thus if one had any aspirations for your distro supporting Gnome in any way, you have to have systemd underneath it all. ..."
Re: Poettering still doesn't get it... Pid 1 is for people wearing big boy pants.
SystemD is corporate money (Redhat support dollars) triumphing over the long hairs sadly.
Enough money can buy a shitload of code and you can overwhelm the hippies with hairball
dependencies (the key moment was udev being dependent on systemd) and soon get as much FOSS as
possible dependent on the Linux kernel.
This has always been the end game as Red Hat makes its
bones on Linux specifically not on FOSS in general (that say runs on Solaris or HP-UX).
The
tighter they can glue the FOSS ecosystem and the Linux kernel together ala Windows lite style
the better for their bottom line. Poettering is just being a good employee asshat
extraordinaire he is.
Re: Ahhh SystemD
I honestly would love someone to lay out the problems it solves.
Solaris has a similar parallellised startup system, with some similar problems, but it didn't need pid 1.
Re: Ahhh SystemD
Agreed, Solaris svcadm and svcs etc are an example of how it should be done. A layered
approach maintaining what was already there, while adding functionality for management
purposes. Keeps all the old text based log files and uses xml scripts (human readable and
editable) for higher level functions.
Afaics, systemd is a power grab by Red Hat and an ego
trip for it's primary developer.
Dumped bloatware Linux in favour of FreeBSD and others after
Suse 11.4, though that was bad enough with Gnome 3...
starbase7, Thursday 10th May 2018 04:36 GMT
SMF?
As an older timer (on my way but not there yet), I never cared for the init.d startup and I dislike the systemd monolithic
architecture.
What I do like is Solaris SMF and wish Linux would have adopted a method such as or similar to that. I still think SMF
was/is a great comprise to the init.d method or systemd manor.
I used SMF professionally, but now I have moved on with Linux professionally as Solaris is, well, dead. I only get to
enjoy SMF on my home systems, and savor it. I'm trying to like Linux over all these years, but this systemd thing is a real
big road block for me to get enthusiastic.
I have a hard time understanding why all the other Linux distros joined hands with Redhat and implemented that thing,
systemd. Sigh.
Anonymous Coward, Thursday 10th May 2018 04:53 GMT
Re: SMF?
You're not alone in liking SMF and Solaris.
AFAICT everyone followed RedHat because they also dominate Gnome, and chose to make Gnome depend on systemd. Thus if
one had any aspirations for your distro supporting Gnome in any way, you have to have systemd underneath it all.
RedHat seem to call the shots these days as to what a Linux distro has. I personally have mixed opinions on this; I think the
vast anarchy of Linux is a bad thing for Linux adoption ("this is the year of the Linux desktop" don't make me laugh), and
Linux would benefit from a significant culling of the vast number of distros out there. However if that did happen and all
that was left was something controlled by RedHat, that would be a bad situation.
Steve Davies, Thursday 10th May 2018 07:30 GMT 3
Re: SMF?
Remember who 'owns' SMF... namely Oracle. They may well have made it impossible for anyone to adopt. That stance is not
unknown now is it...?
As for systemd, I have bit my teeth and learned to tolerate it. I'll never be as comfortable with it as I was with the old
init system but I did start running into issues especially with shutdown syncing with it on some complex systems.
Still not sure if systemd is the right way forward even after four years.
Daggerchild, Thursday 10th May 2018 14:30 GMT
Re: SMF?
SMF should be good, and yet they released it before they'd documented it. Strange priorities...
And XML is *not* a config file format you should let humans at. Finding out the correct order to put the XML elements in
to avoid unexplained "parse error", was *not* a fun game.
And someone correct me, but it looks like there are SMF properties of a running service that can only be modified/added by
editing the file, reloading *and* restarting the service. A metadata and state/dependency tracking system shouldn't require
you to shut down the priority service it's meant to be ensuring... Again, strange priorities...
12 1 Reply
Friday 11th May 2018 07:55 GMTonefangSilver badge
Reply Icon
FAIL
Re: SMF?
"XML is *not* a config file format you should let humans at"
XML is a format you shouldn't let computers at, it was designed to be human readable and writable. It fails totally.
5 1 Reply
Friday 6th July 2018 12:27 GMTHans 1Silver badge
Reply Icon
Re: SMF?
Finding out the correct order to put the XML elements in to avoid unexplained "parse error", was *not* a fun game.
Hm, you do know the grammar is in a dtd ? Yes, XML takes time to learn, but very powerful once mastered.
0 1 Reply
Thursday 10th May 2018 13:24 GMTCrazyOldCatManSilver badge
Reply Icon
Re: SMF?
I have a hard time understanding why all the other Linux distros joined hands with Redhat and implemented that thing, systemd
Several reasons:
A lot of other distros use Redhat (or Fedora) as their base and then customise it.
A lot of other distros include things dependant on systemd (Gnome being the one with biggest dependencies - you can just
about to get it to run without systemd but it's a pain and every update will break your fixes).
That's a very primitive thinking. If RHEL is royally screwed, like is the case with RHEL7,
that affects Kubernetes -- it does not exists outside the OS
Might just be a Debian thing as I haven't looked into it, but I have enough suspicion towards
systemd that I find it worth mentioning. Until fairly recently (in terms of Debian releases),
the default configuration was to murder a user's processes when they log out. This includes
things such as screen and tmux, and I seem to recall it also murdering disowned and NOHUPed
processes as well.
A dilemma for a Really Enterprise Dependant Huge Applications Technology company - The
technology they provide is open, so almost anyone could supply and support it. To continue
growing, and maintain a healthy profit they could consider locking their existing customer
base in; but they need to stop other suppliers moving in, who might offer a better and
cheaper alternative, so they would like more control of the whole ecosystem. The scene: An
imaginary high-level meeting somewhere - The agenda: Let's turn Linux into Windows - That
makes a lot of money:-
Q: Windows is a monopoly, so how are we going to monopolise something that is free and
open, because we will have to supply source code for anything that will do that? A: We make
it convoluted and obtuse, then we will be the only people with the resources to offer it
commercially; and to make certain, we keep changing it with dependencies to "our" stuff
everywhere - Like Microsoft did with the Registry.
Q: How are we going to sell that idea? A: Well, we could create a problem and solve it -
The script kiddies who like this stuff, keep fiddling with things and rebooting all of the
time. They don't appear to understand the existing systems - Sell the idea they do not need
to know why *NIX actually works.
Q: *NIX is designed to be dependable, and go for long periods without rebooting, How do we
get around that. A: That is not the point, the kids don't know that; we can sell them the
idea that a minute or two saved every time that they reboot is worth it, because they
reboot lots of times in every session - They are mostly running single user laptops, and not
big multi-user systems, so they might think that that is important - If there is
somebody who realises that this is trivial, we sell them the idea of creating and
destroying containers or stopping and starting VMs.
Q: OK, you have sold the concept, how are we going to make it happen? A: Well, you know
that we contribute quite a lot to "open" stuff. Let's employ someone with a reputation for
producing fragile, barely functioning stuff for desktop systems, and tell them that we need a
"fast and agile" approach to create "more advanced" desktop style systems - They would lead a
team that will spread this everywhere. I think I know someone who can do it - We can have
almost all of the enterprise market.
Q: What about the other large players, surely they can foil our plan? A: No, they won't
want to, they are all big companies and can see the benefit of keeping newer, efficient
competitors out of the market. Some of them sell equipment and system-wide consulting, so
they might just use our stuff with a suitable discount/mark-up structure anyway.
This is scarily possible and undeserving of the troll icon.
Harkens easily to non-critical software developers intentionally putting undocumented,
buggy code into production systems, forcing the company to keep the guy on payroll to keep
the wreck chugging along.
But replacing it with systemd is akin to "fixing" the restrictions of travel by bicycle
(limited speed and range, ending up sweaty at your destination, dangerous in heavy traffic)
by replacing it with an Apache helicopter gunship that has a whole new set of restrictions
(need for expensive fuel, noisy and pisses off the neighbors, need a crew of trained
mechanics to keep it running, local army base might see you as a threat and shoot missiles at
you)
Too bad we didn't get the equivalent of a bicycle with an electric motor, or perhaps a
moped.
Those who do not understand Unix are condemned to reinvent it, poorly.
"It sounds super basic, but actually it is much more complex than people think,"
Poettering said. "Because Systemd knows which service a process belongs to, it can shut down
that process."
Init has had the groundwork for most of the missing features since the early 1980s. For
example the "id" field in /etc/inittab was intended for a "makefile" like syntax to fix most
of these problems but was dropped in the early days of System V because it wasn't needed.
That is the main problem. With different processes you get different results. For all its
faults, SysV init and RC scripts was understandable to some extent. My (cursory)
understanding of systemd is that it appears more complicated to UNDERSTAND than the init
stuff.
The init scripts are nice text scripts which are executed by a nice well documented shell
(bash mostly). Systemd has all sorts of blobs that somehow do things and are totally
confusing to me. It suffers from "anti- kiss "
Perhaps a nice book could be written WITH example to show what is going on.
Now let's see does audio come before or after networking (or at the same time)?
If they removed logging from the systemd core and went back to good ol' plaintext
syslog[-ng], I'd have very little bad to say about Lennart's monolithic pet project. Indeed,
I much prefer writing unit files than buggering about getting rcorder right in the old SysV
init.
Now, if someone wanted to nuke pulseaudio from orbit and do multiplexing in the kernel a
la FreeBSD, I'll chip in with a contribution to the warhead fund. Needing a userland daemon
just to pipe audio to a device is most certainly a solution in search of a problem.
From now on, I will call Systemd-based Linux distros "SNU Linux". Because Systemd's Not
Unix-like.
It's not clever, but it's the future. From now on, all major distributions will be called
SNU Linux. You can still freely choose to use a non-SNU linux distro, but if you want to use
any of the "normal" ones, you will have to call it "SNU" whether you like it or not. It's for
your own good. You'll thank me later.
However, I don't recall any major agreement that init needed fixing. Between BSD and SysV
inits, probably 99.999% of all use cases were covered. In the 1 in 100,000 use case, a little
bit of C (stand alone code, or patching init itself) covered the special case. In the case of
Slackware's SysV/BSD amalgam, I suspect it was more like one in ten million.
So in all reality, systemd is an answer to a problem that nobody had. There was no reason
for it in the first place. There still isn't a reason for it ... especially not in the
999,999 places out of 1,000,000 where it is being used. Throw in the fact that it's sticking
its tentacles[0] into places where nobody in their right mind would expect an init as a
dependency (disk partitioning software? WTF??), can you understand why us "old guard" might
question the sanity of people singing it's praises?
[0] My spall chucker insists that the word should be "testicles". Tempting ...
It's a pretty polarizing debate: either you see Systemd as a modern, clean, and coherent
management toolkit
Very, very few Linux users see it that way.
or an unnecessary burden running roughshod over the engineering maxim: if it ain't
broke, don't fix it.
Seen as such by 90% of Linux users because it demonstrably is.
Truthfully Systemd is flawed at a deeply fundamental level. While there are a very few
things it can do that init couldn't - the killing off processes owned by a service mentioned
as an example in this article is handled just fine by a well written init script - the
tradeoffs just aren't worth it. For example: fscking BINARY LOGS. Even if all of Systemd's
numerous other problems were fixed that one would keep it forever on my list of things to
avoid if at all possible, and the fact that the Systemd team thought it a good idea to make
the logs binary shows some very troubling flaws in their thinking at a very fundamental
level.
WRT grep and logs I'm the same way which is why I hate json so much. My saying has been
along the lines of "if it's not friends with grep/sed then it's not friends with me". I have
whipped some some whacky sed stuff to generate a tiny bit of json to read into chef for
provisioning systems though.
XML is similar though I like XML a lot more at least the closing tags are a lot easier to
follow then trying to count the nested braces in json.
I haven't had the displeasure much of dealing with the systemd binary logs yet myself.
> I haven't had the displeasure much of dealing with the systemd binary logs yet
myself.
"I have no clue what I'm talking about or what's a robust solution but dear god, that
won't stop me!" – why is it that all the people complaining about journald sound like
that?
systemd works just fine with regular syslog-ng, without journald (that's the thing that
has binary logs) in sight
"systemd works just fine with regular syslog-ng, without journald (that's the thing that
has binary logs) in sight"
Journald can't be switched off, only redirected to /dev/null. It still generates binary
log data (which has caused me at least one system hang due to the absurd amount of data it
was generating on a system that was otherwise functioning correctly) and consumes system
resources. That isn't my idea of "works just fine".
""I have no clue what I'm talking about or what's a robust solution but dear god, that
won't stop me!" – why is it that all the people complaining about journald sound like
that?"
Nice straw man. Most of the complaints I've seen have been from experienced people who do
know what they're talking about.
"I have no clue what I'm talking about or what's a robust solution but dear god, that
won't stop me!" – why is it that all the people complaining about journald sound like
that?
I have had the displeasure of dealing with journald and it is every bit as bad as everyone
says and worse.
systemd works just fine with regular syslog-ng, without journald (that's the thing that
has binary logs) in sight
Yeah, I've tried that. It caused problems. It wasn't a viable option.
Parking U$5bn in redhad for a few months will fix this...
So it's now been 4 years since they first tried to force that shoddy desk-top init system
into our servers? And yet they still feel compelled to tell everyone, look it really isn't
that terrible. That should tell you something. Unless you are tone death like Redhat.
Surprised people didn't start walking out when Poettering outlined his plans for the next
round of systemD power grabs...
Anyway the only way this farce will end is with shareholder activism. Some hedge fund to
buy 10-15 percent of redhat (about the amount you need to make life difficult for management)
and force them to sack that "stable genius" Poettering. So market cap is 30bn today. Anyone
with 5bn spare to park for a few months wanna step forward and do some good?
Early on I warned that he was trying to solve a very large problem space. He insisted he
could do it with his 10 or so "correct" ways of doing things, which quickly became 20, then
30, then 50, then 90, etc.. etc. I asked for some of the features we had in init, he said "no
valid use case". Then, much later (years?), he implements it (no use case provided btw).
Interesting fellow. Very bitter. And not a good listener. But you don't need to listen
when you're always right.
Now, you see, you just summed up the whole problem. Like systemd's author, you think you
know better than the admin how to run his machine, without knowing, or caring to ask, what
he's trying to achieve. Nobody ever runs a computer, to achieve running systemd do
they.
I don't claim I know better, but I do know that I never saw a non-distribution provided
init script that handled correctly the basic of corner cases – service already running,
run file left-over but process dead, service restart – let alone the more obscure ones,
like application double forking when it shouldn't (even when that was the failure mode of the
application the script was provided with). So maybe, just maybe, you haven't experienced
everything there is to experience, so your opinion is subjective?
Yes, the sides of the discussion should talk more, but this applies to both sides. "La,
la, la, sysv is working fine on my machine, thankyouverymuch" is not what you can call
"participating in discussion". So is quoting well known and long discussed (and disproven)
points. (and then downvoting people into oblivion for daring to point this things out).
now in the real world, people that have to deal with init systems on daily basis, as
distribution maintainers, by large, have chosen to switch their distributions to systemd, so
the whole situation I can sum up one way:
I do know that I never saw a non-distribution provided init script that handled
correctly the basic of corner cases – service already running
This only shows that you don't have much real life experience managing lots of hosts.
like application double forking when it shouldn't
If this is a problem in the init script, this should be fixed in the init script. If this
is a problem in the application itself, it should be fixed in the application,
not worked around by the init mechanism. If you're suggesting the latter, you
should not be touching any production box.
"La, la, la, sysv is working fine on my machine, thankyouverymuch" is not what you
can call "participating in discussion".
Shoving down systemd down people's throat as a solution to a non-existing problem, is not
a discussion either; it is the very definition of 'my way or the highway' thinking.
now in the real world, people that have to deal with init systems on daily
basis
Indeed and having a bunch of sub-par developers, focused on the 'year of the Linux
desktop' to decide what the best way is for admins to manage their enterprise environment is
not helping.
"the dogs may bark, but the caravan moves on"
Indeed. It's your way or the highway; I thought you were just complaining about the people
complaining about systemd not wanting to have a discussion, while all the while it's systemd
proponents ignoring and dismissing very valid complaints.
"I never saw ... run file left-over but process dead, service restart ..."
Seriously? I wrote one last week! You use an OS atomic lock on the pidfile and exec the
service if the lock succeeded. The lock dies with the process. It's a very small
shellscript.
I shot a systemd controlled service. Systemd put it into error state and wouldn't restart
it unless I used the right runes. That is functionally identical to the thing you just
complained about.
"application double forking when it shouldn't"
I'm going to have to guess what that means, and then point you at DJB's daemontools. You
leave a FD open in the child. They can fork all they like. You'll still track when the last
dies as the FD will cause an event on final close.
"So maybe, just maybe, you haven't experienced everything there is to
experience"
You realise that's the conspiracy theorist argument "You don't know everything, therefore
I am right". Doubt is never proof of anything.
"La, la, la, sysv is working fine" is not what you can call "participating in
discussion".
Well, no.. it's called evidence. Evidence that things are already working fine, thanks.
Evidence that the need for discussion has not been displayed. Would you like a discussion
about the Earth being flat? Why not? Are you refusing to engage in a constructive discussion?
How obstructive!
"now in the real world..."
In the *real* world people run Windows and Android, so you may want to rethink the "we
outnumber you, so we must be right" angle. You're claiming an awful lot of highground you don't seem to actually know your way
around, while trying to wield arguments you don't want to face yourself...
"(and then downvoting people into oblivion for daring to point this things
out)"
It's not some denialist conspiracy to suppress your "daring" Truth - you genuinely deserve
those downvotes.
I have no idea how or why systemd ended up on servers. Laptops I can see the appeal for "this
is the year of the linux desktop" - for when you want your rebooted machine to just be there
as fast as possible (or fail mysteriously as fast as possible). Servers, on the other hand,
which take in the order of 10+ minutes to get through POST, initialising whatever LOM, disk
controllers, and whatever exotica hardware you may also have connected, I don't see a benefit
in Linux starting (or failing to start) a wee bit more quickly. You're only going to reboot
those beasts when absolutely necessary. And it should boot the same as it booted last time.
PID1 should be as simple as possible.
I only use CentOS these days for FreeIPA but now I'm questioning my life decisions even
here. That Debian adopted systemd too is a real shame. It's actually put me off the whole
game. Time spent learning systemd is time that could have been spent doing something useful
that won't end up randomly breaking with a "will not fix" response.
Systemd should be taken out back and put out of our misery.
"... Another thing bit us with systemd recently as well again going back to bind. Someone on the team upgraded our DNS systems to systemd and the startup parameters for bind were not preserved because systemd ignores the /etc/default/bind file. As a result we had tons of DNS failures when bind was trying to reach out to IPv6 name servers(ugh), when there is no IPv6 connectivity in the network (the solution is to start bind with a -4 option). ..."
"... I'm sure I've only scratched the surface of systemd pain. I'm sure it provides good value to some people, I hear it's good with containers (I have been running LXC containers for years now, I see nothing with systemd that changes that experience so far). ..."
"... If systemd is a solution to any set of problems, I'd love to have those problems back! ..."
(20 of which on Debian, before that was Slackware)
I am new to systemd, maybe 3 or 4 months now tops on Ubuntu, and a tiny bit on Debian
before that.
I was confident I was going to hate systemd before I used it just based on the comments I
had read over the years, I postponed using it as long as I could. Took just a few minutes of
using it to confirm my thoughts. Now to be clear, if I didn't have to mess with the systemd
to do stuff then I really wouldn't care since I don't interact with it (which is the case on
my laptop at least though laptop doesn't have systemd anyway). I manage about 1,000 systems
running Ubuntu for work, so I have to mess with systemd, and init etc there. If systemd would
just do ONE thing I think it would remove all of the pain that it has inflicted on me over
the past several months and I could learn to accept it.
That one thing is, if there is an init script, RUN IT. Not run it like systemd does now.
But turn off ALL intelligence systemd has when it finds that script and run it. Don't put it
on any special timers, don't try to detect if it is running already, or stopped already or
whatever, fire the script up in blocking mode and wait till it exits.
My first experience with systemd was on one of my home servers, I re-installed Debian on
it last year, rebuilt the hardware etc and with it came systemd. I believe there is a way to
turn systemd off but I haven't tried that yet. The first experience was with bind. I have a
slightly custom init script (from previous debian) that I have been using for many years. I
copied it to the new system and tried to start bind. Nothing. I looked in the logs and it
seems that it was trying to interface with rndc(internal bind thing) for some reason, and
because rndc was not working(I never used it so I never bothered to configure it) systemd
wouldn't launch bind. So I fixed rndc and systemd would now launch bind, only to stop it
within 1 second of launching. My first workaround was just to launch bind by hand at the CLI
(no init script), left it running for a few months. Had a discussion with a co-worker who
likes systemd and he explained that making a custom unit file and using the type=forking
option may fix it.. That did fix the issue.
Next issue came up when dealing with MySQL clusters. I had to initialize the cluster with
the "service mysql bootstrap-pxc" command (using the start command on the first cluster
member is a bad thing). Run that with systemd, and systemd runs it fine. But go to STOP the
service, and systemd thinks the service is not running so doesn't even TRY to stop the
service(the service is running). My workaround for my automation for mysql clusters at this
point is to just use mysqladmin to shut the mysql instances down. Maybe newer mysql versions
have better systemd support though a co-worker who is our DBA and has used mysql for many
years says even the new Maria DB builds don't work well with systemd. I am working with Mysql
5.6 which is of course much much older.
Next issue came up with running init scripts that have the same words in them, in the case
of most recently I upgraded systems to systemd that run OSSEC. OSSEC has two init scripts for
us on the server side (ossec and ossec-auth). Systemd refuses to run ossec-auth because it
thinks there is a conflict with the ossec service. I had the same problem with multiple
varnish instances running on the same system (varnish instances were named varnish-XXX and
varnish-YYY). In the varnish case using custom unit files I got systemd to the point where it
would start the service but it still refuses to "enable" the service because of the name
conflict (I even changed the name but then systemd was looking at the name of the binary
being called in the unit file and said there is a conflict there).
fucking a. Systemd shut up, just run the damn script. It's not hard.
Later a co-worker explained the "systemd way" for handling something like multiple varnish
instances on the system but I'm not doing that, in the meantime I just let chef start the
services when it runs after the system boots(which means they start maybe 1 or 2 mins after
bootup).
Another thing bit us with systemd recently as well again going back to bind. Someone on
the team upgraded our DNS systems to systemd and the startup parameters for bind were not
preserved because systemd ignores the /etc/default/bind file. As a result we had tons of DNS
failures when bind was trying to reach out to IPv6 name servers(ugh), when there is no IPv6
connectivity in the network (the solution is to start bind with a -4 option).
I believe I have also caught systemd trying to mess with file systems(iscsi mount points).
I have lots of automation around moving data volumes on the SAN between servers and attaching
them via software iSCSI directly to the VMs themselves(before vsphere 4.0 I attached them via
fibre channel to the hypervisor but a feature in 4.0 broke that for me). I noticed on at
least one occasion when I removed the file systems from a system that SOMETHING (I assume
systemd) mounted them again, and it was very confusing to see file systems mounted again for
block devices that DID NOT EXIST on the server at the time. I worked around THAT one I
believe with the "noauto" option in fstab again. I had to put a lot of extra logic in my
automation scripts to work around systemd stuff.
I'm sure I've only scratched the surface of systemd pain. I'm sure it provides good value
to some people, I hear it's good with containers (I have been running LXC containers for
years now, I see nothing with systemd that changes that experience so far).
But if systemd would just do this one thing and go into dumb mode with init scripts I
would be quite happy.
Now more seriously: it really strikes me that complaints about systemd come from people
managing non-trivial setups like the one you describe. While it might have been a PITA to get
this done with the old init mechanism, you could make it work reliably.
If systemd is a solution to any set of problems, I'd love to have those problems
back!
I knew systemd was coming thanks to playing with Fedora. The quicker start-up times were
welcomed. That was about it! I have had to kickstart many of my CentOS 7 builds to disable
IPv6 (NFS complains bitterly), kill the incredibly annoying 'biosdevname' that turns sensible
eth0/eth1 into some daftly named nonsense, replace Gnome 3 (shudder) with MATE, and fudge
start-up processes. In a previous job, I maintained 2 sets of CentOS 7 'infrastructure'
servers that provided DNS, DHCP, NTP, and LDAP to a large number of historical vlans. Despite
enabling the systemd-network wait online option, which is supposed to start all networks
*before* listening services, systemd would run off flicking all the "on" switches having only
set-up a couple of vlans. Result: NTP would only be listening on one or two vlan interfaces.
The only way I found to get around that was to enable rc.local and call systemd to restart
the NTP daemon after 20 seconds. I never had the time to raise a bug with Red Hat, and I
assume the issue still persists as no-one designed systemd to handle 15-odd vlans!?
I can't remember if it's HPE or Dell (or both) where you can use set the kernel option
biosdevname=0 during build/boot to turn all that renaming stuff off and revert to ethX.
However on (RHEL?)/CentOS 7 I've found that if you build a server like that, and then try
to renam/swap the interfaces it will refuse point blank to allow you to swap the interfaces
round so that something else can be eth0. In the end we just gave up and renamed everything
lanX instead which it was quite happy with.
"I can't remember if it's HPE or Dell (or both) where you can use set the kernel option
biosdevname=0 during build/boot to turn all that renaming stuff off and revert to ethX."
I'm using this on my Debian 9 systems. IIRC the option to do so will be removed in Debian
10.
I'm not really bothered about whether init was perfect from the beginning - for as long as
I've been using Linux (20 years) until now, I have never known the init system to be the
cause of major issues. Since in my experience it's not been seriously broken for two decades,
why throw it out now for something that is orders of magnitude more complex and ridiculously
overreaching?
Like many here I bet, I am barely tolerating SystemD on some servers because RHEL/CentOS 7
is the dominant business distro with a decent support life - but this is also the first time
I can recall ever having serious unpredictable issues with startup and shutdown on Linux
servers.
stiine, Thursday 10th May 2018 15:38 GMT
sysV init
I've been using Linux ( RedHat, CentOS, Ubuntu), BSD (Solaris, SunOS, freeBSD) and Unix ( aix, sysv all of the way back to
AT&T 3B2 servers) in farms of up to 400 servers since 1988 and I never, ever had issues with eth1 becoming eth0 after a
reboot. I also never needed to run ifconfig before configuring an interface just to determine what the inteface was going to
be named on a server at this time. Then they hired Poettering... now, if you replace a failed nic, 9 times out of 10, the
interface is going to have a randomly different name.
Well, I am compelled to agree with most everything you wrote except one niche area that
systemd does better: Remember putzing about with the amd? One line in fstab:
No worries, as has happened with every workaround to make systemD simply mount cifs or NFS
at boot, yours will fail as soon as the next change happens, yet it will remain on the 'net
to be tried over and over as have all the other "fixes" for Poettering's arrogant
breakages.
The last one I heard from him on this was "don't mount shares at boot, it's not reliable
WONTFIX".
Which is why we're all bitching.
Break my stuff.
Web shows workaround.
Break workaround without fixing the original issue, really.
Never ensure one place for current dox on what works now.
Repeat above endlessly.
Fine if all you do is spin up endless identical instances in some cloud (EG a big chunk of
RH customers - but not Debian for example). If like me you have 20+ machines customized to
purpose...for which one workaround works on some but not others, and every new release of
systemD seems to break something new that has to be tracked down and fixed, it's not
acceptable - it's actually making proprietary solutions look more cost effective and less
blood pressure raising.
The old init scripts worked once you got them right, and stayed working. A new distro
release didn't break them, nor did a systemD update (because there wasn't one). This feels
more like sabotage.
Quite understandable that people who don't know anything else would accept systemd. For
everyone else it has nothing to do with old school but everything to do with unpredictability
of systemd.
Today I've kickstarted RHEL7 on a rack of 40 identical servers using same script. On about
25 out of 40 postinstall script added to rc.local failed to run with some obscure error about
script being terminated because something unintelligible did not like it. It never ever
happened on RHEL6, it happens all the time on RHEL7. And that's exactly the reason I
absolutely hate it both RHEL7 and systemd.
Poettering still doesn't get it... Pid 1 is for people wearing big boy pants.
"And perhaps, in the process, you may warm up a bit more to the tool"
Like from LNG to Dry Ice? and by tool does he mean Poettering or systemd?
I love the fact that they aren't trying to address the huge and legitimate issues with
Systemd, while still plowing ahead adding more things we don't want Systemd to touch into
it's ever expanding sprawl.
The root of the issue with Systemd is the problems it causes, not the lack of
"enhancements" initd offered. Replacing Init didn't require the breaking changes and
incompatibility induced by Poettering's misguided handiwork. A clean init replacement would
have made Big Linux more compatible with both it's roots and the other parts of the broader
Linux/BSD/Unix world. As a result of his belligerent incompetence, other peoples projects
have had to be re-engineered, resulting in incompatibility, extra porting work, and security
problems. In short were stuck cleaning up his mess, and the consequences of his security
blunders
A worthy Init replacement should have moved to compiled code and given us asynchronous
startup, threading, etc, without senselessly re-writing basic command syntax or
compatibility. Considering the importance of PID 1, it should have used a formal development
process like the BSD world.
Fedora needs to stop enabling his prima donna antics and stop letting him touch things
until he admits his mistakes and attempts to fix them. The flame wars not going away till he
does.
Re: Poettering still doesn't get it... Pid 1 is for people wearing big boy pants.
SystemD is corporate money (Redhat support dollars) triumphing over the long hairs sadly.
Enough money can buy a shitload of code and you can overwhelm the hippies with hairball
dependencies (the key moment was udev being dependent on systemd) and soon get as much FOSS
as possible dependent on the Linux kernel. This has always been the end game as Red Hat makes
its bones on Linux specifically not on FOSS in general (that say runs on Solaris or HP-UX).
The tighter they can glue the FOSS ecosystem and the Linux kernel together ala Windows lite
style the better for their bottom line. Poettering is just being a good employee asshat
extraordinaire he is.
Raise your hand if you've been completely locked out of a server or laptop (as in, break out
the recovery media and settle down, it'll be a while) because systemd:
1.) Couldn't raise a network interface
2.) Farted and forgot the UUID for a disk, then refused to give a recovery shell
3.) Decided an unimportant service (e.g. CUPS or avahi) was too critical to start before
giving a login over SSH or locally, then that service stalls forever
4.) Decided that no, you will not be network booting your server today. No way to recover
and no debug information, just an interminable hang as it raises wrong network interfaces and
waits for DHCP addresses that will never come.
And lest the fun be restricted to startup, on shutdown systemd can quite happily hang
forever doing things like stopping nonessential services, *with no timeout and no way to
interrupt*. Then you have to Magic Sysreq the machine, except that sometimes secure servers
don't have that ability, at least not remotely. Cue data loss and general excitement.
And that's not even going into the fact that you need to *reboot the machine* to patch the
*network enabled* and highly privileged systemd, or that it seems to have the attack surface
of Jupiter.
Upstart was better than this. SysV was better than this. Mac is better than this. Windows
is better than this.
I honestly would love someone to lay out the problems it solves. Solaris has a similar
parallellised startup system, with some similar problems, but it didn't need pid 1.
Agreed, Solaris svcadm and svcs etc are an example of how it should be done. A layered
approach maintaining what was already there, while adding functionality for management
purposes. Keeps all the old text based log files and uses xml scripts (human readable and
editable) for higher level functions. Afaics, systemd is a power grab by red hat and an ego
trip for it's primary developer. Dumped bloatware Linux in favour of FreeBSD and others after
Suse 11.4, though that was bad enough with Gnome 3...
"... OpenStack's core value is to gather a pool of hypervisor-enabled computers and enable the delivery of virtual machines (VMs) on demand to users. ..."
Both OpenStack and Docker were conceived to make IT more agile. OpenStack has
strived to do this by turning hitherto static IT resources into elastic infrastructure, whereas
Docker has reached for this goal by harmonizing development, test, and production resources, as
Red Hat's Neil Levine suggests .
But while Docker adoption has soared, OpenStack is still largely stuck in neutral. OpenStack
is kept relevant by so many wanting to believe its promise, but never hitting its stride
due to a host of factors , including complexity.
And yet Docker could be just the thing to turn OpenStack's popularity into productivity.
Whether a Docker-plus-OpenStack pairing is right for your enterprise largely depends on the
kind of capacity your enterprise hopes to deliver. If simply Docker, OpenStack is probably
overkill.
An open source approach to delivering virtual machines
OpenStack is an operational model for delivering virtualized compute capacity.
Sure, some give it a more grandiose definition ("OpenStack
is a set of software tools for building and managing cloud computing platforms for public and
private clouds"), but if we ignore secondary services like Cinder, Heat, and Magnum, for
example, OpenStack's core value is to gather a pool of hypervisor-enabled computers and
enable the delivery of virtual machines (VMs) on demand to users.
That's it.
Not that this is a small thing. After all, without OpenStack, the hypervisor sits idle,
lonesome on a single computer, with no way to expose that capacity programmatically (or
otherwise) to users.
Before cloudy systems like OpenStack or Amazon's EC2, users would typically file a help
ticket with IT. An IT admin, in turn, would use a GUI or command line to create a VM, and then
share the credentials with the user.
Systems like OpenStack significantly streamline this process, enabling IT to
programmatically deliver capacity to users. That's a big deal.
Docker peanut butter, meet
OpenStack jelly
Docker, the darling of the containers world, is similar to the VM in the IaaS picture
painted above.
A Docker host is really the unit of compute capacity that users need, and not the container
itself. Docker addresses what you do with a host once you've got it, but it doesn't really help
you get the host in the first place.
A Docker machine provides a client-side tool that lets you request Docker hosts from an IaaS
provider (like EC2 or OpenStack or vSphere), but it's far from a complete solution. In part,
this stems from the fact that Docker doesn't have a tenancy model.
With a hypervisor, each VM is a tenant. But in Docker, the Docker host is a tenant. You
typically don't want multiple users sharing a Docker host because then they see each others'
containers. So typically an enterprise will layer a cloud system underneath Docker to add
tenancy. This yields a stack that looks like: hardware > hypervisor > Docker host >
container.
A common approach today would be to take OpenStack and use it as the enterprise platform to
deliver capacity on demand to users. In other words, users rely on OpenStack to request a
Docker host, and then they use Docker to run containers in their Docker host.
So far, so good.
If all you need is Docker...
Things get more complicated when we start parsing what capacity needs delivering.
When an enterprise wants to use Docker, they need to get Docker hosts from a data center.
OpenStack can do that, and it can do it alongside delivering all sorts of other capacity to the
various teams within the enterprise.
But if all an enterprise IT team needs is Docker containers delivered, then OpenStack -- or
a similar orchestration tool -- may be overkill, as VMware executive Jared Rosoff told me.
For this sort of use case, we really need a new platform. This platform could take the form
of a piece of software that an enterprise installs on all of its computers in the data center.
It would expose an interface to developers that lets them programmatically create Docker hosts
when they need them, and then use Docker to create containers in those hosts.
Google has a vision for something like this with its Google Container Engine . Amazon has something
similar in its EC2 Container Service
. These are both API's that developers can use to provision some Docker-compatible capacity
from their data center.
As for Docker, the company behind Docker, the technology, it seems to have punted on this
problem. focusing instead on what happens on the host itself.
While we probably don't need to build up a big OpenStack cloud simply to manage Docker
instances, it's worth asking what OpenStack should look like if what we wanted to deliver was
only Docker hosts, and not VMs.
Again, we see Google and Amazon tackling the problem, but when will OpenStack, or one of its
supporters, do the same? The obvious candidate would be VMware, given its longstanding
dominance of tooling around virtualization. But the company that solves this problem first, and
in a way that comforts traditional IT with familiar interfaces yet pulls them into a cloudy
future, will win, and win big.
"... if those employees become unhappy, they can effectively go anywhere they want. ..."
"... IBM's partner/reseller ecosystem is nowhere near what it was since it owned the PC and Server businesses that Lenovo now owns. And IBM's Softlayer/BlueMix cloud is largely tied to its legacy software business, which, again, is slowing. ..."
"... I came to IBM from their SoftLayer acquisition. Their ability to stomp all over the things SoftLayer was almost doing right were astounding. I stood and listened to Ginni say things like, "We purchased SoftLayer because we need to learn from you," and, "We want you to teach us how to do Cloud the right way, since we spent all these years doing things the wrong way," and, "If you find yourself in a meeting with one of our old teams, you guys are gonna be the ones in charge. You are the ones who know how this is supposed to work - our culture has failed at it." Promises which were nothing more than hollow words. ..."
"... Next, it's a little worrisome that the author, now over the whole IBM thing is recommending firing "older people," you know, the ones who helped the company retain its performance in years' past. The smartest article I've read about IBM worried about its cheap style of "acquiring" non-best-of-breed companies and firing oodles of its qualified R&D guys. THAT author was right. ..."
"... Four years in GTS ... joined via being outsourced to IBM by my previous employer. Left GTS after 4 years. ..."
"... The IBM way of life was throughout the Oughts and the Teens an utter and complete failure from the perspective of getting work done right and using people to their appropriate and full potential. ..."
"... As a GTS employee, professional technical training was deemed unnecessary, hence I had no access to any unless I paid for it myself and used my personal time ... the only training available was cheesy presentations or other web based garbage from the intranet, or casual / OJT style meetings with other staff who were NOT professional or expert trainers. ..."
"... As a GTS employee, I had NO access to the expert and professional tools that IBM fricking made and sold to the same damn customers I was supposed to be supporting. Did we have expert and professional workflow / document management / ITIL aligned incident and problem management tools? NO, we had fricking Lotus Notes and email. Instead of upgrading to the newest and best software solutions for data center / IT management & support, we degraded everything down the simplest and least complex single function tools that no "best practices" organization on Earth would ever consider using. ..."
"... And the people management paradigm ... employees ranked annually not against a static or shared goal or metric, but in relation to each other, and there was ALWAYS a "top 10 percent" and a "bottom ten percent" required by upper management ... a system that was sociopathic in it's nature because it encourages employees to NOT work together ... by screwing over one's coworkers, perhaps by not giving necessary information, timely support, assistance as needed or requested, one could potentially hurt their performance and make oneself look relatively better. That's a self-defeating system and it was encouraged by the way IBM ran things. ..."
IBM has not had a particularly great track record when it comes to integrating the cultures
of other companies into its own, and brain drain with a company like Red Hat is a real risk
because if those employees become unhappy, they can effectively go anywhere they want.
They have the skills to command very high salaries at any of the top companies in the
industry.
The other issue is that IBM hasn't figured out how to capture revenue from SMBs -- and that
has always been elusive for them. Unless a deal is worth at least $1 million, and realistically
$10 million, sales guys at IBM don't tend to get motivated.
The 5,000-seat and below market segment has traditionally been partner territory, and when
it comes to reseller partners for its cloud, IBM is way, way behind AWS, Microsoft, Google, or
even (gasp) Oracle, which is now offering serious margins to partners that land workloads on
the Oracle cloud.
IBM's partner/reseller ecosystem is nowhere near what it was since it owned the PC and
Server businesses that Lenovo now owns. And IBM's Softlayer/BlueMix cloud is largely tied to
its legacy software business, which, again, is slowing.
... ... ...
But I think that it is very unlikely the IBM Cloud, even when juiced on Red Hat steroids,
will become anything more ambitious than a boutique business for hybrid workloads when compared
with AWS or Azure. Realistically, it has to be the kind of cloud platform that interoperates
well with the others or nobody will want it.
1. IBM used to value long-term employees. Now they "value" short-term contractors -- but
they still pull them out of production for lots of training that, quite frankly, isn't
exactly needed for what they are doing. Personally, I think that IBM would do well to return
to valuing employees instead of looking at them as expendable commodities, but either way,
they need to get past the legacies of when they had long-term employees all watching a single
main frame.
2. As IBM moved to an army of contractors, they killed off the informal (but important!)
web of tribal knowledge. You know, a friend of a friend who new the answer to some issue, or
knew something about this customer? What has happened is that the transaction costs (as
economists call it) have escalated until IBM can scarcely order IBM hardware for its own
projects, or have SDM's work together.
geek49203_z Number 2 is a problem everywhere. As long-time employees (mostly baby-boomers)
retire, their replacements are usually straight out of college with various non-technical
degrees. They come in with little history and few older-employees to which they can turn for
"the tricks of the trade".
I came to IBM from their SoftLayer acquisition. Their ability to stomp all over the things
SoftLayer was almost doing right were astounding. I stood and listened to Ginni say things
like, "We purchased SoftLayer because we need to learn from you," and, "We want you to teach
us how to do Cloud the right way, since we spent all these years doing things the wrong way,"
and, "If you find yourself in a meeting with one of our old teams, you guys are gonna be the
ones in charge. You are the ones who know how this is supposed to work - our culture has
failed at it." Promises which were nothing more than hollow words.
1. IBM used to value long-term employees. Now they "value" short-term contractors -- but
they still pull them out of production for lots of training that, quite frankly, isn't
exactly needed for what they are doing. Personally, I think that IBM would do well to return
to valuing employees instead of looking at them as expendable commodities, but either way,
they need to get past the legacies of when they had long-term employees all watching a single
main frame.
2. As IBM moved to an army of contractors, they killed off the informal (but important!)
web of tribal knowledge. You know, a friend of a friend who new the answer to some issue, or
knew something about this customer? What has happened is that the transaction costs (as
economists call it) have escalated until IBM can scarcely order IBM hardware for its own
projects, or have SDM's work together.
geek49203_z Number 2 is a problem everywhere. As long-time employees (mostly baby-boomers)
retire, their replacements are usually straight out of college with various non-technical
degrees. They come in with little history and few older-employees to which they can turn for
"the tricks of the trade".
I came to IBM from their SoftLayer acquisition. Their ability to stomp all over the things
SoftLayer was almost doing right were astounding. I stood and listened to Ginni say things
like, "We purchased SoftLayer because we need to learn from you," and, "We want you to teach
us how to do Cloud the right way, since we spent all these years doing things the wrong way,"
and, "If you find yourself in a meeting with one of our old teams, you guys are gonna be the
ones in charge. You are the ones who know how this is supposed to work - our culture has
failed at it." Promises which were nothing more than hollow words.
In the 1970's 80's and 90's I was working in tech support for a company called ROLM. We were
doing communications , voice and data and did many systems for Fortune 500 companies along
with 911 systems and the secure system at the White House. My job was to fly all over North
America to solve problems with customers and integration of our equipment into their business
model. I also did BETA trials and documented systems so others would understand what it took
to make it run fine under all conditions.
In 84 IBM bought a percentage of the company and the next year they bought out the
company. When someone said to me "IBM just bought you out , you must thing you died and went
to heaven." My response was "Think of them as being like the Federal Government but making a
profit". They were so heavily structured and hide bound that it was a constant battle working
with them. Their response to any comments was "We are IBM"
I was working on an equipment project in Colorado Springs and IBM took control. I was
immediately advised that I could only talk to the people in my assigned group and if I had a
question outside of my group I had to put it in writing and give it to my manager and if he
thought it was relevant it would be forwarded up the ladder of management until it reached a
level of a manager that had control of both groups and at that time if he thought it was
relevant it would be sent to that group who would send the answer back up the ladder.
I'm a
Vietnam Veteran and I used my military training to get things done just like I did out in the
field. I went looking for the person I could get an answer from.
At first others were nervous
about doing that but within a month I had connections all over the facility and started
introducing people at the cafeteria. Things moved quickly as people started working together
as a unit. I finished my part of the work which was figuring all the spares technicians would
need plus the costs for packaging and service contract estimates. I submitted it to all the
people that needed it. I was then hauled into a meeting room by the IBM management and
advised that I was a disruptive influence and would be removed. Just then the final contracts
that vendors had to sign showed up and it used all my info. The IBM people were livid that
they were not involved.
By the way a couple months later the IBM THINK magazine came out with a new story about a
radical concept they had tried. A cover would not fit on a component and under the old system
both the component and the cover would be thrown out and they would start from scratch doing
it over. They decided to have the two groups sit together and figure out why it would not fit
and correct it on the spot.
Another great example of IBM people is we had a sales contract to install a multi node
voice mail system at WANG computers but we lost it because the IBM people insisted on
bundling in AS0400 systems into the sale to WANG computer. Instead we lost a multi million
dollar contract.
Eventually Siemens bought 50% of the company and eventually full control. Now all we heard
was "That is how we do it in Germany" Our response was "How did that WW II thing work
out".
The author may have more loyalty to Microsoft than he confides, is the first thing noticeable
about this article. The second thing is that in terms of getting rid of those aged IBM
workers, I think he may have completely missed the mark, in fairness, that may be the product
of his IBM experience, The sheer hubris of tech-talking from the middle of the story and
missing the global misstep that is today's IBM is noticeable. As a stockholder, the first
question is, "Where is the investigation to the breach of fiduciary duty by a board that owes
its loyalty to stockholders who are scratching their heads at the 'positive' spin the likes of
Ginni Rometty is putting on 20 quarters of dead losses?" Got that, 20 quarters of losses.
Next, it's a little worrisome that the author, now over the whole IBM thing is
recommending firing "older people," you know, the ones who helped the company retain its
performance in years' past. The smartest article I've read about IBM worried about its cheap
style of "acquiring" non-best-of-breed companies and firing oodles of its qualified R&D
guys. THAT author was right.
IBM's been run into the ground by Ginni, I'll use her first name, since apparently my
money is now used to prop up this sham of a leader, who from her uncomfortable public
announcement with Tim Cook of Apple, which HAS gone up, by the way, has embraced every
political trend, not cause but trend from hiring more women to marginalizing all those
old-time white males...You know the ones who produced for the company based on merit, sweat,
expertise, all those non-feeling based skills that ultimately are what a shareholder is
interested in and replaced them with young, and apparently "social" experts who are pasting
some phony "modernity" on a company that under Ginni's leadership has become more of a pet
cause than a company.
Finally, regarding ageism and the author's advocacy for the same, IBM's been there, done
that as they lost an age discrimination lawsuit decades ago. IBM gave up on doing what it had
the ability to do as an enormous business and instead under Rometty's leadership has tried to
compete with the scrappy startups where any halfwit knows IBM cannot compete.
The company has rendered itself ridiculous under Rometty, a board that collects paychecks
and breaches any notion of fiduciary duty to shareholders, an attempt at partnering with a
"mod" company like Apple that simply bolstered Apple and left IBM languishing and a rejection
of what has a track record of working, excellence, rewarding effort of employees and the
steady plod of performance. Dump the board and dump Rometty.
Four years in GTS ... joined via being outsourced to IBM by my previous employer. Left GTS
after 4 years.
The IBM way of life was throughout the Oughts and the Teens an utter and complete failure
from the perspective of getting work done right and using people to their appropriate and
full potential. I went from a multi-disciplinary team of engineers working across
technologies to support corporate needs in the IT environment to being siloed into a
single-function organization.
My first year of on-boarding with IBM was spent deconstructing
application integration and cross-organizational structures of support and interwork that I
had spent 6 years building and maintaining. Handing off different chunks of work (again,
before the outsourcing, an Enterprise solution supported by one multi-disciplinary team) to
different IBM GTS work silos that had no physical spacial relationship and no interworking
history or habits. What we're talking about here is the notion of "left hand not knowing what
the right hand is doing" ...
THAT was the IBM way of doing things, and nothing I've read
about them over the past decade or so tells me it has changed.
As a GTS employee, professional technical training was deemed unnecessary, hence I had no
access to any unless I paid for it myself and used my personal time ... the only training
available was cheesy presentations or other web based garbage from the intranet, or casual /
OJT style meetings with other staff who were NOT professional or expert trainers.
As a GTS
employee, I had NO access to the expert and professional tools that IBM fricking made and
sold to the same damn customers I was supposed to be supporting. Did we have expert and
professional workflow / document management / ITIL aligned incident and problem management
tools? NO, we had fricking Lotus Notes and email. Instead of upgrading to the newest and best
software solutions for data center / IT management & support, we degraded everything down
the simplest and least complex single function tools that no "best practices" organization on
Earth would ever consider using.
And the people management paradigm ... employees ranked annually not against a static or
shared goal or metric, but in relation to each other, and there was ALWAYS a "top 10 percent"
and a "bottom ten percent" required by upper management ... a system that was sociopathic in
it's nature because it encourages employees to NOT work together ... by screwing over one's
coworkers, perhaps by not giving necessary information, timely support, assistance as needed
or requested, one could potentially hurt their performance and make oneself look relatively
better. That's a self-defeating system and it was encouraged by the way IBM ran things.
The "not invented here" ideology was embedded deeply in the souls of all senior IBMers I
ever met or worked with ... if you come on board with any outside knowledge or experience,
you must not dare to say "this way works better" because you'd be shut down before you could
blink. The phrase "best practices" to them means "the way we've always done it".
IBM gave up on innovation long ago. Since the 90's the vast majority of their software has
been bought, not built. Buy a small company, strip out the innovation, slap an IBM label on
it, sell it as the next coming of Jesus even though they refuse to expend any R&D to push
the product to the next level ... damn near everything IBM sold was gentrified, never cutting
edge.
And don't get me started on sales practices ... tell the customer how product XYZ is a
guaranteed moonshot, they'll be living on lunar real estate in no time at all, and after all
the contracts are signed hand the customer a box of nuts & bolts and a letter telling
them where they can look up instructions on how to build their own moon rocket. Or for XX
dollars more a year, hire a Professional Services IBMer to build it for them.
I have no sympathy for IBM. They need a clean sweep throughout upper management,
especially any of the old True Blue hard-core IBMers.
We tried our best to be SMB partners with IBM & Arrow in the early 2000s ... but could
never get any traction. I personally needed a mentor, but never found one. I still have/wear
some of their swag, and I write this right now on a re-purposed IBM 1U server that is 10
years old, but ... I can't see any way our small company can make $ with them.
Watson is impressive, but you can't build a company on just Watson. This author has some
great ideas, yet the phrase that keeps coming to me is internal politics.
That corrosive reality has & will kill companies, and it will kill IBM unless it is dealt
with.
Turn-arounds are possible (look at MS), but they are hard and dangerous. Hope IBM can
figure it out...
Hole opens up remote-code execution to miscreants – or a crash, if you're
lucky A security bug in Systemd can be exploited over the network to, at best, potentially
crash a vulnerable Linux machine, or, at worst, execute malicious code on the box.
The flaw therefore puts Systemd-powered Linux computers – specifically those using
systemd-networkd – at risk of remote hijacking: maliciously crafted DHCPv6 packets can
try to exploit the programming cockup and arbitrarily change parts of memory in vulnerable
systems, leading to potential code execution. This code could install malware, spyware, and
other nasties, if successful.
The vulnerability – which was made public this week – sits within the
written-from-scratch DHCPv6 client of the open-source Systemd management suite, which is built
into various flavors of Linux.
This client is activated automatically if IPv6 support is enabled, and relevant packets
arrive for processing. Thus, a rogue DHCPv6 server on a network, or in an ISP, could emit
specially crafted router advertisement messages that wake up these clients, exploit the bug,
and possibly hijack or crash vulnerable Systemd-powered Linux machines.
systemd-networkd
is vulnerable to an out-of-bounds heap write in the DHCPv6 client when handling options sent by
network adjacent DHCP servers. A attacker could exploit this via malicious DHCP server to
corrupt heap memory on client machines, resulting in a denial of service or potential code
execution.
Felix Wilhelm, of the Google Security team, was credited with discovering the flaw,
designated CVE-2018-15688 . Wilhelm found that a
specially crafted DHCPv6 network packet could trigger "a very powerful and largely controlled
out-of-bounds heap write," which could be used by a remote hacker to inject and execute
code.
"The overflow can be triggered relatively easy by advertising a DHCPv6 server with a
server-id >= 493 characters long," Wilhelm noted.
In addition to Ubuntu and Red
Hat Enterprise Linux, Systemd has been adopted as a service manager for Debian, Fedora, CoreOS,
Mint, and SUSE Linux Enterprise Server. We're told RHEL 7, at least, does not use the
vulnerable component by default.
Systemd creator Lennart Poettering has already
published a security fix for the vulnerable component
– this should be weaving its way into distros as we type.
If you run a Systemd-based Linux system, and rely on systemd-networkd, update your operating
system as soon as you can to pick up the fix when available and as necessary.
The bug will come as another argument against Systemd as the Linux management tool continues
to fight for the hearts and minds of admins and developers alike. Though a number of major
admins have in recent years adopted and championed it as
the replacement for the old Init era, others within the Linux world seem to still be less than
impressed with Systemd and Poettering's occasionally
controversial management of the tool. ® Page:
As anyone who bothers to read my comments (BTW "hi" to both of you) already knows, I
despise systemd with a passion, but this one is more an IPv6 problem in general.
Yes this is an actual bug in networkd, but IPv6 seems to be far more bug prone than v4,
and problems are rife in all implementations. Whether that's because the spec itself is
flawed, or because nobody understands v6 well enough to implement it correctly, or possibly
because there's just zero interest in making any real effort, I don't know, but it's a fact
nonetheless, and my primary reason for disabling it wherever I find it. Which of course
contributes to the "zero interest" problem that perpetuates v6's bug prone condition, ad
nauseam.
IPv6 is just one of those tech pariahs that everyone loves to hate, much like systemd,
albeit fully deserved IMO.
Oh yeah, and here's the obligatory "systemd sucks". Personally I always assumed the "d"
stood for "destroyer". I believe the "IP" in "IPv6" stands for "Idiot Protocol".
Fortunately, IPv6 by lack of adopted use, limits the scope of this bug.
Yeah, fortunately IPv6 is only used by a few fringe organizations like Google and
Microsoft.
Seriously, I personally want nothing to do with either systemd or IPv6. Both seem to me to
fall into the bin labeled "If it ain't broke, let's break it" But still it's troubling that
things that some folks regard as major system components continue to ship with significant
security flaws. How can one trust anything connected to the Internet that is more
sophisticated and complex than a TV streaming box?
Was going to say the same thing, and I disable IPv6 for the exact same reason. IPv6 code
isn't as well tested, as well audited, or as well targeted looking for exploits as IPv4.
Stuff like this only proves that it was smart to wait, and I should wait some more.
Count me in the camp of who hates systemd(hates it being "forced" on just about every
distro, otherwise wouldn't care about it - and yes I am moving my personal servers to Devuan,
thought I could go Debian 7->Devuan but turns out that may not work, so I upgraded to
Debian 8 a few weeks ago, and will go to Devuan from there in a few weeks, upgraded one
Debian 8 to Devuan already 3 more to go -- Debian user since 1998), when reading this article
it reminded me of
This makes me glad I'm using FreeBSD. The Xorg version in FreeBSD's ports is currently
*slightly* older than the Xorg version that had that vulnerability in it. AND, FreeBSD will
*NEVER* have systemd in it!
(and, for Linux, when I need it, I've been using Devuan)
That being said, the whole idea of "let's do a re-write and do a 'systemd' instead of
'system V init' because WE CAN and it's OUR TURN NOW, 'modern' 'change for the sake of
change' etc." kinda reminds me of recent "update" problems with Win-10-nic...
Oh, and an obligatory Schadenfreude laugh: HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA
HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA
HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA HA!!!!!!!!!!!!!!!!!!!
Finally got all my machines cut over from Debian to Devuan.
Might spin a FreeBSD system up in a VM and have a play.
I suspect that the infestation of stupid into the Linux space won't stop with or be
limited to SystemD. I will wait and watch to see what damage the re-education gulag has done
to Sweary McSwearFace (Mr Torvalds)
Not really, systemd has its tentacles everywhere and runs as root.
Yes, but not really the problem in this case. Any DHCP client is going to have to
run at least part of the time as root. There's not enough nuance in the Linux privilege model
to allow it to manipulate network interfaces, otherwise.
Yes, but not really the problem in this case. Any DHCP client is going to have to run at
least part of the time as root. There's not enough nuance in the Linux privilege model to
allow it to manipulate network interfaces, otherwise.
Sorry but utter bullshit. You can if you are so inclined you can use the Linux
Capabilities framework for this kind of thing. See
https://wiki.archlinux.org/index.php/capabilities
I remain very happy that I don't use systemd on any of my machines anymore. :)
"others within the Linux world seem to still be less than impressed with Systemd"
Yep, I'm in that camp. I gave it a good, honest go, but it increased the amount of hassle
and pain of system management without providing any noticeable benefit, so I ditched it.
> Just like it's entirely possible to have a Linux system without any GNU in it
Just like it's possible to have a GNU system without Linux on it - ho well as soon as GNU
MACH is finally up to the task ;-)
On the systemd angle, I, too, am in the process of switching all my machines from Debian
to Devuan but on my personnal(*) network a few systemd-infected machines remain, thanks to a
combination of laziness from my part and stubborn "systemd is quite OK" attitude from the
raspy foundation. That vuln may be the last straw : one on the aforementionned machines sits
on my DMZ, chatting freely with the outside world. Nothing really crucial on it, but i'd hate
it if it became a foothold for nasties on my network.
(*) policy at work is RHEL, and that's negociated far above my influence level, but I
don't really care as all my important stuff runs on Z/OS anyway ;-) . Ok we have to reboot a
few VMs occasionnally when systemd throws a hissy fit -which is surprisingly often for an
"enterprise" OS -, but meh.
"This code is actually pretty bad and should raise all kinds of red flags in a code
review."
Yeah, but for that you need people who can do code reviews, and also people who can accept
criticism. That also means saying "no" to people who are bad at coding, and saying that
repeatedly if they don't learn.
SystemD seems to be the area where people gather who want to get code in for their
resumes, not for people who actually want to make the world a better place.
... that an init, traditionally, is a small bit of code that does one thing very well.
Like most of the rest of the *nix core utilities. All an init should do is start PID1, set
run level, spawn a tty (or several), handle a graceful shutdown, and log all the above in
plaintext to make troubleshooting as simplistic as possible. Anything else is a vanity
project that is best placed elsewhere, in it's own stand-alone code base.
Inventing a clusterfuck init variation that's so big and bulky that it needs to be called
a "suite" is just asking for trouble.
IMO, systemd is a cancer that is growing out of control, and needs to be cut out of Linux
before it infects enough of the system to kill it permanently.
That's why systemd-networkd is a separate, optional component, and not actually part of
the init daemon at all. Most systemd distros do not use it by default and thus are not
vulnerable to this unless the user actively disables the default network manager and chooses
to use networkd instead.
Pardon my ignorance (I don't use a distro with systemd) why bother with networkd in the
first place if you don't have to use it.
Mostly because the old-style init system doesn't cope all that well with systems that move
from network to network. It works for systems with a static IP, or that do a DHCP request at
boot, but it falls down on anything more dynamic.
In order to avoid restarting the whole network system every time they switch WiFi access
points, people have kludged on solutions like NetworkManager. But it's hard to argue it's
more stable or secure than networkd. And this is always going to be a point of vulnerability
because anything that manipulates network interfaces will have to be running as root.
These days networking is essential to the basic functionality of most computers; I think
there's a good argument that it doesn't make much sense to treat it as a second-class
citizen.
"Funny that I installed ubuntu 18.04 a few weeks ago and the fucking thing installed
itself then! ( and was a fucking pain to remove)."
So I looked into it a bit more, and from a few references at least, it seems like Ubuntu
has a sort of network configuration abstraction thingy that can use both NM and
systemd-networkd as backends; on Ubuntu desktop flavors NM is usually the default, but
apparently for recent Ubuntu Server, networkd might indeed be the default. I didn't notice
that as, whenever I want to check what's going on in Ubuntu land, I tend to install the
default desktop spin...
"LP is a fucking arsehole."
systemd's a lot bigger than Lennart, you know. If my grep fu is correct, out of 1543
commits to networkd, only 298 are from Lennart...
in many respects when it comes to software because, over time, the bugs will have been
found and squashed. Systemd brings in a lot of new code which will, naturally, have lots of
bugs that will take time to find & remove. This is why we get problems like this DHCP
one.
Much as I like the venerable init: it did need replacing. Systemd is one way to go, more
flexible, etc, etc. Something event driven is a good approach.
One of the main problems with systemd is that it has become too big, slurped up lots of
functionality which has removed choice, increased fragility. They should have concentrated on
adding ways of talking to existing daemons, eg dhcpd, through an API/something. This would
have reused old code (good) and allowed other implementations to use the API - this letting
people choose what they wanted to run.
But no: Poettering seems to want to build a Cathedral rather than a Bazzar.
He appears to want to make it his way or no way. This is bad, one reason that *nix is good
is because different solutions to a problem have been able to be chosen, one removed and
another slotted in. This encourages competition and the 'best of breed' comes out on top.
Poettering is endangering that process.
Also: he refusal to accept patches to let it work on non-Linux Unix is just plain
nasty.
One of the main problems with systemd is that it has become too big, slurped up lots of
functionality which has removed choice, increased fragility.
IMO, there is a striking paralell between systemd and the registry in Windows OSs.
After many years of dealing with the registry (W98 to XPSP3) I ended up seeing the
registry as a sort of developer sanctioned virus running inside the OS, constantly changing
and going deeper and deeper into the OS with every iteration and as a result, progressively
putting an end to the possibility of knowing/controlling what was going on inside your
box/the OS.
Years later, when I learned about the existence of systemd (I was already running Ubuntu)
and read up on what it did and how it did it, it dawned on me that systemd was nothing more
than a registry class virus and it was infecting Linux_land at the behest of the
developers involved.
So I moved from Ubuntu to PCLinuxOS and then on to Devuan.
Call me paranoid but I am convinced that there are people both inside and outside IT that
actually want this and are quite willing to pay shitloads of money for it to
happen.
I don't see this MS cozying up to Linux in various ways lately as a coincidence: these
things do not happen just because or on a senior manager's whim.
What I do see (YMMV) is systemd being a sort of convergence of Linux with Windows,
which will not be good for Linux and may well be its undoing.
Much as I like the venerable init: it did need replacing.
For some use cases, perhaps. Not for any of mine. SysV init, or even BSD init, does
everything I need a Linux or UNIX init system to do. And I don't need any of the other crap
that's been built into or hung off systemd, either.
BSD init and SysV init work pretty darn well for their original purpose -- servers with
static IP addresses that are rebooted no more than once in a fortnight. Anything more dynamic
starts to give it trouble.
Linus doesn't care. systemd has nothing to do with the kernel ... other than the fact that
the lead devs for systemd have been banned from working on the kernel because they don't play
nice with others.
I've been using runit, because I am too lazy and clueless to write init scripts reliably.
It's very lightweight, runs on a bunch of systems and really does one thing - keep daemons
up.
I am not saying it's the best - but it looks like it has a very small codebase, it doesn't
do much and generally has not bugged me after I configured each service correctly. I believe
other systems also exist to avoid using init scripts directly. Not Monit, as it relies on you
configuring the daemon start/stop commands elsewhere.
On the other hand, systemd is a massive sprawl, does a lot of things - some of them
useful, like dependencies and generally has needed more looking after. Twice I've had errors
on a Django server that, after a lot of looking around ended up because something had changed
in the, Chef-related, code that's exposed to systemd and esoteric (not emitted by systemd)
errors resulted when systemd could not make sense of the incorrect configuration.
I don't hate it - init scripts look a bit antiquated to me and they seem unforgiving to
beginners - but I don't much like it. What I certainly do hate is how, in an OS that is
supposed to be all about choice, sometime excessively so as in the window manager menagerie,
we somehow ended up with one mandatory daemon scheduler on almost all distributions. Via, of
all types of dependencies, the GUI layer. For a window manager that you may not even have
installed.
Talk about the antithesis of the Unix philosophy of do one thing, do it well.
Oh, then there are also the security bugs and the project owner is an arrogant twat. That
too.
"init scripts look a bit antiquated to me and they seem unforgiving to beginners"
Init scripts are shell scripts. Shell scripts are as old as Unix. If you think that makes
them antiquated then maybe Unix-like systems are not for you. In practice any sub-system
generally gets its own scripts installed with the rest of the S/W so if being unforgiving
puts beginners off tinkering with them so much the better. If an experienced Unix user really
needs to modify one of the system-provided scripts their existing shell knowledge will let
them do exactly what's needed. In the extreme, if you need to develop a new init script then
you can do so in the same way as you'd develop any other script - edit and test from the
command line.
I personally like openrc as an init system, but systemd is a symptom of the tooling
problem.
It's for me a retrograde step but again, it's linux, one can, as you and I do, just remove
systemd.
There are a lot of people in the industry now who don't seem able to cope with shell
scripts nor are minded to research the arguments for or against shell as part of a unix style
of system design.
In conclusion, we are outnumbered, but it will eventually collapse under its own weight
and a worthy successor shall rise, perhaps called SystemV, might have to shorten that name a
bit.
"In addition to Ubuntu and Red Hat Enterprise Linux, Systemd has been adopted as a service
manager for Debian, Fedora, CoreOS, Mint, and SUSE Linux Enterprise Server. We're told RHEL
7, at least, does not use the vulnerable component by default."
I can tell you for sure that no version of Fedora does, either, and I'm fairly sure that
neither does Debian, SLES or Mint. I don't know anything much about CoreOS, but
https://coreos.com/os/docs/latest/network-config-with-networkd.html suggests it actually
*might* use systemd-networkd.
systemd-networkd is not part of the core systemd init daemon. It's an optional component,
and most distros use some other network manager (like NetworkManager or wicd) by default.
I mean commercial distributions seem to be particularly interested in trying out new
things that can increase their number of support calls. It's probably just that networkd is
either to new and therefore not yet in the release, or still works so badly even the most
rudimentary tests fail.
There is no reason to use that NTP daemon of systemd, yet more and more distros ship with
it enabled, instead of some sane NTP-server.
I won't hold my breath, then. I have a laptop at the moment that refuses to boot because
(as I've discovered from looking at the journal offline) pulseaudio is in an infinite loop
waiting for the successful detection of some hardware that, presumably, I don't have.
I imagine I can fix it by hacking the file-system (offline) so that fuckingpulse is no
longer part of the boot configuration, but I shouldn't have to. A decent init system would be
able to kick of everything else in parallel and if one particular service doesn't come up
properly then it just logs the error. I *thought* that was one of the claimed advantages of
systemd, but apparently that's just a load of horseshit.
My NAT router statefully firewalls incoming IPv6 by default, which I consider equivalently
secure. NAT adds security mostly by accident, because it de-facto adds a firewall that blocks
incoming packets. It's not the address translation itself that makes things more secure, it's
the inability to route in from the outside.
NAT is schtick for connecting a whole LAN to a WAN using a single IPv4 address (useful
with IPv4 because most ISPs don't give you a /24 when you sign up). If you have a native IPv6
address you'll have something like 2^64 addresses, so machines on your LAN can have an actual
WAN-visible address of their own without needing a trick like NAT.
"so machines on your LAN can have an actual WAN-visible address of their own without
needing a trick like NAT."
Avoiding that configuration is exactly the use case for using NAT with IPv6. As others
have pointed out, you can accomplish the same thing with IPv6 router configuration, but NAT
is easier in terms of configuration and maintenance. Given that, and assuming that you don't
want to be able to have arbitrary machines open ports that are visible to the internet, then
why not use NAT?
Also, if your goal is to make people more likely to move to IPv6, pointing out IPv4
methods that will work with IPv6 (even if you don't consider them optimal) seems like a
really, really good idea. It eases the transition.
Please El Reg these stories make ma rage at breakfast, what's this?
The bug will come as another argument against Systemd as the Linux management tool
continues to fight for the hearts and minds of admins and developers alike.
Less against systemd (which should get attacked on the design & implementation level)
or against IPv6 than against the use of buffer-overflowable languages in 2018 in code that
processes input from the Internet (it's not the middle ages anymore) or at least very hard
linting of the same.
But in the end, what did it was a violation of the Don't Repeat Yourself principle and
lack of sufficently high-level datastructures. Pointer into buffer, and the remaining buffer
length are two discrete variables that need to be updated simultaneously to keep the
invariant and this happens in several places. This is just a catastrophe waiting to happen.
You forget to update it once, you are out! Use structs and functions updating the structs
correctly.
The function receives a pointer to the option buffer buf, it's remaining size buflen
and the IA to be added to the buffer. While the check at (A) tries to ensure that the buffer
has enough space left to store the IA option, it does not take the additional 4 bytes from
the DHCP6Option header into account (B). Due to this the memcpy at (C) can go out-of-bound
and *buflen can underflow [i.e. you suddenly have a gazillion byte buffer, Ed.] in (D) giving
an attacker a very powerful and largely controlled OOB heap write starting at (E).
why don't we stop writing code in languages that make it easy to screw up so easily like
this?
There are plenty about nowadays, I'd rather my DHCP client be a little bit slower at
processing packets if I had more confidence it would not process then incorrectly and execute
code hidden in said packets...
The circus that is called "Linux" have forced me to Devuan and the likes however the
circus is getting worse and worse by the day, thus I have switched to the BSD world, I will
learn that rather than sit back and watch this unfold As many of us have been saying, the
sudden switch to SystemD was rather quick, perhaps you guys need to go investigate why it
really happened, don't assume you know, go dig and you will find the answers, it's rather
scary, thus I bid the Linux world a farewell after 10 years of support, I will watch the
grass dry out from the other side of the fence, It was destined to fail by means of
infiltration and screw it up motive(s) on those we do not mention here.
As many of us have been saying, the sudden switch to SystemD was rather quick, perhaps
you guys need to go investigate why it really happened, don't assume you know, go dig and you
will find the answers, it's rather scary ...
Indeed, it was rather quick and is very scary.
But there's really no need to dig much, just reason it out.
It's like a follow the money situation of sorts.
I'll try to sum it up in three short questions:
Q1: Hasn't the Linux philosophy (programs that do one thing and do it well) been a
success?
A1: Indeed, in spite of the many init systems out there, it has been a success in
stability and OS management. And it can easily be tested and debugged, which is an essential
requirement.
Q2: So what would Linux need to have the practical equivalent of the registry in
Windows for?
A2: So that whatever the registry does in/to Windows can also be done in/to Linux.
Q3: I see. And just who would want that to happen? Makes no sense, it is a huge
step backwards.
OK, so I was able to check through the link you provided, which says "up to and including
239", but I had just installed a systemd update and when you said there was already a fix
written, working it's way through the distro update systems, all I had to do was check my
log.
Linux Mint makes it easy.
But why didn't you say something such as "reported to affect systemd versions up to and
including 239" and then give the link to the CVE? That failure looks like rather careless
journalism.
"... I worked as a contractor for IBM's IGS division in the late '90s and early 2000s at their third biggest customer, and even then, IBM was doing their best to demoralize their staff (and contractors) and annoy their customers as much as possible! ..."
"... IBM charged themselves 3x the actual price to customers for their ThinkPads at the time! This meant that I never had a laptop or desktop PC from IBM in the 8 years I worked there. If it wasn't for the project work I did I would not have had a PC to work on! ..."
"... What was strange is that every single time I got a pay cut, IBM would then announce that they had bought a new company! I would have quit long before I did, but I was tied to them while waiting for my Green Card to be approved. I know that raises are few in the current IBM for normal employees and that IBM always pleads poverty for any employee request. Yet, they somehow manage to pay billions of dollars for a new company. Strange that, isn't it? ..."
"... I moved to the company that had won the contract and regret not having the chance to tell that IBM manager what I thought about him and where he could stick the new laptop. ..."
"... After that experience I decided to never work for them in any capacity ever again. I feel pity for the current Red Hat employees and my only advice to them is to get out while they can. "DON'T FOLLOW THE RED HAT TO HELL" ..."
Red Hat will be a distant memory in a few years as it gets absorbed by the abhorrent IBM
culture and its bones picked clean by the IBM beancounters. Nothing good ever happens to a
company bought by IBM.
I worked as a contractor for IBM's IGS division in the late '90s and early 2000s at their
third biggest customer, and even then, IBM was doing their best to demoralize their staff (and
contractors) and annoy their customers as much as possible!
Some examples:
The on-site IBM employees (and contractors) had to use Lotus Notes for email. That was
probably the worst piece of software I have ever used - I think baboons on drugs could have
done a better design job. IBM set up a T1 (1.54 Mbps) link between the customer and the local
IBM hub for email, etc. It sounds great until you realize there were over 150 people involved
and due to the settings of Notes replication, it could often take over an hour to actually
download email to read.
To do my job I needed to install some IBM software. My PC did not have enough disk space for
this software as well as the other software I needed. Rather than buy me a bigger hard disk I
had to spend 8 hours a week installing and reinstalling software to do my job.
I waited three months for a $50 stick of memory to be approved. When it finally arrived my
machine had been changed out (due to a new customer project) and the memory was not compatible!
Since I worked on a lot of projects I often had machines supplied by the customer on my desk.
So, I would use one of these as my personal PC and would get an upgrade when the next project
started!
I was told I could not be supplied with a laptop or desktop from IBM as they were too
expensive (my IBM division did not want to spend money on anything). IBM charged themselves 3x
the actual price to customers for their ThinkPads at the time! This meant that I never had a
laptop or desktop PC from IBM in the 8 years I worked there. If it wasn't for the project work
I did I would not have had a PC to work on!
IBM has many strange and weird processes that allow them to circumvent the contract they
have with their preferred contractor companies. This meant that for a number of years I ended
up getting a pay cut. What was strange is that every single time I got a pay cut, IBM would
then announce that they had bought a new company! I would have quit long before I did, but I
was tied to them while waiting for my Green Card to be approved. I know that raises are few in
the current IBM for normal employees and that IBM always pleads poverty for any employee
request. Yet, they somehow manage to pay billions of dollars for a new company. Strange that,
isn't it?
Eventually I was approved to get a laptop and excitedly watched it move slowly through the
delivery system. I got confused when it was reported as delivered to Ohio rather than my work
(not in Ohio). After some careful searching I discovered that my manager and his wife both
worked for IBM from their home in, yes you can guess, Ohio. It looked like he had redirected my
new laptop for his own use and most likely was going to send me his old one and claim it was a
new one. I never got the chance to confront him about it, though, as IBM lost the contract with
the customer that month and before the laptop should have arrived IBM was out! I moved to the
company that had won the contract and regret not having the chance to tell that IBM manager
what I thought about him and where he could stick the new laptop.
After that experience I decided to never work for them in any capacity ever again. I feel
pity for the current Red Hat employees and my only advice to them is to get out while they can.
"DON'T FOLLOW THE RED HAT TO HELL"
I sense that a global effort is ongoing to shutdown open source software by brute force.
First, the enforcement of the EU General Data Protection Regulation (GDPR) by ICANN.org to
enable untraceable takeovers of domains. Microsoft buying github. Linus Torvalds forced out
of his own Linux kernel project because of the Code of Conduct and now IBM buying RedHat. I
wrote the following at https://lulz.com/linux-devs-threaten-killswitch-coc-controversy-1252/
"Torvalds should lawyer up. The problems are the large IT Tech firms who platinum donated all
over the place in Open Source land. When IBM donated with 1 billion USD to Linux in 2000
https://itsfoss.com/ibm-invest-1-billion-linux/ a friend who vehemently was against the GPL
and what Torvalds was doing, told me that in due time OSS would simply just go away.
These Community Organizers, not Coders per se, are on a mission to overtake and control
the Linux Foundation, and if they can't, will search and destroy all of it, even if it
destroys themselves. Coraline is merely a expendable pion here. Torvalds is now facing unjust
confrontations and charges resembling the nomination of Judge Brett Kavanaugh. Looking at the
CoC document it even might have been written by a Google executive, who themselves currently
are facing serious charges and lawsuits from their own Code of Conduct. See theintercept.com,
their leaked video the day after the election of 2016. They will do anything to pursue this.
However to pursue a personal bias or agenda furnishing enactments or acts such as to, omit
contradicting facts (code), commit perjury, attend riots and harassments, cleanse Internet
archives and search engines of exculpatory evidence and ultimately hire hit-men to
exterminate witnesses of truth (developers), in an attempt to elevate bias as fabricated fact
(code) are crimes and should be prosecuted accordingly."
It does not matter if somebody "stresses independence word are cheap. The mere fact that this
is not IBM changes relationships. also IBM executives need to show "leadership" and that entails
some "general direction" for Red Hat from now on. At least with Microsoft and HP relationship
will be much cooler, then before.
Also IBM does not like "charity" projects like CentOS and that will be affected too, no
matter what executives tell you right now. Paradoxically this greatly strengthen the position of
Oracle Linux.
The status of IBM software in corporate world 9outside finance companies) is low and their
games with licenses (licensing products per core, etc) are viewed by most of their customers as
despicable. This was one of the reasons IBM lost it share in enterprise software. For example,
greed in selling Tivoli more or less killed the software. All credits to Lou Gerstner who
initially defined this culture of relentless outsource and cult of the "bottom line" (which was
easy for his because he does not understood technology at all). His successor was even more
active in driving company into the ground. R ampant cost-arbitrage driven offshoring has left a
legacy of dissatisfied customers. Most projects are over priced. and most of those which were
priced more or less on industry level had bad quality results and costs overruns.
IBM cut severance pay to 1 month, is firing people left and right and is insensitive to the
fired employees and the result is enormous negativity for them. Good people are scared to work
for them and people are asking tough questions.
It's strategy since Gerstner. Palmisano (this guys with history diploma witched into
Cybersecurity after retirement in 2012 and led Obama cybersecurity commission) & Ginni Rometty was completely
neoliberal mantra "share holder value", grow earnings per share at all costs. They all manage IBM
for financial appearance rather than the quaility products. There was no focus on
breakthrough-innovation, market leadership in mega-trends (like cloud computing) or even giving
excellent service to customers.
Ginni Rometty accepted bonuses during times of layoffs and outsourcing.
When company have lost it architectural talent the brand will eventually die. IBM still has
very high number of patents every year. It is still a very large company in terms of revenue and
number of employees. However, there are strong signs that its position in the technology industry
might deteriorate further.
Cormier also stressed Red Hat independence when we asked how the acquisition would affect
ongoing partnerships in place with Amazon Web Services, Microsoft Azure, and other public
clouds.
"One of the things you keep seeing in this is that we're going to run Red Hat as a separate
entity within IBM," he said. "One of the reasons is business. We need to, and will, remain
Switzerland in terms of how we interact with our partners. We're going to continue to
prioritize what we do for our partners within our products on a business case perspective,
including IBM as a partner. We're not going to do unnatural things. We're going to do the right
thing for the business, and most importantly, the customer, in terms of where we steer our
products."
Red Hat promises that independence will extend to Red Hat's community projects, such as its
freely available Fedora Linux distribution which is widely used by developers. When asked what
impact the sale would have on Red Hat maintained projects like Fedora and CentoOS, Cormier
replied, "None. We just came from an all-hands meeting from the company around the world for
Red Hat, and we got asked this question and my answer was that the day after we close, I don't
intend to do anything different or in any other way than we do our every day today. Arvind,
Ginnie, Jim, and I have talked about this extensively. For us, it's business as usual. Whatever
we were going to do for our road maps as a stand alone will continue. We have to do what's
right for the community, upstream, our associates, and our business."
This all sounds good, but as they say, talk is cheap. Six months from now we'll have a
better idea of how well IBM can walk the walk and leave Red Hat alone. If it can't and Red Hat
doesn't remain clearly distinct from IBM ownership control, then Big Blue will have wasted $33
billion it can't afford to lose and put its future, as well as the future of Red Hat, in
jeopardy.
Step back and think about this for a minute. There are plenty of examples of people who were
doing their jobs, IN SPADES, putting in tons of unpaid overtime, and generally doing whatever
was humanly possible to make sure that whatever was promised to the customer was delivered
(within their span of control... I'm not going to get into a discussion of how IBM pulls the
rug out from underneath contracts after they've been signed).
These people were, and still are, high performers, they are committed to the job and the
purpose that has been communicated to them by their peers, management, and customers; and
they take the time (their OWN time) to pick up new skills and make sure that they are still
current and marketable. They do this because they are committed to doing the job to the best
of their ability.... it's what makes them who they are.
IBM (and other companies) are firing these very people ***for one reason and one reason
ONLY***: their AGE. They have the skills and they're doing their jobs. If the same person was
30 you can bet that they'd still be there. Most of the time it has NOTHING to do with
performance or lack of concurrency. Once the employee is fired, the job is done by someone
else. The work is still there, but it's being done by someone younger and/or of a different
nationality.
The money that is being saved by these companies has to come from somewhere. People that
are having to withdraw their retirement savings 20 or so years earlier than planned are going
to run out of funds.... and when they're in nursing homes, guess who is going to be
supporting them? Social security will be long gone, their kids have their own monetary
challenges.... so it will be government programs.... maybe.
This is not just a problem that impacts the 40 and over crowd. This is going to impact our
entire society for generations to come.
The business reality you speak of can be tempered via government actions. A few things:
One of the major hardships here is laying someone off when they need income the most -
to pay for their children's college education. To mitigate this, as a country we could make a
public education free. That takes off a lot of the sting, some people might relish a change
in career when they are in their 50s except that the drop in salary is so steep when changing
careers.
We could lower the retirement age to 55 and increase Social Security to more than a
poverty-level existence.Being laid off when you're 50 or 55 - with little chance to be hired
anywhere else - would not hurt as much.
We could offer federal wage subsidies for older workers to make them more attractive to
hire. While some might see this as a thumb on the scale against younger workers, in reality
it would be simply a counterweight to the thumb that is already there against older
workers.
Universal health care equalizes the cost of older and younger workers.
The other alternative is a market-based life that, for many, will be cruel, brutish, and
short.
As a new engineering graduate, I joined a similar-sized multinational US-based company in the
early '70s. Their recruiting pitch was, "Come to work here, kid. Do your job, keep your nose
clean, and you will enjoy great, secure work until you retire on easy street".
Soon after I started, the company fired hundreds of 50-something employees and put we
"kids" in their jobs. Seeing that employee loyalty was a one way street at that place, I left
after a couple of years. Best career move I ever made.
As a 25yr+ vet of IBM, I can confirm that this article is spot-on true. IBM used to be a
proud and transparent company that clearly demonstrated that it valued its employees as much
as it did its stock performance or dividend rate or EPS, simply because it is good for
business. Those principles helped make and keep IBM atop the business world as the most
trusted international brand and business icon of success for so many years. In 2000, all that
changed when Sam Palmisano became the CEO. Palmisano's now infamous "Roadmap 2015" ran the
company into the ground through its maniacal focus on increasing EPS at any and all costs.
Literally. Like, its employees, employee compensation, benefits, skills, and education
opportunities. Like, its products, product innovation, quality, and customer service. All of
which resulted in the devastation of its technical capability and competitiveness, employee
engagement, and customer loyalty. Executives seemed happy enough as their compensation grew
nicely with greater financial efficiencies, and Palisano got a sweet $270M+ exit package in
2012 for a job well done. The new CEO, Ginni Rometty has since undergone a lot of scrutiny
for her lack of business results, but she was screwed from day one. Of course, that doesn't
leave her off the hook for the business practices outlined in the article, but what do you
expect: she was hand picked by Palmisano and approved by the same board that thought
Palmisano was golden.
In 1994, I saved my job at IBM for the first time, and survived. But I was 36 years old. I
sat down at the desk of a man in his 50s, and found a few odds and ends left for me in the
desk. Almost 20 years later, it was my turn to go. My health and well-being is much better
now. Less money but better health. The sins committed by management will always be: "I was
just following orders".
"... Correction, March 24, 2018: Eileen Maroney lives in Aiken, South Carolina. The name of her city was incorrect in the original version of this story. ..."
Consider, for example, a planning presentation that former IBM executives said was drafted by heads of a business unit carved
out of IBM's once-giant software group and charged with pursuing the "C," or cloud, portion of the company's CAMS strategy.
The presentation laid out plans for substantially altering the unit's workforce. It was shown to company leaders including Diane
Gherson, the senior vice president for human resources, and James Kavanaugh, recently elevated to chief financial officer. Its language
was couched in the argot of "resources," IBM's term for employees, and "EP's," its shorthand for early professionals or recent college
graduates.
Among the goals: "Shift headcount mix towards greater % of Early Professional hires." Among the means: "[D]rive a more aggressive
performance management approach to enable us to hire and replace where needed, and fund an influx of EPs to correct seniority mix."
Among the expected results: "[A] significant reduction in our workforce of 2,500 resources."
A slide from a similar presentation prepared last spring for the same leaders called for "re-profiling current talent" to "create
room for new talent." Presentations for 2015 and 2016 for the 50,000-employee software group also included plans for "aggressive
performance management" and emphasized the need to "maintain steady attrition to offset hiring."
IBM declined to answer questions about whether either presentation was turned into company policy. The description of the planned
moves matches what hundreds of older ex-employees told ProPublica they believe happened to them: They were ousted because of their
age. The company used their exits to hire replacements, many of them young; to ship their work overseas; or to cut its overall headcount.
Ed Alpern, now 65, of Austin, started his 39-year run with IBM as a Selectric typewriter repairman. He ended as a project manager
in October of 2016 when, he said, his manager told him he could either leave with severance and other parting benefits or be given
a bad job review -- something he said he'd never previously received -- and risk being fired without them.
Albert Poggi, now 70, was a three-decade IBM veteran and ran the company's Palisades, New York, technical center where clients
can test new products. When notified in November of 2016 he was losing his job to layoff, he asked his bosses why, given what he
said was a history of high job ratings. "They told me," he said, "they needed to fill it with someone newer."
The presentations from the software group, as well as the stories of ex-employees like Alpern and Poggi, square with internal
documents from two other major IBM business units. The documents for all three cover some or all of the years from 2013 through the
beginning of 2018 and deal with job assessments, hiring, firing and layoffs.
The documents detail practices that appear at odds with how IBM says it treats its employees. In many instances, the practices
in effect, if not intent, tilt against the company's older U.S. workers.
For example, IBM spokespeople and lawyers have said the company never considers a worker's age in making decisions about layoffs
or firings.
But one 2014 document reviewed by ProPublica includes dates of birth. An ex-IBM employee familiar with the process said executives
from one business unit used it to decide about layoffs or other job changes for nearly a thousand workers, almost two-thirds of them
over 50.
Documents from subsequent years show that young workers are protected from cuts for at least a limited period of time. A 2016
slide presentation prepared by the company's global technology services unit, titled "U.S. Resource Action Process" and used to guide
managers in layoff procedures, includes bullets for categories considered "ineligible" for layoff. Among them: "early professional
hires," meaning recent college graduates.
In responding to age-discrimination complaints that ex-employees file with the EEOC, lawyers for IBM say that front-line managers
make all decisions about who gets laid off, and that their decisions are based strictly on skills and job performance, not age.
But ProPublica reviewed spreadsheets that indicate front-line managers hardly acted alone in making layoff calls. Former IBM managers
said the spreadsheets were prepared for upper-level executives and kept continuously updated. They list hundreds of employees together
with codes like "lift and shift," indicating that their jobs were to be lifted from them and shifted overseas, and details such as
whether IBM's clients had approved the change.
An examination of several of the spreadsheets suggests that, whatever the criteria for assembling them, the resulting list of
those marked for layoff was skewed toward older workers. A 2016 spreadsheet listed more than 400 full-time U.S. employees under the
heading "REBAL," which refers to "rebalancing," the process that can lead to laying off workers and either replacing them or shifting
the jobs overseas. Using the job search site LinkedIn, ProPublica was able to locate about 100 of these employees and then obtain
their ages through public records. Ninety percent of those found were 40 or older. Seventy percent were over 50.
IBM frequently cites its history of encouraging diversity in its responses to EEOC complaints about age discrimination. "IBM has
been a leader in taking positive actions to ensure its business opportunities are made available to individuals without regard to
age, race, color, gender, sexual orientation and other categories," a lawyer for the company wrote in a May 2017 letter. "This policy
of non-discrimination is reflected in all IBM business activities."
But ProPublica found at least one company business unit using a point system that disadvantaged older workers. The system awarded
points for attributes valued by the company. The more points a person garnered, according to the former employee, the more protected
she or he was from layoff or other negative job change; the fewer points, the more vulnerable.
The arrangement appears on its face to favor younger newcomers over older veterans. Employees were awarded points for being relatively
new at a job level or in a particular role. Those who worked for IBM for fewer years got more points than those who'd been there
a long time.
The ex-employee familiar with the process said a 2014 spreadsheet from that business unit, labeled "IBM Confidential," was assembled
to assess the job prospects of more than 600 high-level employees, two-thirds of them from the U.S. It included employees' years
of service with IBM, which the former employee said was used internally as a proxy for age. Also listed was an assessment by their
bosses of their career trajectories as measured by the highest job level they were likely to attain if they remained at the company,
as well as their point scores.
The tilt against older workers is evident when employees' years of service are compared with their point scores. Those with no
points and therefore most vulnerable to layoff had worked at IBM an average of more than 30 years; those with a high number of points
averaged half that.
Perhaps even more striking is the comparison between employees' service years and point scores on the one hand and their superiors'
assessments of their career trajectories on the other.
Along with many American employers, IBM has argued it needs to shed older workers because they're no longer at the top of their
games or lack "contemporary" skills.
But among those sized up in the confidential spreadsheet, fully 80 percent of older employees -- those with the most years of
service but no points and therefore most vulnerable to layoff -- were rated by superiors as good enough to stay at their current
job levels or be promoted. By contrast, only a small percentage of younger employees with a high number of points were similarly
rated.
"No major company would use tools to conduct a layoff where a disproportionate share of those let go were African Americans or
women," said Cathy Ventrell-Monsees, senior attorney adviser with the EEOC and former director of age litigation for the senior lobbying
giant AARP. "There's no difference if the tools result in a disproportionate share being older workers."
In addition to the point system that disadvantaged older workers in layoffs, other documents suggest that IBM has made increasingly
aggressive use of its job-rating machinery to pave the way for straight-out firings, or what the company calls "management-initiated
separations." Internal documents suggest that older workers were especially targets.
Like in many companies, IBM employees sit down with their managers at the start of each year and set goals for themselves. IBM
graded on a scale of 1 to 4, with 1 being top-ranked.
Those rated as 3 or 4 were given formal short-term goals known as personal improvement plans, or PIPs. Historically many managers
were lenient, especially toward those with 3s whose ratings had dropped because of forces beyond their control, such as a weakness
in the overall economy, ex-employees said.
But within the past couple of years, IBM appears to have decided the time for leniency was over. For example, a software group
planning document for 2015 said that, over and above layoffs, the unit should seek to fire about 3,000 of the unit's 50,000-plus
workers.
To make such deep cuts, the document said, executives should strike an "aggressive performance management posture." They needed
to double the share of employees given low 3 and 4 ratings to at least 6.6 percent of the division's workforce. And because layoffs
cost the company more than outright dismissals or resignations, the document said, executives should make sure that more than 80
percent of those with low ratings get fired or forced to quit.
Finally, the 2015 document said the division should work "to attract the best and brightest early professionals" to replace up
to two-thirds of those sent packing. A more recent planning document -- the presentation to top executives Gherson and Kavanaugh
for a business unit carved out of the software group -- recommended using similar techniques to free up money by cutting current
employees to fund an "influx" of young workers.
In a recent interview, Poggi said he was resigned to being laid off. "Everybody at IBM has a bullet with their name on it," he
said. Alpern wasn't nearly as accepting of being threatened with a poor job rating and then fired.
Alpern had a particular reason for wanting to stay on at IBM, at least until the end of last year. His younger son, Justin, then
a high school senior, had been named a National Merit semifinalist. Alpern wanted him to be able to apply for one of the company's
Watson scholarships. But IBM had recently narrowed eligibility so only the children of current employees could apply, not also retirees
as it was until 2014.
Alpern had to make it through December for his son to be eligible.
But in August, he said, his manager ordered him to retire. He sought to buy time by appealing to superiors. But he said the manager's
response was to threaten him with a bad job review that, he was told, would land him on a PIP, where his work would be scrutinized
weekly. If he failed to hit his targets -- and his managers would be the judges of that -- he'd be fired and lose his benefits.
Alpern couldn't risk it; he retired on Oct. 31. His son, now a freshman on the dean's list at Texas A&M University, didn't get
to apply.
"I can think of only a couple regrets or disappointments over my 39 years at IBM,"" he said, "and that's one of them."
'Congratulations on Your Retirement!'
Like any company in the U.S., IBM faces few legal constraints to reducing the size of its workforce. And with its no-disclosure
strategy, it eliminated one of the last regular sources of information about its employment practices and the changing size of its
American workforce.
But there remained the question of whether recent cutbacks were big enough to trigger state and federal requirements for disclosure
of layoffs. And internal documents, such as a slide in a 2016 presentation titled "Transforming to Next Generation Digital Talent,"
suggest executives worried that "winning the talent war" for new young workers required IBM to improve the "attractiveness of (its)
culture and work environment," a tall order in the face of layoffs and firings.
So the company apparently has sought to put a softer face on its cutbacks by recasting many as voluntary rather than the result
of decisions by the firm. One way it has done this is by converting many layoffs to retirements.
Some ex-employees told ProPublica that, faced with a layoff notice, they were just as happy to retire. Others said they felt forced
to accept a retirement package and leave. Several actively objected to the company treating their ouster as a retirement. The company
nevertheless processed their exits as such.
Project manager Ed Alpern's departure was treated in company paperwork as a voluntary retirement. He didn't see it that way, because
the alternative he said he was offered was being fired outright.
Lorilynn King, a 55-year-old IT specialist who worked from her home in Loveland, Colorado, had been with IBM almost as long as
Alpern by May 2016 when her manager called to tell her the company was conducting a layoff and her name was on the list.
King said the manager told her to report to a meeting in Building 1 on IBM's Boulder campus the following day. There, she said,
she found herself in a group of other older employees being told by an IBM human resources representative that they'd all be retiring.
"I have NO intention of retiring," she remembers responding. "I'm being laid off."
ProPublica has collected documents from 15 ex-IBM employees who got layoff notices followed by a retirement package and has talked
with many others who said they received similar paperwork. Critics say the sequence doesn't square well with the law.
"This country has banned mandatory retirement," said Seiner, the University of South Carolina law professor and former EEOC appellate
lawyer. "The law says taking a retirement package has to be voluntary. If you tell somebody 'Retire or we'll lay you off or fire
you,' that's not voluntary."
Until recently, the company's retirement paperwork included a letter from Rometty, the CEO, that read, in part, "I wanted to take
this opportunity to wish you well on your retirement While you may be retiring to embark on the next phase of your personal journey,
you will always remain a valued and appreciated member of the IBM family." Ex-employees said IBM stopped sending the letter last
year.
IBM has also embraced another practice that leads workers, especially older ones, to quit on what appears to be a voluntary basis.
It substantially reversed its pioneering support for telecommuting, telling people who've been working from home for years to begin
reporting to certain, often distant, offices. Their other choice: Resign.
David Harlan had worked as an IBM marketing strategist from his home in Moscow, Idaho, for 15 years when a manager told him last
year of orders to reduce the performance ratings of everybody at his pay grade. Then in February last year, when he was 50, came
an internal video from IBM's new senior vice president, Michelle Peluso, which announced plans to improve the work of marketing employees
by ordering them to work "shoulder to shoulder." Those who wanted to stay on would need to "co-locate" to offices in one of six cities.
Early last year, Harlan received an email congratulating him on "the opportunity to join your team in Raleigh, North Carolina."
He had 30 days to decide on the 2,600-mile move. He resigned in June.
David Harlan worked for IBM for 15 years from his home in Moscow, Idaho, where he also runs a drama company. Early last year,
IBM offered him a choice: Move 2,600 miles to Raleigh-Durham to begin working at an office, or resign. He left in June. (Rajah Bose
for ProPublica)
After the Peluso video was leaked to the press, an IBM spokeswoman told the Wall Street Journal that the "
vast
majority " of people ordered to change locations and begin reporting to offices did so. IBM Vice President Ed Barbini said in
an initial email exchange with ProPublica in July that the new policy affected only about 2,000 U.S. employees and that "most" of
those had agreed to move.
But employees across a wide range of company operations, from the systems and technology group to analytics, told ProPublica they've
also been ordered to co-locate in recent years. Many IBMers with long service said that they quit rather than sell their homes, pull
children from school and desert aging parents. IBM declined to say how many older employees were swept up in the co-location initiative.
"They basically knew older employees weren't going to do it," said Eileen Maroney, a 63-year-old IBM product manager from Aiken,
South Carolina, who, like Harlan, was ordered to move to Raleigh or resign. "Older people aren't going to move. It just doesn't make
any sense." Like Harlan, Maroney left IBM last June.
Having people quit rather than being laid off may help IBM avoid disclosing how much it is shrinking its U.S. workforce and where
the reductions are occurring.
Under the federal WARN Act , adopted in the wake
of huge job cuts and factory shutdowns during the 1980s, companies laying off 50 or more employees who constitute at least one-third
of an employer's workforce at a site have to give advance notice of layoffs to the workers, public agencies and local elected officials.
Similar laws in some states where IBM has a substantial presence are even stricter. California, for example, requires advanced
notice for layoffs of 50 or more employees, no matter what the share of the workforce. New York requires notice for 25 employees
who make up a third.
Because the laws were drafted to deal with abrupt job cuts at individual plants, they can miss reductions that occur over long
periods among a workforce like IBM's that was, at least until recently, widely dispersed because of the company's work-from-home
policy.
IBM's training sessions to prepare managers for layoffs suggest the company was aware of WARN thresholds, especially in states
with strict notification laws such as California. A 2016 document entitled "Employee Separation Processing" and labeled "IBM Confidential"
cautions managers about the "unique steps that must be taken when processing separations for California employees."
A ProPublica review of five years of WARN disclosures for a dozen states where the company had large facilities that shed workers
found no disclosures in nine. In the other three, the company alerted authorities of just under 1,000 job cuts -- 380 in California,
369 in New York and 200 in Minnesota. IBM's reported figures are well below the actual number of jobs the company eliminated in these
states, where in recent years it has shuttered, sold off or leveled plants that once employed vast numbers.
By contrast, other employers in the same 12 states reported layoffs last year alone totaling 215,000 people. They ranged from
giant Walmart to Ostrom's Mushroom Farms in Washington state.
Whether IBM operated within the rules of the WARN act, which are notoriously fungible, could not be determined because the company
declined to provide ProPublica with details on its layoffs.
A Second Act, But Poorer
W ith 35 years at IBM under his belt, Ed Miyoshi had plenty of experience being pushed to take buyouts, or early retirement packages,
and refusing them. But he hadn't expected to be pushed last fall.
Miyoshi, of Hopewell Junction, New York, had some years earlier launched a pilot program to improve IBM's technical troubleshooting.
With the blessing of an IBM vice president, he was busily interviewing applicants in India and Brazil to staff teams to roll the
program out to clients worldwide.
The interviews may have been why IBM mistakenly assumed Miyoshi was a manager, and so emailed him to eliminate the one U.S.-based
employee still left in his group.
"That was me," Miyoshi realized.
In his sign-off email to colleagues shortly before Christmas 2016, Miyoshi, then 57, wrote: "I am too young and too poor to stop
working yet, so while this is good-bye to my IBM career, I fully expect to cross paths with some of you very near in the future."
He did, and perhaps sooner than his colleagues had expected; he started as a subcontractor to IBM about two weeks later, on Jan.
3.
Miyoshi is an example of older workers who've lost their regular IBM jobs and been brought back as contractors. Some of them --
not Miyoshi -- became contract workers after IBM told them their skills were out of date and no longer needed.
Employment law experts said that hiring ex-employees as contractors can be legally dicey. It raises the possibility that the layoff
of the employee was not for the stated reason but perhaps because they were targeted for their age, race or gender.
IBM appears to recognize the problem. Ex-employees say the company has repeatedly told managers -- most recently earlier this
year -- not to contract with former employees or sign on with third-party contracting firms staffed by ex-IBMers. But ProPublica
turned up dozens of instances where the company did just that.
Only two weeks after IBM laid him off in December 2016, Ed Miyoshi of Hopewell Junction, New York, started work as a subcontractor
to the company. But he took a $20,000-a-year pay cut. "I'm not a millionaire, so that's a lot of money to me," he says. (Demetrius
Freeman for ProPublica)
Responding to a question in a confidential questionnaire from ProPublica, one 35-year company veteran from New York said he knew
exactly what happened to the job he left behind when he was laid off. "I'M STILL DOING IT. I got a new gig eight days after departure,
working for a third-party company under contract to IBM doing the exact same thing."
In many cases, of course, ex-employees are happy to have another job, even if it is connected with the company that laid them
off.
Henry, the Columbus-based sales and technical specialist who'd been with IBM's "resiliency services" unit, discovered that he'd
lost his regular IBM job because the company had purchased an Indian firm that provided the same services. But after a year out of
work, he wasn't going to turn down the offer of a temporary position as a subcontractor for IBM, relocating data centers. It got
money flowing back into his household and got him back where he liked to be, on the road traveling for business.
The compensation most ex-IBM employees make as contractors isn't comparable. While Henry said he collected the same dollar amount,
it didn't include health insurance, which cost him $1,325 a month. Miyoshi said his paycheck is 20 percent less than what he made
as an IBM regular.
"I took an over $20,000 hit by becoming a contractor. I'm not a millionaire, so that's a lot of money to me," Miyoshi said.
And lower pay isn't the only problem ex-IBM employees-now-subcontractors face. This year, Miyoshi's payable hours have been cut
by an extra 10 "furlough days." Internal documents show that IBM repeatedly furloughs subcontractors without pay, often for two,
three or more weeks a quarter. In some instances, the furloughs occur with little advance notice and at financially difficult moments.
In one document, for example, it appears IBM managers, trying to cope with a cost overrun spotted in mid-November, planned to dump
dozens of subcontractors through the end of the year, the middle of the holiday season.
Former IBM employees now on contract said the company controls costs by notifying contractors in the midst of projects they have
to take pay cuts or lose the work. Miyoshi said that he originally started working for his third-party contracting firm for 10 percent
less than at IBM, but ended up with an additional 10 percent cut in the middle of 2017, when IBM notified the contractor it was slashing
what it would pay.
For many ex-employees, there are few ways out. Henry, for example, sought to improve his chances of landing a new full-time job
by seeking assistance to finish a college degree through a federal program designed to retrain workers hurt by offshoring of jobs.
But when he contacted the Ohio state agency that administers the Trade Adjustment Assistance, or TAA, program, which provides
assistance to workers who lose their jobs for trade-related reasons, he was told IBM hadn't submitted necessary paperwork. State
officials said Henry could apply if he could find other IBM employees who were laid off with him, information that the company doesn't
provide.
TAA is overseen by the Labor Department but is operated by states under individual agreements with Washington, so the rules can
vary from state to state. But generally employers, unions, state agencies and groups of employers can petition for training help
and cash assistance. Labor Department data compiled by the advocacy group Global Trade Watch shows that employers apply in about
40 percent of cases. Some groups of IBM workers have obtained retraining funds when they or their state have applied, but records
dating back to the early 1990s show IBM itself has applied for and won taxpayer assistance only once, in 2008, for three Chicago-area
workers whose jobs were being moved to India.
Teasing New Jobs
A s IBM eliminated thousands of jobs in 2016, David Carroll, a 52-year-old Austin software engineer, thought he was safe.
His job was in mobile development, the "M" in the company's CAMS strategy. And if that didn't protect him, he figured he was only
four months shy of qualifying for a program that gives employees who leave within a year of their three-decade mark access to retiree
medical coverage and other benefits.
But the layoff notice Carroll received March 2 gave him three months -- not four -- to come up with another job. Having been a
manager, he said he knew the gantlet he'd have to run to land a new position inside IBM.
Still, he went at it hard, applying for more than 50 IBM jobs, including one for a job he'd successfully done only a few years
earlier. For his effort, he got one offer -- the week after he'd been forced to depart. He got severance pay but lost access to what
would have been more generous benefits.
Edward Kishkill, then 60, of Hillsdale, New Jersey, had made a similar calculation.
A senior systems engineer, Kishkill recognized the danger of layoffs, but assumed he was immune because he was working in systems
security, the "S" in CAMS and another hot area at the company.
The precaution did him no more good than it had Carroll. Kishkill received a layoff notice the same day, along with 17 of the
22 people on his systems security team, including Diane Moos. The notice said that Kishkill could look for other jobs internally.
But if he hadn't landed anything by the end of May, he was out.
With a daughter who was a senior in high school headed to Boston University, he scrambled to apply, but came up dry. His last
day was May 31, 2016.
For many, the fruitless search for jobs within IBM is the last straw, a final break with the values the company still says it
embraces. Combined with the company's increasingly frequent request that departing employees train their overseas replacements, it
has left many people bitter. Scores of ex-employees interviewed by ProPublica said that managers with job openings told them they
weren't allowed to hire from layoff lists without getting prior, high-level clearance, something that's almost never given.
ProPublica reviewed documents that show that a substantial share of recent IBM layoffs have involved what the company calls "lift
and shift," lifting the work of specific U.S. employees and shifting it to specific workers in countries such as India and Brazil.
For example, a document summarizing U.S. employment in part of the company's global technology services division for 2015 lists nearly
a thousand people as layoff candidates, with the jobs of almost half coded for lift and shift.
Ex-employees interviewed by ProPublica said the lift-and-shift process required their extensive involvement. For example, shortly
after being notified she'd be laid off, Kishkill's colleague, Moos, was told to help prepare a "knowledge transfer" document and
begin a round of conference calls and email exchanges with two Indian IBM employees who'd be taking over her work. Moos said the
interactions consumed much of her last three months at IBM.
Next Chapters
W hile IBM has managed to keep the scale and nature of its recent U.S. employment cuts largely under the public's radar, the company
drew some unwanted attention during the 2016 presidential campaign, when then-candidate
Donald Trump lambasted it for eliminating 500 jobs in Minnesota, where the company has had a presence for a half century, and
shifting the work abroad.
The company also has caught flak -- in places like
Buffalo, New
York ;
Dubuque, Iowa ; Columbia,
Missouri , and
Baton Rouge, Louisiana -- for promising jobs in return for state and local incentives, then failing to deliver. In all, according
to public officials in those and other places, IBM promised to bring on 3,400 workers in exchange for as much as $250 million in
taxpayer financing but has hired only about half as many.
After Trump's victory, Rometty, in a move at least partly aimed at courting the president-elect, pledged to hire 25,000 new U.S.
employees by 2020. Spokesmen said the hiring would increase IBM's U.S. employment total, although, given its continuing job cuts,
the addition is unlikely to approach the promised hiring total.
When The New York Times ran a story last fall saying IBM now has
more employees in India than the U.S.,
Barbini, the corporate spokesman, rushed to declare, "The U.S. has always been and remains IBM's center of gravity." But his stream
of accompanying tweets and graphics focused
as much on the company's record for racking up patents as hiring people.
IBM has long been aware of the damage its job cuts can do to people. In a series of internal training documents to prepare managers
for layoffs in recent years, the company has included this warning: "Loss of a job often triggers a grief reaction similar to what
occurs after a death."
Most, though not all, of the ex-IBM employees with whom ProPublica spoke have weathered the loss and re-invented themselves.
Marjorie Madfis, the digital marketing strategist, couldn't land another tech job after her 2013 layoff, so she headed in a different
direction. She started a nonprofit called Yes She Can Inc. that provides job skills development for young autistic women, including
her 21-year-old daughter.
After almost two years of looking and desperate for useful work, Brian Paulson, the widely traveled IBM senior manager, applied
for and landed a position as a part-time rural letter carrier in Plano, Texas. He now works as a contract project manager for a Las
Vegas gaming and lottery firm.
Ed Alpern, who started at IBM as a Selectric typewriter repairman, watched his son go on to become a National Merit Scholar at
Texas A&M University, but not a Watson scholarship recipient.
Lori King, the IT specialist and 33-year IBM veteran who's now 56, got in a parting shot. She added an addendum to the retirement
papers the firm gave her that read in part: "It was never my plan to retire earlier than at least age 60 and I am not committing
to retire. I have been informed that I am impacted by a resource action effective on 2016-08-22, which is my last day at IBM, but
I am NOT retiring."
King has aced more than a year of government-funded coding boot camps and university computer courses, but has yet to land a new
job.
David Harlan still lives in Moscow, Idaho, after refusing IBM's "invitation" to move to North Carolina, and is artistic director
of the Moscow Art Theatre (Too).
Ed Miyoshi is still a technical troubleshooter working as a subcontractor for IBM.
Ed Kishkill, the senior systems engineer, works part time at a local tech startup, but pays his bills as an associate at a suburban
New Jersey Staples store.
This year, Paul Henry was back on the road, working as an IBM subcontractor in Detroit, about 200 miles from where he lived in
Columbus. On Jan. 8, he put in a 14-hour day and said he planned to call home before turning in. He died in his sleep.
Correction, March 24, 2018: Eileen Maroney lives in Aiken, South Carolina. The name of her city was incorrect in the original
version of this story.
Do you have information about age discrimination at IBM?
Peter Gosselin joined ProPublica as a contributing
reporter in January 2017 to cover aging. He has covered the U.S. and global economies for, among others, the Los Angeles Times and
The Boston Globe, focusing on the lived experiences of working people. He is the author of "High Wire: The Precarious Financial Lives
of American Families."
Ariana Tobin is an engagement reporter at ProPublica,
where she works to cultivate communities to inform our coverage. She was previously at The Guardian and WNYC. Ariana has also worked
as digital producer for APM's Marketplace and contributed
to outlets including The
New Republic , On Being , the
St. Louis
Beacon and Bustle .
There's not a word of truth quoted in this article. That is, quoted from IBM spokespeople. It's the culture there now. They don't
even realize that most of their customers have become deaf to the same crap from their Sales and Marketing BS, which is even worse
than their HR speak.
The sad truth is that IBM became incapable of taking its innovation (IBM is indeed a world beating, patent generating machine)
to market a long time ago. It has also lost the ability (if it ever really had it) to acquire other companies and foster their
innovation either - they ran most into the ground. As a result, for nearly a decade revenues have declined and resource actions
grown. The resource actions may seem to be the ugly problem, but they're only the symptom of a fat greedy and pompous bureaucracy
that's lost its ability to grow and stay relevant in a very competitive and changing industry. What they have been able to perfect
and grow is their ability to downsize and return savings as dividends (Big Sam Palmisano's "innovation"). Oh, and for senior management
to line their pockets.
Nothing IBM is currently doing is sustainable.
If you're still employed there, listen to the pain in the words of your fallen comrades and don't knock yourself out trying
to stay afloat. Perhaps learn some BS of your own and milk your job (career? not...) until you find freedom and better pastures.
If you own stock, do like Warren Buffett, and sell it while it still has some value.
This is NOTHING NEW! All major corporations have and will do this at some point in their existence. Another industry that does
this regularly every 3 to 5 years is the pharamaceutical industry. They'll decimate their sales forces in order to, as they like
to put it, "right size" the company.
They'll cloak it as weeding out the low performers, but they'll try to catch the "older" workers in the net as well.
"... I took an early retirement package when IBM first started downsizing. I had 30 years with them, but I could see the writing on the wall so I got out. I landed an exec job with a biotech company some years later and inherited an IBM consulting team that were already engaged. I reviewed their work for 2 months then had the pleasure of terminating the contract and actually escorting the team off the premises because the work product was so awful. ..."
"... Every former or prospective IBM employee is a potential future IBM customer or partner. How you treat them matters! ..."
"... I advise IBM customers now. My biggest professional achievements can be measured in how much revenue IBM lost by my involvement - millions. Favorite is when IBM paid customer to stop the bleeding. ..."
I took an early retirement package when IBM first started downsizing. I had 30 years
with them, but I could see the writing on the wall so I got out. I landed an exec job with a
biotech company some years later and inherited an IBM consulting team that were already
engaged. I reviewed their work for 2 months then had the pleasure of terminating the contract
and actually escorting the team off the premises because the work product was so
awful.
They actually did a presentation of their interim results - but it was a 52 slide package
that they had presented to me in my previous job but with the names and numbers changed.
see more
Intellectual Capital Re-Use! LOL! Not many people realize in IBM that many, if not all of the
original IBM Consulting Group materials were made under the Type 2 Materials clause of the
IBM Contract, which means the customers actually owned the IP rights of the documents. Can
you imagine the mess if just one customer demands to get paid for every re-use of the IP that
was developed for them and then re-used over and over again?
Beautiful! Yea, these companies so fast to push experienced people who have dedicated their
lives to the firm - how can you not...all the hours and commitment it takes - way
underestimate the power of the network of those left for dead and their influence in that
next career gig. Memories are long...very long when it comes to experiences like this.
I advise IBM customers now. My biggest professional achievements can be measured in how
much revenue IBM lost by my involvement - millions. Favorite is when IBM paid customer to
stop the bleeding.
"... As long as companies pay for their employees' health insurance they will have an incentive to fire older employees. ..."
"... The answer is to separate health insurance from employment. Companies can't be trusted. Not only health care, but retirement is also sorely abused by corporations. All the money should be in protected employee based accounts. ..."
American companies pay health insurance premiums based on their specific employee profiles. Insurance companies compete with each
other for the business, but costs are actual. And based on the profile of the pool of employees. So American companies fire older
workers just to lower the average age of their employees. Statistically this is going to lower their health care costs.
As long as companies pay for their employees' health insurance they will have an incentive to fire older employees.
They have an incentive to fire sick employees and employees with genetic risks. Those are harder to implement as ways to
lower costs. Firing older employees is simple to do, just look up their ages.
The answer is to separate health insurance from employment. Companies can't be trusted. Not only health care, but retirement
is also sorely abused by corporations. All the money should be in protected employee based accounts.
By the way, most tech companies are actually run by older people. The goal is to broom out mid-level people based on age. Nobody
is going to suggest to a sixty year old president that they should self fire, for the good of the company.
"... It's no coincidence whatsoever that Diane Gherson, mentioned prominently in the article, blasted out an all-employees email crowing about IBM being a great place to work according to (ahem) LinkedIn. I desperately want to post a link to this piece in the corporate Slack, but that would get me fired immediately instead of in a few months at the next "resource action." It's been a whole 11 months since our division had one, so I know one is coming soon. ..."
"... I used to say when I was there that: "After every defeat, they pin medals on the generals and shoot the soldiers". ..."
"... 1990 is also when H-1B visa rules were changed so that companies no longer had to even attempt to hire an American worker as long as the job paid $60,000, which hasn't changed since. This article doesn't even mention how our work visa system facilitated and even rewarded this abuse of Americans. ..."
"... Well, starting in the 1980s, the American management was allowed by Reagan to get rid of its workforce. ..."
"... It's all about making the numbers so the management can present a Potemkin Village of profits and ever-increasing growth sufficient to get bonuses. There is no relation to any sort of quality or technological advancement, just HR 3-card monte. They have installed air bearing in Old Man Watson's coffin as it has been spinning ever faster ..."
"... Corporate America executive management is all about stock price management. Their bonus's in the millions of dollars are based on stock performance. With IBM's poor revenue performance since Ginny took over, profits can only be maintained by cost reduction. Look at the IBM executive's bonus's throughout the last 20 years and you can see that all resource actions have been driven by Palmisano's and Rominetty's greed for extravagant bonus's. ..."
"... Also worth noting is that IBM drastically cut the cap on it's severance pay calculation. Almost enough to make me regret not having retired before that changed. ..."
"... Yeah, severance started out at 2 yrs pay, went to 1 yr, then to 6 mos. and is now 1 month. ..."
"... You need to investigate AT&T as well, as they did the same thing. I was 'sold' by IBM to AT&T as part of he Network Services operation. AT&T got rid of 4000 of the 8000 US employees sent to AT&T within 3 years. Nearly everyone of us was a 'senior' employee. ..."
dragonflap• 7
months ago I'm a 49-year-old SW engineer who started at IBM as part of an acquisition in 2000. I got laid off in 2002 when IBM
started sending reqs to Bangalore in batches of thousands. After various adventures, I rejoined IBM in 2015 as part of the "C" organization
referenced in the article.
It's no coincidence whatsoever that Diane Gherson, mentioned prominently in the article, blasted out an all-employees email
crowing about IBM being a great place to work according to (ahem) LinkedIn. I desperately want to post a link to this piece in the
corporate Slack, but that would get me fired immediately instead of in a few months at the next "resource action." It's been a whole
11 months since our division had one, so I know one is coming soon.
The lead-in to this piece makes it sound like IBM was forced into these practices by inescapable forces. I'd say not, rather
that it pursued them because a) the management was clueless about how to lead IBM in the new environment and new challenges so
b) it started to play with numbers to keep the (apparent) profits up....to keep the bonuses coming. I used to say when I was
there that: "After every defeat, they pin medals on the generals and shoot the soldiers".
And then there's the Pig with the Wooden Leg shaggy dog story that ends with the punch line, "A pig like that you don't eat
all at once", which has a lot of the flavor of how many of us saw our jobs as IBM die a slow death.
IBM is about to fall out of the sky, much as General Motors did. How could that happen? By endlessly beating the cow to get
more milk.
IBM was hiring right through the Great Depression such that It Did Not Pay Unemployment Insurance. Because it never laid people
off, Because until about 1990, your manager was responsible for making sure you had everything you needed to excel and grow....and
you would find people that had started on the loading dock and had become Senior Programmers. But then about 1990, IBM starting
paying unemployment insurance....just out of the goodness of its heart. Right.
1990 is also when H-1B visa rules were changed so that companies no longer had to even attempt to hire an American worker
as long as the job paid $60,000, which hasn't changed since. This article doesn't even mention how our work visa system facilitated
and even rewarded this abuse of Americans.
I found that other Ex-IBMer's respect other Ex-IBMer's work ethics, knowledge and initiative.
Other companies are happy to get them as a valueable resource. In '89 when our Palo Alto Datacenter moved, we were given two
options: 1.) to become a Programmer (w/training) 2.) move to Boulder or 3.) to leave.
I got my training with programming experience and left IBM in '92, when for 4 yrs IBM offerred really good incentives for leaving
the company. The Executives thought that the IBM Mainframe/MVS z/OS+ was on the way out and the Laptop (Small but Increasing Capacity)
Computer would take over everything.
It didn't. It did allow many skilled IBMers to succeed outside of IBM and help built up our customer skill sets. And like many,
when the opportunity arose to return I did. In '91 I was accidentally given a male co-workers paycheck and that was one of the
reasons for leaving. During my various Contract work outside, I bumped into other male IBMer's that had left too, some I had trained,
and when they disclosed that it was their salary (which was 20-40%) higher than mine was the reason they left, I knew I had made
the right decision.
Women tend to under-value themselves and their capabilities. Contracting also taught me that companies that had 70% employees
and 30% contractors, meant that contractors would be let go if they exceeded their quarterly expenditures.
I first contracted with IBM in '98 and when I decided to re-join IBM '01, I had (3) job offers and I took the most lucrative
exciting one to focus on fixing & improving DB2z Qry Parallelism. I developed a targeted L3 Technical Change Team to help L2 Support
reduce Customer problems reported and improve our product. The instability within IBM remained and I saw IBM try to eliminate
aging, salaried, benefited employees. The 1.) find a job within IBM ... to 2.) to leave ... was now standard.
While my salary had more than doubled since I left IBM the first time, it still wasn't near other male counterparts. The continual
rating competition based on salary ranged titles and timing a title raise after a round of layoffs, not before. I had another
advantage going and that was that my changed reduced retirement benefits helped me stay there. It all comes down to the numbers
that Mgmt is told to cut & save IBM. While much of this article implies others were hired, at our Silicon Valley Location and
other locations, they had no intent to backfill. So the already burdened employees were laden with more workloads & stress.
In the early to mid 2000's IBM setup a counter lab in China where they were paying 1/4th U.S. salaries and many SVL IBMers
went to CSDL to train our new world 24x7 support employees. But many were not IBM loyal and their attrition rates were very high,
so it fell to a wave of new-hires at SVL to help address it.
It's all about making the numbers so the management can present a Potemkin Village of profits and ever-increasing growth
sufficient to get bonuses. There is no relation to any sort of quality or technological advancement, just HR 3-card monte. They
have installed air bearing in Old Man Watson's coffin as it has been spinning ever faster
Corporate America executive management is all about stock price management. Their bonus's in the millions of dollars are
based on stock performance. With IBM's poor revenue performance since Ginny took over, profits can only be maintained by cost
reduction. Look at the IBM executive's bonus's throughout the last 20 years and you can see that all resource actions have been
driven by Palmisano's and Rominetty's greed for extravagant bonus's.
Bravo ProPublica for another "sock it to them" article - journalism in honor of the spirit of great newspapers everywhere that
the refuge of justice in hard times is with the press.
Also worth noting is that IBM drastically cut the cap on it's severance pay calculation. Almost enough to make me regret
not having retired before that changed.
You need to investigate AT&T as well, as they did the same thing. I was 'sold' by IBM to AT&T as part of he Network Services
operation. AT&T got rid of 4000 of the 8000 US employees sent to AT&T within 3 years. Nearly everyone of us was a 'senior' employee.
As a permanent old contractor and free-enterprise defender myself, I don't blame IBM a bit for wanting to cut the fat. But
for the outright *lies, deception and fraud* that they use to break laws, weasel out of obligations... really just makes me want
to shoot them... and I never even worked for them.
Where I worked, In Rochester,MN, people have known what is happening for years. My last years with IBM were the most depressing
time in my life.
I hear a rumor that IBM would love to close plants they no longer use but they are so environmentally polluted that it is cheaper
to maintain than to clean up and sell.
One of the biggest driving factors in age discrimination is health insurance costs, not salary. It can cost 4-5x as much to
insure and older employee vs. a younger one, and employers know this. THE #1 THING WE CAN DO TO STOP AGE DISCRIMINATION IS TO
MOVE AWAY FROM OUR EMPLOYER-PROVIDED INSURANCE SYSTEM. It could be single-payer, but it could also be a robust individual market
with enough pool diversification to make it viable. Freeing employers from this cost burden would allow them to pick the right
talent regardless of age.
The American business have constantly fought against single payer since the end of World War II and why should I feel sorry
for them when all of a sudden, they are complaining about health care costs? It is outrageous that workers have to face age discrimination;
however, the CEOs don't have to deal with that issue since they belong to a tiny group of people who can land a job anywhere else.
Single payer won't help. We have single payer in Canada and just as much age discrimination in employment. Society in general
does not like older people so unless you're a doctor, judge or pharmacist you will face age bias. It's even worse in popular culture
never mind in employment.
Thanks for the great article. I left IBM last year. USA based. 49. Product Manager in one of IBMs strategic initiatives, however
got told to relocate or leave. I found another job and left. I came to IBM from an acquisition. My only regret is, I wish I had
left this toxic environment earlier. It truely is a dreadful place to work.
The methodology has trickled down to smaller companies pursuing the same net results for headcount reduction. The similarities
to my experience were painful to read. The grief I felt after my job was "eliminated" 10 years ago while the Recession was at
its worst and shortly after my 50th birthday was coming back. I never have recovered financially but have started writing a murder
mystery. The first victim? The CEO who let me go. It's true. Revenge is best served cold.
Well written . people like me have experienced exactly what you wrote. IBM is a shadow of it's former greatness and I have
advised my children to stay away from IBM and companies like it as they start their careers. IBM is a corrupt company. Shame on
them !
I suspect someone will end up hunt them down with an axe at some point. That's the only way they'll probably learn. I don't
know about IBM specifically, but when Carly Fiorina ran HP, she travelled with and even went into engineering labs with an armed
security detail.
Was let go after 34 years of service. Mine Resource Action latter had additional lines after '...unless you are offered ...
position within IBM before that date.' , implying don't even try to look for a position. They lines were ' Additional business
controls are in effect to manage the business objectives of this resource action, therefore, job offers within (the name of division)
will be highly unlikely.'.
I've worked for a series of vendors for over thirty years. A job at IBM used to be the brass ring; nowadays, not so much.
I've heard persistent rumors from IBMers that U.S. headcount is below 25,000 nowadays. Given events like the recent downtime
of the internal systems used to order parts (5 or so days--website down because staff who maintained it were let go without replacements),
it's hard not to see the spiral continue down the drain.
What I can't figure out is whether Rometty and cronies know what they're doing or are just clueless. Either way, the result
is the same: destruction of a once-great company and brand. Tragic.
Well, none of these layoffs/ageist RIFs affect the execs, so they don't see the effects, or they see the effects but attribute
them to some other cause.
(I'm surprised the article doesn't address this part of the story; how many affected by layoffs are exec/senior management?
My bet is very few.)
I was a D-banded exec (Director-level) who was impacted and I know even some VPs who were affected as well, so they do spread
the pain, even in the exec ranks.
That's different than I have seen in companies I have worked for (like HP). There RIFs (Reduction In Force, their acronym for
layoff) went to the director level and no further up.
F or nearly a half century, IBM came as close as any company to bearing the torch for the American Dream.
As the world's dominant technology firm, payrolls at International Business Machines Corp. swelled to nearly a quarter-million
U.S. white-collar workers in the 1980s. Its profits helped underwrite a broad agenda of racial equality, equal pay for women and
an unbeatable offer of great wages and something close to lifetime employment, all in return for unswerving loyalty.
But when high tech suddenly started shifting and companies went global, IBM faced the changing landscape with a distinction most
of its fiercest competitors didn't have: a large number of experienced and aging U.S. employees.
The company reacted with a strategy that, in the words of one confidential planning document, would "correct seniority mix." It
slashed IBM's U.S. workforce by as much as three-quarters from its 1980s peak, replacing a substantial share with younger, less-experienced
and lower-paid workers and sending many positions overseas. ProPublica estimates that in the past five years alone, IBM has eliminated
more than 20,000 American employees ages 40 and over, about 60 percent of its estimated total U.S. job cuts during those years.
In making these cuts, IBM has flouted or outflanked U.S. laws and regulations intended to protect later-career workers from age
discrimination, according to a ProPublica review of internal company documents, legal filings and public records, as well as information
provided via interviews and questionnaires filled out by more than 1,000 former IBM employees.
Among ProPublica's findings, IBM:
Denied older workers information the law says they need in order to decide whether they've been victims of age bias, and required
them to sign away the right to go to court or join with others to seek redress. Targeted people for layoffs and firings with techniques
that tilted against older workers, even when the company rated them high performers. In some instances, the money saved from the
departures went toward hiring young replacements. Converted job cuts into retirements and took steps to boost resignations and firings.
The moves reduced the number of employees counted as layoffs, where high numbers can trigger public disclosure requirements. Encouraged
employees targeted for layoff to apply for other IBM positions, while quietly advising managers not to hire them and requiring many
of the workers to train their replacements. Told some older employees being laid off that their skills were out of date, but then
brought them back as contract workers, often for the same work at lower pay and fewer benefits.
IBM declined requests for the numbers or age breakdown of its job cuts. ProPublica provided the company with a 10-page summary
of its findings and the evidence on which they were based. IBM spokesman Edward Barbini said that to respond the company needed to
see copies of all documents cited in the story, a request ProPublica could not fulfill without breaking faith with its sources. Instead,
ProPublica provided IBM with detailed descriptions of the paperwork. Barbini declined to address the documents or answer specific
questions about the firm's policies and practices, and instead issued the following statement:
"We are proud of our company and our employees' ability to reinvent themselves era after era, while always complying with the
law. Our ability to do this is why we are the only tech company that has not only survived but thrived for more than 100 years."
With nearly 400,000 people worldwide, and tens of thousands still in the U.S., IBM remains a corporate giant. How it handles the
shift from its veteran baby-boom workforce to younger generations will likely influence what other employers do. And the way it treats
its experienced workers will eventually affect younger IBM employees as they too age.
Fifty years ago, Congress made it illegal with the Age Discrimination
in Employment Act , or ADEA, to treat older workers differently than younger ones with only a few exceptions, such as jobs that
require special physical qualifications. And for years, judges and policymakers treated the law as essentially on a par with prohibitions
against discrimination on the basis of race, gender, sexual orientation and other categories.
In recent decades, however, the courts have responded to corporate pleas for greater leeway to meet global competition and satisfy
investor demands for rising profits by expanding the exceptions and
shrinking
the protections against age bias .
"Age discrimination is an open secret like sexual harassment was until recently," said Victoria Lipnic, the acting chair of the
Equal Employment Opportunity Commission, or EEOC, the independent federal agency that administers the nation's workplace anti-discrimination
laws.
"Everybody knows it's happening, but often these cases are difficult to prove" because courts have weakened the law, Lipnic said.
"The fact remains it's an unfair and illegal way to treat people that can be economically devastating."
Many companies have sought to take advantage of the court rulings. But the story of IBM's downsizing provides an unusually detailed
portrait of how a major American corporation systematically identified employees to coax or force out of work in their 40s, 50s and
60s, a time when many are still productive and need a paycheck, but face huge hurdles finding anything like comparable jobs.
The dislocation caused by IBM's cuts has been especially great because until recently the company encouraged its employees to
think of themselves as "IBMers" and many operated under the assumption that they had career-long employment.
When the ax suddenly fell, IBM provided almost no information about why an employee was cut or who else was departing, leaving
people to piece together what had happened through websites, listservs and Facebook groups such as "Watching IBM" or "Geographically
Undesirable IBM Marketers," as well as informal support groups.
Marjorie Madfis, at the time 57, was a New York-based digital marketing strategist and 17-year IBM employee when she and six other
members of her nine-person team -- all women in their 40s and 50s -- were laid off in July 2013. The two who remained were younger
men.
Since her specialty was one that IBM had said it was expanding, she asked for a written explanation of why she was let go. The
company declined to provide it.
"They got rid of a group of highly skilled, highly effective, highly respected women, including me, for a reason nobody knows,"
Madfis said in an interview. "The only explanation is our age."
Brian Paulson, also 57, a senior manager with 18 years at IBM, had been on the road for more than a year overseeing hundreds of
workers across two continents as well as hitting his sales targets for new services, when he got a phone call in October 2015 telling
him he was out. He said the caller, an executive who was not among his immediate managers, cited "performance" as the reason, but
refused to explain what specific aspects of his work might have fallen short.
It took Paulson two years to land another job, even though he was equipped with an advanced degree, continuously employed at high-level
technical jobs for more than three decades and ready to move anywhere from his Fairview, Texas, home.
"It's tough when you've worked your whole life," he said. "The company doesn't tell you anything. And once you get to a certain
age, you don't hear a word from the places you apply."
Paul Henry, a 61-year-old IBM sales and technical specialist who loved being on the road, had just returned to his Columbus home
from a business trip in August 2016 when he learned he'd been let go. When he asked why, he said an executive told him to "keep your
mouth shut and go quietly."
Henry was jobless more than a year, ran through much of his savings to cover the mortgage and health insurance and applied for
more than 150 jobs before he found a temporary slot.
"If you're over 55, forget about preparing for retirement," he said in an interview. "You have to prepare for losing your job
and burning through every cent you've saved just to get to retirement."
IBM's latest actions aren't anything like what most ex-employees with whom ProPublica talked expected from their years of service,
or what today's young workers think awaits them -- or are prepared to deal with -- later in their careers.
"In a fast-moving economy, employers are always going to be tempted to replace older workers with younger ones, more expensive
workers with cheaper ones, those who've performed steadily with ones who seem to be up on the latest thing," said Joseph Seiner,
an employment law professor at the University of South Carolina and former appellate attorney for the EEOC.
"But it's not good for society," he added. "We have rules to try to maintain some fairness in our lives, our age-discrimination
laws among them. You can't just disregard them."
Fedora is fully owned by Red Hat and CentOS requires the availability of the Red Hat
repositories which they aren't obliged to make public to non-customers..
Fedora is fully under Red Hat's control. It's used as a bleeding edge distro for hobbyists
and as a testing ground for code before it goes into RHEL. I doubt its going away since it
does a great job of establishing mindshare but no business in their right mind is going to
run Fedora in production.
But CentOS started as a separate organization with a fairly adversarial relationship to
Red Hat since it really is free RHEL which cuts into their actual customer base. They didn't
need Red Hat repos back then, just the code which they rebuilt from scratch (which is why
they were often a few months behind).
If IBM kills CentOS a new one will pop up in a week, that's the beauty of the GPL.
Perhaps someone can explain this... Red Hat's revenue and assets barely total about $5B. Even
factoring in market share and capitalization, how the hey did IBM come up with $34B cash
being a justifiable purchase price??
Honestly, why would Red Hat have said no? 1648 posts | registered 4/3/2012
IBM has been fumbling around for a while. They didn't know how to sell Watson as they
sold it like a weird magical drop in service and it failed repeatedly, where really it
should be a long term project that you bring customer's along for the ride...
I had a buddy using their cloud service and they went to spin up servers and IBM was all
"no man we have to set them up first".... like that's not cloud IBM...
If IBM can't figure out how to sell its own services I'm not sure the powers that be are
capable of getting the job done ever. IBM's own leadership seems incompatible with the
state of the world.
IBM basically bought a ton of service contracts for companies all over the world. This is
exactly what the suits want: reliable cash streams without a lot of that pesky development
stuff.
IMHO this is perilous for RHEL. It would be very easy for IBM to fire most of the
developers and just latch on to the enterprise services stuff to milk it till its dry.
I can only see this as a net positive - the ability to scale legacy mainframes onto "Linux"
and push for even more security auditing.
I would imagine the RHEL team will get better funding but I would be worried if you're a
centos or fedora user.
I'm nearly certain that IBM's management ineptitude will kill off Fedora and CentOS (or at
least severely gimp them compared to how they currently are), not realizing how massively
important both of these projects are to the core RHEL product. We'll see RHEL itself suffer
as a result.
I normally try to understand things with an open mindset, but in this case, IBM has had
too long of a history of doing things wrong for me to trust them. I'll be watching this
carefully and am already prepping to move off of my own RHEL servers once the support
contract expires in a couple years just in case it's needed.
My previous job (6+ years ago now) was at a university that was rather heavily invested in
IBM for a high performance research cluster. It was something around 100 or so of their
X-series blade servers, all of which were running Red Hat Linux. It wouldn't surprise me if
they decided to acquire Red Hat in large part because of all these sorts of IBM systems that
run Red Hat on them.
blockquote> Will IBM even know what to do with them?
My previous job (6+ years ago now) was at a university that was rather heavily invested in
IBM for a high performance research cluster. It was something around 100 or so of their
X-series blade servers, all of which were running Red Hat Linux. It wouldn't surprise me if
they decided to acquire Red Hat in large part because of all these sorts of IBM systems that
run Red Hat on them.
That was my thought. IBM wants to own an operating system again. With AIX being relegated
to obscurity, buying Red Hat is simpler than creating their own Linux fork.
Valuing Red Hat at $34 billion means valuing it at more than 1/4 of IBMs current market cap.
From my perspective this tells me IBM is in even worse shape than has been reported.
"... Adjusting for inflation, I make $6K less than I did my first day. My group is a handful of people as at least 1/2 have quit or retired. To support our customers, we used to have several people, now we have one or two and if someone is sick or on vacation, our support structure is to hope nothing breaks. ..."
I've worked there 17 years and have worried about being layed off for about 11 of them. Moral is in the toilet. Bonuses for the
rank and file are in the under 1% range while the CEO gets millions. Pay raises have been non existent or well under inflation
for years.
Adjusting for inflation, I make $6K less than I did my first day. My group is a handful of people as at least 1/2 have
quit or retired. To support our customers, we used to have several people, now we have one or two and if someone is sick or on
vacation, our support structure is to hope nothing breaks.
We can't keep millennials because of pay, benefits and the expectation of being available 24/7 because we're shorthanded. As
the unemployment rate drops, more leave to find a different job, leaving the old people as they are less willing to start over
with pay, vacation, moving, selling a house, pulling kids from school, etc.
The younger people are generally less likely to be willing to work as needed on off hours or to pull work from a busier colleague.
I honestly have no idea what the plan is when the people who know what they are doing start to retire, we are way top heavy
with 30-40 year guys who are on their way out, very few of the 10-20 year guys due to hiring freezes and we can't keep new people
past 2-3 years. It's like our support business model is designed to fail.
Maybe we get really lucky and they RIF Lennart Poettering or he quits? I hear IBM doesn't
tolerate prima donnas and cults of personality quite as much as RH?
IBM already had access to Red Hat's patents, including for patent defence purposes. Look
up "open innovation network".
This acquisition is about: (1) IBM needing growth, or at least a plausible scenario for
growth. (2) Red Hat wanting an easy expansion of its sales channels, again for growth. (3)
Red Hat stockholders being given an offer they can't refuse.
This acquisition is not about: cultural change at IBM. Which is why the acquisition will
'fail'. The bottom line is that engineering matters at the moment (see: Google, Amazon), and
IBM sacked their engineering culture across the past two decades. To be successful IBM need
to get that culture back, and acquiring Red Hat gives IBM the opportunity to create a
product-building, client-service culture within IBM. Except that IBM aren't taking the
opportunity, so there's a large risk the reverse will happen -- the acquisition will destroy
Red Hat's engineering- and service-oriented culture.
This could be interesting: will the systemd kraken manage to wrap its tentacles around the
big blue container ship and bring it to a halt, or will the container ship turn out to be
well armed and fatally harpoon the kraken (causing much rejoicing in the rest of the Linux
world)?
you can change the past so that a "proper replacement" isn't automatically expected to do
lots of things that systemd does. That damage is done. We got "better is worse" and enough
people liked it-- good luck trying to go back to "worse is better"
I presume they were waiting to see what happened to Solaris. When Oracle bought Sun
(presumably the only other company who might have bought them was IBM) there were really
three enterprise unixoid platforms: Solaris, AIX and RHEL (there were some smaller ones and
some which were clearly dying like HPUX). It seemed likely at the time, but not yet certain,
that Solaris was going to die (I worked for Sun at the time this happened and that was my
opinion anyway). If Solaris did die, then if one company owned both AIX and RHEL then that
company would own the enterprise unixoid market. If Solaris didn't die on the other
hand then RHEL would be a lot less valuable to IBM as there would be meaningful competition.
So, obviously, they waited to see what would happen.
Well, Solaris is perhaps not technically quite dead yet but certainly is moribund, and IBM
now owns both AIX and RHEL & hence the enterprise unixoid market. As an interesting
side-note, unless Oracle can keep Solaris on life-support this means that IBM own all-but own
Oracle's OS as well ('Oracle Linux' is RHEL with, optionally, some of their own additions to
the kernel).
"... "It's a desperate deal by a company that missed the boat for the last five years," the managing director at BTIG said on " Closing Bell ." "I'm not surprised that they bought Red Hat , I'm surprised that it took them so long. They've been behind the cloud eight ball." ..."
IBM's $34 billion acquisition of Red Hat is a last-ditch effort by IBM to play catch-up
in the cloud industry, says BTIG's Joel Fishbein.
"It's a desperate deal by a company that missed the boat for the last five years,"
Fishbein says.
The software maker will become a unit of IBM's Hybrid Cloud division, bringing it one
step closer to becoming "relevant again in the space," Fishbein says.
IBM's
$34 billion acquisition of Red Hat is a last-ditch effort by IBM to play catch-up in the cloud industry,
analyst Joel Fishbein told CNBC on Monday.
"It's a desperate deal by a company that missed the boat for the last five years," the
managing director at BTIG said on " Closing Bell ." "I'm not surprised that they bought
Red Hat , I'm surprised
that it took them so long. They've been behind the cloud eight ball."
This is IBM's largest deal ever and the third-biggest tech deal in the history of the United
States. IBM is paying more than a 60 percent premium for the software maker, but
CEO Ginni Rometty told CNBC earlier in the day it was a "fair price."
As a 25yr+ vet of IBM, I can confirm that this article is spot-on true. IBM used to be a proud and transparent company that clearly
demonstrated that it valued its employees as much as it did its stock performance or dividend rate or EPS, simply because it is
good for business. Those principles helped make and keep IBM atop the business world as the most trusted international brand and
business icon of success for so many years. In 2000, all that changed when Sam Palmisano became the CEO. Palmisano's now infamous
"Roadmap 2015" ran the company into the ground through its maniacal focus on increasing EPS at any and all costs. Literally.
Like, its employees, employee compensation, benefits, skills, and education opportunities. Like, its products, product innovation,
quality, and customer service.
All of which resulted in the devastation of its technical capability and competitiveness, employee engagement, and customer
loyalty. Executives seemed happy enough as their compensation grew nicely with greater financial efficiencies, and Palisano got
a sweet $270M+ exit package in 2012 for a job well done.
The new CEO, Ginni Rometty has since undergone a lot of scrutiny for her lack of business results, but she was screwed from
day one. Of course, that doesn't leave her off the hook for the business practices outlined in the article, but what do you expect:
she was hand picked by Palmisano and approved by the same board that thought Palmisano was golden.
People (and companies) who have nothing to hide, hide nothing. People (and companies) who are proud of their actions, share
it proudly. IBM believes it is being clever and outsmarting employment discrimination laws and saving the company money while
retooling its workforce. That may end up being so (but probably won't), but it's irrelevant. Through its practices, IBM has lost
the trust of its employees, customers, and ironically, stockholders (just ask Warren Buffett), who are the very(/only) audience
IBM was trying to impress. It's just a huge shame.
I agree with many who state the report is well done. However, this crap started in the early 1990s. In the late 1980s, IBM offered
decent packages to retirement eligible employees. For those close to retirement age, it was a great deal - 2 weeks pay for every
year of service (capped at 26 years) plus being kept on to perform their old job for 6 months (while collecting retirement, until
the government stepped in an put a halt to it). Nobody eligible was forced to take the package (at least not to general knowledge).
The last decent package was in 1991 - similar, but not able to come back for 6 months. However, in 1991, those offered the package
were basically told take it or else. Anyone with 30 years of service or 15 years and 55 was eligible and anyone within 5 years
of eligibility could "bridge" the difference. They also had to sign a form stating they would not sue IBM in order to get up to
a years pay - not taxable per IRS documents back then (but IBM took out the taxes anyway and the IRS refused to return - an employee
group had hired lawyers to get the taxes back, a failed attempt which only enriched the lawyers). After that, things went downhill
and accelerated when Gerstner took over. After 1991, there were still a some workers who could get 30 years or more, but that
was more the exception. I suspect the way the company has been run the past 25 years or so has the Watsons spinning in their graves.
Gone are the 3 core beliefs - "Respect for the individual", "Service to the customer" and "Excellence must be a way of life".
IBM's policy reminds me of the "If a citizen = 30 y.o., then mass execute such, else if they run then hunt and kill them one by
one" social policy in the Michael York movie "Logan's Run."
From Wiki, in case you don't know: "It depicts a utopian future society on the surface, revealed as a dystopia where the population
and the consumption of resources are maintained in equilibrium by killing everyone who reaches the age of 30. The story follows
the actions of Logan 5, a "Sandman" who has terminated others who have attempted to escape death, and is now faced with termination
himself."
Perhaps someone can explain this... Red Hat's revenue and assets barely total about $5B.
Even factoring in market share and capitalization, how the hey did IBM come up with $34B
cash being a justifiable purchase price??
Honestly, why would Red Hat have said no?
You don't trade at your earnings, you trade at your share price, which for Red Hat and
many other tech companies can be quite high on Price/Earnings. They were trading at 52 P/E.
Investors factor in a bunch of things involving future growth, and particularly for any
companies in the cloud can quite highly overvalue things.
A 25 year old company trading at a P/E of 52 was already overpriced, buying at more than 2x
that is insane. This might just be the deal that kills IBM because there's no way that they
don't do a writedown of 90% of the value of this acquisition within 5 years.
3 hours ago
afidel wrote: show nested quotes
Kilroy420 wrote: Perhaps someone can explain this... Red Hat's revenue and assets barely
total about $5B. Even factoring in market share and capitalization, how the hey did IBM come up
with $34B cash being a justifiable purchase price??
Honestly, why would Red Hat have said no?
You don't trade at your earnings, you trade at your share price, which for Red Hat and many
other tech companies can be quite high on Price/Earnings. They were trading at 52 P/E.
Investors factor in a bunch of things involving future growth, and particularly for any
companies in the cloud can quite highly overvalue things.
A 25 year old company trading at a P/E of 52 was already overpriced, buying at more than 2x
that is insane. This might just be the deal that kills IBM because there's no way that they
don't do a writedown of 90% of the value of this acquisition within 5 years.
OK. I did 10 years at IBM Boulder..
The problem isn't the purchase price or the probable write-down later.
The problem is going to be with the executives above it. One thing I noticed at IBM is that
the executives needed to put their own stamp on operations to justify their bonuses. We were on
a 2 year cycle of execs coming in and saying "Whoa.. things are too centralized, we need to
decentralize", then the next exec coming in and saying "things are too decentralized, we need
to centralize".
No IBM exec will get a bonus if they are over RedHat and exercise no authority over it. "We
left it alone" generates nothing for the PBC. If they are in the middle of a re-org, then the
specific metrics used to calculate their bonus can get waived. (Well, we took an unexpected hit
this year on sales because we are re-orging to better optimize our resources). With that P/E,
no IBM exec is going to get a bonus based on metrics. IBM execs do *not* care about what is
good for IBM's business. They are all about gaming the bonuses. Customers aren't even on the
list of things they care about.
I am reminded of a coworker who quit in frustration back in the early 2000's due to just
plain bad management. At the time, IBM was working on Project Monterey. This was supposed to be
a Unix system across multiple architectures. My coworker sent his resignation out to all hands
basically saying "This is stupid. we should just be porting Linux". He even broke down the
relative costs. Billions for Project Monterey vs thousands for a Linux port. Six months later,
we get an email from on-high announcing this great new idea that upper management had come up
with. It would be far cheaper to just support Linux than write a new OS.. you'd think that
would be a great thing, but the reality is that all it did was create the AIX 5L family, which
was AIX 5 with an additional CD called Linux ToolBox, which was loaded with a few Linux
programs ported to a specific version of AIX, but never kept current. IBM can make even great
decisions into bad decisions.
In May 2007, IBM announced the transition to LEAN. Sounds great, but this LEAN was not on
the manufacturing side of the equation. It was in e-Business under Global Services. The new
procedures were basically call center operations. Now, prior to this, IBM would have specific
engineers for specific accounts. So, Major Bank would have that AIX admin, that Sun admin, that
windows admin, etc. They knew who to call and those engineers would have docs and institutional
knowledge of that account. During the LEAN announcement, Bob Moffat described the process.
Accounts would now call an 800 number and the person calling would open a ticket. This would
apply to *any* work request as all the engineers would be pooled and whoever had time would get
the ticket. So, reset a password - ticket. So, load a tape - ticket. Install 20 servers -
ticket.
Now, the kicker to this was that the change was announced at 8AM and went live at noon. IBM
gave their customers who represented over $12 Billion in contracts 4 *hours* notice that they
were going to strip their support teams and treat them like a call center. (I will leave it as
an exercise to the reader to determine if they would accept that kind of support after spending
hundreds of millions on a support contract).
(The pilot program for the LEAN process had its call center outsourced overseas, if that
helps you try to figure out why IBM wanted to get rid of dedicated engineers and move to a
call-center operation).
IBM will have to work hard to overcome RH customers' natural (and IMHO largely justified)
suspicion of Big Blue.
Notable quotes:
"... focused its workforce on large "hub" cities where graduate engineers prefer to live – New York City, San Francisco, and Austin, in the US for instance – which allowed it to drive out older, settled staff who refused to move closer to the office. ..."
"... The acquisition of Sun Microsystems by Oracle comes to mind there. ..."
"... When Microsoft bought out GitHub, they made a promise to let it run independently and now IBM's given a similar pledge in respect of RedHat. They ought to abide by that promise because the alternatives are already out there in the form of Ubuntu and SUSE Linux Enterprise Server. ..."
...That transformation has led to accusations of Big Blue ditching its
older staff for newer workers to somehow spark some new energy within it. It also
cracked down on
remote employees , and focused its workforce on large "hub" cities where graduate engineers
prefer to live – New York City, San Francisco, and Austin, in the US for instance –
which allowed it to drive out older, settled staff who refused to move closer to the
office.
Easy, the same way they deal with their existing employees. It'll be the IBM way or the
highway. We'll see the usual repetitive and doomed IBM strategy of brutal downsizings
accompanied by the earnest IBM belief that a few offshore wage slaves can do as good a job as
anybody else.
The product and service will deteriorate, pricing will have to go up significantly to
recover the tens of billions of dollars of "goodwill" that IBM have just splurged, and in
five years time we'll all be saying "remember how the clueless twats at IBM bought Red Hat
and screwed it up?"
One of IBM's main problems is lack of revenue, and yet Red Hat only adds about $3bn to
their revenue. As with most M&A the motivators here are a surplus of cash and hopeless
optimism, accompanied by the suppression of all common sense.
"What happens over the next 12 -- 24 months will be ... interesting. Usually the
acquisition of a relatively young, limber outfit with modern product and service by one of
the slow-witted traditional brontosaurs does not end well"
The acquisition of Sun Microsystems by Oracle comes to mind there.
When Microsoft bought
out GitHub, they made a promise to let it run independently and now IBM's given a similar
pledge in respect of RedHat. They ought to abide by that promise because the alternatives are
already out there in the form of Ubuntu and SUSE Linux Enterprise Server.
"... IBM was already "working on Linux." For decades. With multiple hundreds of full-time Linux developers--more than any other corporate contributor--around the world. And not just on including IBM-centric function into Linux, but on mainstream community projects. There have been lots of Linux people in IBM since the early-90's. ..."
"... From a customer standpoint the main thing RedHat adds is formal support. There are still a lot of companies who are uncomfortable deploying an OS that has product support only from StackExchange and web forums ..."
"... You would do better to look at the execution on the numbers - RedHat is not hitting it's targets and there are signs of trouble. These two businesses were both looking for a prop and the RedHat shareholders are getting out while the business is near it's peak. ..."
honestly, MS would be fine. They're big into Linux and open source and still a heavily
pro-engineering company.
Companies like Oracle and IBM are about nothing but making money. Which is why they're
both going down the tubes. No-one who doesn't already have them goes near them.
IBM was already "working on Linux." For decades. With multiple hundreds of full-time Linux
developers--more than any other corporate contributor--around the world. And not just on
including IBM-centric function into Linux, but on mainstream community projects. There have
been lots of Linux people in IBM since the early-90's.
The OS is from Linus and chums, Redhat adds a few storage bits and some Redhat logos
and erm.......
From a customer standpoint the main thing RedHat adds is formal support. There are still a
lot of companies who are uncomfortable deploying an OS that has product support only from
StackExchange and web forums. This market is fairly insensitive to price, which is good for a
company like RedHat. (Although there has been an exodus of higher education customers as the
price has gone up; like Sun did back in the day, they've been squeezing out that market. Two
campuses I've worked for have switched wholesale to CentOS.)
You would do better to look at the execution on the numbers - RedHat is not hitting it's
targets and there are signs of trouble. These two businesses were both looking for a prop and
the RedHat shareholders are getting out while the business is near it's peak.
Footnote: $699 License Fee applies to your systemP server running RHEL 7 with 4 cores
activated for one year.
To activate additional processor cores on the systemP server, a fee
of $199 per core applies. systemP offers a new Semi-Activation Mode now. In systemP
Semi-Activation Mode, you will be only charged for all processor calls exceeding 258 MIPS,
which will be processed by additional semi-activated cores on a pro-rata basis.
RHEL on systemP servers also offers a Partial Activation Mode, where additional cores can be
activated in Inhibited Efficiency Mode.
To know more about Semi-Activation Mode, Partial
Activation Mode and Inhibited Efficiency Mode, visit http://www.ibm.com/systemp [ibm.com] or contact your IBM
systemP Sales Engineer.
$34B? I was going to say this is the biggest tech acquisition ever, but it's second after
Dell buying EMC. I'm not too sure what IBM is going to do with that, but congrats to whoever
is getting the money...
"... But I do beg to differ about the optimism, because, as my boss likes to quote, "culture eats strategy for breakfast". ..."
"... So the problem is that IBM have bought a business whose competencies and success factors differ from the IBM core. Its culture is radically different, and incompatible with IBM. ..."
"... Many of its best employees will be hostile to IBM ..."
"... And just like a gas giant, IBM can be considered a failed star ..."
Quite a lot of the "OMG" moments rests on three assumptions:
Red Hat is 100% brilliant and speckless
IBM is beyond hope and unchangeable
This is a hostile takeover
I beg to differ on all counts. Call me beyond hope myself because of my optimism, but I do
think what IBM bought most is a way to run a business. RH is just too big to be borged into a
failing giant without leaving quite a substantial mark.
Note: I didn't downvote you, its a valid argument. I can understand why you think that,
because I'm in the minority that think the IBM "bear" case is overdone. They've been cleaning
their stables for some years now, and that means dropping quite a lot of low margin business,
and seeing the topline shrink. That attracts a lot of criticism, although it is good business
sense.
But I do beg to differ about the optimism, because, as my boss likes to quote,
"culture eats strategy for breakfast".
And (speaking as a strategist) that's 100% true, and 150% true when doing M&A.
So the problem is that IBM have bought a business whose competencies and success
factors differ from the IBM core. Its culture is radically different, and incompatible with
IBM.
Many of its best employees will be hostile to IBM . RedHat will be borged, and it
will leave quite a mark. A bit like Shoemaker-Levi did on Jupiter. Likewise there will be
lots of turbulence, but it won't endure, and at the end of it all the gas giant will be
unchanged (just a bit poorer). And just like a gas giant, IBM can be considered a failed
star .
"... As long as IBM doesn't close-source RH stuff -- most of which they couldn't if they wanted to -- CentOS will still be able to do builds of it. The only thing RH can really enforce control over is the branding and documentation. ..."
"... Might be a REALLY good time to fork CentOS before IBM pulls an OpenSolaris on it. Same thing with Fedora. ..."
"... I used to be a Solaris admin. Now I am a linux admin in a red hat shop. Sun was bought by Oracle and more or less died a death. Will the same happen now? I know that Sun and RH are _very_ differeht beasts but I am thinking that now is the time to stop playing on the merry go round called systems administration. ..."
Re: If IBM buys Redhat then what will happen to CentOS?
If IBM buys Redhat then what will happen to CentOS?
As long as IBM doesn't close-source RH stuff -- most of which they couldn't if they wanted to -- CentOS will still be able
to do builds of it. The only thing RH can really enforce control over is the branding and documentation.
"I found that those with real talent that matched IBM needs are well looked after."
The problem is that when you have served your need you tend to get downsized as the expectation is that the cheaper offshore
bodies can simply take over support etc after picking up the skills they need over a few months !!!
This 'Blue meets Red and assimilates' will be very interesting to watch and will need lots and lots of popcorn on hand !!!
Scientific Linux is a good idea in theory, dreadful in practice.
The idea of a research/academic-software-focused distro is a good one: unfortunately (I say unfortunately, but it's certainly
what I would do myself), increasing numbers of researchers are now developing their pet projects on Debian or Ubuntu, and so therefore
often only make .deb packages available.
Anyone who has had any involvement in research software knows that if you find yourself in the position of needing to compile
someone else's pet project from source, you are often in for an even more bumpy ride than usual.
And the lack of compatible RPM packages just encourages more and more researchers to go where the packages (and the free-ness)
are, namely Debian and friends, which continue to gather momentum, while Red Hat continues to stagnate.
Red Hat may be very stable for running servers (as long as you don't need anything reasonably new (not bleeding edge, but at
least newer than three years old)), but I have never really seen the attraction in it myself (especially as there isn't much of
a "community" feeling around it, as its commercial focus gets in the way).
I used to be a Solaris admin. Now I am a linux admin in a red hat shop. Sun was bought by Oracle and more or less died
a death. Will the same happen now? I know that Sun and RH are _very_ differeht beasts but I am thinking that now is the time to
stop playing on the merry go round called systems administration.
Dear Red Hatters, welcome to the world of battery hens, all clucking and clicking away to produce the elusive golden egg while
the axe looms over their heads. Even if your mental health survives, you will become chicken feed by the time you are middle aged.
IBM doesn't have a heart; get out while you can. Follow the example of IBMers in Australia who are jumping ship in their droves,
leaving behind a crippled, demoralised workforce. Don't become a Mad Hatter.
Hello, we are mandating some new policies, git can no longer be used, we must use IBM synergy
software with rational rose.
All open source software is subject to corporate approval first,
we know we know, to help streamline this process we have approved GNU CC and are looking into
this Mak file program.
We are very pleased with systemd, we wish to further expand it's dhcp
capabilities and also integrate IBM analytics -- We are also going through a rebranding
operation as we feel the color red is too jarring for our customers, we will now be known as
IBM Rational Hat and will only distribute through our retail channels to boost sales -- Look
for us at walmart, circuit city, and staples
IBM are paying around 12x annual revenue for Red Hat which is a significant multiple so they
will have to squeeze more money out of the business somehow. Either they grow customers or
they increase margins or both.
IBM had little choice but to do something like this. They are in a terminal spiral thanks
to years of bad leadership. The confused billing of the purchase smacks of rush, so far I
have seen Red Hat described as a cloud company, an info sec company, an open source
company...
So IBM are buying Red Hat as a last chance bid to avoid being put through the PE threshing
machine. Red Hat get a ludicrous premium so will take the money.
And RH customers will want to check their contracts...
"... IBM license fees are predatory. Plus they require you to install agents on your servers for the sole purpose of calculating use and licenses. ..."
"... IBM exploits workers by offshoring and are slow to fix bugs and critical CVEs ..."
IBM buys a company, fires all the transferred employees and hopes they can keep selling
their acquired software without further development. If they were serious, they'd have
improved their own Linux contribution efforts.
But they literally think they can somehow keep
selling software without anyone with knowledge of the software, or for transferring skills to
their own employees.
They literally have no interest in actual software development. It's all
about sales targets.
My advice to Red Hat engineers is to get out now. I was an engineer at a company that was
acquired by IBM. I was fairly senior so I stayed on and ended up retiring from the IBM, even
though I hated my last few years working there. I worked for several companies during my
career, from startups to fortune 100 companies. IBM was the worst place I worked by far.
Consider every bad thing you've ever heard about IBM. I've heard those things too, and the
reality was much worse.
IBM hasn't improved their Linux contribution efforts because it wouldn't know how. It's
not for lack of talented engineers. The management culture is simply pathological. No dissent
is allowed. Everyone lives in fear of a low stack ranking and getting laid off. In the end it
doesn't matter anyway. Eventually the product you work on that they originally purchased
becomes unprofitable and they lay you off anyway. They've long forgotten how to develop
software on their own. Don't believe me? Try to think of an IBM branded software product that
they built from the ground up in the last 25 years that has significant market share.
Development managers chase one development fad after another hoping to find the silver bullet
that will allow them to continue the relentless cost cutting regime made necessary in order
to make up revenue that has been falling consistently for over a decade now.
As far as I could tell, IBM is good at two things:
Financial manipulation to disguise there shrinking revenue
Buying software companies and mining them for value
Yes, there are still some brilliant people that work there. But IBM is just not good at
turning ideas into revenue producing products. They are nearly always unsuccessful when they
try and then the go out and buy a company the succeeded in bring to market the kind of
product that they tried and failed to build themselves.
They used to be good at customer support, but that is mainly lip service now. Just before
I left the company I was tapped to deliver a presentation at a customer seminar. The audience
did not care much about my presentation. The only thing they wanted to talk about was how
much they had invested millions in re-engineering their business to use our software and now
IBM appeared to be wavering in their long term commitment to supporting the product. It was
all very embarrassing because I knew what they didn't, that the amount of development and
support resources currently allocated to the product line were a small fraction of what they
once were. After having worked there I don't know why anyone would ever want to buy a license
for any of their products.
IBM engineers aren't actually crappy. It's the fucking MBAs in management who have no clue
about how to run a software development company. Their engineers will want to do good work,
but management will worry more about headcount and sales.
IBM acquisitions never go well. All companies acquired by IBM go through a process of
"Blue washing", in which the heart and soul of the acquired company is ripped out, the body
burnt, and the remaining ashes to be devoured and defecated by its army of clueless salesmen
and consultants. It's a sad, and infuriating, repeated pattern. They no longer develop
internal talent. They drive away the remaining people left over from the time when they still
did develop things. They think they can just buy their way into a market or technology,
somehow completely oblivious to the fact that their strategy of firing all their acquired
employees/knowledge and hoping to sell software they have no interest in developing would
somehow still retain customers. They literally could have just reshuffled and/or hired more
developers to work on the kernel, but the fact they didn't shows they have no intention of
actually contributing.
Red Hat closed Friday at $116.68 per share, looks like the buy out is for $190. Not
everyone will be unhappy with this. I hope the Red Hat employees that won't like the upcoming
cultural changes have stock and options, it may soften the blow a bit.
Oh, good. Now IBM can turn RH into AIX while simultaneously suffocating whatever will be
left of Redhat's staff with IBM's crushing, indifferent, incompetent bureaucracy.
This is what we call a lose - lose situation. Well, except for the president of Redhat, of
course. Jim Whitehurst just got rich.
Depends on the state. Non-compete clauses are unenforceable in some jurisdictions. IBM
would want some of the people to stick around. You can't just take over a complex system from
someone else and expect everything to run smoothly or know how to fix or extend it. Also, not
everyone who works at Red Hat gets anything from the buyout unless they were regularly giving
employees stock. A lot of people are going to want the stable paycheck of working for IBM
instead of trying to start a new company.
However, some will inevitably get sick of working at IBM or end up being laid off at some
point. If these people want to keep doing what they're doing, they can start a new company.
If they're good at what they do, they probably won't have much trouble attracting some
venture capital either.
Red Hat went public in 1999, they are far from being a start-up. They have acquired
several companies themselves so they are just as corporate as IBM although significantly
smaller.
My feelings exactly. As a former employee for both places, I see this as the death knell
for Red Hat. Not immediately, not quickly, but eventually Red Hat's going to go the same way
as every other company IBM has acquired.
Red Hat's doom (again, all IMO) started about 10 years ago or so when Matt Szulik left and
Jim Whitehurst came on board. Nothing against Jim, but he NEVER seemed to grasp what F/OSS
was about. Hell, when he came onboard he wouldn't (and never did) use Linux at all: instead
he used a Mac, and so did the rest of the EMT (executive management team) over time. What
company is run by people who refuse to use its own product except for one that doesn't have
faith. The person on top of the BRAND AND PEOPLE team "needed" an iPad, she said, to do her
work (quoting a friend in the IT dept who was asked to get it and set it up for her).
Then when they (the EMTs) wanted to move away from using F/OSS internally to outsourcing
huge aspects of our infrastructure (like no longer using F/OSS for email and instead
contracting with GOOGLE to do our email, calendaring and document sharing) is when, again for
me, the plane started to spiral. How can we sell to OUR CUSTOMERS the idea that "Red Hat and
F/OSS will suit all of your corporate needs" when, again, the people running the ship didn't
think it would work for OURS? We had no special email or calendar needs, and if we did WE
WERE THE LEADERS OF OPEN SOURCE, couldn't we make it do what we want? Hell, I was on an
internal (but on our own time) team whose goal was to take needs like this and incubate them
with an open source solution to meet that need.
But the EMTs just didn't want to do that. They were too interested in what was "the big
thing" (at the time Open Shift was where all of our hiring and resources were being poured)
to pay attention to the foundations that were crumbling.
And now, here we are. Red Hat is being subsumed by the largest closed-source company on
the planet, one who does their job sub-optimally (to be nice). This is the end of Red Hat as
we know it. Without 5-7 years Red Hat will go the way of Tivoli and Lotus: it will be a brand
name that lacks any of what made the original company what it was when it was acquired.
IBM must be borrowing a lot of cash to fund the acquisition. At last count it had about $12B in the bank... https://www.marketwatch.com/investing/stock/ibm/financials/balance-sheet.
Looking at the Red Hat numbers, I would not want to be an existing IBM share-holder this morning; both companies missing market
expectations and in need of each other to get out of the rut.
It is going to take a lot of effort to make that 63% premium pay-off. If it does not pay-off pretty quickly, the existing RedHat
leadership with gone in 18 months.
P.S.
Apparently this is going to be financed by a mixture of cash and debt - increasing IBM's existing debt by nearly 50%. Possible
credit rating downgrade on the way?
As soon as they have a minimum of experience with the terrible IBM change management processes, the many layers of bureocracy
and management involved and the zero or negative value they add to anything at all.
IBM is a shinking ship, the only question being how long it will take to happen. Anyone thinkin RH has any future other than
languish and disappear under IBM management is dellusional. Or a IBM stock owner.
I'm still trying to figure out "why" they bought Red hat.
The only thing my not insignificant google trawling can find me is that Red Hat sell to the likes of Microsoft and google -
now, that *is* interesting. IBM seem to be saying that they can't compete directly but they will sell upwards to their overlords
- no ?
As far as I can tell, it is be part of IBM's cloud (or hybrid cloud) strategy. RH have become/are becoming increasingly successful
in this arena.
If I was being cynical, I would also say that it will enable IBM to put the RH brand and appropriate open source soundbites on
the table for deal-making and sales with or without the RH workforce and philosophy. Also, RH's subscription-base must figure greatly
here - a list of perfect customers ripe for "upselling". bazza
Re: But *Why* did they buy them?
I'm fairly convinced that it's because of who uses RedHat. Certainly a lot of financial institutions do, they're in the market
for commercial support (the OS cost itself is irrelevant). You can tell this by looking at the prices RedHat were charging for
RedHat MRG - beloved by the high speed share traders. To say eye-watering, PER ANNUM too, is an understatement. You'd have to
have got deep pockets before such prices became ignorable.
IBM is a business services company that just happens to make hardware and write OSes. RedHat has a lot of customers interested
in business services. The ones I think who will be kicking themselves are Hewlett Packard (or whatever they're called these days).
Because AIX and RHEL are the two remaining enterprise unixoid platforms (Solaris & HPUX are moribund and the other players
are pretty small). Now both of those are owned by IBM: they now own the enterprise unixoid market.
"I'm still trying to figure out "why" they bought Red hat."
What they say? It somehow helps them with cloud. Doesn't sound like much money there - certainly not enough to justify the
significant increase in debt (~US$17B).
What could it be then? Well RedHat pushed up support prices and their customers didn't squeal much. A lot of those big enterprise
customers moved from expensive hardware/expensive OS support over the last ten years to x86 with much cheaper OS support so there's
plenty of scope for squeezing more.
I can see what each company will get out of the deal and how they might
potentially benefit. However, Red Hat's culture is integral to their success. Both company
CEOs were asked today at an all-hands meeting about how they intend to keep the promise of
remaining distinct and maintaining the RH culture without IBM suffocating it. Nothing is
supposed to change (for now), but IBM has a track record of driving successful companies and
open dynamic cultures into the ground. Many, many eyes will be watching this.
Hopefully IBM current top Brass will be smart and give some autonomy to Red Hat and leave
it to its own management style. Of course, that will only happen if they deliver IBM goals
(and that will probably mean high double digit y2y growth) on regular basis...
One thing is sure, they'll probably kill any overlapsing product in the medium term (who
will survive between JBOSS and Websphere is an open bet).
(On a dream side note, maybe, just maybe they'll move some of their software development
to Red Hat)
Good luck. Every CEO thinks they're the latest incarnation of Adam Smith, and they're all
dying to be seen as "doing something." Doing nothing, while sometimes a really smart thing
and oftentimes the right thing to do, isn't looked upon favorably these days in American
business. IBM will definitely do something with Red Hat; it's just a matter of what.
The Last but not LeastTechnology is dominated by
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt.
Ph.D
FAIR USE NOTICEThis site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
You can use PayPal to to buy a cup of coffee for authors
of this site
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society.We do not warrant the correctness
of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be
tracked by Google please disable Javascript for this site. This site is perfectly usable without
Javascript.
