On Tue, Jul 8, 2014 at 11:13 AM, Lamar Owen <lowen@xxxxxxxx> wrote:
> On 07/08/2014 11:58 AM, Les Mikesell wrote:
>> ... How much is this going to cost a typical company _just_ to keep
>> their existing programs working the same way over the next decade
>> (which is a relatively short time in terms of business-process changes)?
>
> Les, this is the wrong question to ask. The question I ask is 'What
> will be my return on investment be, in potentially lower costs, to run
> my programs in a different way?'
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?
> Fact is that all of the
> major Linux distributions are going this way; do you really think all of
> them would change if this change were stupid?
Yes, Linux distributions do a lot of things I consider stupid. Take
the difficulty of maintaining real video drivers as an example.
> Even the Unix philosophy was new at one point. Just because it works
> doesn't mean it's the best that can be found.
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.
>> Even if the changes themselves are minor, you have to cover the cost
>> of paying some number of people for that 'get used to the syntax'
>> step. Personally I think Red Hat did everyone a disservice by
>> splitting the development side off to fedora and divorcing it from the
>> enterprise users that like the consistency.
>
> Consistency is not the only goal.
But that's why we are here using an 'enterprise' release, not
rebuilding gentoo every day.
> Efficiency should trump consistency,
Efficiency comes from following standards so components are reusable
and can be layered on top of each other. Then you can focus on making
the least efficient part better and spend your time where it will make
a difference. Adding options to increase efficiency is great - as long
as you don't break backwards compatibility.
> and I for one like being able to see where the direction lies well in
> advance of EL adopting a feature blind. Or don't you remember how Red
> Hat Linux development used to be before Fedora and the openness of that
> process?
Yes, I remember it worked fantastically well up through at least RH7 -
which was pretty much compatible with CentOS3. 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.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
