Re: [Gnu-arch-users] the way forward

[Thomas Lord]

5On Tue, 2005-09-06 at 22:52 +0100, Robin Green wrote:

> The general point: at _least_ two distro vendor startups - Canonical and
> rpath - appear to be interested in supporting Gnu/linux users in the spirit
> of Free Software, i.e. supporting and encouraging custom modifications.

I think the spirit of free software is far larger than supporting and 
encouraging custom modifications.   At root, it's about how the golden
rule, sharing, bits, and software engineering interact.   My
understanding (and unfortunate experience) is that Canonical closely
guards (doesn't share) an infrastructure which is designed to be
centralized, that they regard the community of volunteers as a resource
to be competed for, and that they are disrespectful of the sources of
engineering talent whose work-product gave them a leg-up in getting
started.  They don't seem all that different from Red Hat to me, 
just incrementally more efficient and currently aimed at the lower
end of the market (the classical strategy for how challengers defeat
established firms in software).  File this under "volunteer lock-in".

>From an engineering perspective, I question why we need platform
distribution companies *at that scale* *at all*.   It seems to me like
an effort to create vulnerabilities, discourage the development of
tractable platforms (by addicting customers to the workaround for
intractable platforms), etc.   By this point in history, such efforts
have resulted in a platform that has a distinctly limited shelf-life
and a labor force that is uncomfortably close to being unprepared to
repair that situation.

> They are doing this partly because there is a perceived gap in the market.
> Want the security of a corporation maintaining your distro of choice like
> with Red Hat, but with the freedom to make custom modifications? This is
> one of the selling points of both companies. I wish them both the best of
> luck.

A federation of much smaller distro companies could do the same job much
more securely and while encouraging far higher quality results.  Such
solutions seem to me to be economically viable for the players but are 
hard to get started and aren't even on the map of windfall-seeking 
investors these days.


> 
> So I think basically, we are _already_ starting to see bigger and better
> alternatives to the kind of lock-in-happy distro vendors that you described
> in your email, and the situation isn't as bleak as you make out. Those
> damned capitalists are already _onto_ this idea - they're not stupid ( ;) ) -

Yes, they are.  Hopefully if I reiterate why often enough it'll sink in.
I've got a few days.... :-)



> so we need to support the enlightened companies in this route with our words
> and our money, and criticise them if they start restricting freedom to tinker
> - but not paint them as "evil" for _everything_ they do that's not 100%
> perfect. (hint, hint.)

I can only say that my experience -- my own life experience and the
direct observations I'm privileged to make of the volunteer community --
don't really give me any reason to back down from the harsh criticisms
I'm making.


> On Mon, Sep 05, 2005 at 06:41:00PM -0700, Thomas Lord wrote:
> > The effort to lock-in customers permeates even the market for IT
> > professionals.  For example, vendors such as Red Hat create credential-
> > offering programs for IT professionals.   They have succeeded in
> > substituting "Red Hat expert" for "unix expert"
> 
> To be fair, they're not the only ones to blame for that change.

Far from it.   I explicitly chose them as an interesting case study and
I did that because I think they are typical.   Historically, they are
also leaders in these practices so maybe they deserve "a special place
in hell" but, semi-famous flames against Tiemann aside, that is not
my point here.


> In a very real sense, if Linux had been allowed to call itself a Unix,
> the word Unix might not seem so "old hat" today. Stupid, stupid, stupid.


Trademarks don't matter much.   The code on the ground does and that's
what I'm talking about.  That and the infrastructure-on-the-ground which
produces that code.

> 
> That's a minor issue, though. More to the point is the fact that the Unix
> "platform" had been fragmented into several quite different branches long
> before Linux's ascendancy. Solaris is much more different from Red Hat
> that Red Hat is different from SuSE, in my opinion.


Two wrongs don't make a right.


> > Volunteer Lock-in Objective: Market Dubious Standards
> 
> Occam's razor: the poorness of the standards might have more to do with
> the fact that they need to roughly reflect existing implementations right now,
> not be idealistic representations of perfect, unrealised systems.
> 
> Much can be cut away by the careful application of Occam's razor to your 
> email,
> I feel.

Although Arch famously has struggled to port to Windows, it has (and 
with amazingly little "autoconf" baggage) ported easily to many
platforms.  (Yes, I neglected a couple of one-line patches for
AIX or somesuch.)   How did I do that?  By coding to venerable standards
and best practices. 

Meanwhile, just pray for the poor soul who wants to take a typical
Linux-based project and compile it on something as esoteric and
forgotten as, say, a BSD variant.   


> 
> > Volunteer Lock-in Objective: Bloated Software Stacks and Intricate
> > Dependencies
> 
> Intricate software dependencies and high SLOC count (compared to historical 
> systems)
> are characteristics of many large-scale systems these days, open source or 
> not.

Yes, and that's a bug.   Move closer to where people are really serious
about software and you'll see that this is entirely unnecessary.


> 
> > Software which more or less works but needs
> > frequent repair, software which thwarts migration away from the
> > platform, and software for which maintenance work can not be broken down
> > into independent efforts is the ideal.  In software engineering we know
> > that the best way to achieve these aims is to produce systems comprised
> > of many more lines of code than is actually needed, to sprinkle that
> > code with platform-specific assumptions, to make each component depend
> > on as many others as possible, and to make certain that the interfaces
> > between components are poorly controlled and subject to frequent change.
> 
> So in other words, a bazaar-style, decentralised development model which
> places high value on reuse of code, a high value on readability of code at
> the expense of brevity, and a low value on backward compatibility?
> 
> Sounds good to me, for a highly under-development system - which is just
> what Gnu/Linux is!

I think you missed the sarcasm of my comments which I called out later
by bold-facing "the negation of best practices".


> 
> Users want backward compatibility of course and developers want to press on
> ahead and refactor and improve bad interfaces - but that's why God invented
> code branches and support contracts.

That wasn't God.


> 
> > The aims can be achieved by leading volunteer engineers into habits
> > which are simply the negation of best software engineering practices.
> 
> So a cathedral-style, centralised development model which discourages too much
> reuse of code, encourages brief, unreadable code, and is really anal about
> bug-for-bug 100% backward compatibility - that is what constitutes
> "best software engineering practices"?

Centralized -- no.

Discourages too much reuse -- yes.

Brief -- yes.

Unreadable -- no.

Anal about bug-for-bug 100% backward compatibility -- sometimes but not
always.  In the platform business, maybe even "often" rather than 
"sometimes".  Observe Sun in this regard.

"Cathedral-style" -- no comment can be made on that garbage essay.

It doesn't all reduce to the soundbite questions you've been led to
concentrate on.

> > Volunteer Lock-in Strategy: Exclude Thoughtful Engineers from Executive
> > Management
> 
> If you want notes like this to be read by VCs 

Ha ha ha ha.  That's funny.  Whew... that's rich.   Yes, very funny.
Ha ha.  A more intellectually disengaged bunch of powerful people 
you are less than likely to find.

> I see where you're going with the "exploitation" theme, but
> compared to poor labourers working in sweatshop-like conditions to produce
> many of the food, clothes, furnishings and electronics we all consume, I
> can't really get that worked up about it, personally. At least volunteers
> have a choice - by definition.

Think globally, act locally, and learn to recognize the patterns of
attack your enemy favors.

> 
> Basically, capitalism treats people like shit whenever it can get away with it
> (as we've just seen in New Orleans, with the smirking, bored-looking Bush
> [corrupt capitalist par excellence] even attracting the ire of formely 
> hard-core
> supporters for his handling of the rescue operation).
> 
> So in order to _fundamentally_ change the depradations of capitalism you need
> revolution, not liberal moral pleading. Liberal moral pleading can put 
> band-aids
> over some symptoms here and there (huge band aids on a human scale, sure), but
> it doesn't address the disease, it merely (at best) calls our attention to it.
> Sorry.

Capitalism as a mode of exchange and method for controlling the
distribution of goods is just fine, imo --- it's particular
*capitalists* who are the problem.

I engage in moral pleading because I know some of these guys, I
know where they come from, I was in school with some of them --
they are capable, even if not by-default inclined, to respond to
moral, ethical, engineering, and social responsibility arguments.
They are aware that should enough people like me fail, they face
the "up against the wall, mother-fucker" scenario.   If Katrina
has demonstrated anything, one thing is that when push comes to shove,
the military and the feds aren't there to protect *them*, not
that way at least.


> > Volunteer Lock-in Strategy: Trash and Take Over Threatening Projects
> > 
> > At certain times, projects that arise outside of the business activities
> > of GNU/Linux vendors may achieve a momentum and trajectory of their own
> > which undermines the interests of those vendors (GCC under Kenner vs.
> > Cygnus;  GNU Arch vs. Canonical).   With only moderate spending on
> > falsely-friendly "forks", such projects can be reliably taken over and
> > their maintainers discredited and pushed to the sidelines.
> 
> I think your personal interest here is clouding your judgement. I think
> that sadly, the fork had more to do with your pig-headedness, your erratic
> (to say the least) behaviour and the serious deficiencies of the tla 1.x
> design than any malevolent desire from Canonical to "trash and take over".
> Any one of those factors on its own could have been worked around - but
> together, they would have been a deal-breaker, I'm sure.

I put forward a plan -- involving infrastructure development and
political structure -- to improve my bandwidth and develop Arch
for the long term.

Canonical implemented all of my plan except for the part involving
detailed review of changes by myself and other "senior" developers.
And they used their implementation to run roughshod over the GNU
project.  They drove the resulting fork into a dive -- planning all
along to exploit, trash, and abandon those aspects of the Arch project
that they did not themselves control.


> 
> So, their behaviour was entirely rational

Talk to me in 5 years, assuming I'm still here, which is currently 
rather unlikely.

-t