| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Alex Turner" <armtuk(at)gmail(dot)com> |
| Cc: | "Steve Atkins" <steve(at)blighty(dot)com>, "Pgsql-Performance ((E-mail))" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: 64-bit vs 32-bit performance ... backwards? |
| Date: | 2006-06-13 02:44:01 |
| Message-ID: | 15368.1150166641@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"Alex Turner" <armtuk(at)gmail(dot)com> writes:
> Anyone who has tried x86-64 linux knows what a royal pain in the ass it
> is. They didn't do anything sensible, like just make the whole OS 64 bit,
> no, they had to split it up, and put 64-bit libs in a new directory /lib64.
Actually, there's nothing wrong with that. As this thread already made
clear, there are good reasons why you might want to run 32-bit apps as
well as 64-bit apps on your 64-bit hardware. So the 32-bit libraries
live in /usr/lib and the 64-bit ones in /usr/lib64. If you ask me, the
really serious mistake in this design is they didn't decree separate bin
directories /usr/bin and /usr/bin64 too. This makes it impossible to
install 32-bit and 64-bit versions of the same package at the same time,
something that curiously enough people are now demanding support for.
(Personally, if I'd designed it, the libraries would actually live in
/usr/lib32 and /usr/lib64, and /usr/lib would be a symlink to whichever
you needed it to be at the moment. Likewise for /usr/bin.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Browne | 2006-06-13 02:51:42 | Re: 64-bit vs 32-bit performance ... backwards? |
| Previous Message | Leigh Dyer | 2006-06-13 02:42:03 | Re: 64-bit vs 32-bit performance ... backwards? |