I just read the “Does the Distro Matter” post and immediately felt compelled to relay some of my experiences, not with distributions, but with recruiters. What is the deal with these people? Does it matter if a company is looking for experience with RHEL5 and you have experience with CentOS5? No! From a technical point of view they are almost identical! I would personally say that if you have 5-10 years experience with almost any distribution you should be able to move into a new one easily. But core skills do not matter to recruiters, only how well you match the buzz words. I helped a friend install a distributed MySQl environment for a small company once, but since it was not my company it apparently does not count as real experience. I may be a Java programmer with experience with several IDE’s but since Microsoft Visual Studio’s is not one of them it is the same as if I answered “What’s Java?” Why is this? What is wrong with these people?

I blame three things:

1) The recruiters, or even the companies central HR, are not in the field and thus do not understand the buzz words on their sheet. Most of them would not know the difference between one distribution of Linux and another. They also would not understand KRB/AD cross platform integration if it hit them in the face. They only know what is on the list in front of them. To them the difference between FC10 and FC11 may as well be the difference between speaking Bask and Thai. The people who would understand never get to see your resume.

2) The people who are looking for employees are too specific – mostly due to the fact the screeners don’t know anything. Do you ask for some one who understands the differences between Exchange Server 2003 and Server 2003 with Exchange? No, but they will ask for some one with RHEL5 (Even if they are using CentOS5) because that is what they are using. They could just ask for 15 years Linux experience but they don’t. In addition it would seem most people write the job requests so specific that only an internal candidate could possibly fill them. For example “Must have 5 years experience with Joseph ERP” Is not valid when Joseph ERP has less then 2000 outstanding user licenses across the globe and has only produced a commercial product for the last 6 years! Just because they guy your replacing had 5 years experience with it does not mean you need to be looking for some one with the exact same experience. Some times this is done so they can higher the internal candidate they had in mind before HR told them they had to post the job publicly, or sometimes this is done so they can decline any candidate they don’t feel is a good personal fit without filling out a ton of paperwork with HR, and sometimes it is because the person writing the job description was not thinking; i.e. the Joseph ERP example above.

3) The current applicant pool is so great they can get away with it. When I am loosing out to people with masters degrees, $100K worth of certifications, and 15 years experience, for a $20/hour job on a 3 Mo. contract you know there is a problem. That is too much experience for that job. On the other hand, if you have reached upper management, you have been apparently poisoned from playing in the field. No on wants to higher a former Director to manage their system migrations, so I should be grateful that they have the good sense to realize the over qualified person is a barging and buy. But this does mean that almost no mater how strict you write your requirements and how literal the recruiters follow them, eventually you will find a person who fits your requirements, or at least lies well enough to get in the door.

As an abstract complain, why do they ask what other jobs you have applied for and then disparage where you have applied? And why would they say they know some one at company X but when it is not the person you know at company X they believe you are lying about knowing any one at company X? And finally you do not have the technical experience to understand what I am telling you so why are you interrogating me regarding my technical experience. When I say that I believe DR is dead because of the reduced cost of CDP w/ FO why do you conclude I have no DR experience? I have many other complaints but I think most of them have been covered in prior posts.

Host Identity Protocol

This is going to be an uncherictersticaly short post; however I am woundering what is up with the Host Identity Protocol? For those who do not know the HIP allows for the implemntation of the HIT or Host Identity Tag. This is designed to solve the issue of moblie people losing thier sessions and streams when moving between networks. The assumption is that all, or atleast the majority, of services identify a client based upon there IP address. Acording to the abstract this will also make setting up servers behind NAT fierwalls easyer and increase security by uniqly identifying each host similer to an ssh finger print.

However I have three questins that leasd me to ask why this is a real projects:

1) Session ID's - When an application server needs to indentify a client they issue a session id to the client. For example when you hit my tomcat server and start a particuler session I don't care what network the client is on or what physical server the client may be hitting, I need to identify the client for the life of his session. Session ID's are already in place - so what what portion of session ID's fails so badly that it needs to be replaced with an entierly seporate project?

2) Existing Identifyers - Why not use existing identifiers such as the MAC address of the clients network interface? While it is true that ones IP can change all to frequently during the cource of a normal mobile operation, the MAC does not.

3a) Security Vs. Privacy - The answer to the above question leads to my final concern. Mac addresses can change when one user changes network interfaces. However the protocol sugested, as I understand it, sits between the Addressing and Transport layers. This is tradtionaly tied to a network interface thus changing interfaces would also change your HIT. The other one would be that MAC addresses can be esaly changed and this breaks it from being a consistant and secure identifyer. But HIP suffers from this as well.

3b) Security Vs. Privacy - There was a way to solve this security issue introduced back in the 90's; it was called CPU ID. This was a hardware based ID that was easy for all applications to read but very difficult to change or mask. The problem soon became that everyone screamed PRIVACY! It turns out people do not want to be uniquely identified with all of there activities on line at all times. As such manufactures quickly included the option to volunteerly turn off CPUID, and that was so popular it started to come turned off by default. This, of course, made it a completely invalid identifier.

So, unless you planning on replacing an entirely server side expiration based session ID I do not see how this will work. However, at the same time, I can not see why you want to replace session ID's. This leaves me to ask - Why is this a real project?

This is an actually question I am hoping some one can answer so please feel free to comment to this via the blog comments, or like most of you do, via twitter or facebook.