Aug 12, 2010

It is best to install Eclipse standalone and use its own software
update/install mechanism, rather than rely on system package management
(pacman, in this case). This avoids all sorts of permission and plugin
conflicts.

Mar 05, 2010

After installing Atlassian Connector in Eclipse and everything just goes
to shit: all installed plugins disappear from preferences. The problem,
as it turns out, lies in installing Eclipse as root (sudo pacman -S) and
later installing plugins while Eclipse is running as non-root.

Feb 09, 2010

After updating to GWT 2.0.1 (official) and moving our project to a
arch/vbox, I had a small adventure trying to get DevMode window to come
up: it just wouldn't. The window just came up blank and nothing else
happened.

It turns out you are running awesome, Java may not play nice. You
need this:

Jan 10, 2010

A number of things happened recently — a new iMac, a new dev project,
new developers on the team, new unexplained gremlins — that made me
realize: virtualization is the way to go. We develop on Linux, so I
chose VirtualBox because it's free-er and lighter than VMWare.

The problem

Software is not system agnostic. If you chose to develop on your own
machine then it has to serve several masters: you, the owner and
operator, and the projects you're working on. As a result, you spend
time configuring your system for multiple potentially conflicting tasks
and solving system-related problems instead of actually working on the
project. Increasing the number of developers and projects obviously
makes things worse.

Adding development systems and setup time

It's rarely just a simple checkout from your favorite source control
repo. There are also tools and libraries to install (some of which will
serve no other purpose than this particular project), tables to set up
and checklists to follow.

Multiple developers

No two environments are the same, especially when run by different
people. Ultimately, each developer must design his/her own unique
solution to getting the project to run on their system. Sometimes the
solution does not exist.

Multiple projects

There is crap you install for every project and probably never remove.
Then there is crap that has to run as part of the context of working on
project X: Eclipse, several VIM sessions, consoles, terminals, CSS color
pickers, etc.. This is crap you have to fire up and shut down when you
switch contexts. No, you do not have unlimited system resources.

If all this crap hogging your precious system is bad enough, what do you
do when you have, say, two projects that require different versions of
Postgres?

Conflicts with YOUR system

Even if only work on one thing, your personal machine lives its own
independent life. What happens to your machine during its course might
affect your environment in ways you may not expect, much less like. Just
recently a Safari 4.0.4 (how appropriate) broke GWT hosted mode, and the
only solution was a manual rollback. Yeah, fun!

The verdict

Your environment-sensitive projects are bad for your system. Your system
is bad for your environment-sensitive projects. They must be divided.

The solution

Why, of course the nice isolated VM that fires up in an instant and
tucks away when not needed.

Every developer can have the exact same environment

No unexplained irreproducible glitches, no variances.

Context switching

Press a button and your whole development environment disappears. With
all its running tomcat servers, databases end editors. System resources:
free!

Press another button and it's back exactly as it was.

Snapshots

Snapshots are incredibly useful. Save any known good state and revert to
it when things have gone bad. No need to retrace your steps if you don't
want to.

More importantly, this is unlimited freedom to try anything. Want to
replace X11 fonts and see what it looks like? No problem! Make a
snapshot and fire away. You'll be spared the agony of having to fix the
system you just broke.

As of VirtualBox 3.1 snapshots are brancheable! You can branch off any
snapshot, past or future (relative), and have a whole tree of them.
Right now you can only run one snapshot at a time, though, but there is
a way of spawning off a new machine.

Target environment

Your target environment will likely be different from your host. In a VM
it can be exactly the same, or at most you'll have to resolve conflicts
between one development environment and the target, rather than many.

Ah, here we go: `proper headers`_ â€” yay! Wait, what?
/usr/src/linux-headers-2.6.31-302-ec2/scripts/mod/modpost requires
GLIBC_2.8, and we can't mess with glibc or the kernel. Attempted
building and installing glibc 2.8 on the side, no go. Damn.

So, to recap: after a full day of installing headers, installing hacked
headers, building glibc 2.8 and a futile attempt to get vboxdrv to build
with that, hacking modpost, trying two different PUEL versions (3.0 and
3.1) we still get nothing.

VBox OSE won't compile because of failing some version dependency checks
and CentOS repo is hopelessly out of date. Tried with multiple different
versions of vbox, ultimately it's too much pain.

Another possibility worth exploring is bringing up the image in vmware
or xen.

System Message: WARNING/2 (/home/dev/work.shared/unthingable/content/installing-virtualbox-puel-on-centos-5-rackspace-slicehost.rst, line 68)

malformed hyperlink target.

System Message: WARNING/2 (/home/dev/work.shared/unthingable/content/installing-virtualbox-puel-on-centos-5-rackspace-slicehost.rst, line 69)

After a couple of days of digging through outdated and conflicting
documentation, I finally figured out the proper steps. Then
jamesconway from #vbox put it all nicely together:

As root:
1. pacman -Syu xorg
install entire group (is everything actually required?)
2. pacman -S kernel26-headers gcc make
3. Install guest additions
4. X -configure
5. change the mouse driver from "mouse" to "vboxmouse" in /root/xorg.conf.new
6. mv /root/xorg.conf.new /etc/X11/xorg.conf
7. add hal to DAEMONS in rc.conf
rc.vboxadd is not required because it is added to /etc/rc.local automatically
Not as root:
8. add /usr/bin/VBoxClient-all to the top of ~/.xinitrc (even if it does not exist)