Showing 4 posts
Back in February, I bought a copy of Parallels Desktop 2 and have been a very happy user of it since then. However, when Parallels 3 appeared, I hesitated to pre-order it (even at a very low price) and I did well: after it was released, I tried it on my MacBook Pro and their 3D support is useless for me. I could not play neither Half-Life 2 nor Doom 3 at acceptable speeds, being the former much worse than the latter in this regard. Now, I'm evaluating VMware Fusion RC1, and I'm almost convinced to pre-order it. This product is very similar to Parallels and in fact several of its features seem "inspired" on it, such as Unity (Coherence in Parallels speak). But it has some important features that Parallels cannot currently match. To know: support for 64-bit guests, support for 2 virtual CPUs in guests and support to network-boot the virtual machine. All of these are cool from a development point of view. The first two allow one to run some more versions of specific operating systems, such as NetBSD/amd64, as well as enabling SMP support in them. The last one makes it easy to boot development kernels without modifying any virtual disk (haven't tried this yet, though). All is not good though. Fusion is also supposed to have experimental 3D support inside the guest machines (up to DirectX 8.1). However, when trying to launch Half-Life 2 inside a Windows XP SP2 virtual machine, Windows crashed with a BSOD. At least I could launch it in Parallels, albeit it was simply unplayable. But as none of the two products make for a good gaming experience, I personally don't care about this feature. Let's conclude with some numbers about the speed of each product. I installed Debian GNU/Linux leeny under Parallels and Fusion and built monotone-0.35 from scratch under them. The virtual machines were configured to have 768MB of RAM of a total of 2GB and the machine was idle aside from the build jobs. Obviously, in the case of Parallels I could only run the test with the i386 port, but in Fusion I used both the i386 and amd64 ports with 1 and 2 virtual CPUs. I also ran the same tests on the native machine using Mac OS X 10.4.10. The timings only include the make command, not ./configure. Parallels, 32-bit, 1 virtual CPU, 'make': real 17m33.048s, user 14m24.342s, sys 3m4.080s Fusion, 32-bit, 1 virtual CPU, 'make': real 16m35.507s, user 14m57.016s, sys 1m29.134s Fusion, 32-bit, 2 virtual CPUs, 'make -j2': real 10m0.341s, user 17m23.541s, sys 2m12.604s Fusion, 64-bit, 2 virtual CPUs, 'make -j2': real 10m24.617s, user 18m26.985s, sys 1m26.133s Native, Mac OS X, 'make': real 12m50.640s, user 11m12.997s, sys 1m20.344s Native, Mac OS X, 'make -j2': real 7m3.536s, user 11m22.875s, sys 1m26.366s See this thread for other opinions.
July 22, 2007
·
Tags:
<a href="/tags/fusion">fusion</a>, <a href="/tags/parallels">parallels</a>, <a href="/tags/virtualization">virtualization</a>
Continue reading (about
3 minutes)
If memory serves well, today makes the sixth month since I have got my MacBook Pro and, during this period, have been using it as my sole computer. I feel it is a good time for another mini-review. Well... to get started: this machine is great; I probably haven't been happier with any other computer before. I have been able to work on real stuff — instead of maintaining the machine — during these months without a hitch. Strictly speaking I've got a couple of problems... but that was "my fault" for installing experimental kernel drivers. As regards the machine's speed, which I think is the main reason why I wanted to write this post: it is pretty impressive considering it is a laptop. With a good amount of RAM, programs behave correctly and games can be played at high quality settings with a decent FPS rate. But, and everything has a "but": I really, really, really hate its hard disk (a 160 GB, 5400 RPM drive). I cannot stress that more. It's slow. Painfully slow under medium load. Seek times are horrible. That alone makes me feel I'm using a 10 year-old machine. I'm waiting for the shiny-new big 7200 RPM drives to become a bit easier to purchase and will make the switch, even if that means my battery life will be a bit shorter. About Mac OS X... what can I say that you already don't know. It is very comfortable for daily use — although that's very subjective, of course; it's quite "funny" to read some reviews that blame OS X for not behaving exactly like Windows — and, being based on Unix, allows me to do serious development with a sane command-line environment and related tools. Parallels Desktop for Mac is my preferred tool so far as I can seamlessly work with Windows-only programs and do Linux/NetBSD development, but other free applications are equally great; some worth of mention: Adium X, Camino or QuickSilver. At last, sometimes I miss having a desktop computer at home because watching TV series/movies on the laptop is rather annoying — I have to keep adjusting the screen's position so it's properly visible when laying on bed. I can imagine that an iMac with the included remote control and Front Row could be awesome for this specific use. All in all, don't hesitate to buy this machine if you are considering it as a laptop or desktop replacement. But be sure to pick the new 7200 RPM drive if you will be doing any slightly-intensive disk operation.
June 21, 2007
·
Tags:
<a href="/tags/mac">mac</a>, <a href="/tags/macos">macos</a>, <a href="/tags/parallels">parallels</a>, <a href="/tags/review">review</a>
Continue reading (about
3 minutes)
These days I'm seizing some of my free time to continue what I did as my SoC 2006 project: the Boost.Process library. There is still a lot of work to be done, but some items are annoying enough to require early attention (well, I can't speak of "early" because I hadn't touched the code for months). Boost.Process aims to be a cross-platform library and currently works under POSIX-based systems (such as Linux, NetBSD or Mac OS X) as well as under Win32 systems. However, developing such a thing is not easy if you don't have concurrent access to both systems to test your code as you go. That is because, past summer, Win32 support was "second class": I first coded everything under NetBSD and, eventually, I fired up my Windows XP installation and fixed any problems that arised due to the new code. This was suboptimal and really slowed down the development of the library. Now, with a MacBook Pro and Parallels Desktop for Mac, these issues have gone away. I can now code under whichever system I want and immediately test my changes on the other system without having to reboot! It's so convenient... And, with Coherence mode, everything is so transparent... just check out the following screenshot: To make things better I could share the project's code over the virtual network to avoid having to commit changes to the public repository before having tested them on the two systems. If you inspect the logs, you'll see many "Add feature X" commits followed by a "Fix previous under Win32". But it is a minor issue right now. Kudos to the Parallels developers, who made this possible and painless. I now understand the "computer as a tool" paradigm rather than a "computer as a hobby".
April 2, 2007
·
Tags:
<a href="/tags/boost-process">boost-process</a>, <a href="/tags/parallels">parallels</a>, <a href="/tags/virtualization">virtualization</a>
Continue reading (about
2 minutes)
I recently installed NetBSD-current (4.99.12 at the time I did this) inside Parallels Desktop for Mac. Everything went fine except for the configuration of the XFree86 shipped with the base system: I was unable to get high resolutions to work (over 1024x768 if I recall correctly), and I wanted to configure a full-screen desktop. In my specific case, this is 1440x900, the MacBook Pro's native resolution. It turns out I had to manually add a mode line to the XF86Config file to get that resolution detected. I bet recent X.Org versions do not need this as, e.g. Fedora Core 6 works fine without manual fiddling. Writing mode lines is not fun, but fortunately I came across an automated generator. In fact, this seems to be just a web-based frontend to the gtf tool provided by NVIDIA. So I entered the appropriate details (x = 1440, y = 900, refresh = 60), hit the Generate modeline button and got: # 1440x900 @ 60.00 Hz (GTF) hsync: 55.92 kHz; pclk: 106.47 MHz Modeline "1440x900_60.00" 106.47 1440 1520 1672 1904 900 901 904 932 -HSync +Vsync After that I had to make the HorizSync and VertRefresh values in my configuration file a bit wider to fulfill this mode's request and everything worked fine. Be extremely careful if you mess with synchronization values though; incorrect ones can physically damage a monitor, although I think this is not a problem for LCDs.
March 15, 2007
·
Tags:
<a href="/tags/netbsd">netbsd</a>, <a href="/tags/parallels">parallels</a>, <a href="/tags/x11">x11</a>
Continue reading (about
2 minutes)