Yeah when I did manage to get parallels to run plan 9 (v3) it looked like garbage and I couldn't install it due to graphics mess ups. I'm now hearing really great things about VMWare Fusion for the Mac... and I'm considering taking my business there.
On 8/29/07, Axel Belinfante <[EMAIL PROTECTED]> wrote: > > late follow up. I'm running v 3 build 4560, with converted v 2 image. > seems to work fine, as far as I can judge -- > apart from things I notice while typing this, see below (*) > > did not (yet) try direct install of plan 9 in v 3. > > resolution 1680x1050 is standard supported, > aux/vga -m vesa -p lists no depth 32 at all, only 8, 16 and 24. > this is on a quite recent 20" imac. > > audio works per ac97 instructions in wiki > page 'Installing in parallels desktop on Mac OS X' > > > (*) minor problems: > I'm typing this from a vncv session to unix within the parallels > plan 9 on the mac. it works ok, but the mouse cursor does funny things. > > screen shot http://www.cs.utwente.nl/~belinfan/parpic01.png > > in the vnc-ed unix session I run rio as wm. > when I move the fat arrow in the vnc window, > while moving it a transparent square box > (or rather: hole, since it is tranparent) > of, dunno, 10x10 pixels appears in the mouse cursor, > moreover, pieces of the mouse cursor get left behind. > combined with the transparancy thing this means I can draw by > moving mouse moving south-east and can erase by moving mouse north-west. > > also, probably unrelated to vncv, when I use lens outside the vncv window > I also see the image of the mouse cursor in the lens window. don't > recall seeing that in native plan 9. > > > turns out I have an 'international english' keyboard > where `/~ key is next to left shift key, > and a plus-minus/paragraph(?) key is at the usual `/~ position. > parallels seems not to know about this keyboard: > when I press the plus-minus/paragraph(?) key I get the `/~. > > > about the 'Installing in parallels desktop on Mac OS X' page: > I was surprised to see that > applying the suggested 'hget -o file URL' idiom to existing > /sys/src/9/port/devaudio.c overwrites the first part of it > by retreived file, but leaves the last part in place. > turns out 1) ac97 port/devaudio.c is shorter than the original > 2) hget -o opens existing file without truncate, on purpose. > I guess in case of an existing (different) file, first get > original out of the way before using: hget -o file URL > > > Axel. >
