BICK to drop Sparc support

I have previously been releasing a package called BICK, which builds
bootable ISO images from file trees, with support for both Intel x86
PC and Sun Sparc platforms, even integrated into the same image so it
can boot on either (and, of course, run a different set of binaries).

Ref:  http://freshmeat.net/projects/bick/

Several problems have plagued the project, but the biggest one is the
collision between SILO, and mkisofs (now part of cdrtools).  SILO is
principly a hard drive boot loader, but can be used on CDROMs when a
patch it supplies is used to modify the mkisofs command so that when
the ISO is built with certain options, the SILO boot loader knows how
to find what it needs to find to load the kernel.

This has been a problem because mkisofs has seen upgrades which are
even included in various distributions, before SILO has upgraded the
patch to work with the new version.  But even with the patch now up
to date with mkisofs, the biggest problem remains that this still
requires patching mkisofs and recompiling, and mkisofs (and cdrtools)
is one of the more difficult packages to get compiled right (mostly
because its author, Jörg Schilling, has a very customized compilation
system, and doesn't treat Linux favorably (and has some valid points
in regard to that as well; see README.linux in cdrtools).

Long ago, SILO dealt with ISO images by having a program that modified
a produced ISO image to integrate the SILO boot time sectors into it,
and make the modifications necessary.  I believe SILO should go back
to that method, as opposed to attempting to track changes to mkisofs.
Alternatively, SILO should be designed to figure out where things are,
such as looking at the partition table and accessing the kernel image
in a partition, or finding its data blocks by reading the ISO filessytem
data pointers at run time instead of depending on a stored pointer.

Sun Sparc has a special way of handling partitions for booting kernels.
Why can't Linux be booted that way, too?  Apparently most everything
else can be done that way.

I do not want to require everyone who uses BICK on an Intel x86 system
to have to recompile cdrtools.  I do not want to have to distribute a
binary of mkisofs with BICK, which probably has to then be linked with
a number of different library versions so everyone can use it.

And I do not want to get into making modifications to SILO.  Hacking
things like that is good for one's own uses, but for long term software
releasing, this is really not a good practice.  Not only would I then
be dependent on SILO keeping up with cdrtools, but I'd further have to
make sure my patch to SILO would keep up, which would just be extra
work for me to do that I really don't need to add on.  Further, the
documentation on how certain things work in the Sparc machines, such
as the assembly language interfaces to the PROM code, has been hard to
find, and I just don't have the time to learn it on a code-and-debug
basis, or reverse engineer it from existing code (which cannot be an
exhaustive form of reference).

I am also a bit disillusioned by the directions Sun is taking with
regard to the support of Linux.  Basically, they are drawing a line
between Sparc and Intel's x86 architecture, and making that line also
be a line between Solaris and Linux (with regard to their support).
As I'm sure everyone here also believes, I believe these two lines
should be orthogonal, and either OS should be available for either
architecture, and that Sun should be happy to sell Sparc hardware to
Linux users looking for an alternative to Intel.

This has already resulted in dropping Sun Sparc from my business plans,
which were originally the inspiration to make BICK have Sparc support.
I will be looking at what options might be coming onto the market for
the PPC architecture, as an alternative to Sparc for the alternative
to Intel, but in the mean time, my business plans will be Intel-only.
That business is not about BICK, per se; it would just be a user of it.

I had intended to make this decision a couple months ago.  But I just
didn't really spend any time on the BICK project until now, so it was
simply held off.  But at this time I do need to have BICK move forward,
and the Sparc support is currently holding it back.  BICK version 0.8.0
supports Sparc, but version 0.9.0 most likely will not.  I'm hoping to
have the next BICK version out within a month, despite a big rewrite of
a large part of it.

The point I want to emphasize is that this decision is reversable.  If
conditions change, I could go back to adding Sparc support.  However,
the further BICK moves forward into Intel-only territory, the harder it
probably will be to add that support back in.  I will try to leave the
door open based on my understanding of how Sun Sparc booting works, but
that understanding was never 100% complete, and without practicing it
could certainly fade out as I move along.  It may end up that I can do
a Sparc version of BICK, but not an integrated one which would make a
dual-platform ISO.

I regret this decision, but it simply has to be made, and I no longer
have the time to put it off any further.

-- 
Phil Howard
[email protected]