Mark Knecht posted
below, on Tue, 13 Dec 2005 16:11:51 -0800:
> Hi. I completely agree with your issues above. Unfortunately there
> are times, such as this one where we paid $thousands to take an
> in-depth investing class and we needed immediate computer capabilities
> or we'd have to bring Windows back up. That wasn't acceptable.
> Generally speaking, for the last few days, the only place I've been
> browsing is this one site where we're getting trained, as well as
> using GMail. I have a reasonable expectation that both of these sites
> are honest and would not knowingly do anything wrong. That doesn't
> mean there couldn't be a problem, but sometimes you have to take short
> term risks in order to move forward at an acceptable pace.
Agreed, altho I expect I'd be /very/ sure /before/ I paid that sort of
money for a class, that I had things set up suitably for it. Ideally, I
wouldn't take a class that said it required MSWormOS/IE, either, choosing
instead to purchase from a different supplier, but of course, reality
sometimes doesn't match ideals, and every person must choose where to draw
the line at compromise on their own. No condemnation from me on that!
> One thing I'm working on right now is a setup that would allow me
> to dual boot into the athlon-xp environment for testing purposes. I
> run a real-time development kernel from Ingo Molnar for my audio work.
> So far I cannot make it work as well as my older Athlon-xp machines so
> I'm going to boot into the chroot with it's own kernel to see if this
> is a 64-bit issue. But that's for later.
I recall your posts on the subject here, and have come across your
related comments in a couple other locations as well, so yes, I'm aware of
the issues you are experiencing in that area, and /wish/ there was
something I could do to help.
Incidentally, and of some surprise to me, when I switched to RAID
recently, the increase in performance and decrease in latency was
rather better than I expected. One reads all the time about the slowness
of disk access, but to see how reducing that with raid perceptibly
affected performance in areas I /would/ have considered unrelated...
Let's just say I've been fully satisfied and /very/ pleasantly surprised.
It might be worth some research, anyway, into whether the same effect
might be seen at the real-time-processing level necessary for serious
audio and multi-media work. It could be that RAID is a solution (or more
likely part of one) that isn't so widely known in the realm. I'm not that
seriously into real-time audio processing, but was rather favorably
impressed here, I know that!
> Question - Could /home be a separate partition that's visible
> (somehow) to both environments?
Yes. That is in fact what the bind-mount sort of stuff accomplishes. I
don't claim to have any more than a passing knowledge or experience in the
area, however, and haven't installed a 32-bit chroot here, so don't have
that specific experience either. However, for whatever reason, I /do/
seem to make better sense of just reading some of those things than some
have even after having done them, so I have a limited bit of knowledge in
>From the comments I have in my /etc/fstab:
# for mount --bind, --rbind, and --move
# Dev/Part MntPnt Type MntOpt D F
# /old/dir /new/dir none bind 0 0
That's based on chance comments I've seen, and the material found in the
mount manpage. Thus, read up there, paying particular attention to the
information on the --bind, --rbind, and --move parameters. I don't recall
the details of the differences at this point, and only had the hint in my
fstab comments to remind me where to look for more information, should I
decide I needed such a thing.
That said, after reading the mount manpage, you should have a better idea
of what the scripts/tarballs/whatever mentioned in this thread, are doing
with the bind --mount type stuff, and hopefully should be able to extend
it to create your own mount --bind stuff, such as doing it with /home, as
needed. You should then be able to choose the correct parameter of the
three for your intended usage, as necessary.
BTW, on your df listing earlier... perhaps what you want is the output of
the mount command, without any other parameters? Also note the existence
of /etc/mtab (maintained by mount, don't go hand editing but just looking
should be fine), and /proc/mounts. All three (the two files and the
output of mount with no parameters) list essentially the same thing, altho
the content of the two files may differ slightly. The df output can then
provide the info it was designed to provide -- disk-free information --
without having to rely on it for info it wasn't designed to provide -- an
accurate mappping of mountpoints.
Hopefully that's enough to get you started in the right directions. I
can't do more off the top of my head, without rereading the info myself,
and then would be basically repeating it, so you should be able to get the
same effect by reading it in the original, rather than having me repeat
I should also mention the Gentoo amd64 32-bit chroot guide, which used to
be in the technotes but I believe has now moved. You've read it, right?
If not, I suggest you search the gentoo amd64 stuff and find it, as it's
quite helpful with the whole thing, and is what the tarball and etc you
are using is based on. Again, if I had actually done it myself, I'd be
able to provide my usual level of detail, but I've only read about it, so...
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 in
email@example.com mailing list