Search Results: "will"

17 August 2007

MJ Ray: Free Software Competitions

Georg Greve of FSFE asks people to Submit your Free Software projects for the Trophees du Libre - closing date 1 October 2007. I also saw somewhere a link to the entry form for the New Zealand OS Awards - the event is in October, but I can't see a closing date on the form. If you're a non-programmer and want to do something very helpful for a project like Koha, please consider writing us a nomination. Koha won a Trophee du Libre a couple of years ago. By the time the deadline hits this year, maybe 3.0 will be out.

Russell Coker: Controlling a STONITH and Upgrading a Cluster

One situation that you will occasionally encounter when running a Heartbeat cluster is a need to prevent a STONITH of a node. As documented in my previous post about testing STONITH the ability to STONITH nodes is very important in an operating cluster. However when the sys-admin is performing maintenance on the system or programmers are working on a development or test system it can be rather annoying. One example of where STONITH is undesired is when upgrading packages of software related to the cluster services. If during a package upgrade the data files and programs related to the OCF script are not synchronised (EG you have two programs that interact and upgrading one requires upgrading the other) at the moment that the status operation is run then an error may occur which may trigger a STONITH. Another possibility is that if using small systems for testing or development (EG running a cluster under Xen with minimal RAM assigned to each node) then a package upgrade may cause the system to thrash which might then cause a timeout of the status scripts (a problem I encounter when upgrading my Xen test instances that have 64M of RAM). If a STONITH occurs during the process of a package upgrade then you are likely to have consistency problems with the OS due to RPM and DPKG not correctly calling fsync(), this can cause the OCF scripts to always fail to run the status command which can cause an infinite loop of the cluster nodes in question being STONITHed. Incidentally the best way to test for this (given the problems of a STONITH sometimes losing log data) is to boot the node in question without Heartbeat running and then run the OCF status commands manually (I previously documented three ways of doing this). Of course the ideal (and recommended) way of solving this problem is to migrate all services from a node using the crm_resource program. But in a test or development situation you may forget to migrate all services or simply forget to run the migration before the package upgrade starts. In that case the best thing to do is to be able to remove the ability to call STONITH . For my testing I use Xen and have the nodes ssh to the Dom0 to call STONITH, so all I have to do to remove the STONITH ability is to stop the ssh daemon on the Dom0. For a more serious test network (EG using IPMI or an equivalent technology to perform a hardware STONITH as well as ssh for OS level STONITH on a private network) a viable option might be to shut down the switch port used for such operations - shutting down switch ports is not a nice thing to do, but to allow you to continue work on a development environment without hassle it’s a reasonable hack. When choosing your method of STONITH it’s probably worth considering what the possibilities are for temporarily disabling it - preferably without having to walk to the server room.

Stefano Zacchiroli: debcheckout bits

debcheckout: some new bits Some new bits about debcheckout (talk is cheap, code here): (Perl) Tip of the day: Switch.pm With "use Switch;" you will win a switch statement for your Perl programs, which can be used as follows:
switch ($repo_type)  
  case "cvs"    my $module = pop @cmd; push @cmd, ("-d", $destdir, $module);  
  case /^(bzr darcs git hg svn)$/
                push @cmd, $destdir;  
  else   die "sorry, don't know how to set the destination directory for $repo_type repositories (patches welcome!)\n";  
 

This is far better than a chain of if/elsif statements and has even a sane semantics (e.g. no need of explicit breaks, possibility to have higher-case branches, ...). Unfortunately, it is not possible (using a simple syntax) to match a scalar value against an array case branch. Therefore the only way to factorize branches is (when possible) to rely on regexp alternative branches, as it is done in the code snippet above.

Andrew McMillan: Hosting on IPv6: autoconfiguration of IPv6 addresses may be harmful

The availability of IPv6 worldwide is surprisingly extensive, nowadays, but over the past years as it has slowly filtered around, people have had bad experiences with it because of poor routing. It seems that, as always, a bad rep travels about 20 times further than a good one, so an automatic response to casual problems that people see when using IPv6 is to blacklist it, without actually investigating the problem. Take today, for an example. Someone said to me "I disabled IPv6 in Firefox because it was slow for one of my favourite sites". OK, so show me this favourite site. Show me the traceroute. Give me some facts! Further investigation showed that although there is an AAAA record for www.crooksandliars.com, there is nothing listening on the other end! Looking at the AAAA record returned, we see that it is an autoconfigured IPv6 address of the form xxxx:xxxx:xxxx:xxxx:xxxx:xxFF:FExx:xxxx and can conjecture that the likely problem is that someone has done a hardware upgrade on their server, so they now have a different MAC, and consequently the autoconfigured IPv6 address has changed. Other scenarios are entirely possible, of course, but this is a likely one. This is the second case I have seen where someone was running publicly available services on IPv6 using a manual DNS record pointing at an automatic IPv6 address, but I doubt that it will be the last. Unless there is infrastructure in place to automatically update your DNS when your address is autoconfigured, you are going to get bitten by this problem at some point if people remotely connect to your system for some service.

Erich Schubert: Skype taking down your network

Side note: According to the Skype RSS data feed, right now 174086 user are online. That less than 10% of the usual numbers, isn't it? To me, that's more than a few users.Skype is harmful. Here's the explantaion why:Skype uses P2P technology where it is not needed. There are parts of VoIP where it does make sense (when a direct connection is possible, transfer the data directly between clients), but pretty much any VoIP software does that.And there are parts, where it doesn't make sense. This includes not accessing the login servers directly, but trying to use other Skype users as proxies.Now what I've seen happening in some networks is the following: Skype fails to login directly, so it starts connecting random peers it has seen before. It keeps a list of 200 peers for that in the registry. So when it fails to connect, it will try contacting these 200 peers instead. Now if you have multiple users sharing your connection, let's say 10 and a cheap router with limited memory, 2000 connections is a lot to keep track of. It might start losing other connections. Such as your mail an web connections.This is exactly what I've seen today: the internet connection becoming pretty much unuseable (single packets would work fine, but not TCP/IP transfers of more than a few kb). When we found out it might be due to Skype malfunctioning, and gave the order for everyone to shut down Skype (which didn't work anyway, so people quickly complied), Internet became useable again. Let me emphasize that: it wasn't a bandwidth issue, but it was just the sheer number of connections opened by Skype that caused more important connections to be dropped by the routers.So why is Skype not using proper servers, like MSN, AIM and ICQ do? Because they're cheapskates. It's cheaper for them to let others use your bandwidth instead of having to provide enough to handle all the data. The other reason is that it's harder for system administrators to deny access to Skype, if any other Skype user can proxy your access to the actual login server. But if you want/need a central user registry, you can't rely on a true P2P system. It's bound to get disconnected at some point.And yes, this especially means that Skype is not a good idea in a corporate environment with a large number of users. The skype approach works well for a single user at home, but the Skype networking behaviour can take down your routers if you have too many users running Skype at the same time. Other software choices, such as the standardized, vendor independant SIP protocol for VoIP, however would even allow you to setup a proper VoIP telephone system, with conference rooms, complex call routing, dictionaries, callback, routing to ATM or mobiles, complex voice mail systems, you name it. Skype is designed for single home users, not for company use.P.S. Am I the only one who thinks the Skype UI is crap? No groups (at least not in my version, which is the latest there is for Linux), and totally idiotic button placement (like this ugly 'add' button I'm pretty much never ever, and a floding-up button next to it with the options, quit and recent chats (do they have anything in common?) hidden in there. How about using a menu bar like everybody else? How about organizing functionality in a human-comprehendable way?P.P.S. What I guess has happened: somehow, most nodes (especially super nodes) got convined that the actual login servers are bad. As long, as some still had the connection, login still worked. At least sometimes (many probably experienced an unstable Skype connection before they could no longer login). But at a certain point, a large part of the network got separated from the login nodes and started routing requests around chaotically, trying to find the actual login server. The only way they have for fixing it, is slowly convincing and nodes on the perimeter of the P2P network about the proper location for the login servers, and that way spreading the correct information around again. Or shipping a new version which will re-inject this information in clients again. Just my guesses.P.P.P.S. It would be interesting to know what had caused this. If it was some kind of subtle attack on the network. Like someone trying to convince supernodes that the login servers are bad and untrustworthy or something. Maybe just by sending spoofed bad data packets from the login servers IP or so.P^4.S. Interesting graph on the number of Skype users logged in. Still going down.

16 August 2007

Neil Williams: dpkg-cross/apt-cross changes

Making progress here - courtesy of apt-rdepends and Simon Law. The Depends handling in libapt-pkg-perl is fraught with difficulty. Self-referencing arrays mean that I can't use my normal use Data::Dumper; print Dumper($foo); because Dumper quickly descends into an infinite loop and if you don't catch it fast, you lose X.
Hopefully, using a simpler interface will help develop other scripts to use the apt cache directly.

Neil Williams: gpe-expenses moves to GPLv3

I actually should have done this at the last release as that already includes some files licenced under GPLv3 but now I'm ready to make an upstream release (including an updated German translation that missed the original string deadline). The only real change is that debian/copyright has grown to the extent that each package is 10kb larger than before!
One day, when GPL3 goes into /usr/share/common-licences, I'll get back to the small packages. Still, Emdebian won't need the extra bloat so it's only a Debian issue.

Alexis Sukrieh: Perl Console 0.2 Debian package

The first version of the debian package of Perl Console has been uploaded to the NEW queue. For those who are waiting for it, I’ve also uploaded the package here. Thanks to the patch sent by Antonio Terceiro, the version 0.3 will be properly packaged ala Perl (namely with the famous Makefile.PL, MANIFEST and friends). I plan to adress the multi-line issue for 0.3 (mainly handling code with loops or conditional structures), as Florian Ragwitz underlined, it could be worth using Devel::REPL instead of rewriting the wheel.

Paul van Tilburg: Work Has Started

Two weeks ago I started my new job at the Formal Methods research group of the Department of Mathematics of Computer Science at the Eindhoven University of Technology. So, what have I been up to until now? Well, as you can imagine it takes some time to settle down. I got a room with two other PhD students. I have installed my new (and fast!) computer with Debian Sid and am very happy about it. I have created my academic website using Webgen (like I do with all my sites), attempting to have it look the same as the main university site. I think I have succeeded. Next to the settling down I have been meeting all the people of our group and reading a lot of papers in my future area of research. What will I be doing the next few weeks then? For the moment I’ll continue to do a lot of reading. My research is in the area of the automata theory and the process algebra and ways to combine them. Besides reading up on that I will be continuing upon my master project and try to get the result published. Also, my first conference has been planned! Yay! From September 2 till September 8 I will be in Lisbon to attend the CONCUR 2007 conference and also have a look around town, of course.

15 August 2007

Holger Levsen: Debians 24th birthday

So Debian is now 14 years old - ignoring the timezone differences :-) Thanks for all your contributions and have fun with Debian today and everyday! ;-)

While thinking about it, I remembered a question I was recently asked in an interview to look into my crystal ball and tell how Debian will look like in ten years. I couldn't really figure out a concrete answer, I just said vaguely that I hope it changes in some ways, while I hope other things stay like they are.

What do you think?

Simon Richter: IPv7 will be...

... much like IPv6, except they finally decide to move the checksums to the end of packets to make it easier to handle them in hardware. It's not as if there hasn't been any precedent for that.

Lior Kaplan: openooffice.org bug triage - the end

During the last 6 weeks I’ve been working on the debian openoffice.org bug triage, targeting 166 old bugs reported against versions lower than 2.0.0. Today, I’ve closed all the remaining bugs without response from the submitter to the 3 pings sent. During the process, 50% of the bugs were found to still be relevant for recent versions of openoffice.org or to be already fixed by them. For those interested, the final statistics are: 24 bug reproduced.
61 bugs closed as fixed / not relevant any more
81 bugs closed due to lack of submitter response. So the oo.org bug count decreased from around 500 to around 350. So I hope this will help to openoffice.org team to focus on the remaining bugs. As 350 bug is still a lot, I intend to repeat the process when version 2.2.1 will enter testing. p.s If any other teams think they need help with bug triage - you’re welcome to contact me.

Russell Coker: ARP

In the IP protocol stack the lowest level protocol is ARP (the Address Resolution Protocol). ARP is used to request the Ethernet hardware (MAC) address of the host which owns a particular IP address. # arping 192.168.0.43
ARPING 192.168.0.43
60 bytes from 00:60:b0:3c:62:6b (192.168.0.43): index=0 time=339.031 usec
60 bytes from 00:60:b0:3c:62:6b (192.168.0.43): index=1 time=12.967 msec
60 bytes from 00:60:b0:3c:62:6b (192.168.0.43): index=2 time=168.800 usec
— 192.168.0.43 statistics —
3 packets transmitted, 3 packets received, 0% unanswered One creative use of this is the program arping which will send regular ARP request packets for an IP address and give statistics on the success of getting responses. The above is the result of an arping command which shows that the machine in question can respond in 12.9msec or less. One of the features of arping (when compared to the regular ping which uses an ICMP echo) is that it will operate when the interface has no IP address assigned or when the IP address does not match the netmask for the network in question. This means that if you have a network which lacks DHCP and you want to find a spare IP address in the range that is used then you can use arping without assigning yourself an IP address first. If you wanted to use ping in that situation then you would have to first assign an IP address in which case you may have already broken the network! Another useful utility is arpwatch. This program listens to ARP traffic and will notify the sys-admin when new machines appear. The notification message will include the Ethernet hardware address and the name of the manufacturer of the device (if it’s known). When you use arpwatch you can say “who added the device with the Intel Ethernet card to the network at lunch time?” instead of “who did something recently to the network that made it break?”. The more specific question is more likely to get an accurate answer.

Russell Coker: ARP

In the IP protocol stack the lowest level protocol is ARP (the Address Resolution Protocol). ARP is used to request the Ethernet hardware (MAC) address of the host which owns a particular IP address. # arping 192.168.0.43
ARPING 192.168.0.43
60 bytes from 00:60:b0:3c:62:6b (192.168.0.43): index=0 time=339.031 usec
60 bytes from 00:60:b0:3c:62:6b (192.168.0.43): index=1 time=12.967 msec
60 bytes from 00:60:b0:3c:62:6b (192.168.0.43): index=2 time=168.800 usec
— 192.168.0.43 statistics —
3 packets transmitted, 3 packets received, 0% unanswered One creative use of this is the program arping which will send regular ARP request packets for an IP address and give statistics on the success of getting responses. The above is the result of an arping command which shows that the machine in question can respond in 12.9msec or less. One of the features of arping (when compared to the regular ping which uses an ICMP echo) is that it will operate when the interface has no IP address assigned or when the IP address does not match the netmask for the network in question. This means that if you have a network which lacks DHCP and you want to find a spare IP address in the range that is used then you can use arping without assigning yourself an IP address first. If you wanted to use ping in that situation then you would have to first assign an IP address in which case you may have already broken the network! Another useful utility is arpwatch. This program listens to ARP traffic and will notify the sys-admin when new machines appear. The notification message will include the Ethernet hardware address and the name of the manufacturer of the device (if it’s known). When you use arpwatch you can say “who added the device with the Intel Ethernet card to the network at lunch time?” instead of “who did something recently to the network that made it break?”. The more specific question is more likely to get an accurate answer.

Julien Danjou: i386--, amd64++

As I said previously, abydos was dead. I bought new hardware some days after, mainly a new Enermax Liberty ELT 500 W power supply (ATX 2.2 compliant, sick, my old Enermax ATX 1.2 could not work with new mainboards), an Asus P5K, 2 GB of G.Skill DDR2 PC6400, an Intel Core 2 Duo E6750 and a GeForce 8400 GS 512 MB. At that time, I just switched the hard drives without reinstalling the box. However, I had to reinstall some days because my old was an old Intel Pentium 4 (i386) and the new is 64 bits-ready. Before that, I played with some kind of stuff. First, installing cpufrequtils is just magic, because now my processor is set at 2 GHz instead of 2.66 GHz, and rise to 2.66 GHz on demand. Just cool: less power, less warm, less noise. I tried to tweak my SATA drives. I did something very wrong: hdparm -s. Kids, don't do this at home, it killed my hard drives! Yes, you're warned if you read the hdparm manual and you have to force the command, but I'm mad anyway. After that, the drives were no more detected at boot time by the buggy BIOS. Why buggy? Because after some googling, I found that they were NOT dead, just sleeping. And the fucking BIOSes around never try to wake them up. Fortunately, hdparm people distribute an bootable ISO that will wake your drives... It saved me. The Asus P5K is not well supported by the 2.6.18 kernel, so you won't have network during install of etch (or lenny beta 1), and when you will reboot you won't be able to boot correctly because initrd is stuck with hard drive detection. Furthermore 2.6.18 on this mainboard is fucking slow anyway. Fortunately, I just added another NIC in the box, boot on the CD, mount disks, chrooted and dist-upgrade to sid with a 2.6.22 kernel which work perfectly. So now, everything's ready and set up, I can play!

Mike Hommey: WebKit (almost) in unstable

I finally uploaded the first release of WebKit to unstable. It will obviously need to go through NEW first, which might take some time. There still is work to do, first of which being to correctly setup the git repositories. For the moment, there is only a git repository following upstream svn available on git.d.o. The branches are a bit messy, though ; I have to figure out why git-svn insists on randomly recreating the master branch… I supposedly removed the master branch to have the svn branch follow the git-svn remote. Anyways, once it is sorted out, I’ll set up a special branch to create our tarballs and from which we’d derive the debian branch (or not, this is not decided yet). This special branch will be a copy of the upstream branch with some stuff removed (see debian/copyright in the current packages source for a list of these). Speaking of the package source, since NEW is not available, I made the packages sources and binaries available on gluck. An important note: the version I uploaded is made from revision 24735 of upstream svn repository, which is from July 27. Unfortunately, to be able to build the first version of epiphany that includes webkit embedding (2.19.6) as is, webkit_gtk_page_can_go_forward and webkit_gtk_page_can_go_backward are needed, and these, while available in the API headers, only appeared in the source code on July 30. However, I built a hacked epiphany with calls to these functions removed (which means back and forward buttons won’t work properly), and made it available on gluck too. Be aware this version requires glib and gtk from experimental, which, I’ve been said, made all gtk/glib warnings fatal. That means all applications that usually fill your .xsession-errors log file are likely to crash with these versions. You’ll note integration is not yet perfect, biggest misfeature being the scrollbars missing, and some glitches such as the user agent (it is hardcoded in WebKit :-/), and the about window still saying it is based on Gecko ;) I’ll try to push a new version of WebKit soon enough. Stay tuned.

Lars Wirzenius: Debian: Debian 14 years

To celebrate Debian's 14th birthday, in Helsinki, Finland, on August 16, from 18:00 onwards, let's gather in AWK or Annankadun William K (the southern end of Annankatu) for a beer or two. For those without calendars, that's tomorrow.

Robert Collins: 15 Aug 2007

When are two identical changes the same, and when aren't they? Theres a little bit of debate started by Andrew Cowie posting about unmixing the paint. Matt Palmer followed up with a claim that a particular technique used by Andrew is dangerous, and finally Andrew Bennetts makes the point that text conflicts are a small subset of merge conflicts. That said, one critical task for a version control system is the merge command. Lets define merge at a human level as "reproduce the changes made in branch A in my branch B". There are a lot of taste choices that can be made without breaking this definition. For instance, merge that combines all the individual changes into one - losing the individual commit deltas meets this description. So does a merge which requires all text conflicts to be resolved during the merge commands execution, or one that does not give a human a chance to review the merged tree before recording it as a commit. So if the goal of merge is to reproduce these other changes, then we are essentially trying to infer what the *change* was. For example, in an ideal world, merging a branch that changes all "log messages of floating points to 6 digit scale." would know enough to catch all new log messages added in my branch, regardless of language, actual api used etc etc. But that is fantasy at the moment. The best we can do today depends on how we capture the change. For instance, Darcs allows some changes to be captured as symbol changing patches, and others as regular textual diffs. So the problem about whether arriving at the same result can be rephrased 'when is arriving at the same result correct or incorrect'. For instance, if I write a patch and put it up as plain text on a website, then two people developing $foo download it and apply it, they have duplicate changes but its clearly correct that a merge between them should not error on this. On the other hand, the example Andrew Bennetts quotes in his post is a valid example of two people making the same change, but the line needing a change during the merge to remain correct. Here's another, example though. If I commit something faulty to my branch, and you pull from me before I fix it. Then while I fix the bug, you also fix it - the same way. That is another example of no-conflict being correct. If its possible for either answer - conflict, or do not conflict - to be correct, then what should a VCS author do? There are several choices here: I think that our job is to assess what the maximum harm from choosing the wrong default is, and the likely hood of that occuring, and then make a choice. Short of fantasy no merge is, in general, definately good or bad - your QA process (such as an automatic test suite) needs to run regardless of the VCS's logic. The risk of a bad merge is relatively low, because you should be testing, and if the merge is wrong you can just not commit it, or roll it back. So our job in merge is to make it likely as possible that your test suite will pass when you have done the merge, without further human work. This is very different to trying to always conflict whenever we cannot be 100% sure that the text is what a human would have created. Its actually harder to take this approach than conflicting - conflicting is easy.

Bastian Venthur: My top 5 Firefox/Thunderbird annoyances

Firefox is constantly gaining marked share (especially here in Europe) and it’s little not-yet-so-popular brother Thunderbird is evolving too. While I’m happy that they’re contributing their part to bring Free Software to the masses, I’m concerned that the quality of their software (especially Firefox under Linux) has decreased in the last months. Here are my top 5 annoyances for Firefox and Thunderbird. Some of them only apply to Debian’s version others are more visible on my fairly old and “slow” (1.5GHz/512MiB) Laptop than on current and therefor faster machines: Firefox Thunderbird While I’m still happy with Thunderbird (or Iceddove as we call it here) I’m really searching for an alternative to Firefox (Iceweasel). Unfortunately there is currently no alternative available which fits all my needs. Firefox has two extensions no other browser seems to provide and without which I wouldn’t want to work anymore (I wonder if that was a proper English sentence…): While other browsers have some ad-blocking functionality too, they all seem to lack the filter set updater. The next best alternatives are Konqueror and Epiphany but besides the lack of the above features every one of them has it’s own little quirks which doesn’t really motivate me to make the switch yet. But Konqueror is making progress and I’m really looking forward to KDE4 which will hopefully bring a usable web browser so I can finally get rid of Firefox. Update: Ooops, I nearly forgot my favorite pet annoyance of Firefox under Linux: Why does it have to insult the user’s eyes with this ugly toolkit when drawing check boxes, line edits, buttons etc? Firefox under Windows paints stuff like that according to Windows’ current theme, Konqueror under Linux as well, but what does Firefox for years?

Russell Coker: IT Recruiting Agencies - Advice for Contract Workers

I read an interesting post on Advogato about IT recruiting agencies (along with an interesting preface about medical treatment for broken ribs). Their report closely mirrored my experience in many ways. Here are what I consider to be the main points for a job applicant dealing with recruiters:
  1. Ask more than you believe that you are worth - the worst they can do is say “no” (and you will feel like a fool if the agency pays you less than half what the client pays because you didn’t ask for enough).

  2. Put lots of terms in your CV that will work for grep or other searches. A human who reads your CV will know that if you describe 3 years of Linux sys-admin experience that you can do BASH shell scripting and sys-admin work on other versions of Unix. But if a search doesn’t match it then the typical recruiting agent won’t offer you the position. I have idly considered saying things like “Perl (not Pearl) experience” to catch mis-spelled grep operations.

  3. Recruiting agents will frequently demand that you re-write your CV to match a position that they have open, they will say things such as “you claim 3 years of shell scripting and Perl experience but I don’t see that on your CV” and insist that you re-write it to give more emphasis to that area.

  4. Most recruiting agents are compulsive liars and don’t understand computers, you have to deal with the fact that to get most of the better paying positions you need to have an incompetent liar represent you. Avoid the stupid liars though. For example I once refused to deal with an agent who told me about his plans for stealing the CV database from the agency he worked for and selling it to another agency - not because he was shifty in every possible way, but because he was so stupid as to boast about such things immediately after meeting me on a train.

  5. Expect that recruiting agents won’t understand the technology. If you politely and subtly offer to assist them in writing a letter to a client recommending you then they will often accept. Why would they go to the effort of assessing your skills and writing a short letter to the client describing how good you are when you can do that for them? On one particularly amusing occasion I was applying for a position with IBM and the recruiting agent had been supplied with a short quiz of technical skills to assess all applicants - they gave me the answer sheet and asked me to self-assess (I got 100% - but it was an easy test and I would have got the same result anyway).

  6. Some levels of stupidity are so great that you should avoid dealing with the agent (and possibly the agency that employs them). Being unable to view a HTML file is one criteria I have used since 1999 (every OS since about 1998 came with a web browser built in). Another example is an agent who tried to convince me that “.au” is not a valid suffix for an email address (I was applying for a sys-admin job with an ISP). Job adverts that mis-spell terms (such as Perl spelled at Pearl) are also a warning sign.

  7. Gossip is important to your business! Some agencies will pay you what you earn and merely terminate your contract when things go wrong. Other agencies will refuse to pay you when things go bad, or even demand that paid money be returned and threaten legal action. Talk to other contract workers in your region and learn the goss about the bad agencies. Also track agency name changes, when a bad agency changes name don’t be fooled.

When applying for a position advertised by an agency you will ideally start by seeing an advert with a phone number and an email address. The best strategy in that case seems to be to send your CV with a brief cover letter and then about 5 minutes after your mail server sends the message to their mail server you phone them. I found that I got a significantly higher success rate (in terms of having the agent send my CV to the client) if I phoned them when my CV arrived. Sometimes a fax number is advertised, unless there is some problem that prevents sending a document via email (such as the agency having a broken mail server) then do not FAX them. A faxed document will have to be faxed on to the client and will look bad after the double-fax operation and will prevent the agent from grepping it. Rumor has it that agents will often post fake adverts for the purpose of collecting CVs (so that they can boast to clients In most situations a recruiting agent should insist on meeting you for an interview before sending your CV to a client. The only exception is if you are applying for a job in another country. Meeting an agent at a restaurant or other public place is not uncommon (often they want to meet you while travelling between other locations and sometimes their main office is not in a good location). I suspect that some agencies start with a “virtual office” and perform all their interviews in public places (this doesn’t mean that they will do a worse job than the more established agencies). If an agent is prepared to recommend you to a client without meeting you then they are not doing their job properly. It used to be that there were enough agencies pretending to do their job that you could ignore the agencies that will recommend any unseen candidate. But now an increasing number of agencies do this and if you want a contract you may have to deal with them. When an agency has a fancy office keep in mind that they paid for it by taking money from people like you! For contract work a recruiting agent is not your friend, they make their money by getting you to accept less money than the client pays them - the less they pay you the more money they make. A common claim is “we only take a fixed percentage of what the client pays”, but when you ask what that percentage is they refuse to answer - I guess that the fixed percentage is 50% or as close to it as they can manage.

Next.

Previous.