Re: Canonical and Debian
On 6/5/05, Tollef Fog Heen <tfheen@err.no> wrote:
> * "Michael K. Edwards"
>
> | So either Debian collectively is
> | willing to labor to maintain a high standard of portability and
> | stability, or we need to focus on a few arches and ignore
> | bugs-in-principle that don't happen to break on those systems.
>
> At the same time, if we're releasing i386, powerpc and amd64 we have a
> fair bit of spread: We have both little- and big-endian, we have 32
> bit and 64 bit and we have signed and unsigned char and we have
> linuxthreads and pure NPTL threading libraries.
>
> This doesn't uncover all possible build and runtime problems, but it's
> a good start to having portable code.
In 1990, this was a good start (substituting vendor variants of thread
libraries for linux variants). In 2005, a good start is to have a
variety of processor alignment constraints, a variety of OCaml and gcj
native-code back ends (and absences thereof), a variety of space/speed
trade-offs in the gcc -O2 defaults, and a variety of kernel
micro-versions. Granted that that's a higher quality standard than
could seriously have been proposed in 1990, but if you ever paid the
FSF $5K for a coherent GNU tools build (as I did back then), you know
how much the state of the art has improved.
When I first packaged an OCaml library with a native-code component, I
struggled with build issues on unfamiliar Linux ports. That's a
_good_ thing. It meant that I had to learn the difference between
optimized and optimizing OCaml compilers, and to fix broken upstream
build scripts that didn't make the distinction correctly. Next year,
when open-source MMIX cores have the best bang-for-the-buck in
embedded space :-), we'll be glad that Debian's 11 architectures cover
quite a bit of autoconf parameter space.
Cheers,
- Michael
Reply to: