Mailing List Archive

Mark Knecht wrote:
> 2010/12/9 Mateusz Arkadiusz Mierzwinski<mateuszmierzwinski@gmail.com>:
>
>> Dale, I tell You one thing - choose multilib. This don't do nothing wrong.
>> You can use 32-bit app compatibility and this don't reduce performance of
>> overall system.
>>
> Agreed. I think the only downside is _slightly_ slower emerge times
> which with modern processors like Dale is going to use shouldn't be
> much of an issue at all. I don't know of any other negative side
> effects.
>
> Cheers,
> Mark
>
>

Again, things are in flux here. You folks may have to look at time
stamps to see where my brain is at any given point.

It sounds like I need to go multilib for now and when everything gets
sorted out for pure 64 bit, then switch to pure 64. I say this because
I can switch from mulitlib to no-multilib without reinstalling. The
reverse is not the case and requires a re-install. Correct?

I'm glad I came on here and asked questions now. O_O

Dale

:-) :-)

P. S. I got more replies to read. Watch me change my mind again. lol

J. Roeleveld wrote:
> On Thursday 09 December 2010 12:58:36 Paul Jewell wrote:
>
>> When I installed my system back in January, I started off with 64 bit only,
>> and immediately hit a problem with grub compilation. I switched to
>> multilib, and the installation went smoothly. I would recommend Pappy's
>> seeds as a starting point for kernel configuration. Even if you don't use
>> his seed, the debian resource to identify drivers is useful. If you need a
>> link, I'll sort it out when I get home. I have not had any issues with the
>> multilib setup, and compared to my old AthlonXP system it flies!
>>
> Ok, that's probably why it works for me then :)
> I use multilib as I prefer the flexibility and didn't have to go with grub-
> static for a while now.
>
> --
> Joost Roeleveld
>
>
>

I'm thinking, AT THE MOMENT, of going multilib and grub-static. That
way down the road, I can switch to no-multilib and not have to reinstall
grub. To simple huh?

Dale

:-) :-)

Duncan wrote:
> Florian Philipp posted on Thu, 09 Dec 2010 11:12:36 +0100 as excerpted:
>
>
>>> However, kde4 uses a database for akonadi. With older versions (thru
>>> 4.3 at least), it was mysql by default.
>>>
>> [...]
>>
>> Same issue with Amarok.
>>
> Thanks for the reminder. I'd forgotten about amarok, as I got disgusted
> with it awhile back, when they basically decided their amd64 users didn't
> matter (the embedded mysql lib they were using was broken on amd64, and it
> wasn't exactly an unknown break, either, they simply didn't care about
> such users enough to stop them from making it mandatory), and switched to
> something (mpd, with several front-ends, still less bloated than amarok)
> far less bloated and more in tune with my needs anyway. Of course, it
> didn't help that they'd dumped most of the features I found likable in the
> kde3 version, only to add more bloat I found nothing but useless to the
> kde4 version, either, but it was the utter unconcern about their kde4 amd64
> users, when kde3 was already no longer supported by kde itself (and was on
> its way out for Gentoo) that was the last straw for me.
>
> But yes, amarok requires mysql too, unfortunately.
>
>

I can do this then. I'll just copy everything on /home over EXCEPT the
.kde directory. I don't have anything in there anyway. I use Seamonkey
for email so as long as I have .mozilla, I'm good to go. Heck, I may
just copy .mozilla over and let the rest go. Well, I need my Documents
folder too.

Looks like this was simple enough to solve. Just leave .kde behind at
least. No worries. Wish the multilib issue was this simple. o_O

Dale

:-) :-)

On Fri, Dec 10, 2010 at 2:27 AM, Frank Peters <frank.peters@comcast.net> wrote:
> On Thu, 9 Dec 2010 11:58:36 +0000
> "Paul Jewell" <paul@teulu.org> wrote:
>
>> When I installed my system back in January, I started off with 64 bit
>> only, and immediately hit a problem with grub compilation.
>
> Why not just use lilo?  Lilo doesn't need the kernel to boot the
> system and it compiles on pure 64-bit systems.
>
> I hate to proselytize, but it seems to me that grub has been pushed
> into the Linux world without merit.  Lilo does the job just as well.

What's the advantage of LILO nowadays? I used grub because of two
reasons: 1) I don't need to re-install the MBR when changing grub's
.conf file and 2) I can edit configuration at boot time, useful when
you messed up your grub.conf. Last time I checked (admittedly long
time ago) LILO cannot do both of these. Granted, I've never used LILO,
does it boot faster or runs on more platforms or is there any
particular reason why you used it?

On Thu, Dec 9, 2010 at 11:37 AM, Dale <rdalek1967@gmail.com> wrote:

> Frank Peters wrote:
>
>> On Thu, 9 Dec 2010 10:04:52 +0000 (UTC)
>> Duncan<1i5t5.duncan@cox.net> wrote:
>>
>>
>>
>>>
>>>
>>>> Stan Sander wrote:
>>>>
>>>>
>>>
>>>
>>>> In addition to using grub-static, you will need to have the IA32
>>>>> Emulation enabled in your kernel, else you won't be able to execute
>>>>> grub at all. It's under file formats / Emulations in the menu.
>>>>>
>>>>>
>>>> I think that's covered in the handbook, now, but posting's still good,
>>> just in case it would have been overlooked. FWIW when I first switched
>>> to
>>> no-multilib, before I did the 32-bit chroot thing, I tried turning off
>>> that option in the kernel... and found I couldn't run... I think it was
>>> lilo I was running at the time, properly, so it's definitely worth
>>> remembering.
>>>
>>>
>>>
>> Lilo doesn't need the kernel at all. I have IA32 turned off and I use
>> lilo to boot. There is no problem.
>>
>> Unless there is some special requirement, most people probably use grub
>> because of the "follow the leader" syndrome. Lilo is still quite
>> effective
>> and also quite simple. Fortunately, the Gentoo overlords have not removed
>> lilo from the portage tree, but if they ever do, I will just compile it
>> myself. Continuous change is not a law of the universe. Some methods
>> never become obsolete (out of fashion perhaps, but fashion should never
>> be the final guide).
>>
>> Frank Peters
>>
>>
>>
>
> No offense intended but I have used both lilo and grub. I used lilo first
> and for me, it was a nightmare. Fixing even a small typo was painful for
> me. I switched to grub and the difference was like flying the space shuttle
> or riding a tri-cycle. Let's remove the computers from the space shuttle
> just to make it as difficult.
>
> I may have to use lilo one day but grub will be long dead and will not
> compile on any rig I have.
>
> Dale
>
>
Good analogy. My issue with grub is that when it fails, I'm stuck in a tin
can in low earth orbit and likely to burn up in the atmosphere.

Recovering from a fall off my tri-cycle is not nearly as painful.



> :-) :-)
>
>

On Thu, Dec 9, 2010 at 8:55 AM, Dale <rdalek1967@gmail.com> wrote:
<SNIP>
>
> I'm thinking, AT THE MOMENT, of going multilib and grub-static.  That way
> down the road, I can switch to no-multilib and not have to reinstall grub.
>  To simple huh?
>
> Dale

Sounds like things are still in flux somewhere. ;-) ;-)

I think multilib for now is really best. Once I thought I'd do what
you outline above. After a while I decided I'm not using my computer
to make a political statement and why change. It's not important to me
and 32-bit support gives you options even if you don't use them.

There are other things that haven't been discussed like running a
chroot with 32-bit or VMWare running 32-bit Windows. I have no idea
how the multilib/no-multilib thing effects those and why do I care?

I certainly don't remember any problems specifically caused by
multilib bringing down a 64-bit system so why not run it?

You'll be happy.

- Mark

Harry Holt wrote:
>
> On Thu, Dec 9, 2010 at 11:37 AM, Dale <rdalek1967@gmail.com
> <mailto:rdalek1967@gmail.com>> wrote:
>
> Frank Peters wrote:
>
> On Thu, 9 Dec 2010 10:04:52 +0000 (UTC)
> Duncan<1i5t5.duncan@cox.net <mailto:1i5t5.duncan@cox.net>> wrote:
>
>
>
> Stan Sander wrote:
>
>
> In addition to using grub-static, you will need to
> have the IA32
> Emulation enabled in your kernel, else you won't
> be able to execute
> grub at all. It's under file formats / Emulations
> in the menu.
>
> I think that's covered in the handbook, now, but posting's
> still good,
> just in case it would have been overlooked. FWIW when I
> first switched to
> no-multilib, before I did the 32-bit chroot thing, I tried
> turning off
> that option in the kernel... and found I couldn't run... I
> think it was
> lilo I was running at the time, properly, so it's
> definitely worth
> remembering.
>
>
> Lilo doesn't need the kernel at all. I have IA32 turned off
> and I use
> lilo to boot. There is no problem.
>
> Unless there is some special requirement, most people probably
> use grub
> because of the "follow the leader" syndrome. Lilo is still
> quite effective
> and also quite simple. Fortunately, the Gentoo overlords have
> not removed
> lilo from the portage tree, but if they ever do, I will just
> compile it
> myself. Continuous change is not a law of the universe. Some
> methods
> never become obsolete (out of fashion perhaps, but fashion
> should never
> be the final guide).
>
> Frank Peters
>
>
>
> No offense intended but I have used both lilo and grub. I used
> lilo first and for me, it was a nightmare. Fixing even a small
> typo was painful for me. I switched to grub and the difference
> was like flying the space shuttle or riding a tri-cycle. Let's
> remove the computers from the space shuttle just to make it as
> difficult.
>
> I may have to use lilo one day but grub will be long dead and will
> not compile on any rig I have.
>
> Dale
>
>
> Good analogy. My issue with grub is that when it fails, I'm stuck in
> a tin can in low earth orbit and likely to burn up in the atmosphere.
>
> Recovering from a fall off my tri-cycle is not nearly as painful.
>
>
> :-) :-)
>
>

When lilo failed for me one time, I had to reinstall. I couldn't get
anything to work. With grub, I just edit the boot line. If grub
doesn't load, boot a CD, mount the partitions and chroot in to fix it.
I have never had to do that with grub tho. I have no clue how to fix
lilo tho.

Some of this is because grub has "just worked" for me and lilo was a
pain for me. Maybe it has changed, I don't know. I just remember how
it was back then.

Dale

:-) :-)

On Fri, 10 Dec 2010 04:04:50 +1100
Lie Ryan <lie.1296@gmail.com> wrote:

>
> What's the advantage of LILO nowadays? I used grub because of two
> reasons: 1) I don't need to re-install the MBR when changing grub's
> .conf file and 2) I can edit configuration at boot time, useful when
> you messed up your grub.conf. Last time I checked (admittedly long
> time ago) LILO cannot do both of these. Granted, I've never used LILO,
> does it boot faster or runs on more platforms or is there any
> particular reason why you used it?
>

For one thing, it is completely independent of the kernel and some
were expressing concerns about compatibility with 64-bit.

Lilo is also simpler, but it is not as versatile as grub.

My point is not that lilo is an advantage, but that it should not
be overlooked by those who may not require a complex set-up.
The trend seems to be to trash everything in favour of grub.

The legacy boot method is being slowly eliminated and will be
replaced by EFI. For this there is elilo, which I hope to be
using.

Frank Peters

Dale posted on Thu, 09 Dec 2010 10:28:39 -0600 as excerpted:

> One would think people would learn from KDE that stopping support for
> one to favor the new one makes people . . . upset. I guess some people
> never learn tho.

Well, the grub thing has been going on for years, from well before kde4.
It was just hidden better, because as I said, it's a small enough program
that the distributions could reasonably take up the slack.

It seems trinity is doing the same with kde3, but it took long enough to
pick it up that the gap was very visible to users, and it remains to be
seen how well they'll do. But I do wish them well, it's actually possible
to do with FLOSS, and if things go well, here in a few years we'll have a
qt (by then qt4) based "lite" desktop, with trinity or whatever they've
decided to call it by then, parallel on the qt side, to the gtk-based xfce
on the gtk side. Perhaps that's the best of both worlds, but it would
have been nice had that support gap never had to happen. <shrug>

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Frank Peters posted on Thu, 09 Dec 2010 10:36:29 -0500 as excerpted:

> On Thu, 09 Dec 2010 00:11:20 -0600
> Dale <rdalek1967@gmail.com> wrote:
>
>
>> I do have nvidia video cards. I assume the nvidia-drivers package will
>> work fine with no-multilib? The way I am reading things it will but I
>> do want drivers that work.
>>
>>
> Don't forget about the stock nv driver that is supplied by Xorg. It may
> not have 3D acceleration but it will perform very well for most common
> activities. Both work as no-multilib.
>
> I set up my system in a way that allows me to start X with either the nv
> or the proprietary nvidia driver. For normal activities, which is most
> of the time, I use nv, but there are some occasions when I require the
> full power of the proprietary nvidia.

FWIW and heads-up: The nv driver has been partially supported by nVidia
in the past, mostly as a driver that can be run long enough for users to
get to the nVidia site and download the nVidia driver. However, they've
announced its deprecation, and that they won't be updating it any longer.
Officially, nVidia says users can switch to the also unaccelerated vesa
driver if needed, but they don't mention the nouveau driver. The word is,
however, that the nouveau driver is already better than the nv driver and
that distributions were starting to ship it anyway, to the point that it
really didn't make that much sense for nVidia to continue supporting the nv
driver.

So do consider switching, at least as you upgrade. It's probably not
ready to switch to for folks on 100% stable just yet, but as stable
upgrades, it should be.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Thu, Dec 9, 2010 at 2:01 PM, Frank Peters <frank.peters@comcast.net>wrote:

> On Fri, 10 Dec 2010 04:04:50 +1100
> Lie Ryan <lie.1296@gmail.com> wrote:
>
> >
> > What's the advantage of LILO nowadays? I used grub because of two
> > reasons: 1) I don't need to re-install the MBR when changing grub's
> > .conf file and 2) I can edit configuration at boot time, useful when
> > you messed up your grub.conf. Last time I checked (admittedly long
> > time ago) LILO cannot do both of these. Granted, I've never used LILO,
> > does it boot faster or runs on more platforms or is there any
> > particular reason why you used it?
> >
>
> For one thing, it is completely independent of the kernel and some
> were expressing concerns about compatibility with 64-bit.
>
> Lilo is also simpler, but it is not as versatile as grub.
>
> My point is not that lilo is an advantage, but that it should not
> be overlooked by those who may not require a complex set-up.
> The trend seems to be to trash everything in favour of grub.
>
> The legacy boot method is being slowly eliminated and will be
> replaced by EFI. For this there is elilo, which I hope to be
> using.
>
> Frank Peters
>
>
Yes, simplicity is why I have continued to stick with lilo (since 1995). It
just always has worked. There's nothing more frustrating for me than trying
to boot a machine and being presented with a

grub >

and having no clue what went wrong or where to go (although, yes, that's
because of experience with lilo - and lack of it with grub). I did try to
use grub for a time when it became popular, but after my first experience
with it trying to recover from a failed boot I gave up.

The main advantage to me - why I started using it - was that it plays well
with the Windows loader. I don't do those kind of dual-boot machines
anymore, but it was very convenient being able to recover a Windows boot
manager - or install a new one - and all I had to do to get back to my Linux
boot was edit the BOOT.INI file.

... HH

Dale posted on Thu, 09 Dec 2010 10:53:02 -0600 as excerpted:

> Again, things are in flux here. You folks may have to look at time
> stamps to see where my brain is at any given point.
>
> It sounds like I need to go multilib for now and when everything gets
> sorted out for pure 64 bit, then switch to pure 64. I say this because
> I can switch from mulitlib to no-multilib without reinstalling. The
> reverse is not the case and requires a re-install. Correct?

Correct.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Dale posted on Thu, 09 Dec 2010 11:03:56 -0600 as excerpted:

> I can do this then. I'll just copy everything on /home over EXCEPT the
> .kde directory. I don't have anything in there anyway. I use Seamonkey
> for email so as long as I have .mozilla, I'm good to go. Heck, I may
> just copy .mozilla over and let the rest go. Well, I need my Documents
> folder too.
>
> Looks like this was simple enough to solve. Just leave .kde behind at
> least. No worries. Wish the multilib issue was this simple. o_O

Seems to be good.

Depending on how much customizing you do to your kde (and mozilla), you
can try copying them over too. If anything breaks, you know what to
"uncopy". =:^/ But it might be easier to do that and find what to uncopy
if necessary, then re-customize everything, at least if you're as heavy a
customizer as I am. And worst-case, you simply erase that bit and start
clean.

Meanwhile, for the akonadi stuff at least, there's a bit of config
outside .kde. I'm not /exactly/ sure of the default location as I've
changed enough stuff around here to never be sure, but I /believe/ that
bit is in ~/.config/<something> by default. (Maybe .config/akonadi/ ?)

But if you don't use kmail, kontact or kopete either, it may be that
you'll never notice an akonadi issue even if there is one.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Duncan writes:

> Dale posted on Thu, 09 Dec 2010 11:03:56 -0600 as excerpted:

> > Looks like this was simple enough to solve. Just leave .kde behind at
> > least. No worries. Wish the multilib issue was this simple. o_O
>
> Seems to be good.
>
> Depending on how much customizing you do to your kde (and mozilla), you
> can try copying them over too. If anything breaks, you know what to
> "uncopy". =:^/ But it might be easier to do that and find what to uncopy
> if necessary, then re-customize everything, at least if you're as heavy a
> customizer as I am. And worst-case, you simply erase that bit and start
> clean.

As I hate to re-create my KDE setup from scratch, I simply did nothing when
I switched to 64bits a while ago. No problem. I even dual-booted a couple of
times between 32 and 64 bit Gentoo. BTW, I still have the 32bit Gentoo,
although cleaned from large stuff like KDE, because occasionally I need to
build 32bit stuff.

> Meanwhile, for the akonadi stuff at least, there's a bit of config
> outside .kde. I'm not /exactly/ sure of the default location as I've
> changed enough stuff around here to never be sure, but I /believe/ that
> bit is in ~/.config/<something> by default. (Maybe .config/akonadi/ ?)

In there are the resource agents and the akonadiserverrc. Data base stuff is
in .local/share/akonadi.

Wonko

Duncan wrote:
> Frank Peters posted on Thu, 09 Dec 2010 10:36:29 -0500 as excerpted:
>
>
>> On Thu, 09 Dec 2010 00:11:20 -0600
>> Dale<rdalek1967@gmail.com> wrote:
>>
>>
>>
>>> I do have nvidia video cards. I assume the nvidia-drivers package will
>>> work fine with no-multilib? The way I am reading things it will but I
>>> do want drivers that work.
>>>
>>>
>>>
>> Don't forget about the stock nv driver that is supplied by Xorg. It may
>> not have 3D acceleration but it will perform very well for most common
>> activities. Both work as no-multilib.
>>
>> I set up my system in a way that allows me to start X with either the nv
>> or the proprietary nvidia driver. For normal activities, which is most
>> of the time, I use nv, but there are some occasions when I require the
>> full power of the proprietary nvidia.
>>
> FWIW and heads-up: The nv driver has been partially supported by nVidia
> in the past, mostly as a driver that can be run long enough for users to
> get to the nVidia site and download the nVidia driver. However, they've
> announced its deprecation, and that they won't be updating it any longer.
> Officially, nVidia says users can switch to the also unaccelerated vesa
> driver if needed, but they don't mention the nouveau driver. The word is,
> however, that the nouveau driver is already better than the nv driver and
> that distributions were starting to ship it anyway, to the point that it
> really didn't make that much sense for nVidia to continue supporting the nv
> driver.
>
> So do consider switching, at least as you upgrade. It's probably not
> ready to switch to for folks on 100% stable just yet, but as stable
> upgrades, it should be.
>
>

I'll keep that in mind. I have heard of the driver but been waiting on
it to "develop" some more. It looks to me like nvidia would just give
out some specs and let the community do it. They could always tell them
what they can't release publicly to keep the competition from getting a
heads up.

I have a fellow Gentooer that sent me a video card. The word snail mail
is coming to mind. With the holidays and all, it may be next week
before it gets here. I went to a local puter shop and picked up a used
ATI card to do the install with. I'm going to run memtest and such
first anyway. I just hope this card will work well enough for this. I
have never used a ATI card before. If it can put text on the screen for
me, I'm happy.

Funny thing is, the guy shipped the video card two or three days before
Newegg shipped the DVD drive. UPS will be here very shortly with the
DVD drive. lol I told you snail mail was coming to mind here. lol

Hoping to get started here shortly.

Dale

:-) :-)

Alex Schuster wrote:
> Duncan writes:
>
>
>> Dale posted on Thu, 09 Dec 2010 11:03:56 -0600 as excerpted:
>>
>
>>> Looks like this was simple enough to solve. Just leave .kde behind at
>>> least. No worries. Wish the multilib issue was this simple. o_O
>>>
>> Seems to be good.
>>
>> Depending on how much customizing you do to your kde (and mozilla), you
>> can try copying them over too. If anything breaks, you know what to
>> "uncopy". =:^/ But it might be easier to do that and find what to uncopy
>> if necessary, then re-customize everything, at least if you're as heavy a
>> customizer as I am. And worst-case, you simply erase that bit and start
>> clean.
>>
> As I hate to re-create my KDE setup from scratch, I simply did nothing when
> I switched to 64bits a while ago. No problem. I even dual-booted a couple of
> times between 32 and 64 bit Gentoo. BTW, I still have the 32bit Gentoo,
> although cleaned from large stuff like KDE, because occasionally I need to
> build 32bit stuff.
>
>
>> Meanwhile, for the akonadi stuff at least, there's a bit of config
>> outside .kde. I'm not /exactly/ sure of the default location as I've
>> changed enough stuff around here to never be sure, but I /believe/ that
>> bit is in ~/.config/<something> by default. (Maybe .config/akonadi/ ?)
>>
> In there are the resource agents and the akonadiserverrc. Data base stuff is
> in .local/share/akonadi.
>
> Wonko
>
>

I had forgot about Kopete. I do use it. I may can just save the one
file/directory for Kopete and .mozilla. I'll most likely just try the
whole thing at first. If it causes me grief, I can logout, go to a
console and delete what I don't need.

I think I know what file Kopete uses. I looked at it one time before.
I think it is in a config directory or something.

UPS just ran. I got what I need to get started with the testing at least.

Dale

:-) :-)

On Friday 10 December 2010 00:28:59 Dale wrote:
> I had forgot about Kopete. I do use it. I may can just save the one
> file/directory for Kopete and .mozilla. I'll most likely just try the
> whole thing at first. If it causes me grief, I can logout, go to a
> console and delete what I don't need.
>
> I think I know what file Kopete uses. I looked at it one time before.
> I think it is in a config directory or something.

The logs, pictures and stuff are in:
~/.kde4/share/apps/kopete

config-file is:
~/.kde4/share/config/kopeterc

User-accounts + passwords are, on my install, in the "kwallet" thing.
Wallets are at:
~/.kde4/share/apps/kwallet

> UPS just ran. I got what I need to get started with the testing at least.

Have fun :)

On Thursday 09 December 2010 16:48:01 Dale wrote:
> J. Roeleveld wrote:
> > On Wednesday 08 December 2010 23:23:18 Mark Knecht wrote:
> >> On Wed, Dec 8, 2010 at 1:17 PM, Dale<rdalek1967@gmail.com> wrote:
> >>> Hi,
> >>>
> >>> First post here. I'm usually on gentoo user. I'm in the process of
> >>> building a new system which will be 64 bit. I am looking for advice.
> >>> I would like people to post things that I might run into that one
> >>> wouldn't expect and some things that are different from x86. I was
> >>> looking at something on my old rig and noticed the USE flag smp. I
> >>> didn't know about that until I ran up on it. I learned something by
> >>> pure dumb luck.
> >>>
> >>> I'm a long time Gentoo user. Installed it at the early stages of 1.4.
> >>> I also use KDE and have fluxbox installed as a backup. The processor
> >>> is a AMD Phenom II X4 955 @3.2Ghz. It will start out with one 4Gb
> >>> stick of ram. I plan to expand that later.
> >>>
> >>> What are some things that I should watch for and enable that isn't so
> >>> obvious for someone new to 64 bit?
> >>>
> >>> Thanks.
> >>>
> >>> Dale
> >>
> >> Hi Dale,
> >>
> >> It's been so long since I've done anything that wasn't 64-bit so
> >>
> >> it's hard to answer. I think the 64-bit install guide is quite good.
> >> One thing that I think some folks (me included) do that differs from
> >> the guide (at least the last time I read it) is to use grub-static
> >> instead of grub. I suspect that's because it's 32-bit and more
> >> compatible.
> >>
> >> Other than that I can't think of anything I do differently.
> >>
> >> Best of luck with the new install. I'm sure it will go great.
> >>
> >> Cheers,
> >> Mark
> >
> > Hi Dale,
> >
> > I run x86 on one machine (Asus EEE 901) and amd64 on all other machines.
> > Last time I installed, I followed the standard Gentoo guide and I didn't
> > have to use "grub-static".
> > Not sure when this was fixed, but the current grub in portage works fine
> > on 64bit.
> >
> > The only thing I can think of that is different is that you will need the
> > nsplugin-wrapper still for some 32bit plugins to work in firefox.
> >
> > --
> > Joost Roeleveld
>
> I have Firefox installed here but mostly use Seamonkey. I assume the
> same would apply for Seamonkey as for Firefox?

I would assume so. The problem is that some (flash for instance) plugins are
32bit only (occasionally 64, but that doesn't seem to last).

--
Joost

On Thu, Dec 9, 2010 at 18:55, Dale <rdalek1967@gmail.com> wrote:
> I'm thinking, AT THE MOMENT, of going multilib and grub-static.  That way
> down the road, I can switch to no-multilib and not have to reinstall grub.
>  To simple huh?
>
> Dale
>
> :-)  :-)
>
>

There's absolutely no reason for you not to use multilib.

Why waste the opportunity to run 32bit applications? You'll never
regret running multilib, infact you'll soon forget it. If, on the
other hand, you choose to run no-multilib, one day you'll have to run
a 32bit app (that day will come, simple Murphy laws) and you'll have
to set up a 32bit chroot for it :)

Grub is *not* an issue, I've never used grub-static on any amd64
system, sys-boot/grub works great. Lilo works, yes, but it really is
old tech. Grub's interactive boot menu is invaluable and can save you
when something goes wrong.

Don't forget that the current multilib implementation doesn't compile
things twice. It just provides the environment and 32bit libraries
required for 32bit applications to build and run. Anything that
supports 64bit builds and runs as 64bit, period :)

--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

on 12/09/2010 06:13 AM Duncan wrote the following:
> Meanwhile, what about that 32-bit chroot option I mentioned? Actually,
> there's a whole properly documented Gentoo guide for that, and it's sort
> of special case, so I'll skip the details on it, but I'll describe enough
> about it so you have some idea why you might want to run one and how it
> works.
Could you point to that gentoo guide about that 32-bit chroot on a
no-multilib host please?

J. Roeleveld wrote:
> On Friday 10 December 2010 00:28:59 Dale wrote:
>
>> I had forgot about Kopete. I do use it. I may can just save the one
>> file/directory for Kopete and .mozilla. I'll most likely just try the
>> whole thing at first. If it causes me grief, I can logout, go to a
>> console and delete what I don't need.
>>
>> I think I know what file Kopete uses. I looked at it one time before.
>> I think it is in a config directory or something.
>>
> The logs, pictures and stuff are in:
> ~/.kde4/share/apps/kopete
>
> config-file is:
> ~/.kde4/share/config/kopeterc
>
> User-accounts + passwords are, on my install, in the "kwallet" thing.
> Wallets are at:
> ~/.kde4/share/apps/kwallet
>
>
>> UPS just ran. I got what I need to get started with the testing at least.
>>
> Have fun :)
>
>
>

Thanks for the info. At least I know what to save.

I had fun. I got to the point where I could boot from the hard drive.
My kernel worked first time out of the box and so did grub-static. Man
this rig is faster. gcc on old rig, about 2 hours. New rig, 20 minutes.

Going to take a nap. One eye already shut. Other is half closed.

Dale

:-) :-)

Thanasis posted on Fri, 10 Dec 2010 14:54:53 +0200 as excerpted:

> on 12/09/2010 06:13 AM Duncan wrote the following:
>> Meanwhile, what about that 32-bit chroot option I mentioned? Actually,
>> there's a whole properly documented Gentoo guide for that, and it's
>> sort of special case, so I'll skip the details on it, but I'll describe
>> enough about it so you have some idea why you might want to run one and
>> how it works.
> Could you point to that gentoo guide about that 32-bit chroot on a
> no-multilib host please?

It's linked from the gentoo/amd64 project page, which is probably worth
bookmarking (or remembering, easy enough once you know it's there) on its
own:

http://amd64.gentoo.org

But here's a direct 32-bit chroot HOWTO link:

http://www.gentoo.org/proj/en/base/amd64/howtos/chroot.xml

There's a number of other useful links on the project page, as well,
including the gentoo/amd64 FAQ:

http://www.gentoo.org/doc/en/gentoo-amd64-faq.xml

And I won't link them directly here, but for those running into -fPIC
errors (as used to be common as *.so libs need it on amd64), there's a
developer's howto on fixing those, and also a listing of the contents of
each of the emul-linux-x86-* packages, for multilib folks that need a 32-
bit library but don't know for sure which emul* package it's in.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Alex Alexander wrote:
> On Thu, Dec 9, 2010 at 18:55, Dale<rdalek1967@gmail.com> wrote:
>
>> I'm thinking, AT THE MOMENT, of going multilib and grub-static. That way
>> down the road, I can switch to no-multilib and not have to reinstall grub.
>> To simple huh?
>>
>> Dale
>>
>> :-) :-)
>>
>>
>>
> There's absolutely no reason for you not to use multilib.
>
> Why waste the opportunity to run 32bit applications? You'll never
> regret running multilib, infact you'll soon forget it. If, on the
> other hand, you choose to run no-multilib, one day you'll have to run
> a 32bit app (that day will come, simple Murphy laws) and you'll have
> to set up a 32bit chroot for it :)
>
> Grub is *not* an issue, I've never used grub-static on any amd64
> system, sys-boot/grub works great. Lilo works, yes, but it really is
> old tech. Grub's interactive boot menu is invaluable and can save you
> when something goes wrong.
>
> Don't forget that the current multilib implementation doesn't compile
> things twice. It just provides the environment and 32bit libraries
> required for 32bit applications to build and run. Anything that
> supports 64bit builds and runs as 64bit, period :)
>
>

I'm working on installing the GUI part now. I did go multilib for now.
This should work better until everything works with 64 bit. I sure
would hate to run into a problem with something I have to have and then
have to reinstall all this again.

I did go with grub-static. Plain grub pulled in something HUGE. This
is one less program to have to deal with.

Thanks.

Dale

:-) :-)