On Mon, Dec 29, 2014 at 3:03 PM, Warren Young <wyml at etr-usa.com> 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 at gmail.com