So, you have more than one Mac machine, you lucky [son|daughter]-of-a-gun! And you’ve got MacPorts installed on both since you’re a complete geek. But you’re getting tired of installing (or, more specifically, compiling) the packages on each of the machines. Especially if you have an older powerpc-based machine, this can be really time consuming. (A recent build of gnome-terminal and all dependencies on a PowerBook took 6 days!)

So, what’s a [guy|girl] to do? Well, you share your packages of course! But… how? Well, after spending hours today beating my head against the keyboard trying to figure it out, I’ve finally got a solution. Now, I know you’ll all be shocked by this, but the documentation for MacPorts sucks! Thankfully, there are some very helpful folks in their IRC channel.

So, now that I have suffered, you don’t have to. I took the time to write up a howto on the MacPorts wiki. So without further ado, I present:

Sharing MacPorts archives between multiple computers

Enjoy and don’t hurt your brain like I had to.

Problem number 1. Running as a daemon doesn’t work. It crashes after a few seconds and OSX prompts you to report the error to Apple. So you have to run it as a foreground process using the -f flag. The problem with this is that you have to keep a terminal handy. So I decided to run it in a screen session so that I could keep it running when I’m not around. Unfortunately, if you start it in a screen session (or via ssh for that matter), the clipboard sharing stops working. I don’t know why, but it does. (If you do know why, please comment and let me know!)

So after quite a bit of struggling, and trying a dozen different solutions, I finally found one that works. Start it in the foreground in the background. That is, start synergys or synergyc with the -f switch, but then put an & (ampersand) after the command to automatically background the task. At this point, you can close the terminal and leave synergy running in the “background”. Of course, YMMV. While this has been working fine for me, if you’ve got a better solution, I’m all ears.

For those who can’t make heads or tails of the preceding paragraph and just want the damned thing to work, start synergyc using:
synergyc -f your.computer.name &
and start synergys using:
synergys -f &
That should get you up and running with full clipboard support.

Note that in my case I was connecting two OSX desktops together. Different combinations of OS’s may yield different results, but I get the feeling that regardless of what OS the other computer is running you’ll still have the same problem on the local OSX machine.

1. Automatically load up ssh-agent and prepare your keys on login.

   OSX and most Linux desktop environments (Gnome, KDE, etc) have a “keyring” that stores system passwords and things for you in a relatively secure fashion. You unlock the keyring with a master password and you get access to stored passwords. ssh-agent can interact with these keyrings to automatically load up your ssh keys at login. You just unlock the keyring once, and your keys are all ready to go.

2. Use short names in your .ssh/config

   Sometimes you’ll be stuck working on servers with extremely long names. Or, worse yet, servers with no DNS name at all where you have to remember the IP address. In this case, you can use a host/hostname combination in your .ssh/config file to give you an easy to type name.

   host = shortname
   hostname = reallylong.nameplusdomain.com

   And, for bonus points, if your current login name doesn’t match the remote login name, you can add a user = remotename line. Now, instead of typing:
   ssh remotename@reallylong.nameplusdomain.com
   I can just do:
   ssh shortname

3. This last one is a potential security risk, but it can be handy when you’re deploying to a machine who’s host key changes regularly. I run into this all the time when preparing new release candidates of our Rails Boxcar images at work. I add stricthostkeychecking = no to my config. If I connect to the same server multiple times and it has a different host key (or no host key stored locally yet) I won’t have to manually approve it. Particularly handy in conjunction with Capistrano since cap will usually choke and exit with an error instead of prompting you with the “Add host key” message.

But, I strongly support their freedom to distribute those packages if they so please. Now, thanks to the oft-criticized but well-worded GPL, Red Hat is obligated to release the source for any modifications to open-source software that they create. This is what allows a project like CentOS to exist. But it turns out that the folks at Red Hat are not happy about someone else making no money off of the money that they made off the people who made no money. So they were kind enough to send their legal attack-dogs after these folks.

But, as GrokLaw has taught us, the snarling and slobbering of legal attack-dogs makes for great entertainment. Among the choice morsels contained within the letter, we have this gem:

Moreover, our client does not allow others to provide links to our client’s web site without permission. Your use of the RED HAT marks while linking to redhat.com suggests that Red Hat somehow sponsors or endorses your company which is false and misleading.

Now, you may have noticed that in a very uncharacteristic move, I’ve linked to every instance of the words Red Hat and RHEL within this article, sometimes gratuitously. This is because I consider this statement, and Red Hat’s position on this matter to be an affront to free speech.

It may not be legal for someone to claim to represent Red Hat. However, if they have something to say about Red Hat, whether that something is positive or negative, they have the right to say it and they have the right to make clear who it is that they’re talking about by providing a relevant reference, such as a link.

So, to you, Red Hat, I say fsck you! Seriously… you seem to have some errant bits floating around spewing out garbage which is tarnishing an otherwise pristine corporate whore reputation filesystem. How do you expect to get clients for your trade if you’ve got these creepy little critters crawling around your nether-regions? So, please, do us all a favor and get yourself checked out before straddling any more servers. Mmm-kay? Great.

For the record, I have no connection to Red Hat. I do not work for Red Hat, I am not supported by Red Hat, and I have never purchased a Red Hat product in my life. Nor do I intend to, at any point in the future, seek or accept employment with Red Hat nor purchase any Red Hat products, including, but not limited to, RHEL (Red Hat Enterprise Linux).

But, either way, it’s quite annoying. I really don’t understand why people are so uncomfortable with saying the word “demon” when talking about computers. They look at “daemon” and think, oh that can’t possibly be the same word as “demon” because that’s bad, so I’ll just pretend it’s something different. Well, sorry, it’s not.

Or, perhaps, they’re thrown off by that letter “a” in there. Now, the fact that the proper historical spelling is dæmon (note the letter æ) should be a slight hint. The “ae” in “daemon” is a digraph meant to represent “æ” since most computer keyboards don’t have a convenient way of typing the letter. So what other words use that letter?

How about: cæsar, æthereal, encyclopædia and hæmoglobin? There are certainly quite a few more, but I don’t feel like turning this into a book. So, let’s look at these words:

Cæsar (Caesar or Cesar)
You wouldn’t order a cAser salad, would you?

Æthereal (aethereal or ethereal)
This one should be particularly noticeable for IT folks. I don’t typically use Athereal to sniff network traffic.

Encyclopædia (encyclopaedia or encyclopedia)
If you look on the side of that big thick book on your shelf, you’ll notice that it is written “Encyclopædia Britannica”. Yet most of us know how to pronounce that word. And, while you’re at it, look up daemon in there.

Hæmoglobin (haemoglobin or hemoglobin)
This is one of those great examples of a word that has been simplified in American English to more accurately reflect the pronunciation. The “a” was removed entirely to simplify the word. Much like removing the “a” from “daemon” to give us “demon” in American English. Imagine that…

Companies like DreamHost have really redefined what one-click installations are all about, but I’m looking to take that further. Not just one-click hosting, but one-click virtual servers. Imagine filling out a form, submitting some billing info, and having a full-blown, ready to go virtual server available for your use (with root access to boot) within a few minutes.

With technologies like Xen allowing lightweight virtual machines, I’m hoping that we’ll soon be able to make this a reality. No more being confined to your $HOME, and trying to install software that isn’t supported by the hosting service within those confines. You’ll now be able to install software as it was MEANT to be installed, and just have it work.

With more and more Web 2.0 (is that cliché yet?) applications coming up, and with more and more developers designing said applications, it’ll be even more important to have an easy and reliable platform for hosting these applications. It’s obviously going to take some hard work and time to get it done, but I think it’ll really be a very positive step for the industry as a whole. Stay tuned for more about this.

Obviously, these are just my opinions and not the policy of Planet Argon, yadda, yadda. Same goes for any future work-related posts. But it’s a very exciting opportunity, and a very exciting time to be getting involved into this portion of the business.

So with a bit of digging, I found an ideal solution (that takes a little bit of work to set up). I use xvfb to provide a local X server that’s very lightweight, and then I run xmove inside it. I then start ogmrip connected to the xmove virtual server, and move it to my desktop to start it running. Once it’s started, I move it back to the xvfb server and get on with my work.

So the setup that I had to do to get this to work was as follows:

1. Configure my local X server (on thief) to accept TCP connections. In my case, this involved editing my ‘gdm.conf’ and setting DisallowTCP=false

2. Install xvfb and xmove on the remote server (encoder). apt-get install xmove xvfb

3. Start up xvfb. Using xvfb-run wasn’t working right for me, so I did it manually from the command line. Since I want to be able to refer to the output later I run it inside a screen session. So I do screen -S xvfb Xvfb :0 -screen 0 1024x768x24 The -S option to screen just gives it an easy name to use later when reconnecting. Note that using a bit depth greater than 24, while shown in the man page for xvfb as being valid, caused the startup to fail each time.

4. Once xvfb is running, I detach from the screen, and then do export DISPLAY=:0 Now we just need to create an .Xauthority file and start up xmove. So I do xauth generate encoder:0 . trusted followed by screen -S xmove xmove and then, once again, detaching from the screen once it’s started up ok.

5. Now it’s just a matter of updating DISPLAY one more time export DISPLAY=:1 (since :1 is the display that xmove uses by default) and starting up an application. Just for testing, I start up xterm and see nothing. (Which is ok, because it means it’s running in the xvfb server.)

6. Then it’s just a matter of doing xmovectrl -moveall thief:0 If this fails with an error you probably need to allow remote connections on the remote machine. So, in my example, I would open a terminal on thief and do xhost +encoder

If you’d like to have your applications open by default on your local machine, you can just pass the -server option to xmove. So, in the above example, instead of doing screen -S xmove xmove I’d do screen -S xmove xmove -server thief:0

And that’s it. With this setup I currently have ogmrip running on encoder and encoding a DVD, while I’m typing this on thief. Later, when I want to check the status of the rip I can connect to encoder, do another xmovectrl and off I go. Cool stuff!

You can grab it from the Software link above, or if you’re just too lazy, here’s a direct link for version 0.5. If anyone finds it useful, or if you have any questions, comments, etc, feel free to leave a comment here to contact me via the About page.

LIFETIME LIMITED WARRANTY

This product is lifetime warranted
- except as defined below -

To be free of defects in materials and workmanship to the original purchaser when used under normal conditions from the date of purchase.

Swivel and tilt mechanisms and bases are warranteed[sic] for 5 years.
Pneumatic cylinders, casters, all wood or plastic components and all upholstery are warranteed[sic] for a period of 3 years.

This chair is made up of the following pieces, from the ground up:

1. Casters
2. Base
3. Pneumatic cylinder with a plastic cover
4. Swivel/tilt mechanism
5. Wooden chair bottom and back, with leather upholstery
6. Plastic arms that also hold the bottom and back together

Ok… so… maybe I’ve missed something important here… but… umm… what exactly IS covered by this warranty then?!

At this point it’s only about 30% complete per the full RFC 4622 spec, but it was enough to add the necessary functionality to Gajim. I will be working on it as time permits to try to support as much of the spec as possible, but the current functionality is enough for most of the standard uses of the spec.

This module is intended to be used along with either a module or an application that conforms pretty well to XEP-0147. My initial reason for writing it was, after all, to improve the XEP-0147 support in Gajim. I believe that the module will make it into the Gajim subversion tree soon, so it will be a bit easier to contribute to. Until then, just use the link above for a static copy of the file. I’ve tried to document what I have so far pretty well. Running epydoc on it should give you more than enough information to start using it.