Mailinglist Archive: opensuse (5130 mails)

< Previous Next >
Re: [SLE] Totally OT: 64/32,... -- memory models are _everything_ to programs
  • From: "Orn E. Hansen" <orn_hansen@xxxxxxxxxxx>
  • Date: Tue, 16 May 2006 20:13:35 +0200
  • Message-id: <200605162013.35511.orn_hansen@xxxxxxxxxxx>
Mánudaginn 15 maí 2006 22:46 skrifaði Jerry Feldman:
> The beauty (and bane) of the x86-64 architectures is that it enables us to
> effectively transition from 32-bit to 64-bit architecture. The bane is that
> some [lazy] developers don't want to make their code 64-bit clean.
> Additionally, 32-bit code running on a 64-bit OS on this architecture may
> run faster than if it were native. One thing we ran into on Alpha/NT is
> that we had a mode that allowed X86 code to run under emulation/translation
> so we had a good application base. The downside was that vendors didn't
> want to port their code to native Alpha so that we really never got a lot
> of good native Alpha applications.
>
Lot of the issues, are related to compilers rather than actually the
developers themselves. But when considering certain commercial stuff,
upgrading or cleaning code may be even harder work and more expensive than
creating the original codebase itself. While at the same time people using
this code, don't want to throw away their investment in the software.

Seen from my point of view, there are some technologies that are
preferrable. 1) Getting rid of the hour "sleep" time of a desktop Linux,
during night hour batch jobbing that is inherent from old Unix and totally
reduntant in the modern desktop world. 2) Being able to boot directly into
an "image" of the last active state. 3) Being able to optimize code into
8/16/32 bit where possible. 4) Being able to have a single codebase library,
so that a library only needs to be loaded "once", so that whenever I start my
puny program my puter won't sleep for a whole minutes while waiting for all
the libraries to initialize. 4) Being able to use the "backwards"
compatibility of the platform, without having to literally boot into DOS. I
personally think these are vital technologies to implement, not to push under
a blanket and wait for someone else to do the job.

> I would prefer on this net, we try to provide solutions to problems.
That is my preferred view.

> --
> Jerry Feldman <gaf@xxxxxxx>
> Boston Linux and Unix user group
> http://www.blu.org PGP key id:C5061EA9
> PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

< Previous Next >
Follow Ups