On Sat, 24 Feb 2001, Chris Tucker wrote:

> THIS TIME, however, I decided to try the precombiled binary thang. I went
> to the precompiled binary directly of the application "dt" and downloaded
> it, gunzipped and untarred it, and it WORKED with much less mucking about
> with the downloading and compiling that I had to put up with before (this
> is especially annoying when you're using a 16mhz cpu!)
>  
> This is really wonderful. This is so wonderful, in fact, that it worries
> me. If I download a precompile binary for "dt", will it work on all
> macs? from a Quadra 840AV with a 640x480 monitor to a SE/30 with it's tiny
> 9" monitor? The same binary will drive both those resolutions w/o
> problems?

The binary should be the same binary that you would have gotten, had you
built the package yourself, and yes, they do run on all macs. In fact,
except for rogues like "dt", m68k binaries run on all m68k machines (sun3,
mvme68k, etc.).

"dt", however, only runs on mac68k, because it requires an adb device. It
also has a bug that's triggered at high resolutions -- actually, long
line lengths. If the line overflows it's fixed buffer, it seems to wrap
nicely, at first, because the buffers are mostly contiguous, but then
after a while the wrapped pieces manifest as garbage on the right side of
the screen, and eventually the program segfaults. The bug is triggered by
running at 600x800 with the small font; I think the large font is good to
1024x768, but I forget.

The above has nothing to do with "source vs. binary", of course.

> What are the advantages/disadvantages of doing things the precompiled way
> vs. the "sup" way?

Sounds like you've figured out the advantages of using binary packages.
One _disadvantage_ is that the binary package collection is not always
consistent, or complete. Another is that the packages are always built
with the same default options. The "dt" package, for example, has a hook
to build with certain non-U.S. keyboards, including dvorak.


Frederick