64bit clean AMD64?

[Peter Arremann]

All,

I was trying to install a 64bit clean (no 32bit code) version of FC3 and 
rawhide this week and I was wondering why there is no good option for this? 
On a webserver I don't need to have a 32bit firefox plugin - but even if I 
deselect all graphical stuff, I still get some i386 packages in there...

What is the future direction on this? When I look at OSF/1 or the IA64 bit 
versions of most Linux distributions I get jealous on how clean their 
environment is... For most server environments, 32bit versions of libraries 
you don't need are just clutter...

Peter.

[Thomas Zehetbauer]

You always get some unnecessary packages, even with pure bitness
installations, for example pcmcia-cs, just remove them manually.

Tom

-- 
  T h o m a s   Z e h e t b a u e r   ( TZ251 )
  PGP encrypted mail preferred - KeyID 96FFCB89
      finger thomasz(a)hostmaster.org for key

Why do you call your dog 1234?
My admin told me not to name my password after my dog.

[Jerone Young]

I would question what you mean by "clean". It is clean already. 64-bit
libraries and 32-bit libraries are clearly separated and there is no
confusion. Most of your apps are compiled 64-bit , some with 32-bit
libraries for backward compatibility. Not every app (open office for
instance) is 64-bit ready. You know the difference is that IA-64 has
NO backward compatibility with anything else. There is a lot of
software that written for Linux (non open source of course) that is
compiled for 32-bit Linux (the most popular Linux). Your system is
going to run at the same speed with or without 32-bit libraries. Also
as mentioned above you can just manually remove them if they bother
you that much. But you may one day need a program that is not 64-bit
ready.  I think your wining is ridiculous.

On Sat, 05 Mar 2005 04:00:21 +0100, Thomas Zehetbauer
<thomasz(a)hostmaster.org&gt; wrote:
>  You always get some unnecessary packages, even with pure bitness
>  installations, for example pcmcia-cs, just remove them manually.
>  
>  Tom
>  
>  --
>    T h o m a s   Z e h e t b a u e r   ( TZ251 )
>    PGP encrypted mail preferred - KeyID 96FFCB89
>        finger thomasz(a)hostmaster.org for key
>  
>  Why do you call your dog 1234?
>  My admin told me not to name my password after my dog.
>  
>  
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-devel-list
>  
>  
>

[Peter Arremann]

On Friday 04 March 2005 22:38, Jerone Young wrote:
>  I think your wining is ridiculous. 
Wasn't aware anyone was whining :-)
I was simply wondering about the future direction - for servers I could care 
less about openoffice - I need a system that works well. Since FC is the 
prototype for RHEL and RH is more open to giving out info about future FC 
releases than EL, it's in my opinion a valid question.
I think I was pretty clean with the examples of Tru64 and IA64 Linux what I 
meant with 64bit clean. I meant the platform as a whole, not a specific piece 
of software. If you have a better name for that I'd love to hear it.

Peter.

[Jef Spaleta]

On Fri, 4 Mar 2005 22:50:03 -0500, Peter Arremann <loony(a)loonybin.org&gt; wrote:
>  On Friday 04 March 2005 22:38, Jerone Young wrote:
>  > I think your wining is ridiculous.
>  
>  Wasn't aware anyone was whining :-)
>  I was simply wondering about the future direction - for servers I could care
>  less about openoffice - I need a system that works well. Since FC is the
>  prototype for RHEL and RH is more open to giving out info about future FC
>  releases than EL, it's in my opinion a valid question.
>  I think I was pretty clean with the examples of Tru64 and IA64 Linux what I
>  meant with 64bit clean. I meant the platform as a whole, not a specific piece
>  of software. If you have a better name for that I'd love to hear it. 
what istall type are you actually doing in the installer? are you
doing a minimal install or server?  'server' as a default install type
is a rather generic concept.. and is not going to meet any single
person's definition completely.  To really setup a server for specific
tasks requires customization you aren't going to be able to rely on a
default install type in the installer to give you exactly what you
want. Why isn't kickstart file creation enough flexibility to create
the system the specific system that you want?  There is room in the
ecosystem for an array of pre-baked kickstart files if there are
people in the community willing to work on them..collect them.. and
maintain them.

-jef"mmmmm beer"spaleta

[Peter Arremann]

On Friday 04 March 2005 22:58, Jeff Spaleta wrote:
>  what istall type are you actually doing in the installer? are you
>  doing a minimal install or server?  'server' as a default install type
>  is a rather generic concept.. and is not going to meet any single
>  person's definition completely.  To really setup a server for specific
>  tasks requires customization you aren't going to be able to rely on a
>  default install type in the installer to give you exactly what you
>  want. Why isn't kickstart file creation enough flexibility to create
>  the system the specific system that you want?  There is room in the
>  ecosystem for an array of pre-baked kickstart files if there are
>  people in the community willing to work on them..collect them.. and
>  maintain them.
>
>  -jef"mmmmm beer"spaleta 
Jeff, its a custom install - when you get to the selection of installed 
packages the following components were selected:
Textbased Internet
Server Configuration Tools
Web Server
Mail Server
FTP Serever
Mysql Database (add php-mysql)
Development Tools
Administration Tools
System Tools (add am-utils)

With that, in both FC3 and Rawhide you still get some 32bit rpms. From the 
installer there is no way to tell what will end up installing 32bit stuff.

So I went ahead and tried install a AMD64 box with FC3 and the packages above, 
I then "rpm -qa --queryformat="%{name}-%{version}-%{release}.%{arch}\n" | 
grep i386 | xargs rpm -e" 

After that I had a box without 32bit packages... Then I do a yum update to get 
the latest updates (that was about 3 weeks ago) and when I get back it showed 
that boost for some reason wanted to install "some" i386 packages - 142 of 
them to be exact... 
I'm sure that was just a packaging error of some form (dependency to -devel 
package I think) but when trying to figure out if there is a way to prevent 
this, I found no good answer...

Peter.

[Jef Spaleta]

On Sat, 5 Mar 2005 11:43:51 -0500, Peter Arremann <loony(a)loonybin.org&gt; wrote:
>  I'm sure that was just a packaging error of some form (dependency
> to -devel
>  package I think) but when trying to figure out if there is a way to prevent
>  this, I found no good answer... 
preventing packaging problems... no there is no good answer...
packagers make mistakes.      If you feel that one specific case with
boost was a packaging problem it needs to be filed as a bug.


-jef

[Paul A Houle]

On Fri, 4 Mar 2005 21:08:35 -0500, Peter Arremann <loony(a)loonybin.org&gt;  
wrote:

>  What is the future direction on this? When I look at OSF/1 or the IA64  
>  bit
>  versions of most Linux distributions I get jealous on how clean their
>  environment is... For most server environments, 32bit versions of  
>  libraries
>  you don't need are just clutter...
>  
	Funny enough,  many operating system for Ultrasparc (both Solaris and  
Debian Linux) decide to run a 32-bit userspace under a 64-bit kernel.

	I think things are different with SPARC than with AMD64;  AMD64 not only  
widens registers,  but it adds more registers.  Some things run faster in  
64-bit mode in AMD64.  On the other hand,  applications that handle a lot  
of pointers will bulk up substantially in 64-bit mode:  32-bit binaries  
will lose less RAM.

	If you're running,  say,  mod_perl,  under Apache prefork,  or even a  
Java system that burns a lot of RAM,  you might be better off running in  
32-bit mode than 64-bit mode.