On Mon, Dec 29, 2014 at 3:03 PM, Warren Young <wyml@xxxxxxxxxxx> wrote:
>
> As a software developer, I think I can speak to both halves of that point.
>
> First, the world where you design, build, and deploy The System is disappearing fast.
Sure, if you don't care if you lose data, you can skip those steps.
Lots of free services that call everything they release 'beta' can get
away with that, and when it breaks it's not the developer answering
the phones if anyone answers at all.
> The world is moving toward incrementalism, where the first version of The System is the smallest thing that can possibly do anyone any good. That is deployed ASAP, and is then built up incrementally over years.
>
That works if it was designed for rolling updates. Most stuff isn't,
some stuff can't be.
> Instead of trying to go from 0 to 100 over the course of ~7 years, you deliver new functionality to production every 1-4 weeks, achieving 100% of the desired feature set over the course of years.
If you are, say, adding up dollars, how many times do you want that
functionality to change?
> This isn’t pie-in-the-sky theoretical BS. This is the way I’ve been developing software for decades, as have a great many others. Waterfall is dead, hallelujah!
>
How many people do you have answering the phone about the wild and
crazy changes you are introducing weekly? How much does it cost to
train them?
> I don’t mean that glibly. I mean you have made a fundamental mistake if your system breaks badly enough due to an OS change that you can’t fix it within an iteration or two of your normal development process. The most likely mistake is staffing your team entirely with people who have never been through a platform shift before.
Please quantify that. How much should a business expect to spend per
person to re-train their operations staff to keep their systems
working across a required OS update? Not to add functionality. To
keep something that was working running the way it was? And
separately, how much developer time would you expect to spend to
follow the changes and perhaps eventually make something work better?
> Again, this is not theoretical bloviation. The software system I’ve been working on for the past 2 decades has been through several of these platform changes. It started on x86 SVR4, migrated to Linux, bounced around several distros, and occasionally gets updated for whatever version of OS X or FreeBSD someone is toying with at the moment.
How many customers for your service did you keep running non-stop
across those transitions? Or are you actually talking about
providing a reliable service?
> Everyone’s moaning about systemd, and how it’s taking over the Linux world, as if it would be better if Red Hat kept on with systemd and all the other Linux distro providers shunned it. Complain about its weaknesses if it you like, but at least it’s looking to be a real de facto standard going forward.
Again, it's only useful to talk about if you can quantify the cost.
What you expect to pay to re-train operations staff -just- for this
change, -just- to keep things working the same.. And separately, what
will it cost in development time to take advantage of any new
functionality?
>> So, seven, even ten, years of stability is really nothing at all. And as
>> Linux seeks to enter into more and more profoundly valuable employment the
>> type of changes that we witnessed from v6 to v7 are simply not going to be
>> tolerated.
>
> Every other OS provider does this.
> (Those not in the process of dying, at any rate. A corpse is stable, but that’s no basis for recommending the widespread assumption of ambient temperature.)
>
> Windows? Check. (Vista, Windows 8, Windows CE/Pocket PC/Windows Mobile/Windows RT/Windows Phone)
We've got lots of stuff that will drop into Windows server versions
spanning well over a 10 year range. And operators that don't have a
lot of special training on the differences between them.
> And when all these breakages occurred, what was the cry heard throughout the land of punditry? “This is Linux’s chance! Having forced everyone to rewrite their software [bogus claim], Bad OS will make everyone move to Linux!” Except it doesn’t happen. Interesting, no?
No, Linux doesn't offer stability either.
> Could it be that software for these other platforms *also* manages to ride through major breaking changes?
>
Were you paying attention when Microsoft wanted to make XP obsolete?
There is a lot of it still running.
>> What enterprise can afford to rewrite all of its software
>> every ten years?
>
> Straw man.
Not really. Ask the IRS what platform they use. And estimate what
it is going to cost us when they change.
>> What enterprise can afford to retrain all of its personnel to
>> use different tools to accomplish the exact same tasks every seven years?
>
> Answer: Every enterprise that wants to remain an enterprise.
>
> This is exactly what happens with Windows and Apple, only on a bit swifter pace, typically.
>
> (The long dragging life of XP is an exception. Don’t expect it to occur ever again.)
No, that is the way things work. And the reason Microsoft is in business.
> Tell that to Google.
With their eternally beta software? With the ability to just drop
things they don't feel like supporting any more? Not everyone has
that luxury.
> What, you think they’re still building Linux boxes based on the same kernel 2.2 custom distro they were using when they started in the mid 1990s?
>
> We don’t have to guess, they’ve told us how they coped:
>
> http://events.linuxfoundation.org/sites/events/files/lcjp13_merlin.pdf
>
> Check out the slide titled "How did that strategy of patching Red Hat 7.1 work out?”
>
> Read through the rest of it, for that matter.
>
> If you come away from it with “Yeah, that’s what I’m telling you, this is a hard problem!” you’re probably missing the point, which is that while your resources aren’t as extensive as Google’s, your problem isn’t nearly as big as Google’s, either.
So again, quantify that. How much should it cost a business _just_ to
keep working the same way? And why do you think it is a good thing
for this to be a hard problem or for every individual user to be
forced to solve it himself?
> Bottom line: This is the job. This is what you get paid to do.
But it could be better, if anyone cared.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
