On 07/08/2014 01:14 PM, Les Mikesell wrote: > On Tue, Jul 8, 2014 at 11:13 AM, Lamar Owen <lowen at pari.edu> wrote: > But the answer is still the same. It's sort of the same as asking > that about getting a shiny new car with a different door size that > won't carry your old stuff without changes and then still won't do it > any better. Our services take all the hardware can do and a lot of > startup initialization on their own. Saving a fraction of a second of > system time starting them is never going to be a good tradeoff for > needing additional engineer training time on how to port them between > two different versions of the same OS. > >> If there is no ROI, or a really long >> ROI, well, I still have C6 to run until 2020 while I invest the time in >> determining if a new way is better or not. > So a deferred cost doesn't matter to you? You aren't young enough to > still think that 6 years is a long time away, are you? Amortized capex matters to me. I may not have the capex budget this year to do the development, but I do have opex monies to research potential development, and opex monies to do grant writing that can fund the development capex. I'm old enough to remember and to have read an original paper copy of the Misosys Quarterly with a column called 'Les Information.' 6 years is a short time, especially for grant funding cycles. But it is enough time for me to have researched, hopefully properly, the means by which to implement hopefully opex-reducing improvements. But these are business decisions, not technical ones. > Re-using things that work may not be best, but if everyone is > continually forced to re-implement them, they will never get a chance > to do what is best. In terms of your ROI question, you should be > asking if that is the best use of your time. My non-development time is opex; my development time is capex (for the purposes of many grants for which we apply). I always ask the question above when figuring ROI. And I got the nickname 'Mr. Make-Do' for the very reason that I do tend to heavily reuse 'ye olde stuffe.' >> Consistency is not the only goal. > But that's why we are here using an 'enterprise' release, not > rebuilding gentoo every day. I guess you missed the adjective 'only' above. Consistency helps reduce opex; reduces opex produces better fiscal efficiency, at least in theory. Each business's situation will be different, YMMV, of course. > >> Efficiency should trump consistency, > Efficiency comes from following standards... Everyone who commented thus far on my statement seems to have missed my wearing my CIO hat. I'm talking fiscal efficiency, as in getting the most bang for the buck, especially in terms of opex, which is nearly always a much larger number than capex for us (and, while I know this is not likely to make much technical sense, it is a true statement that $1 opex is not equal to $1 capex). This is not 'technical efficiency' here, but 'keep the lights on and the budget in the black' efficiency. If the budget goes red long enough it really doesn't matter what you do technically. If I need to get a grant to fund $100,000 capex that will save me $10,000 per year opex (and grants almost never fund opex) it is a no-brainer. > Yes, I remember it worked fantastically well up through at least RH7 - > which was pretty much compatible with CentOS3. Minor correction: RHL 7.2 -> RHAS 2.1. RHL 9 -> RHEL 3. I have a client that still has a RHL 5.2 machine running in production. It does its job, is not internet-connected and thus security updates are irrelevant, and it will run until it dies. Client has no budget to reengineer properly, and is migrating services one at a time in a pretty slow manner. There's only two semi-critical services left, and if they just went away the client would go back to a paper system while a newer system is being built. And they're fully prepared to do that rather than upgrade now. > That was back when > people actually using the systems contributed their fixes directly. > I had a couple of 4+ year uptime runs on a system with RH7 + updates - > and only shut it down to move it once. > I am one of those people who contributed directly; my name can still be found in the changelogs for PostgreSQL 7.4 on CentOS 4 (and I would assume RHEL4, if PostgreSQL is part of the EUS set). I remember the mechanisms, and the gatekeepers, involved, very well. The Fedora way is way more open, with people outside of Red Hat directly managing packages instead of contributing fixes to the 'official' Red Hat packager for that package.