Hello all,
I've got a simple question that I'd like to table for discussion. Current -devel tree seems to suggest that FC6 multilib FC6 has almost doubled in size (from ~13% of the total package count in FC4/5 to ~24% in the current devel tree) On the other hand, FC6 is about to include native 64bit OO and gcj (with browser support) builds, lowering the need for the default i386 support, as only Wine/Extra actually -requires- multilib support to run. More-ever, I'd venture to guess that most x86_64 installation will most likely be used to run native 64bit services and application - mostly on servers and workstation - lowering the need for multilib even further. (You won't run 32bit flash on your brand new 32 cores server... let alone that fact that flash/win32codecs are not supported by Fedora.)
My question is simple: why not add an installation option to disable multilib support completely.
Mind you, I use my workstation to run 32bit software and games... but I rather disable multilib completely and create a small, specialized 'stupid' i386 chroot (no DE, no user-applications; only a basic set of i386 libraries and UI toolkits) and use it to run i386 applications in a confined space. (Xen/i386 might be an interesting option - though it won't be able to run hardware GL applications which I need... ;))
- Gilboa
Gilboa Davara wrote:
Hello all,
I've got a simple question that I'd like to table for discussion. Current -devel tree seems to suggest that FC6 multilib FC6 has almost doubled in size (from ~13% of the total package count in FC4/5 to ~24% in the current devel tree) On the other hand, FC6 is about to include native 64bit OO and gcj (with browser support) builds, lowering the need for the default i386 support, as only Wine/Extra actually -requires- multilib support to run. More-ever, I'd venture to guess that most x86_64 installation will most likely be used to run native 64bit services and application - mostly on servers and workstation - lowering the need for multilib even further. (You won't run 32bit flash on your brand new 32 cores server... let alone that fact that flash/win32codecs are not supported by Fedora.)
My question is simple: why not add an installation option to disable multilib support completely.
Mind you, I use my workstation to run 32bit software and games... but I rather disable multilib completely and create a small, specialized 'stupid' i386 chroot (no DE, no user-applications; only a basic set of i386 libraries and UI toolkits) and use it to run i386 applications in a confined space. (Xen/i386 might be an interesting option - though it won't be able to run hardware GL applications which I need... ;))
- Gilboa
Sorry but I have to disagree here, the x86_64 arch is able to nativly run 32bit and 64bit software, so supporting multilib is using a feature of the hardware and there are many 32bit only apps out there and this also wont change in the near feature. If you don't need the 32bit libs you can simply remove all i386/i686 rpms (yum remove glibc.i686 should do it).
On Sun, 2006-08-20 at 19:13 +0200, dragoran wrote:
Gilboa Davara wrote:
Hello all,
I've got a simple question that I'd like to table for discussion. Current -devel tree seems to suggest that FC6 multilib FC6 has almost doubled in size (from ~13% of the total package count in FC4/5 to ~24% in the current devel tree) On the other hand, FC6 is about to include native 64bit OO and gcj (with browser support) builds, lowering the need for the default i386 support, as only Wine/Extra actually -requires- multilib support to run. More-ever, I'd venture to guess that most x86_64 installation will most likely be used to run native 64bit services and application - mostly on servers and workstation - lowering the need for multilib even further. (You won't run 32bit flash on your brand new 32 cores server... let alone that fact that flash/win32codecs are not supported by Fedora.)
My question is simple: why not add an installation option to disable multilib support completely.
Mind you, I use my workstation to run 32bit software and games... but I rather disable multilib completely and create a small, specialized 'stupid' i386 chroot (no DE, no user-applications; only a basic set of i386 libraries and UI toolkits) and use it to run i386 applications in a confined space. (Xen/i386 might be an interesting option - though it won't be able to run hardware GL applications which I need... ;))
- Gilboa
Sorry but I have to disagree here, the x86_64 arch is able to nativly run 32bit and 64bit software, so supporting multilib is using a feature of the hardware and there are many 32bit only apps out there and this also wont change in the near feature. If you don't need the 32bit libs you can simply remove all i386/i686 rpms (yum remove glibc.i686 should do it).
I'm not suggesting the multilib is not required, I am suggesting to give the option to disable it during the installation. BTW, isn't 'yum remove glibc.i686' a temporary solution? Won't yum will try to reinstall the missing package tree once I run 'yum update' and/or 'yum install foo'?
- Gilboa
On Sun, 2006-08-20 at 20:18 +0300, Gilboa Davara wrote:
I'm not suggesting the multilib is not required, I am suggesting to give the option to disable it during the installation. BTW, isn't 'yum remove glibc.i686' a temporary solution? Won't yum will try to reinstall the missing package tree once I run 'yum update' and/or 'yum install foo'?
- Gilboa
Please forgive my lousy English. I seem to be having a (very) bad-hair-day.
- Gilboa
Gilboa Davara wrote:
On Sun, 2006-08-20 at 19:13 +0200, dragoran wrote:
Gilboa Davara wrote:
Hello all,
I've got a simple question that I'd like to table for discussion. Current -devel tree seems to suggest that FC6 multilib FC6 has almost doubled in size (from ~13% of the total package count in FC4/5 to ~24% in the current devel tree) On the other hand, FC6 is about to include native 64bit OO and gcj (with browser support) builds, lowering the need for the default i386 support, as only Wine/Extra actually -requires- multilib support to run. More-ever, I'd venture to guess that most x86_64 installation will most likely be used to run native 64bit services and application - mostly on servers and workstation - lowering the need for multilib even further. (You won't run 32bit flash on your brand new 32 cores server... let alone that fact that flash/win32codecs are not supported by Fedora.)
My question is simple: why not add an installation option to disable multilib support completely.
Mind you, I use my workstation to run 32bit software and games... but I rather disable multilib completely and create a small, specialized 'stupid' i386 chroot (no DE, no user-applications; only a basic set of i386 libraries and UI toolkits) and use it to run i386 applications in a confined space. (Xen/i386 might be an interesting option - though it won't be able to run hardware GL applications which I need... ;))
- Gilboa
Sorry but I have to disagree here, the x86_64 arch is able to nativly run 32bit and 64bit software, so supporting multilib is using a feature of the hardware and there are many 32bit only apps out there and this also wont change in the near feature. If you don't need the 32bit libs you can simply remove all i386/i686 rpms (yum remove glibc.i686 should do it).
I'm not suggesting the multilib is not required, I am suggesting to give the option to disable it during the installation.
ok I got confused by your title "disable by default"
BTW, isn't 'yum remove glibc.i686' a temporary solution? Won't yum will try to reinstall the missing package tree once I run 'yum update' and/or 'yum install foo'?
I have never tryed it but all apps should somehow depend on glibc that means removing it will remove all i386/686 apps. yum supports execuldearch so you can force it not to install i386 packages. but I don't see a point in removing them... a x86_64 capable box won't have a small hardisk(s) so the extra libs wont be that much of a problem. **
- Gilboa
On Sun, 2006-08-20 at 19:23 +0200, dragoran wrote:
ok I got confused by your title "disable by default"
Bad subject on my side. Changed it to "Add option to disable multilib in Anaconda."
I have never tryed it but all apps should somehow depend on glibc that means removing it will remove all i386/686 apps. yum supports execuldearch so you can force it not to install i386 packages. but I don't see a point in removing them... a x86_64 capable box won't have a small hardisk(s) so the extra libs wont be that much of a problem.
Disk space aside, if you don't need multilib, the same 25% chase you until you delete all the i386 packages, read: +25% Internet bandwidth (especially now that extra and updates are integrated into Anaconda); +25% update time; +25% installation time; Even worse, once you've finally finished the installation (updates included), removing anything between 100 and 600 packages in no small task - It'll most likely render the machine useless for an extra hour or two.
I'm not suggesting we ship a multilib less DVD. I am suggesting we added an option to disable it during the installation.
Gilboa
On 21/08/2006 5:43 a.m., Gilboa Davara wrote:
On Sun, 2006-08-20 at 19:23 +0200, dragoran wrote:
ok I got confused by your title "disable by default"
Bad subject on my side. Changed it to "Add option to disable multilib in Anaconda."
I have never tryed it but all apps should somehow depend on glibc that means removing it will remove all i386/686 apps. yum supports execuldearch so you can force it not to install i386 packages. but I don't see a point in removing them... a x86_64 capable box won't have a small hardisk(s) so the extra libs wont be that much of a problem.
Disk space aside, if you don't need multilib, the same 25% chase you until you delete all the i386 packages, read: +25% Internet bandwidth (especially now that extra and updates are integrated into Anaconda); +25% update time; +25% installation time; Even worse, once you've finally finished the installation (updates included), removing anything between 100 and 600 packages in no small task - It'll most likely render the machine useless for an extra hour or two.
Definitely +1 here. I strongly agree. I run my x86_64 server purely with 64 bit applications and have no need or desire to install i386 binaries as well. Nothing I run or compile requires 32 bit libraries or anything 32 bit, and if there was an application that I found I'd be filing bugs upstream to get it fixed ASAP. This is a general purpose Internet server with BIND/Squid/Postfix/Apache/PHP etc and a variety of other little things which all compile fine from source in a 64 bit environment, in fact I can't remember ever coming across any application which wouldn't build and run.
All it should take from and end user perspective, is an extra tick box, currently defaulting to ticked (ie, multilib by default) somewhere in the installer. Being able to choose would save hours afterwards of looking through packages and uninstalling various things, working out all the dependencies when uninstalling etc
As the future lies more towards x86_64 than i386 this will become a bigger issue in time.
Here in NZ we are still on quotas, and unlimited high speed bandwidth is but a distant dream. So running rawhide with even more download not only takes longer but costs money as the traffic has to be downloaded from offshore.
If Fedora ever does start downloading updates as part of the install (like Windows seems to), this will be an issue then as well.
I've now got yum excluding *.i386 and that works fine after the event, but it's not applicable at install time.
[There are no NZ mirrors carrying rawhide, but that's another story, and less of an issue for me soon as I move to Australia in 2 1/2 weeks.]
reuben
On Sun, 2006-08-20 at 20:18 +0300, Gilboa Davara wrote:
On Sun, 2006-08-20 at 19:13 +0200, dragoran wrote:
Gilboa Davara wrote:
Hello all,
I've got a simple question that I'd like to table for discussion. Current -devel tree seems to suggest that FC6 multilib FC6 has almost doubled in size (from ~13% of the total package count in FC4/5 to ~24% in the current devel tree) On the other hand, FC6 is about to include native 64bit OO and gcj (with browser support) builds, lowering the need for the default i386 support, as only Wine/Extra actually -requires- multilib support to run. More-ever, I'd venture to guess that most x86_64 installation will most likely be used to run native 64bit services and application - mostly on servers and workstation - lowering the need for multilib even further. (You won't run 32bit flash on your brand new 32 cores server... let alone that fact that flash/win32codecs are not supported by Fedora.)
My question is simple: why not add an installation option to disable multilib support completely.
Mind you, I use my workstation to run 32bit software and games... but I rather disable multilib completely and create a small, specialized 'stupid' i386 chroot (no DE, no user-applications; only a basic set of i386 libraries and UI toolkits) and use it to run i386 applications in a confined space. (Xen/i386 might be an interesting option - though it won't be able to run hardware GL applications which I need... ;))
- Gilboa
Sorry but I have to disagree here, the x86_64 arch is able to nativly run 32bit and 64bit software, so supporting multilib is using a feature of the hardware and there are many 32bit only apps out there and this also wont change in the near feature. If you don't need the 32bit libs you can simply remove all i386/i686 rpms (yum remove glibc.i686 should do it).
I'm not suggesting the multilib is not required, I am suggesting to give the option to disable it during the installation. BTW, isn't 'yum remove glibc.i686' a temporary solution? Won't yum will try to reinstall the missing package tree once I run 'yum update' and/or 'yum install foo'?
then in your /etc/yum.conf add: exclude=*.i386 *.i686 *.i586 *.i486
that should ensure yum won't try to add anything like that back.
-sv
On 8/20/06, seth vidal skvidal@linux.duke.edu wrote:
On Sun, 2006-08-20 at 20:18 +0300, Gilboa Davara wrote:
I'm not suggesting the multilib is not required, I am suggesting to give the option to disable it during the installation. BTW, isn't 'yum remove glibc.i686' a temporary solution? Won't yum will try to reinstall the missing package tree once I run 'yum update' and/or 'yum install foo'?
then in your /etc/yum.conf add: exclude=*.i386 *.i686 *.i586 *.i486
that should ensure yum won't try to add anything like that back.
-sv
Thanks. Will it be possible to add it to Anaconda during the installation?
- Gilboa
On Sun, 2006-08-20 at 23:35 +0300, Gilboa Davara wrote:
On 8/20/06, seth vidal skvidal@linux.duke.edu wrote:
On Sun, 2006-08-20 at 20:18 +0300, Gilboa Davara wrote:
I'm not suggesting the multilib is not required, I am suggesting to give the option to disable it during the installation. BTW, isn't 'yum remove glibc.i686' a temporary solution? Won't yum will try to reinstall the missing package tree once I run 'yum update' and/or 'yum install foo'?
then in your /etc/yum.conf add: exclude=*.i386 *.i686 *.i586 *.i486
that should ensure yum won't try to add anything like that back.
-sv
Thanks. Will it be possible to add it to Anaconda during the installation?
Extremely doubtful. It would be the kind of question that would intimidate too many people.
If you want to fix this - edit the yum.conf your self in post.
-sv
On Sunday 20 August 2006 22:28, seth vidal wrote:
Extremely doubtful. It would be the kind of question that would intimidate too many people.
If you want to fix this - edit the yum.conf your self in post.
It would be kind of nice to pass yumopts at the anaconda boot CLI, such as yumopts="exclude *.i?86"
On Mon, 2006-08-21 at 08:44 -0400, Jesse Keating wrote:
On Sunday 20 August 2006 22:28, seth vidal wrote:
Extremely doubtful. It would be the kind of question that would intimidate too many people.
If you want to fix this - edit the yum.conf your self in post.
It would be kind of nice to pass yumopts at the anaconda boot CLI, such as yumopts="exclude *.i?86"
I really don't think we want yet more cli options.
Paul
On Monday 21 August 2006 08:58, Paul Nasrat wrote:
I really don't think we want yet more cli options.
Perhaps not, but the concern is a bit real. It would be really nice to set a way to only install x86_64 packages when starting the install from a CD or such, not a kickstart. Is there even a method to do this from kickstart? (and no, %post yum remove *.i?x86 doesn't count... (: )
On Mon, 2006-08-21 at 09:10 -0400, Jesse Keating wrote:
On Monday 21 August 2006 08:58, Paul Nasrat wrote:
I really don't think we want yet more cli options.
Perhaps not, but the concern is a bit real. It would be really nice to set a way to only install x86_64 packages when starting the install from a CD or such, not a kickstart. Is there even a method to do this from kickstart? (and no, %post yum remove *.i?x86 doesn't count... (: )
why doesn't %post yum remove *.i?86 count?
Why does EVERYTHING have to be accessible from within the installer? If a user wants to do something outside of the norm (and not install multilib packages, imo, is outside of the norm) then they should be able to login once and run one command.
-sv
On Monday 21 August 2006 09:39, seth vidal wrote:
why doesn't %post yum remove *.i?86 count?
Why does EVERYTHING have to be accessible from within the installer? If a user wants to do something outside of the norm (and not install multilib packages, imo, is outside of the norm) then they should be able to login once and run one command.
Because if I'm installing from remote sources, or if I'm at a datacenter, I really don't want to download 2x as many packages, install 2x as many packages, go through 2x as many scriptlets, just to remove 1/2 of them at the end of it all. Seems pretty silly to me. Are we going to get to the point where Anaconda just drops enough bits on the filesystem to reboot, launch pirut and continue the install from there?
On Mon, 2006-08-21 at 09:44 -0400, Jesse Keating wrote:
On Monday 21 August 2006 09:39, seth vidal wrote:
why doesn't %post yum remove *.i?86 count?
Why does EVERYTHING have to be accessible from within the installer? If a user wants to do something outside of the norm (and not install multilib packages, imo, is outside of the norm) then they should be able to login once and run one command.
Because if I'm installing from remote sources, or if I'm at a datacenter, I really don't want to download 2x as many packages, install 2x as many packages, go through 2x as many scriptlets, just to remove 1/2 of them at the end of it all. Seems pretty silly to me. Are we going to get to the point where Anaconda just drops enough bits on the filesystem to reboot, launch pirut and continue the install from there?
If you're at a datacenter installing linux then you should be installing by kickstart. If you're not doing that then you're doing a disservice to your customer b/c of the lack of a consistent install. :)
And then the kickstart install should be something like:
%packages
%post yum remove *.i?86 yum install stuff_I_want
-sv
On Monday 21 August 2006 09:49, seth vidal wrote:
If you're at a datacenter installing linux then you should be installing by kickstart. If you're not doing that then you're doing a disservice to your customer b/c of the lack of a consistent install. :)
Er, s/Datacenter/Colo/ What if it's just my box there, I'm not going to hassle with setting up my laptop to be a kickstart server to reinstall one system or two. My laptop might be the install source, but not a full blown kickstart box.
And then the kickstart install should be something like:
%packages
%post yum remove *.i?86 yum install stuff_I_want
Doesn't this seem backwards to you? Have anaconda run through, do all the dep checking, pull all the packages down and install them, then remove half of it (redoing dep checking), get a new list of packages to install, dep check again, download some more, and then install again?
Jesse Keating wrote:
On Monday 21 August 2006 09:49, seth vidal wrote:
If you're at a datacenter installing linux then you should be installing by kickstart. If you're not doing that then you're doing a disservice to your customer b/c of the lack of a consistent install. :)
Er, s/Datacenter/Colo/ What if it's just my box there, I'm not going to hassle with setting up my laptop to be a kickstart server to reinstall one system or two. My laptop might be the install source, but not a full blown kickstart box.
And then the kickstart install should be something like:
%packages
%post yum remove *.i?86 yum install stuff_I_want
Doesn't this seem backwards to you? Have anaconda run through, do all the dep checking, pull all the packages down and install them, then remove half of it (redoing dep checking), get a new list of packages to install, dep check again, download some more, and then install again?
what about adding a nomultilib boot option to anaconda and document it in the release notes? -> problem solved
On Mon, 2006-08-21 at 16:54 +0200, dragoran wrote:
Jesse Keating wrote:
On Monday 21 August 2006 09:49, seth vidal wrote:
If you're at a datacenter installing linux then you should be installing by kickstart. If you're not doing that then you're doing a disservice to your customer b/c of the lack of a consistent install. :)
Er, s/Datacenter/Colo/ What if it's just my box there, I'm not going to hassle with setting up my laptop to be a kickstart server to reinstall one system or two. My laptop might be the install source, but not a full blown kickstart box.
And then the kickstart install should be something like:
%packages
%post yum remove *.i?86 yum install stuff_I_want
Doesn't this seem backwards to you? Have anaconda run through, do all the dep checking, pull all the packages down and install them, then remove half of it (redoing dep checking), get a new list of packages to install, dep check again, download some more, and then install again?
what about adding a nomultilib boot option to anaconda and document it in the release notes? -> problem solved
adding options everywhere does not, in fact, solve the problem.
It just complicates code maintenance.
-sv
On Mon, 2006-08-21 at 10:57 -0400, seth vidal wrote:
On Mon, 2006-08-21 at 16:54 +0200, dragoran wrote:
Jesse Keating wrote:
Doesn't this seem backwards to you? Have anaconda run through, do all the dep checking, pull all the packages down and install them, then remove half of it (redoing dep checking), get a new list of packages to install, dep check again, download some more, and then install again?
what about adding a nomultilib boot option to anaconda and document it in the release notes? -> problem solved
adding options everywhere does not, in fact, solve the problem.
In my eyes, multilib is a part of the package selection and should be controllers by it. I fail to see why adding i386 packages (or removing them) is any different then wanting to add/remove any other package.
It just complicates code maintenance.
Yeah... but the same can be said against any new feature. *
-sv
Gilboa * And I should know, I use every-time someone tries to force some useless feature down my throat... ;)
Once upon a time, seth vidal skvidal@linux.duke.edu said:
If you're at a datacenter installing linux then you should be installing by kickstart. If you're not doing that then you're doing a disservice to your customer b/c of the lack of a consistent install. :)
And then the kickstart install should be something like:
%packages
%post yum remove *.i?86 yum install stuff_I_want
Okay, why don't we then just make anaconda either:
- always "Core" install (you can install the rest in %post or after boot)
- always "Everything" install (you can remove what you don't want in %post or after boot)
It is kind of dumb to spend time, bandwidth, and disk space installing packages only to immediately remove them (no matter how they are removed).
Jesse Keating jkeating@redhat.com wrote:
On Monday 21 August 2006 09:39, seth vidal wrote:
why doesn't %post yum remove *.i?86 count?
Why does EVERYTHING have to be accessible from within the installer? If a user wants to do something outside of the norm (and not install multilib packages, imo, is outside of the norm) then they should be able to login once and run one command.
Because if I'm installing from remote sources, or if I'm at a datacenter, I really don't want to download 2x as many packages, install 2x as many packages, go through 2x as many scriptlets, just to remove 1/2 of them at the end of it all. Seems pretty silly to me. Are we going to get to the point where Anaconda just drops enough bits on the filesystem to reboot, launch pirut and continue the install from there?
Is it really duplicating all packages for you? From what I see, the x86_64 install DVDs are just a little larger than the i386 ones, so...
On Monday 21 August 2006 11:12, Horst H. von Brand wrote:
Is it really duplicating all packages for you? From what I see, the x86_64 install DVDs are just a little larger than the i386 ones, so...
There are 688 i386 packages in the x86_64 repo. Add to that 1 i586 and 5 i686 packages. That's a lot of packages. On a default x86_64 install into Xen, I have 356 i386 packages installed. 356 is a lot of packages to send down the wire, unpack, layout on the file system, set selinux stuff, and do whatever pre/post processing necessary. Whats worse, a yum remove *.i?86 seems to want to take with it a fair number of x86_64 packages, which is not desired.
On Mon, 2006-08-21 at 12:34 -0400, Jesse Keating wrote:
On Monday 21 August 2006 11:12, Horst H. von Brand wrote:
Is it really duplicating all packages for you? From what I see, the x86_64 install DVDs are just a little larger than the i386 ones, so...
There are 688 i386 packages in the x86_64 repo. Add to that 1 i586 and 5 i686 packages. That's a lot of packages. On a default x86_64 install into Xen, I have 356 i386 packages installed. 356 is a lot of packages to send down the wire, unpack, layout on the file system, set selinux stuff, and do whatever pre/post processing necessary. Whats worse, a yum remove *.i?86 seems to want to take with it a fair number of x86_64 packages, which is not desired.
really? What x86_64 packages does it take and why?
-sv
On Mon, 2006-08-21 at 13:52 -0400, Jesse Keating wrote:
On Monday 21 August 2006 13:45, seth vidal wrote:
really? What x86_64 packages does it take and why?
I'm not entirely sure yet, I'm a bit swamped to do too much debugging right this moment, but I will very soon.
thank you -sv
On Monday 21 August 2006 12:34, Jesse Keating wrote:
Whats worse, a yum remove *.i?86 seems to want to take with it a fair number of x86_64 packages, which is not desired.
There must have been something weird with the state of my xen guest. I updated it to rawhide of last night (I had to remove nautilus.i386 which took out 4~ other i386 packages), then tried yum remove *.i?86 and this time yum only wants to remove 353 i386 packages. No x86_64 packages in the mix.
On 8/21/06, seth vidal skvidal@linux.duke.edu wrote:
Why does EVERYTHING have to be accessible from within the installer?
Is this where I ask for Maelstrom to be ported into python and integrated into anaconda?
-jef"mmm i smell boc choy in the wok"spaleta
Once upon a time Monday 21 August 2006 9:31 pm, Jeff Spaleta wrote:
On 8/21/06, seth vidal skvidal@linux.duke.edu wrote:
Why does EVERYTHING have to be accessible from within the installer?
Is this where I ask for Maelstrom to be ported into python and integrated into anaconda?
I think that is a fair request. While the long tedious install happens in the background you get to play leisurely game. :D better than tetris(1) in the installer.
Dennis
(1) http://www.capnkirby.com/Arklinux2005.2rc3.html yes arklinux lets you play tetris while the installer does its thing
On Mon, 2006-08-21 at 21:50 -0500, Dennis Gilmore wrote:
Once upon a time Monday 21 August 2006 9:31 pm, Jeff Spaleta wrote:
On 8/21/06, seth vidal skvidal@linux.duke.edu wrote:
Why does EVERYTHING have to be accessible from within the installer?
Is this where I ask for Maelstrom to be ported into python and integrated into anaconda?
I think that is a fair request. While the long tedious install happens in the background you get to play leisurely game. :D better than tetris(1) in the installer.
Dennis
(1) http://www.capnkirby.com/Arklinux2005.2rc3.html yes arklinux lets you play tetris while the installer does its thing
Caldera did it first.
Once upon a time, Nicholas Miell nmiell@comcast.net said:
On Mon, 2006-08-21 at 21:50 -0500, Dennis Gilmore wrote:
(1) http://www.capnkirby.com/Arklinux2005.2rc3.html yes arklinux lets you play tetris while the installer does its thing
Caldera did it first.
Solaris has had a web browser in (one of) the installers for years.
On Tue, 22 Aug 2006, Chris Adams wrote:
Once upon a time, Nicholas Miell nmiell@comcast.net said:
On Mon, 2006-08-21 at 21:50 -0500, Dennis Gilmore wrote:
(1) http://www.capnkirby.com/Arklinux2005.2rc3.html yes arklinux lets you play tetris while the installer does its thing
Caldera did it first.
Solaris has had a web browser in (one of) the installers for years.
Yeah, but the solaris installer is mostly an example of what *not* to do
g,d,r, chris
Once upon a time, Ralf Ertzinger fedora@camperquake.de said:
On Tue, 22 Aug 2006 09:04:50 -0400 (EDT), Chris Ricker wrote:
Yeah, but the solaris installer is mostly an example of what *not* to do
For one thing, it installs Solaris.
Only if you try really hard though; mostly it just frustrates the user.
On Mon, 2006-08-21 at 08:44 -0400, Jesse Keating wrote:
On Sunday 20 August 2006 22:28, seth vidal wrote:
Extremely doubtful. It would be the kind of question that would intimidate too many people.
If you want to fix this - edit the yum.conf your self in post.
It would be kind of nice to pass yumopts at the anaconda boot CLI, such as yumopts="exclude *.i?86"
--
I second the above. While I rather see this option in the Anaconda's package selection (instead of doing it from cli), having an option to disable mulitlib from the command line is good enough. (If you need a clean x86_64 install, you most likely know what you are doing and well capable of adding a yumopts command to the boot command line...)
Gilboa
Jesse Keating jkeating@redhat.com wrote:
On Sunday 20 August 2006 22:28, seth vidal wrote:
Extremely doubtful. It would be the kind of question that would intimidate too many people.
If you want to fix this - edit the yum.conf your self in post.
It would be kind of nice to pass yumopts at the anaconda boot CLI, such as yumopts="exclude *.i?86"
Longer term, it should probably be package groups in the vein of "Run i386 applications", "Development environment for i386 applications". Not there yet... but from what I see, x86_64 machines are the majority of what is being sold today, so wait a few years ;-)
On Sun, 2006-08-20 at 20:07 +0300, Gilboa Davara wrote:
Hello all,
I've got a simple question that I'd like to table for discussion. Current -devel tree seems to suggest that FC6 multilib FC6 has almost doubled in size (from ~13% of the total package count in FC4/5 to ~24% in the current devel tree) On the other hand, FC6 is about to include native 64bit OO and gcj (with browser support) builds, lowering the need for the default i386 support, as only Wine/Extra actually -requires- multilib support to run. More-ever, I'd venture to guess that most x86_64 installation will most likely be used to run native 64bit services and application - mostly on servers and workstation - lowering the need for multilib even further. (You won't run 32bit flash on your brand new 32 cores server... let alone that fact that flash/win32codecs are not supported by Fedora.)
My question is simple: why not add an installation option to disable multilib support completely.
Mind you, I use my workstation to run 32bit software and games... but I rather disable multilib completely and create a small, specialized 'stupid' i386 chroot (no DE, no user-applications; only a basic set of i386 libraries and UI toolkits) and use it to run i386 applications in a confined space. (Xen/i386 might be an interesting option - though it won't be able to run hardware GL applications which I need... ;))
- Gilboa
Changed topic to better reflect the post itself...
Gilboa
Gilboa Davara (gilboad@gmail.com) said:
I've got a simple question that I'd like to table for discussion. Current -devel tree seems to suggest that FC6 multilib FC6 has almost doubled in size (from ~13% of the total package count in FC4/5 to ~24% in the current devel tree)
Right. For dual-arch development.
My question is simple: why not add an installation option to disable multilib support completely.
There are yum configuration options for this already.
Bill
On Mon, 2006-08-21 at 12:13 -0400, Bill Nottingham wrote:
Gilboa Davara (gilboad@gmail.com) said:
I've got a simple question that I'd like to table for discussion. Current -devel tree seems to suggest that FC6 multilib FC6 has almost doubled in size (from ~13% of the total package count in FC4/5 to ~24% in the current devel tree)
Right. For dual-arch development.
My question is simple: why not add an installation option to disable multilib support completely.
There are yum configuration options for this already.
... But none can be set during installation, only post installation. I'm looking for an Anaconda switch.
Gilboa
-
Bill Nottingham -
Chris Adams -
Chris Ricker -
Dennis Gilmore -
dragoran -
Gilboa Davara -
Horst H. von Brand -
Jef Spaleta -
Jesse Keating -
Nicholas Miell -
Paul Nasrat -
Ralf Ertzinger -
Reuben Farrelly -
seth vidal