[nSLUG] Debian on an AMD 64

gnwiii at gmail.com gnwiii at gmail.com
Sun Dec 18 09:25:04 AST 2005

On 12/17/05, Jack Warkentin <jwark at eastlink.ca> wrote:
> Hi Everybody
> On December 16, 2005 06:31 pm, J. Paul Bissonnette wrote:
> > Ben Armstrong wrote:
> >
> > >On Fri, 2005-12-16 at 16:27 -0400, Jack Warkentin wrote:
> > >>I got an AMD64-based laptop a few weeks ago and am trying to find
> > >>a suitable distro for it. I read a lot about Debian AMD64 but it
> > >>did not look appealing since it is not possible to run 64-bit and
> > >>32-bit apps at the same time - you have to set up a separate
> > >>chroot for the 32-bit apps.
> > >>
> > >
> > >With open source, everything can be recompiled from source anyway.
> > >Or do you depend on a lot of non-free stuff distributed in binary
> > >form and only available for IA32?
> I depend on very little if any non-free stuff. But according to the
> Debian GNU/Linux AMD64 HOW-TO (see
> https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id271960
> ) "the current AMD64 port of debian is a pure 64bit port. This means
> you can't run binary only programs which are compiled for IA32 or
> applications which haven't been ported to AMD64 yet (e.g.
> OpenOffice.org). This is because you can't mix 32bit applications and
> 64bit libraries. You would also need the 32bit versions of the
> libraries to run a 32bit application."

SGI and Sun have had 64-bit OS's with robust support for legacy 32-bit apps
years, but it does add considerable complexity to things like autoconf.

I *do* depend on OpenOffice.org so I am stuck with needing an AMD64
> distro that includes the ability to run 32-bit apps at the same time
> as 64-bit apps. SuSE 10.0 and Kubuntu 5.10 both have this ability but
> I have issues with both.

OK.  OOo relies heavily on Java.  The linux AMD64 version of java is
relatively new.

See: <URL: http://artax.karlin.mff.cuni.cz/~kendy/blog/> and <URL:
http://blog.janik.cz/> for the status of 64-bit ports
of OOo.  Work is underway, but it is not ready to use.

> Say with recompiling the Debian source code, would this be simply
> > the 32 bit source in and a 64 bit app out? When it comes to software
> > engineering my best grade was a `F-`
> And on 16 Dec at 9:37 pm Ben Armstrong wrote:
> > Source code does not come in "32 bit" and "64 bit" flavours. :)

More like legacy (using int everywhere) and "standards conforming" (using
size_t, etc.), but if you want to take full advantage of 64-bit hardware
you may end up with a very different application.

> > There are potential issues with poorly written source that is
> > written assuming a 32 bit architecture that will not work on a 64
> > bit architecture, but that isn't "32 bit source", it is simply buggy
> > code.
> It is a little bit more than simply "poorly written source" or "buggy
> code". In the C programming language, size matters. Integer (short,
> int and long) and floating point (float and double) variables come in
> different sizes (number of bytes) which are implementation dependent.
> This affects not only simple variables but the way space is allocated
> in structures and arrays. Often integer variables and arrays are used
> to store bit strings so the number of bytes they occupy is critical.
> My knowledge of C is very limited so there are probably other issues
> where size does matter as well.

Many of the differences are handled by the libraries, e.g, generic types
are used instead of "int".  The system headers map "size_t" to the
type and also give you types for use where specific sizes (int16, etc.) are

So when it is said that a 32-bit application has not yet been ported
> to 64-bit it means that all such issues have not yet been resolved.

> Many of these 64-bit issues are already fixed in Debian because
> > Debian has for a long time supported other 64-bit architectures
> > (e.g. Alpha).
> >
> > But yes, essentially it is as you say. When you compile for a 64
> > bit architecture, you use the same source code that would be used to
> > compile the app for a 32 bit architecture.
> I would expect that there would be portions of the code that would be
> surrounded with  #ifdef <some identifier> ... #endif  some of which
> would apply only to 64-bit compiles and some of which would apply
> only to 32-bit compiles.

Only when the 64-bit port does things differently to exploit the hardware.
The issues in porting comes in deciding what changes should be
made to take advantage of 64-bit processing.  Do you allow huge files
even if they can't be used on the 32-bit version of the application?  For
the justification for using a 64-bit processor is to handle larger data.

George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nslug.ns.ca/mailman/private/nslug/attachments/20051218/ae7268f8/attachment-0001.html>

More information about the nSLUG mailing list