On Mon, December 29, 2014 04:22, Ned Slider wrote:> What business model do you have that you > can't build around a product guaranteed to be consistent/supported for > the next 10 years?Well, despite the hype from Wall St., Bay St. and The City, a large number of organisations in the world run on software that is decades old and cannot be economically replaced. In many instances in government and business seven years is a typical time-frame in which to get a major software system built and installed. And I have witnessed longer. 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. In fact, it my considered belief that RH in Version EL7 has done themselves a serious injury with respect to corporate adoption for core systems. Perhaps they seek a different market? Think about it. What enterprise can afford to rewrite all of its software every ten years? What enterprise can afford to retrain all of its personnel to use different tools to accomplish the exact same tasks every seven years? The desktop software churn that the PC has inured in people simply does not scale to the enterprise. If you wish to see what change for change's sake produces in terms of market share consider what Mozilla has done with Firefox. There is absolutely no interface that is as easy to use as the one you have been working on for the past ten years. And that salient fact seems to be completely ignored by many people in the FOSS community. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
On Mon, Dec 29, 2014 at 9:02 AM, James B. Byrne <byrnejb at harte-lyne.ca> wrote:> > So, seven, even ten, years of stability is really nothing at all.Yes exactly. Do you want your bank to manage your accounts with new and not-well-tested software every 7 years or would you prefer the stability of incremental improvements?> Think about it. What enterprise can afford to rewrite all of its software > every ten years? What enterprise can afford to retrain all of its personnel to > use different tools to accomplish the exact same tasks every seven years?It's worse than that - since you can't just replace all of your servers and code at once, your staff has to be trained on at least two and probably three major versions at any given time - and aware of which server runs what, and which command set has to be used. And the cost and risk of errors increases with the number of arbitrary changes across versions. -- Les Mikesell lesmikesell at gmail.com
On Mon, December 29, 2014 9:02 am, James B. Byrne wrote:> > On Mon, December 29, 2014 04:22, Ned Slider wrote: >> What business model do you have that you >> can't build around a product guaranteed to be consistent/supported for >> the next 10 years? > > Well, despite the hype from Wall St., Bay St. and The City, a large number > of > organisations in the world run on software that is decades old and cannot > be > economically replaced. In many instances in government and business seven > years is a typical time-frame in which to get a major software system > built > and installed. And I have witnessed longer. > > 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. In fact, it my considered belief that RH in Version EL7 has > done > themselves a serious injury with respect to corporate adoption for core > systems. Perhaps they seek a different market?I said elsewhere that these changes are partly induced by changes started in kernel some 5 years ago. But now I do realize that at least part of them was pushed on the kernel level by folks from RedHat team...> > Think about it. What enterprise can afford to rewrite all of its software > every ten years? What enterprise can afford to retrain all of its > personnel to > use different tools to accomplish the exact same tasks every seven years? > The > desktop software churn that the PC has inured in people simply does not > scale > to the enterprise. > > If you wish to see what change for change's sake produces in terms of > market > share consider what Mozilla has done with Firefox. There is absolutely no > interface that is as easy to use as the one you have been working on for > the > past ten years. And that salient fact seems to be completely ignored by > many > people in the FOSS community. >Well, there are similar changes in other areas of our [human] communication with computer hardware. Take the step "up" from Gnome 2 to Gnome 3 for instance. From the way that worked over two decades (with logical tree like access to what you need) all switched to please people without brain and ability to categorize things... just able to do search. And you can continue describing the differences each confirming that same point. Which leads me to say: Welcome to ipad generation folks! Valeri ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Mon, Dec 29, 2014 at 10:23 AM, Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote:> > Welcome to ipad generation folks!Yes, but Apple knows enough to stay out of the server business where stability matters - and they are more into selling content than code anyway. Client side things do need to deal with mobility these days - reconnecting automatically after sleep/wakeup and handling network connection changes transparently, but those things don't need to break existing usage. -- Les Mikesell lesmikesell at gmail.com
On Dec 29, 2014, at 8:02 AM, James B. Byrne <byrnejb at harte-lyne.ca> wrote:> In many instances in government and business seven > years is a typical time-frame in which to get a major software system built > and installed. And I have witnessed longer.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. 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. Though you spend the same amount of time, you will not end up in the same place because the world has changed over those years. Instead of building on top of an increasingly irrelevant foundation, you track the actual evolving needs of the organization, so that you end up where the organization needs you to be now, instead of where you thought it would need to be 7 years ago. 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. 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! Second, there is no necessary tie between OS and software systems built on top of it. If your software only runs on one specific OS version, you?re doing it wrong. 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. 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. Unix is about 45 years old now. It?s been thorough shifts that make my personal experience look trivial. (We have yet to get off x86, after all. How hard could it have been, really?) The Unix community knows how to do portability. If you aren?t planning for platform shift, you aren?t planning. We have plenty of technology for coping with platform shift. The autotools, platform-independence libraries (Qt, APR, Boost?), portable language platforms (Perl, Java, .NET?), and on and on. 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.> 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) Apple? Check. (OS 9->X, Lion, Mavericks, Yosemite, iOS 6, iOS 7, iOS 8?) 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? Could it be that software for these other platforms *also* manages to ride through major breaking changes?> What enterprise can afford to rewrite all of its software > every ten years?Straw man. If you have to rewrite even 1% of your system to accommodate the change from EL6 to EL7, you are doing it wrong. If you think EL6 to EL7 is an earth-shaking change, you must not have been through something actually serious, like Solaris to Linux, or Linux to BSD, or (heaven forfend) Linux to Windows. Here you *might* crest the 1% rewrite level, but if you do that right, you just made it possible to port to a third new platform much easier.> 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.)> The > desktop software churn that the PC has inured in people simply does not scale > to the enterprise.Tell that to Google. 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. Bottom line: This is the job. This is what you get paid to do.
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