Re: Enterprise and Debian Pure Blends
Hi:
On Thursday 02 September 2010 20:38:08 CJ Fearnley wrote:
[...]
> I think we need more than "standards, best practices, abstractions and
> modularity". I don't think it is a pessimistic 20 year maturity process
> before "the promised land" will be reached. I think as an industry
> we are not yet even aware of the right design issues for integration
> (at least I haven't yet found a forum where the issue is addressed at
> the scale and scope that is necessary).
I don't think so. I in fact think the opposite: the industry as a whole is
quite aware about requisites, both technical and social, for integration (and
security and promotion):
Clear separation from bugfixes and new functionality
Commit to your own shit*1
Loosly coupling
Backwards compatibility
Deprecate with warning first, then retire
Don't reinvent the wheel
Think about promotion/interaction/maintenance first and always, not as an
afterthought
Document properly and as you go
Test your code (no, "it complies on my box" is not testing enough)
Be proud and professional
etc.
> And developers are even less
> aware of these issues than enterprise admins who are not even as aware
That's the main point: the "industry as whole" is quite aware, the individuals
generally are not so (maybe a side effect of second Sturgeon's Law*2).
> I have argued (in two blog posts[0][1]) that it is a conceptual vision
> issue: we need to take a stand that we require "eternally regenerative
> software" and stop accepting that upgrades require "heart-transplant"
> surgeries.
I saw your references but I find lacking a very important concept:
functionality change and 2^n interactions. There can't possibly be "rolling
updates" if that means uncompatible functionality changes since in a complex
system there's a topping at 2^n interactions where 'n' is the number of
functional elements. There's a why for rolling distributions like Gentoo not
going into production systems and it's that even if they were constantly and
perfectly bug-free, functional change is by itselft a source of
disfunctionality. Is those functional changes what makes software upgrades
kind of a heart transplant instead of a continous maturing process.
But even then, we, as an industry, know how to properly cope with that: if you
happen to have two hearts properly working in parallel, you can go for heart
transplant without service disruption. You *can* design your systems in
quite stablished ways so they can stand continous upgrading, even coping with
functional changes while at it (i.e. ask Google). It's only individuals and
companies are usually too cheap, too lazy and/or too unknownledgeable to
embrace such practices. And with current x86 virtualization it shouldn't
even be so expensive/hard.
*1 While perfectly understandable I find a bit funny when you go to an
upstreamer regarding a bug in a past version and the answer is "too busy/too
short on manpower to support such an ancient version". Hell, it's your
software, be proud of it: make as sure as possible not getting bugs into your
sources is on-par with new functionality development, at least by the time
you call something "stable", and then you will have enough manpower to cope
with the bugs and at the same time you won't look childish and
unprofessional.
*2 http://en.wikipedia.org/wiki/Sturgeon's_Law
Cheers.
Reply to: