# FreeBSD 8.0 x86 and KDE4 full-screen in VirtualBox 3.1.4

I recently downloaded and installed FreeBSD 8.0 as a VirtualBox guest (running in an OpenSolaris host, natch), and quickly discovered two things; i) FreeBSD doesn’t use a desktop GUI by default, and ii) Oracle don’t provide VirtualBox Guest Additions for FreeBSD, such that one cannot handily run a FreeBSD guest full-screen.

The following is a quick how-to which will address both issues, for new guys like me wanting to install FreeBSD 8.0 quickly and use a desktop GUI at larger than 800×600 resolution. For kicks, I thought I’d use KDE for this example – only really having used GNOME on my OSS OS tinkerings to date.

I am using VirtualBox 3.1.4 on an OpenSolaris snv_134 x64 host, and I’m going to install a VM using 8.0-RELEASE-i386-dvd1.iso. This guide assumes familiarity with installing VirtualBox guests. Host and guest OSs must have internet access.

First hiccup; I had to attach the FreeBSD guest hard disk to a SATA (not IDE) controller in my VM, otherwise I encountered the error described by the original poster at http://forums.virtualbox.org/viewtopic.php?f=8&t=19447:

From the FreeBSD ports packages installation options, install:

kde4-4.3.1
xorg-server-1.6.1,1
xorg-drivers-7.4_2

Once FreeBSD reaches the end of the installation process, reboot, login as root, then edit /etc/rc.conf to include the following:

$pfexec ln -s /usr/jdk/jdk1.6.0_18/jre/lib/i386/libnpjp2.so . Restart Firefox. # Who isn’t suing Intel – redux Continuing on from this, looks like nVidia has recently established their own ‘lil anti-Intel site: I’m sure Intel make decent products and what-have-you, but really, where there’s this amount of smoke I think there has to be some fire. # Build Scribus 1.3.6.svn on OpenSolaris x64 – part 2 (UPDATED) Full build instructions as copied/pasted from my bug report – note that this will enable you to build Scribus, but opening/saving Scribus project files is broken. If anyone has a workaround for this let me know…and hopefully the Scribus developers will have a fix soon. EDIT: Saving files does work (there is a bug report here), given the following workaround. It seems Cmake ignores the install directory specified by -DCMAKE_INSTALL_PREFIX:PATH=~/scribusinstall. If you copy the contents of sfw_stage to ~/scribusinstall, saving .sla files apparently then works fine. See below for these commands, options, and directories in context. Also be warned that this whole process can take a while – building Qt for example on an Intel Q8200 quad-core system took about a couple of hours. ********************************************************************************** ********************************************************************************** BUILDING AND INSTALLING SCRIBUS 1.3.6.svn ON OPENSOLARIS DEVELOPMENT BUILD 134 X64 ********************************************************************************** ********************************************************************************** Saturday 13th March 2010 => INSTALL OPENSOLARIS X64 Download osol-dev-134-x86.iso from http://www.genunix.org/ Test case system is an Intel Q8200 (Gigabyte EG31MF-S2 system board) with 4GB RAM. => INSTALL PREREQUISITE PACKAGES Use the OpenSolaris IPS package manager GUI to install the following: versioning/subversion gcc-3 cmake gettext header-xorg = BUILD AND INSTALL QT 4.6.2 FROM SOURCE Download qt-everywhere-opensource-src-4.6.2.tar.gz from http://qt.nokia.com/downloads Copy and unpack the file to /tmp In /tmp/qt-everywhere-opensource-src-4.6.2/ run the following: $ ./configure -platform solaris-g++ -no-webkit
$gmake$ pfexec gmake install


This installs Qt at the default location of /usr/local/Trolltech/Qt-4.6.2

(Note: if you encounter mmap errors when building, increase the swap space following the instructions at http://www.crypticide.com/dropsafe/article/2649)

QTDIR=/usr/local/Trolltech/Qt-4.6.2; export QTDIR


=> BUILD AND INSTALL SCRIBUS

$mkdir ~/scribusinstall$ mkdir ~/scribussource
$cd ~/scribussource$ svn co svn://scribus.info/Scribus/branches/Version135
$cd Version135/Scribus$ mkdir builddir
$cd builddir$ /usr/bin/cmake .. -DCMAKE_INSTALL_PREFIX:PATH=~/scribusinstall
$make$ pfexec make install


Scribus binary is installed to ~/scribussource/Version135/Scribus/builddir/sfw_stage/bin. See the edit at the top of this page to complete the installation.

# Build Scribus 1.3.6.svn on OpenSolaris x64 – UPDATED

(EDIT: looks like I’m unable to open nor save .SLA files with this – which is not particularly useful. Stay tuned…)

(EDIT #2: see here for the workaround)

This has taken me an age to complete, but I’ve had success in the last hour.

My bug report is here. In summary, on Ubuntu Linux (for example) the latest development builds of Scribus have no problems with the Qt packages available from the (Synaptic) default repositories. On OpenSolaris however, this doesn’t seem to be the case with Qt packages available at http://solaris.bionicmutton.org, as I’ve discovered after many hours fruitless tinkering.

I’ve found that I can build Scribus 1.3.6.svn successfully, using Qt 4.6.2 as built from source. Thankfully this is a pretty straightforward (albeit long) process.

Details covering package prerequisites etc are now here.

# Firefox 3.6 Personas, Opera 10.50

Exciting times for fans of cross platform browsers (sorry IE and Safari).

They say open source has made computing fun again, and Firefox Personas is a great example of this. Thousands and thousands of cool skins, and being able to insta-preview each one with a mouse hover is pretty neat!

Some of the themes are delightfully garish:

I’ve only just updated my OpenSolaris development box with Firefox 3.6 (available from here), so once I’ve frittered away a few hours of time having fun with Personas, I’ll look forward to checking out the speed and reliability enhancements. Mind you, I’m pretty darn happy with Firefox these days anyhow, what with being practically the only truly cross platform and open source browser out there. That, and it’s a great browser too.

Meanwhile, Opera 10.50 has been released, and although Linux and UNIX versions are not there yet, a quick play around on a Windows 7 machine reveals it to indeed be very fast, and quite slick. Proof there’s still a place for proprietary software when it’s done right, and when its producers appreciate that customers want the same browsing experience regardless of platform. Let’s hope the Solaris x86 release of Opera 10.50 finally has Flash 10 support!

While I’m on the topic, I will say I’m not particularly interested in Google Chrome. I’ve heard a lot of good things about it, but frankly I’m uncomfortable using a browser developed by a search and advertising giant, and Google’s recent serious privacy blunders really don’t help. Sorry Google, you do a great search product (regardless of the prospect of anti-monopolistic scrutiny in the near future), but I feel a lot healthier leaving my browser, office applications, and operating system to other companies, thanks.

And now I’m off to try more Personas…

# Access Apple MobileMe iDisk from OpenSolaris

Turns out iDisk is WebDAV compliant, and using a generic client seems to be far quicker and more reliable in operation than either managing iDisk content with the MobileMe BUI, or using iDisk+Finder in Mac OS – the latter of which appears to have dire performance issues.

Follow the steps (on an OSOL snv_133 x64 system)…

Use secure WebDAV (standard HTTP works okay too), and enter your iDisk address in the form of idisk.me.com/username

When dragging and dropping files to upload using Nautilus, I noticed that the “File Operations” status bar doesn’t accurately reflect data transfer progress – more often than not the progress bar will sit at some arbitrary reading without any movement. However, looking at Gnome System Monitor -> Network History one can see that data is indeed being uploaded when this happens.