Clint Adams: Inva
baldo, mika misses you.
baldo, mika misses you.
kbd today. I basically took an old Debian patch,
the only significant divergence from the original tarball, and altered
it in a way that I can read and understand it more easily (so I can send
it upstream in good conscience). This process naturally involved a lot
of errors. As I m talking about loadkeys here, they became
unpleasantly obvious whenever I tested my code: First I messed up
everything but plain printable ASCII characters (so the return key was
mapped to Unicode U+0201 instead of the correct K(0x02, 0x01)), then I
managed to completely freeze everything. In both cases, Alt+F7 was
affected by the damage. Just like Ctrl+Alt+Del. Time for the good old
boring
elephants.
I learn from mistakes when I make them twice, so a while sleep 60; do
chvt 7; done loop saved me from further reboots. I nuked /dev/tty1
once more (in the really cool, irreversible way that disables all
keypresses), but I could move on to the next VT. After a final
adjustment, my modified patch finally worked. I sent it upstream,
forgot about the troublesome debugging and went on to something else.
Later in the evening, I decided to end the last school holidays in my
life with a bit of instant messaging. BitlBee, a
Jabber IRC gateway, is running on my virtual private server for this
purpose. Being the occasional chatter that I am, I haven t touched it
since the recent upgrade to Lenny. The format of its account
configuration files has apparently changed, so I started to set up
BitlBee anew. It kept telling me that there is an Authentication
failure ; given the peculiar setup of the XMPP server I use, this didn t
really surprise me. But still, this thing had worked before. Perhaps I
really got my password wrong? I haven t typed it for ages, BitlBee
stored it for me. As the administrator of my Jabber server, I could
easily reset my password to what I thought it was. BitlBee still
refused to get past the identification stage.
I decided to install Gajim, entered my account
information and told it to connect. Gnah. One or the other Python
exception caused an eternal stream of error dialogue boxes to appear
simultaneously and steal my focus. I don t have a keyboard shortcut for
xkill and I couldn t type anything in a Urxvt (error message #54321
would receive the keystrokes). Ctrl+Alt+F1, get me out of here! Oh,
right, I broke that one! At that point, I burst into a laugh.
Somewhere in this post, there are a few bugs to report.
(note that i've just tried enabling the comments feature of
ikiwiki, so feel free to use it
)
(update: okay so i apparently failed to enable comments
earlier... but it should be working now
)
compiz(-fusion) 0.8.2 uploaded to unstable
for all you lovers of desktop bling, the latest stable release
of compiz-fusion has been uploaded to unstable. new features of
note:
deb http://people.debian.org/~seanius/compiz/lenny-backports/amd64 ./
sources.list entry to try it out on an i386 lenny system:
deb http://people.debian.org/~seanius/compiz/lenny-backports/i386 ./
and then apt-get install compiz compiz-fusion-plugins-main
(etc)
so give it a try and let me know how it goes!
pkg-php moving to git
with some initial legwork from Mark Hershberger we've migrated
to a git repository for the php packaging vcs. due to the long and
convoluted history of our svn repository, we decided it wasn't
worth the effort of trying to get every single svn commit mapped
into the new repo. as a compromise to having to start from scratch,
we used the existing branches/tags on top of a series of upstream
tarball imports to get an accurate representation of the release
history.
new git<->bts integration hook for debian packaging
i've been dabbling with a new hook to make for more useful
integration from a git-buildpackage oriented workflow. in this
workflow the changelog is often the last thing prepared, possibly
days or even weeks after a fix has been committed for a bug.
therefore the standard tagpending and typical changelog-scanning
hooks aren't incredibly useful.
instead, this hook scans for "Closes:" meta-info in the commits,
similar to how "git dch" does, and then sends a notification and/or
control commands to the bts. here's an example.
note that it also mentions the branch that recieved the fix in the
notification, so it's easier to see which branches have a fix at a
quick glance.
how to use this for your own git repo:
REPO_PATH=/path/to/your/repo.git
HOOK_REPO_PATH=/somewhere/you/want/to/put/it
git clone git://git.debian.org/users/seanius/vcs-hooks/git-hooks.git $HOOK_REPO_PATH
ln -sf $HOOK_REPO_PATH/git-post-receive-url-notifications.py $REPO_PATH/hooks/post-receive
there's a number of configurable options (take a look at the top
of the file for some fairly verbose comments), but it should work
with some fairly reasonable defaults out of the box.
it can also be configured to do the more traditional
changelog-scanning, but i'm finding it to be a better workflow to
avoid combining changelog entries with the actual fixes (makes them
harder to cherry-pick later), and a notification with a link to the
changelog entry really isn't that useful beyond what "bts tag nnn
pending" can already do. plus i don't like the typical duplication
involved in manually managing the changelog. i find it better to
generate the changelog via git-dch and automatically get all the
"closes:" tags, and then just do a bit of editorial touchups before
preparing/releasing the upload.
so give it a try if you like, feel free to send
feedback/fixes/etc. for example i think the utf-8 support might
still be a bit dodgy, as well as possibly the automatic gitweb url
detection and changelog scanning.
Since we uploaded Xfce 4.6 into Debian Sid, last week, not much
have happened to most people. We had some bug reports, but mostly
from amd64 users, because i386 and ppc packages are not yet
available. The aren't all built at the moment. You can follow the
build status
here if you want. Most packages are built now, but
xfce4-settings is waiting for libcanberra which
is not installable because of a transition and a package waiting in
NEW. It's quite painful to have this upload a bit harmed by this,
but there's not much we could do.
We already passed NEW when uploading to experimental to minimize
the delay where unstable would be unusable, but we can't do that
for packages we don't maintain but depend on. I'm wondering if, for
Xfce 4.6.1 (which is supposed to be out this weekend but won't
because of some problems on the release manager box), I won't
disable the sound settings in xfce4-settings and thus get rid of
the libcanberra build-dep.
If you have keyboard (layout and shortcuts) related bugs, make
sure to re-assign the shortcuts correctly, and re-set the keyboard
model and layout in the keyboard settings. There was a quite large
xorg update at the same time, which now use hal and
console-setup stuff. So you may have problems with that and it can
be a bit hard to know what's going wrong (settings migrations from
Xfce 4.4 to Xfce 4.6, bugs in Xfce 4.6, configuration problems,
conflicts, bugs in xorg etc.)
But all in all, for amd64 users, it seems the transition is well
received and not that bugs have been reported yet (I'm expecting
bug reports to come more when i386 users begin upgrading).
I bought a new machine recently; for the flat at present with the aim of it becoming an upgrade for the media box once my lease is up. Nothing spectacular; E5200 Dual Core Pentium at 2.5Ghz, MSI G41M-FIDP mobo and 4G of OCZ DDR2 800. I don't need that much, but for 30 how could I resist? Total price, including the extra postage tax to NI and a small case, 200 from eBuyer. I had an existing HD I could use and also managed to find a spare DVD writer too.
Hideki Yamane and Nobuhiro Iwamatsu talked about Debian Project last Friday at GREE was one of famous SNS providers in Japan. GREE uses Debian GNU/Linux on large scale for its services.
Hideki, is active Debian Maintainer, talked that using Debian was pretty easy and welcomed every contributors. He also described how Debian Project was managing release, QA, and buildd for a large audience.
Nobuhiro, just passed NM tests and is awaiting final DAM's check, spoke about NM process with his personal experience. He is one of Linux kernel upstream developers and has good knowledges about embedded system programmings and device drivers. I hope he passes DAM's check early to improve Debian more.
I met and talked with some people who were interesting in Debian after the meeting. Yes, I enjoyed that time.
With the new kernel-package hitting Sid today, and the fact that
it no longer does symlink handling by default, I thought it was
time that we had an example script that shows how to do that. This
is a fairly full featured script, feel free to cull down to use
just what you want.
I ll post a couple of ther scripts, if there is interest in
this. BTW, this script does far more than the old
kernel-package postisnt script ever
did.
Have fun.
1 #!/bin/sh - 2 # -*- Mode: Sh -*- 3 # 4 # This is an example of a script that can be run as a postinst hook, 5 # and manages the symbolic links in a manner similar to the kernel 6 # image default behaviour, except that the latest two versions (as 7 # determined by ls -lct) are kept. You can modify this script 8 # 9 # Copyright 2003, 2004, 2005, 2006, 2007, 2008, 2009 Manoj Srivastava 10 # Copyright 2009 Darren Salt 11 12 set -e 13 14 # The dir where symlinks are managed 15 SYMLINKDIR=/ 16 17 if [ $# -ne 2 ]; then 18 echo Usage: $0 version location 19 exit 2 20 fi 21 22 version="$1" 23 vmlinuz_location="$2" 24 vmlinuz_dir="$(dirname "$2")" 25 26 cd $SYMLINKDIR exit 1 27 28 if [ -n "$DEB_MAINT_PARAMS" ]; then 29 eval set -- "$DEB_MAINT_PARAMS" 30 fi 31 32 if [ -z "$1" ] [ "$1" != "configure" ]; then 33 exit 0; 34 fi 35 36 rm -f vmlinuz vmlinuz.old vmlinuz-rd vmlinuz-rd.old initrd.img initrd.img.old 37 38 # Create a temporary file safely 39 if [ -x /bin/tempfile ]; then 40 outfile=$(tempfile -p outp -m 0600); 41 else 42 set -e 43 mkdir /tmp/kernel-image-$version-$$ 44 outfile=/tmp/kernel-image-$version-$$/output 45 fi 46 47 (cd "$vmlinuz_dir" && ls -ct vmlinuz-*) > $outfile 48 49 STD="$(head -n 1 $outfile sed 's/vmlinuz-//')" 50 OLD="$(head -n 2 $outfile tail -n 1 sed 's/vmlinuz-//')" 51 52 if [ "X$STD" = "X" ]; then 53 exit 0; 54 fi 55 56 # If you want version-specific links, here's how to start 57 STD24="$(grep vmlinuz-2.4 $outfile head -n 1 sed 's/vmlinuz-//')" true 58 OLD24="$(grep vmlinuz-2.4 $outfile head -n 1 tail -n 1 sed 's/vmlinuz-//')" true 59 60 STD25="$(grep vmlinuz-2.5 $outfile head -n 1 sed 's/vmlinuz-//')" true 61 OLD25="$(grep vmlinuz-2.5 $outfile head -n 1 tail -n 1 sed 's/vmlinuz-//')" true 62 63 echo Booting $STD, old is $OLD 64 65 if [ -f "$vmlinuz_dir/"initrd.img-$STD ] ; then 66 ln -s "$vmlinuz_dir/"initrd.img-$STD initrd.img 67 ln -s "$vmlinuz_dir/"vmlinuz-$STD vmlinuz-rd 68 else 69 ln -s "$vmlinuz_dir/"vmlinuz-$STD vmlinuz 70 fi 71 72 if [ "X$OLD" != "X" ]; then 73 if [ -f "$vmlinuz_dir/"initrd.img-$OLD ] ; then 74 ln -s "$vmlinuz_dir/"initrd.img-$OLD initrd.img.old 75 ln -s "$vmlinuz_dir/"vmlinuz-$OLD vmlinuz-rd.old 76 else 77 ln -s "$vmlinuz_dir/"vmlinuz-$OLD vmlinuz.old 78 fi 79 fi 80 81 # if [ "X$STD24" != "X" ]; then 82 # if [ -f "$vmlinuz_dir/"initrd.img-$STD24 ] ; then 83 # ln -s "$vmlinuz_dir/"initrd.img-$STD24 initrd24.img 84 # ln -s "$vmlinuz_dir/"vmlinuz-$STD24 vmlinuz24-rd 85 # else 86 # ln -s "$vmlinuz_dir/"vmlinuz-$STD24 vmlinuz24 87 # fi 88 # fi 89 # if [ "X$OLD24" != "X" ]; then 90 # if [ -f "$vmlinuz_dir/"initrd.img-$OLD24 ] ; then 91 # ln -s "$vmlinuz_dir/"initrd.img-$OLD24 initrd24.img.old 92 # ln -s "$vmlinuz_dir/"vmlinuz-$OLD vmlinuz24-rd.old 93 # else 94 # ln -s "$vmlinuz_dir/"vmlinuz-$OLD vmlinuz24.old 95 # fi 96 # fi 97 98 # Run boot loaders here. 99 #lilo 100 101 rm -f $outfile 102 if [ -d /tmp/kernel-image-$version-$$ ]; then 103 rmdir /tmp/kernel-image-$version-$$ 104 fi 105 106 exit 0
At work, we have a bit of a vested interest in the Puppet and Facter packages
that are in Debian, because we ultimately consume them in Ubuntu.
We noticed that what was in Debian unstable was lagging a bit behind what
was released upstream, and when one of my co-workers tried getting in
contact with the Debian developers that were maintaining the Puppet package
and got no response, I got involved.
I got in touch with Micah Anderson and got myself and Nigel Kersten added to the Alioth project for
Puppet.
Despite Jamie Wilkinson being
listed as the maintainer of the facter package in Debian, he
claimed this was news to him, and Matt Palmer, who was listed
as an uploader, didn't really claim much knowledge of maintaining the
package either, so we took that as blessing to take over that package as
well.
This is where the fun begins.
I've been meaning to try out Git ever
since Debconf 7, where all the
cool kids were using it and raving about it.
I've been meaning to make the Debian DHCP package
collaboratively-maintained, and use Git for the revision control, but I
haven't quite gotten off my good intentions and done it yet. Part of the
problem is not knowing exactly what workflow I should use, and suffering
from paralysis by analysis, reluctant to experiment, because I don't want to
go down the wrong path.
Anyway, this is about Puppet, not DHCP. The Puppet package, as it turns out,
is already
maintained in Git on Alioth, so the problem here was more one of
figuring out what the current workflow was, and trying to follow it.
This is where Nigel came in. Conveniently, the upstream Puppet development
is done in Git also, and Nigel is a contributor to Puppet upstream, so he
had some Git-fu. So between the instructions
on how to get started with Git on Alioth and what he knew, we could
start fumbling around.
It seems like the Alioth Git repository was also tracking the upstream
Puppet repository, as there were commits in the Alioth one by Luke Kanies,
and we didn't really imagine that he was doing Debian-specific stuff.
Here's what we ended up doing to try and get what was in the Alioth
repository up to the upstream version 0.24.8 of Puppet:
git clone ssh://apollock@git.debian.org/git/pkg-puppet/puppet.gitThis part was fairly straight forward. Clone what's in Alioth locally.
git remote add reductive git://reductivelabs.com/puppet git remote update git fetch --tags reductiveNext, we added a remote branch that tracked upstream. We called it "reductive", and we updated it. The bit that took some fiddling with was fetching the tags. Nigel later figured out that tags are inherently private to a repository, and normally stay that way. So if I have a local clone of say the upstream Puppet repository, I can tag it to my heart's content, and normally those tags would stay in my local repository, because they're probably only meaningful to me.
git checkout -b upstream/0.24.8 0.24.8This bit took a bit of work to arrive at as well. What we wanted to do was create a new branch called upstream/0.24.8, which was at what was tagged 0.24.8 in the reductive repository. Nigel pondered what would happen if you already had a tag or a branch called "0.24.8" before you added the remote repository. This is also why we had to fetch the tags from the remote repository, so we had something to check out.
git checkout master git merge upstream/0.24.8Next, we switched back to the master branch and merged the contents of our local upstream/0.24.8 branch that we just created. This now got the Puppet source in the master branch up to what was released as version 0.24.8. (and this is better than just running uupdate?) We did some fiddling with the debian/control file and debian/changelog and fixed up a few things that Lintian was bitching about, and were done. I'd set up a sid chroot with cowdancer previously, and had to do some faffing around with git-buildpackage to convince it to use pbuilder. I ended up using
git-buildpackage --git-builder="pdebuild --debbuildopts '-i\.git -I.git' --basepath /var/cache/pbuilder/base-unstable.cow"So now we've got most of what we want to ship checked into Git on Alioth. I have no idea if we've done it "right", I suspect we may have done something wrong by operating on the master branch. Looking at the revision history in the Git repository on Alioth, it looks like previously things have been done a few different ways. I certainly want to write up a definitive workflow once we've figured one out. We haven't uploaded the new package to unstable yet, because we're still trying to give it a modicum of testing, and we'd like to sort out the Facter package as well. The Facter package was a more greenfield exercise, as while there was already a Git repository on Alioth for it, it was empty. So Nigel had to do some futzing around to get it checked in the right way to make git-buildpackage want to build it. He did this by himself, so I'm not sure exactly what he did. I've since discovered that it's probably lacking some dependencies it needs, so that'll need to get fixed before it gets uploaded. I look forward to reading blog posts from the smart people who actually know how to use Git properly, telling me how we should have done it. I'm still very interested in coming up with a proper workflow for preparing packages and committing the changes, and for doing code review.
After far too long (too many holidays away from my keyboard :-) I've released DAViCal 0.9.6.3 and AWL 0.36. This is mostly a stability release, fixing all those little niggles that might only affect a few corner cases, but it frees me up now to concentrate on adding more functionality for a 0.9.7 release in due course. Hopefully this will be the last in the 0.9.6.x series.
More information in the DAViCal release notes on the wiki.
There are quite a few changes to the AWL libraries which this release depends on, but most of those changes have been driven by my Work Request Management System and Capital APMS projects, rather than from DAViCal.
While I did not think I would continue hacking on VoiDroid after achieving a semi-broken proof-of-concept implementation, it seems that I can t get out of it easily :-). I spent today trying to implement a solution which would allow the native C++ code to call into Java - for example, if we have a call in progress, and want to update the call status displayed to the user when it changes. The JNI library has some native callbacks which are getting called on call state changes, but getting the information to Java turned out to be a quite an experience, which, I thought, would be amusing to document, and, hopefully, save someone some quality bang-head-on-desk time.
1. Some of the threads calling native callbacks were initiated in Java (and thus known to JVM), and some where not, they were started in the native code. As JVM did not know anything about them, JNI calls would fail without too much explanation. Eventually I figured that out, and started attaching them as appropriate (JNI provides facilities for that).
2. Even after attaching, I could not resolve references to my classes from the native code, until I found a mysterious line in JNI docs: When a thread is attached to the VM, the context class loader is the bootstrap loader.. Basically, it means that when you attach a native thread, it is only capable of resolving built-in Java classes.
3. I later found a reference to a technique, suggesting to cache a good classloader from a Java-initiated thread, and later set the classloader for the attached thread to it. I implemented that, only to find out that Android s JVM is not your regular JVM, so things are slightly different here, and this technique does not work.
4. Luckily, there is an incredibly useful post describing the problem, and suggesting a workaround: caching an instance of needed class globally in native code, after calling NewGlobalRef on it, to avoid garbage collection on exit from a native function. I did that, however I only had access to the class, and Android JNI only supports calling NewGlobalRef on an object, so I had to create a dummy object in the native code (JNI_OnLoad() function, actually) and cache that.
5. That finally enabled me to call into Java from native, attached threads (w00t!). Unfortunately, you are not allowed to modify the UI (exactly what I wanted to do from my Java callback!) from a non-UI thread, which brought me right back to the drawing board.
6. As callbacks initiated from native code would not work for this reason, it was suggested to me to use a classic producer-consumer mechanism, getting Java call into the native library block until new information gets delivered by a native thread. Easily done with some pthread mutexes, and the goal is close, right?
7. Wrong! Now the problem was that if I started a UI Java thread, which would call the native function in a loop to retrieve the data (it would not actually spin, as the native function blocks until new data is available), then it would be declared not responding by the UI framework in a few seconds. I could start a non-UI thread for that, but you guessed it a non-UI thread is not allowed to update UI! Instead of resolving the problem we just shifted it into the Java land.
8. While I was simply thinking about stuffing the result into a class variable and passing it to the UI thread this way, this tutorial, showing how to display a progress indicator while doing some heavy calculations in the background, provided a more elegant idea. One can use Android s android.os.Handler class to pass messages (with arbitrary payload) between threads.
That was the last piece of the puzzle, which allowed me to finally achieve a working implementation (some 10 hours or so later :-).
ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 eapol_version=2 ap_scan=1 fast_reauth=1 network= ssid="eduroam" key_mgmt=WPA-EAP proto=RSN pairwise=CCMP group=TKIP eap=TTLS anonymous_identity="anonymous@tu-dresden.de" identity="****@tu-dresden.de password= **** ca_cert= /etc/wpa_supplicant/TUD-CACert.pem phase2= auth=PAPInstead of the script suggested at the site above, you can also use this snippet in /etc/network/interfaces:
auto wlan0 iface wlan0 inet dhcp wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf/etc/network/interfaces It is also possible to put the values directly into /etc/network/interfaces:
auto wlan0 iface wlan0 inet dhcp wpa-ssid eduroam wpa-proto RSN wpa-group CCMP TKIP wpa-pairwise CCMP TKIP wpa-key-mgmt WPA-EAP wpa-eap TTLS wpa-ca-cert /etc/wpa_supplicant/TUD-CACert.pem wpa-phase2 "auth=PAP" wpa-anonymous-identity anonymous@tu-dresden.de wpa-identity ****@tu-dresden.de wpa-password ****network-manager Here is a screenshot of the authentication dialog. So now everybody at the University of Dresden wanting to use eduroam should hopefully be able to configure this connection on his Debian/Ubuntu system.
I think I've never mentioned here that I've been microblogging for some
time on identi.ca (also sent to
twitter). That has been preventing
me from writing some of the more banal sorts of blog posts, for good or ill.
I've just added a sidebar to my blog
that holds my most recent dents. With ikiwiki, doing so was
very quick and easy!
I devoured
Racing the Beam
last night. It does a great job at getting inside the Atari 3600 platform and
explaining how it affected the early games that ran on it. Full of great
examples, like Yars Revenge displaying its own code onscreen as a visual
effect, to avoid needing a random number generator. Teaches how to analyse
screenshots of 3600 games and see how the crazily limited hardware was coaxed
into drawing them. Highly recommended, just wish it were twice as long.
(I also enjoyed that the book itself is a nice recursive hack. Its
(fairly cheap) printing process didn't allow reproducing the detailed color
photos of the games needed for reference. So they printed them on the
inside of the dust jacket instead.)
![]() |
dcraw -w -b 1.2 -q 3 -T DSC_0*.NEF
for i in *.tiff ; do j= echo $i sed -e 's/tiff/jpg/g' ; convert $i $j ; done
One really nice feature of maven is the dependency resolution stuff
that it does. The dependency plugin also has an analyse goal that can
detect a number of problems with your dependencies. It can detect
libraries you use but haven't declared in your POM, but work through
transitive dependencies. This can cause build problems when you remove
the library that was dragging in the undeclared dependency. It can also
work out which dependencies you are no longer using, but have a declared
dependency.
mojo-jojo david% mvn dependency:analyze [INFO] Scanning for projects... ... [INFO] [dependency:analyze] [WARNING] Used undeclared dependencies found: [WARNING] commons-collections:commons-collections:jar:3.2:compile [WARNING] commons-validator:commons-validator:jar:1.3.1:compile [WARNING] org.apache.myfaces.core:myfaces-api:jar:1.2.6:compile [WARNING] Unused declared dependencies found: [WARNING] javax.faces:jsf-api:jar:1.2_02:compile ...
Copy of http://lists.debian.org/debian-devel/2009/04/msg00421.html.
Hi folks,
We have been pretty busy these past few weeks with the whole Google Summer of Code 2009 student application process.
Ok, so at work, pretty much the whole company uses Windows, of some sort. The web team, however, are pretty adamant that they use the best tools available for them, and we use Ubuntu because of this (because it s the easiest option that we all have the same distro, and as long as it s Linux, we don t mind)
Anyway, at the moment we re working through the process of moving all our internal business applications from Visual Basic.NET (urgh!) to PHP + a web based app. The Product Owner for this is one of the bosses, who currently uses Windows Vista.
He has, however, seen us all using Ubuntu and it s got him interested in using it. He s said that he wants to try using Ubuntu, and see whether he can get his work done on that, and slowly transition to it, as obviously, he needs to be able to use Windows for the .NET stuff (which sadly, doesn t work well under WINE).
So, we set him up a Virtual Machine, and he got to grips with what he was doing, great. Except for the fact that he had to allocate memory to it, switching back and forth between windows and Ubuntu was a pain. He eventually gave up on this idea, and got a spare machine, a spare monitor, and set it up next to his machine.
Still, however, it was a bit of a pain, he d have to switch position on his desk, start using a different keyboard and mouse, and i was all a bit of hassle.
Recently, we ve gotten a big screen (which isn t actually that big!) for the Web Team to monitor the servers, our order download service, etc etc. We were showing our manager some of the stuff we could do with it, and he asked the question So, how do you control it - to which my response was to move my mouse off of the edge of my screen, and onto the big screen. So is that a third monitor? he asked. No I replied, it s another machine.
Enter Synergy
So this is the point where I explained to our manager exactly what synergy is. Trying to explain it however, is a bit of a hassle, so I ll try my best here. Synergy is an application that allows you to control another machine s keyboard and mouse from your own PC. It s a bit of a mix between a KVM switch, and Remote Desktop, but it doesn t require extra hardware, and you dont have to relay the video across the network to show it on your screen too.
At this point, our boss got a glint in his eye
Does it work in Windows? he asked. At this point, I didn t realise that he had a seperate machine for Ubuntu. I told him it did anyway, but I wasn t too sure whether it worked with Vista
Lets give it a go anyway
So we went over to his machine, and I installed quicksynergy on his ubuntu box, while he downloaded the Windows installer for Synergy. 5 minutes later, he was grinning like a maniac as he moved his mouse from one machine to another.
Now he s happily using Ubuntu without any hassle, it s just a third screen to him - with different stuff on it.
I think the moral here is, there are different ways to get people to be able to use Linux, and Synergy is one of those great tools that enable people to use Linux without having all the hassle that comes with switching over.
I think also, a quote from m manager sums it up.
This is one of the best things I ve seen all year. I thought it d take forever to setup, but it was so quick. I can be so much more productive nowI hope that this will be one of the turning points for my manager, and we ll have another convert by the end of the year
Next.