@Pjoter
Doesn't surprise me. Unless somewhere in the heart of Gnome, there's a wicked #ifndef linux do_it_slow_as_snails #endif group in the code, my best guess is it's in a core dependency.
Maybe sth it needs from ports/pkgsrc is just utterly terrible at doing it's business on BSD. From stuff I googled a few weeks ago, it seems that at least at some point, Gnome 2 startup was mostly I/O bound. I'm still using the same slow hard drive though :-/.
@rpindy
I used Xfce for several months after deciding it was about time to actually try the thing, but left it after getting annoyed with my session crashing back to XDM. Seemed to have something to do with the themeing. Ended up going back to FVWM for ages. Still I think Xfce is one of the best desktop environments for unix systems though
. Deffo would use it again in the future though.
Xfce 4 was very fast when I used it, nothing like how Gnome 2 and KDE 4 ran. But Gnome 2 on Ubuntu is running even faster than Xfce 4 had on FreeBSD. That is nuts!
@Mr-Biscuit
I'm very interested to know how it works out. There's got to be some sense to Gnomes performance...
Between FreeBSD 6.x and 8.x, I've never had any complaints about performance with the OS.
@ side lines
There's a bit of a difference between Chrome, Chromium, and Windows, Linux, and Native builds of each one - particularly without the port being in wide spread usage. The only reason my laptop followed stable instead of releases, fwiw is a level of trust I have in the project. Stability and maintenance are very important to me, to an extent where a www/linux-f10-google-chrome or equaliv. port is most ideal. In particular one that is widely tested and regularly updated. I've also found Google builds of google-chrome itself much more stable on linux than chromium, which makes me even more leerly of testing a grand experiment.
To get modern versions of GFire working, it needs to be patched because of glibc specifics missing from libc. I'm to busy to be doing this sort of thing every few releases. XFire under Windows sucks enough without throwing WINE at it (didn't work when I tried it under FreeBSD 6.x). My opinions of WINEs usefulness on FreeBSD are still not very high, even if it's gotten 'better'. Every time I try using WINE for something on BSD, it generally falls flat on it's face.
Rather than dropbox, the solution that would likely fit my needs *best* is one centred around rdiff but version incompatibilities between what's available on my different systems, creates a bit of a problem :-P. DriveHQs available info doesn't rub me as gently as Dropbox seems to.
So far I've got about 25MB in chat logs under dropboxes control, out of several GB of $HOME. It's been an exceptional improvement over my rs-vars, rs-touch, rs-pull, rs-push, and rs-mgr wrapper scripts: which were used for automating the question of which machine needs to rsync to the other before/after a session. Once I have things sorted, dropbox will likely be used for variable data sets and more static content will get rsync'd to the file server every few weeks.
Once the inotfy support comes along in the linuxator, dropbox should work fine on BSD. When working hours have settled off in the future, I'll be re-evaluating what can be done there and what I can do to help. For now though, I just need the computer to turn it's head and cough about accessing my data.
All of that however is a side line, compared to this topics interest in Gnomes performance