[Ichthux-devel] The Future if IchthuX

[Ben Armstrong]

On 10/28/05, David Blue (Mailing List Addy) <davidslists at gmx.net> wrote:
> I'm not really talking long term solution here, I really only mentioned it
> because IchthuX doesn't work very well on my box and didn't work on the
> laptop I tried to use when I Was giving a presentation. Of course, neither
> did ubuntu 5.04 either, but that's another story all together. All I'm really
> wanting with this is to get a product out that supports with the hardware
> people are trying to use it on while we get our CDD or whatever completed.

Rushing to get out a product will do us no good and our users no good
if it turns out to be hard to support.  On the flip side, I see you're
worried that not rushing means the users end up with nothing.  That is
why I said that as an experiment, I'd support a parallel effort to
produce another edition of Ichthux based on whatever you would like,
but that this should not drag us away from the core work of Ichthux on
the CDD.

> You're right, I do have a different vision. My vision isn't about the CDDs, or
> packaging, or being the next great distro. It's about bringing the greatest
> glory to Christ.

Woah.  Let's not engage in a "who has the purer ideals" contest.  I
hope you realize that although our technical visions seem to clash,
this has little to do with our motivations for being involved in the
project.  We're really not going to progress very far and fast working
as a team if we attack each other in this way.  If, by suggesting that
your vision does not align with mine, you were offended, I sincerly
apologize.  I did not mean to say that your technical vision for
Ichthux is inferior or less purely motivated than mine, but merely
that it is different.  It is no crime to be different.  Diversity is
just as an important part of the free software world as it is of the
church.

>  If that is making this a CDD then, let us do that. But let
> us not become so pedantic in our focus on being a CDD that we lose sight of
> bringing Christ glory.

Well, let's not write off technical arguments you don't quite
understand as being "pedantic".  My arguments are not just abstract
theory.  I'm not just looking for a "correct" solution, and the users.
 Building a CDD is highly pragmatic and user-focused.

> As for my idea, yum and yast have nothing to do with developing IchthuX as a
> CDD, it has to do with getting the word of God to the widest possible
> audience.

And this is a good goal.  I do believe reaching a broader audience is
a good thing.  That's why I encouraged you to work on this in parallel
with work on IchthuX, perhaps as a sister project.  If we were to
broaden the IchthuX project goals too much, it would diffuse our
energies away from ever delivering the CDD.  I hope you understand the
logic in keeping narrow enough goals and see that this is in no way
opposed to the broader mandate of the Great Commission.

> I only mentioned it because it is my understanding that a
> distributed compile tool called icecream will make this process ridiculously
> easy, by being able to compile for different distro's quickly without having
> to do large amounts of reconfiguring. At least, if I am remembering what the
> kde dev I spoke with at Ohio linux fest correctly. So it then becomes a
> matter of some scripts and boom you've got our package, one for debian, one
> for yast, one for fedora, centos/rhel, etc. And really, after weeding out
> bugs in the setup due to compile/configuration errors on our part bugs get
> sent up stream.

I am highly skeptical of the quality of packages that such a tool
would produce.  The goals and architecture of different distributions
widely, and the idiosynchrasies of each package must be worked out by
intelligent solutions devised by the maintainers for each
distribution.  These differences per distribution multiplied by the
differences per package cannot be fully solved by automation.  I am
not saying that automation cannot assist in making packages
simultaneously for multiple Linux distribution, but you would need an
AI of immense proportions to be able to replace the work of the
maintainers of packages across all Linux distributions.  That last 20%
of packaging that is not merely mechanical is very, very difficult. 
It requires an understanding and sensitivity to the differing goals of
each distribution and intelligence to come up with innovative
solutions to problems where there is a clash between how upstream has
implemented something, and how the distribution requires it to be
implemented.

Ben