[rescue] Linux wet paint, was Re: Spark10 CPU question (must fix - SPARC damnit :-) )
mroos at linux.ee
Sat Dec 17 03:41:31 CST 2016
> Well said, and from my perspective, very true.
Yes, agreed - I liked the wet paint analogue very much.
But I do not see it as "kinds having no discipline" - it's rather a
different approach taken to the development process to help with scaling
In a small and controlled team you can force the focus on some spewcific
features and polish these features until they are done. But you can not
scale that model out to lots of developers and lots of features - at
least not with developer doingit for their own fun.
To scale the scope with enthusiast developers, you can do most of the
feature development easily but yoiu have to leave the tail of quality
control to someone more motivated. Linux has selected the model of
bleeding edge and fast developing upstream kernel that is released when
it seems good enough to thew developers, and then distribution makers
try to scale out the testing and stabilization. Some have busoiness
models that can put more reources into it, some use more crowdsourcing
for testing, bus ocassionally thre "wet paint" gets though (Ijust saw it
with container memory management reclaiming problem).
> > > Linux. There is nothing -really- wrong with Linux. It's a little
> > > utilitarian. Almost too much of a good thing. It's in our TV's and in
> > > our phones. Who thought that was going to happen 20 years ago? It seems
> > > to take up new features pretty quick, and the paint is always a bit wet,
> > > either in the kernel, applications or even within the distribution. I
> > > think it's always been like that, and I'm not convinced it will ever be
> > > better. The paint around a feature will cure, but there is always wet
> > > paint somewhere.
Meelis Roos (mroos at linux.ee)
More information about the rescue