Ant, Ivy 2.0.0, and java.net.UnknownHostException

This is a Very Special Guest Post by Jim Moores, another one of the OpenGamma team. We thought this would be useful to the interwebs, and until we have the OpenGamma blog ready to go, we're all ranting as one.

Ivy is a great way of avoiding shipping all the dependent libraries with your code and making upgrading dependencies smoother and easier, but it can still be a bit rough around the edges. For those of you new to Ivy, it's a dependency manager that is built on top of Ant that goes off and downloads and installs all your dependent libraries given a pretty simple list in an xml file. It hit version 2.0 a few months back and started to be really useful with more and more projects switching over to it. Of course Maven has done many of the same things for much longer, but Ivy doesn't require the whole head-warping change of viewpoint that Maven does. To be fair to Maven, I've only used it in passing when building the MyFaces JSF source code and while I did get it working, and was impressed, it took a bit of fiddling. My general understanding of Maven is that it's more declarative than 'normal' build systems - you tell it what you need and you have to rely on it figuring the whole thing out and it requires you let go of the idea of targets and explicit flow control (apologies to Maven fans if any of this is inaccurate). Ivy requires less of a leap of faith because it fits in with the Ant style that is more familiar to many but still brings the advantages of automatic dependency tracking. It can even install itself.

When I first tried Ivy three or four months ago I quickly found that some of the packages I wanted weren't available in the default ibiblio maven repository, in my case it was BerkeleyDB. I soon came across the excellent Ivy RoundUp repository. Ivy RoundUp doesn't actually host the packages themselves, it's a meta-repository that hosts information on how to download extract and repackage artifacts on demand. Unfortunately I couldn't just switch over to RoundUp because I needed some packages that were only on ibibio, so I had to delve deeper into the ivysettings.xml file to set up what is called a chain resolver. Chain resolvers do just what they sound like they do - they try one repository and then fall back to another if the package can't be found in the first. Here is my settings file:

Unfortunately this didn't work at all. It turned out that the example ivy build.xml in the tutorial contains the line:

  <property name="ivy.install.version" value="2.0.0-beta1">
</property>

And that 2.0.0-beta1 has a bug in it that means that chain resolvers don't work. Once I updated the ivy.install.version property to the latest version (2.0.0 at the time) it worked fine. This is still a problem with the tutorials, so be aware.

Since then I've needed to start using Hibernate in my application so I thought adding it would be easy as it's one of the most widely used Java packages. Err, no. After finding Hibernate in RoundUp easily enough (the latest ibibio version is really old), my build hung for some time, apparently unpacking a file, and then went totally exception-tastic on me.

[ivy:cachepath]
[ivy:cachepath] download.1.N65558:
[ivy:cachepath]
[ivy:cachepath]       [get] Getting: file://C:/DOCUME~1/Jim/LOCALS~1/Temp//jta-1_1-classes.zip
[ivy:cachepath]
[ivy:cachepath]       [get] To: C:\Documents and Settings\Jim\.ivy2\packager\cache\jta-1_1-classes.zip
[ivy:cachepath]
[ivy:cachepath]       [get] Error getting file://C:/DOCUME~1/Jim/LOCALS~1/Temp//jta-1_1-classes.zip to C:\Documents and Settings\Jim\.ivy2\packager\cache\jta-1_1-classes.zip
[ivy:cachepath]
[ivy:cachepath] C:\Documents and Settings\Jim\.ivy2\packager\build\javax.transaction\jta\1.1\build.xml:53: The following error occurred while executing this line:
[ivy:cachepath] C:\Documents and Settings\Jim\.ivy2\packager\build\javax.transaction\jta\1.1\packager-output.xml:28: java.net.UnknownHostException: C
[ivy:cachepath]         at org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelper.java:541)
[ivy:cachepath]         at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:418)
[ivy:cachepath]         at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
[ivy:cachepath]         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ivy:cachepath]         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[ivy:cachepath]         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

and another ten pages of related stuff which I'll spare you. There was clearly some problem in downloading the JTA 1.1 classes, which are a dependency of Hibernate. I tried upgrading to the latest version of ivy - didn't work. I then assumed it was an ivy package file and went digging around. When I looked to see the temporary file it was trying to open it wasn't actually there. Hmm. Just before that it implies that it's downloading the file in question. Could it be deleting it? I eventually decided it must be a problem with the file in the repository, so I went looking for help there. That's when I came across this thread on the roundup mailing list archives, and then onto the Roundup discussion of manually downloaded software.

It seems some of the software DOES NOT get downloaded automatically by ivy. Unfortunately, instead of giving you a nice error message telling you where to put it, you get a java.net.UnknownHostException. It turns out you need to download the artifacts manually from the Sun website and put them in the temporary directory ivy uses to store package downloads.

Once it did this it all works magically. Apparently the reason for this is that the download requires ticking a license agreement box which can't be done automatically. I hope this knowledge helps someone save some time. I think in the long run it'll probably mean me having a private repository for those artifacts, but for now I'll leave that for another day.

Dress Code Wars Episode IV: The Suits Strike Back

Wow. What a bit of a crazy couple of days since my last rant on the absurdity of forcing developers to work under dress codes. It hit Proggit, Hacker News, was tweeted by some high-follower-count people, and had more page views than anything else I've done. For those of you new to the feed, welcome!

I've been following the conversation on as many sites as I've been aware of, to try to keep the conversation going, and I was quite chuffed when there were more words on the subject written by !Kirk as by me. Particularly given my verbose writing style, that to me is a sign of a good conversation, which was the primary reason for the rant.

I just wanted to take some time to address some of the common arguments that kept coming up.

Kirk, you're a pompous Prima Donna and you're really not that good, either. Just shut up.

Ahhh, Argumentum ad Hominem. Where would the internet be without you? Just for the record though, I don't claim I'm that good a developer, and while I've been accused in the past of being a Prima Donna, I really don't let it get to me. I think it's more telling about the accuser than the accused.

I like dressing nicely

Bully for you! I'm sure you look lovely in your bespoke suit and custom made shirt. I'm positive you're quite the looker, and are attractive to both genders. You're a straight shooter with Management Potential written all over you.

If you like dressing nicely so much, why are you worried about a lack of a dress code? Why not have no dress code and still wear a suit? If you're just saying that you like dressing well, why not stay dressing well without forcing your sartorial choices on others?

I like South-East Asian food a lot. I think you should like it. But I sure as heck wouldn't have a company cafeteria only sell Thai food, and force you to eat in it every day.

It's better for your career to dress well

Thanks for looking out for your fellow software engineers, and incidentally, I actually agree with this one (if you desire a management role, or a role where you're working very closely with the business on a daily basis, you should dress up a little). But it should be your choice.

This one is an arms race as well. The only way this works is if you dress just a little bit better than everybody else, no matter what they're wearing. Norm is jeans and T-shirt? You wear chinos and a shirt. Norm is slacks and a shirt? You wear a suit. Norm is a suit? You wear a bespoke suit and a custom-made shirt and Hermes tie. No matter what, you always have to dress just a little bit better. You should actually be the most in favor of loosening dress codes, because then you don't have to dress that well/expensively/uncomfortably to still stand out.

Without a dress code, chaos will ensue

"Dress Appropriately" is the most powerful dress code you can have, because it completely eliminates all these arguments:

• People will dress like ragamuffin street tramps. Someone goes too far and you think it affects others? Take them aside and say "that's inappropriate."
• People won't dress up for meetings where formal attire is required. I dress down when I code, but when I meet with investors or customers, I dress up. That's just common sense, and if you actually hire people with common sense, they'll use it.

Fundamentally, we're not children, we're professional software developers. Removing arbitrary rules won't result in a Lord of the Flies situation breaking out.

I don't like seeing your manky feet

Believe it or not, this came up several times. As long as women can wear open toed shoes or nice sandals or whatever, it's just a rubbish argument. You don't like seeing a bloke's feet because you don't usually see a bloke's feet. Believe it or not, there are whole countries where very few people of either gender wear shoes on a regular basis. Get over your foot phobia.

My family needs to eat

Look, I completely understand that your family needs to eat, and if, on balance, the best job on offer is one which dictates a dress code, and you're aware of the likely attitude of the firm based on the existence of said dress code, you should take it. I didn't want a job with a dress code when I took the contract with Big Bank B, but my family needed to eat as well. Pragmatism is the primary virtue of the successful professional software developer.

Just be aware that if the firm has a dress code, in my opinion, that signals many things about the firm and its relationship with its technical staff. Go into it with your eyes open. And in my opinion, if you have a choice between a job with no dress code, and a slightly higher-paid job with a dress code, you should pick the one without the dress code.

Software Developers Should Never Have Dress Codes

On Saturday, I visited my dry cleaner. [1] Normally this wouldn't be a particularly momentous occasion [2], except that it was the first time in three weeks that I had gone. Up until the end of August, I had to make sure that like clockwork, at least every 2 weeks my Better Half or I made the trek to the dry cleaners, to make sure that I had suitable attire for my Cash Money Day Job. But it hit me on Saturday that this was a thing of the past: I no longer work for a company foolish enough to have a dress code for its technical staff.

When I first joined Big Bank B on my 6-month contract, it was the first time I had ever in my life had to dress up for work. I'd managed to work full-time for over 10 years, inside financial services and technology firms, and never had a dress code. In fact, my previous company (Investment Bank A) was so notoriously dress-down for financial services that there was a catty reference in the New York Times regarding the fact that people would (gasp! shock! horror!) show up to meetings in shorts and flip flops. At Hedge Fund V (the previous employer), while traders would usually show up in business casual, nobody cared what the geeks wore. However, the week before I started at Big Bank B, I had to go out and shell out a few hundred pounds on all the things that I didn't have enough of: work shirts, proper shoes, non-denim trousers. All this just to go into an office and code all day.

There's no justification for a dress code policy in this day and age if you view the primary function of a software developer to be the development of software. Right now I'm wearing shorts, sandals, and a T-shirt. Can anyone argue that I'd be more productive (in quantity or quality of technical output) if I was wearing chinos and a blue shirt? Or, perish the thought, a suit and tie? Definitely not.

However, the big question is Why? Why in the world do people still persist with this gross stupidity in this day and age? And why is it that big banks, in particular, seem to be so obsessed with dress codes?

In The Trenches, Fighting Bugs

A few years ago, I interviewed with Lehman Brothers. I noticed that all the technologists interviewing me (and it was an all-tech interview process) were wearing suits. Some of them had ties on, some of them didn't. I didn't wear a suit to the interview, and felt a little self conscious about it. [3] I asked one of the guys there why in the world they were so dressed up to write code all day.

Apparently this had come up in the past, and one of the Really Big American Bosses justified the policy with a phrase that has stuck in my mind ever since: "When a soldier goes to war, he wears a uniform."

There are so many things wrong with that statement that I can't even enumerate them, but let's start with the most glaring: Programmers Are Not Soldiers. Soldiers go to boot camp, a process designed specifically to break down their sense of self and recraft the mentality of the individual to mindlessly obey orders, even unto death. Soldiers go to war; soldiers fight people with weapons; soldiers live in barracks and eat in mess halls and, you know, act like they're in the military.

That's not what I do as a software engineer/craftsman: I think; I discuss; I code; I maintain. I don't live in close quarters with my coworkers; I get to eat what I want when I want; and while whiteboard discussions may get pretty heated, they're seldom settled with bayonets. I don't write code while firing an automatic weapon, and I don't engage in hand-to-hand combat with bugs. How in the world does a standard set by a military organization apply to a private sector financial technology job? [4]

Developers Should Be Heard But Not Seen

Second justification that I've heard for these ridiculous policies actually came from the hiring manager at one of the firms that bought out the carcass of Lehman, maintaining the dress code insanity: "if you ever have to go to the trading floor, there might be customers on there, and we won't want them to see you dressed down." That's right, because someone might see a derivatives trading floor, and figure out that there are actual programmers who make the software that keeps the 8 LCD displays each of the traders have full of blinkenlights.

It reminds me of firms that I've heard of that actually have separate entrances for the IT staff: customers and well-dressed individuals in Door A, all the plebes in Door B (heaven forfend that the twain shall meet). Big Bank B effectively had this policy, in putting all customer-facing activities in one building, while putting all non-customer-facing activities (IT, Operations, Back-Office, Middle-Office) in a whole different building.[5]

Yet most firms that have the separate-door, or separate-building policy, have it in place specifically so that the staff that don't have to dress in a certain way to satisfy the sartorial requirements of outside customers/investors didn't have to. Big Bank B said "not only are we going to shield you from view, we're still going to make you dress uncomfortably."

The Replaceable Engineering Unit

So given that dress codes are a net negative for developers, what could really be behind the correlation between probability of dress codes and size of the firm?

Remember, Big Banks actively fight against entrepreneurial/independent-minded technical staff. And then they make them all dress alike. The two, I think, are inextricably linked by one factor: a desire to smooth out the inherent human differences in employees of a firm grown too big for its management structures to cope with.

The Mythical Man Month was written at a time when almost all developers were working in large institutions, and it speaks to the levels that managers at those institutions will go to try to view individual employees as nothing but entries in a Gantt Chart. It doesn't work, because technologists have different skill levels, different interests, different speeds. But big organizations plan at very senior levels, where the people who are making decisions are unable to even conceptualize the differences between the people underneath them (because they're past the 150-person soft limit on social group sizing).

When faced with the requirement that you manage people beyond your cognitive limits, you can respond in one of two ways:

• Decentralize, and give massive autonomy to the people underneath you whose organizational unit size is within Dunbar's Number; or
• Standardize, and try to force individualism out of the equation.

Let's go back to Lehman Brothers. I think it's actually a telling example, because military units inevitably combine attempts at minimizing individual differences with organizational units that are below Dunbar's Number. So boot camp attempts to minimize individualism at the level of individual troops, but many decisions are made at the level of cognitive limits of social size.

The only way to combine the two though is to have senior executives/military officers making broad-sweep policy decisions ("we're going to start trading Convertible Bonds," "we're going to centralize all treasury activities," "we're going to invade Iraq"), but defer all decisions that rely on the individual skills and proclivities of individuals to the level of managers that actually understand the staff that they have. While many financial technology organizations claim to be applying that principle, ask yourself the following questions:

• Are individual line-level technical leads able to chose the major technologies that go into their software, or is there a central group that specifies the technologies that must be used?
• Are individual line-level managers free to determine the set of methodologies that work best for the team, or is there one over-arching set of methodologies that must be followed?
• Are individual teams able to determine their own deployment strategies based on their technology and the needs of the business, or is there a single policy that determines how software is going to be deployed?
• Do individuals have control over their programming environment (including hardware and software choices, and customization of everything they need), or is there a single image and single standard set of hardware that all developers get?
• Can people choose their attire, when there isn't a valid business reason to dress beyond the comfort level, or is there a dress code that must be adhered to?

My Advice To You

If you ever interview with a firm that has a dress code for techies, don't take the job. And more importantly, tell HR that this is part of the reason you're turning down the job. Because if you are able to find a firm that has reasonable pay, and doesn't have a dress code, that tells you a lot about its relationship with its technical staff. The dress code, on the other hand, is a very clear bright-line test to see an organization that undervalues the individualism that makes strong technologists as valuable as they are.

Plus, working in shorts and a T-shirt is pretty darn cool. Particularly when you get off at Bank or Canary Wharf station and everybody else is dressed up and already sweating at 8:30am.

Footnotes:

[1]: Not the best choice around actually. They're good, but Go Gay just a couple blocks up has a better reputation. However, as I don't drive, the extra couple of blocks I'd have to walk loaded down with lots of dry cleaning trumps an arguably better quality of service.
[2]: I can't/don't iron. When I was growing up, having shirts professionally cleaned and pressed cost so little that there wasn't a point in my parents doing it, and thus they never taught me to. And professionals do a much better job than your house cleaner does (if you're one of the people who has your cleaner do your ironing for you), so the cost really isn't much of an issue.
[3]: Seriously, whoever came up with that whole "dress your best for an interview" advice never had to nip out "for a Doctor's appointment" to interview. I mean, if you're actually gainfully employed, and you don't dress up in your current gig, dressing up is a dead giveaway you're interviewing. So if you do show up extremely well dressed for something that isn't a whole-day interview, it basically says "I'm unemployed."
[4]: I mean, while we're at it, you know who else wears uniforms? Ninjas. And while it's completely Awesome to imagine that we're all ninjas, we're not. If we were, we'd be too busy fighting pirates to get any software written.
[5]: Yep, that means that if you wanted to talk to the people using the software you built, you actually had to go to a whole different building a 5-10 minute walk away. Not that I ever did, mind you.

Hardcore Once More

I've mentioned a few times that I've been working on Something Big, and it's time for me to expose myself a little more publicly. It has bearing on the types of things I'll be writing about, so I think it's time to fill in the loyal Kirk's Rants readership.

As most of you know by now, I moved to the UK five and a half years ago after starting my career in Silicon Valley working for pure-technology startups, specializing in the database and web application infrastructure space. When I moved here, I looked at quite a few early-stage technology startups, but ultimately decided to sell out and work in the financial services area. I did this for a few reasons: London at the time wasn't particularly conducive to working in a pure technology startup; financial services were where the Cash Money was at; and I wanted a chance to build a Next Stage for my career. At the time, I felt that working in financial services, given the concentration of financial technology jobs in London, was the right next step for my career.

Over the last few years, I've run the gamut of financial services firms: I started out in charge of the risk management and analytics software for a hedge fund management group; I was in charge of Front Office Technology architecture for a medium-sized derivatives trading group; I worked as a grunt contractor for a Very Big American Bank.

Am I glad I've done it? Most certainly. I've worked with a great group of people, made great friends, and learned a massive amount about how the financial industry actually works. I think it was the right choice for me five and a half years ago. But it's not the right choice for me now.

Since my 6-months at Big Bank B came to an end on Friday, I've taken the Leap of Faith and have co-founded a technology startup. I've joined the circle from Hard Core Startup Geek to Financial Services Sell-Out back to Hard Core Startup Geek.

I can't say precisely what we're doing at this stage, except to say that along the way I've seen a lot of inefficiencies in the way that financial services firms develop software, and I think that we as an industry can do better. I think that financial services are too important to the global economy, and software engineering is too important to modern financial services, to accept the status quo: not only can we do better, but we must do better. Most importantly, I believe that what we as a startup are doing will help.

I'm joined by two exceptional co-founders, and have a network of other technology startups in London that didn't exist a few years ago. As I've written before, London is now a phenomenal location for a technology startup, and what we're doing we couldn't do anywhere else in the world. If you've been on the fence, take the plunge. London is now a fantastic place to do a startup, and this is a fantastic time to do it.

In short, watch this space.

P.S. Maybe I was too entrepreneurial after all.

Big Banks: Embrace Entrepreneurial Techies

After I had been made redundant by Investment Bank A, and before starting at Big Bank B, I interviewed with a Large Teutonic Bank's capital markets division, for a permanent role in London. This was to be a tech lead and architect on a massive greenfield project, where a key part of the role was to bring in "fresh blood" who had worked with some new technologies that the development manager was considering. It required spending quite a bit of time investigating technologies for potential inclusion, doing trial and error, and general research time as the project developed due to the issues of scale involved. Because it involved a lot of real-time updates, massive database work, and distributed systems development, the hiring manager though I'd be an excellent candidate. So did all the other senior architects in the group.

I was turned down for the job by the boss' boss. The reason? "He's too entrepreneurial."

I was recently chatting with another London Techie who was interviewing for a permanent role with a Large Yanqui Bank, and he had a similar experience. The hiring manager liked him and his experience, he got through the gauntlet of developers on the ground who would work with him on a daily basis, and he had to go through the "formality" of the HR interview before they could extend him an offer.

He was turned down for the job by HR. The reason? "He's too independent."

Once is coincidence, twice is a trend.

Entrepreneurial Is An Insult?

So let's consider the two of us. We're both active in the technology community outside of work hours: we blog, we go to meetups, we speak at conferences, we work on open source technologies. We've both established that we're able to apply ourselves at a strong level technically, and are able to pick up new technologies on a regular basis, both in and out of work.

You might think that these would be useful traits. You might think that these are in no small part why the hiring managers wanted to hire us in the first place. You'd be right: they realized that they needed outside skills, and some of them cutting-edge skills that are difficult to get inside the sclerotic community of financial services technology, and that they needed to pull in people who Think For Themselves. But The Organization stopped them.

Apparently both Senior Manager and HR Drone viewed us as unacceptable risks (in fact, it was spelled out precisely why I was a risk: in 5 years, I might not want to be in the same role on the same project). We would think for ourselves, we would seek out new challenges, we would rock the boat.

The fact that these tendencies lead inexorably to us having the skills necessary to perform the jobs has never apparently crossed their minds. They somehow think they can find non-independent, non-entrepreneurial technologists who are familiar with cutting-edge technologies and are able to do proper trial-and-error with design, architecture, and vendor selection. Really? How's that working out for you?

If you're worried that these candidates might eventually want to, gasp, leave the firm, on their own terms (e.g. before you make them redundant), isn't that the price you pay for having a pool of talent you can draw from to get "fresh blood"? If everybody in the world works for the first firm that hires them for the rest of their lives, how would you be able to hire people?

If you're worried, ultimately, that these candidates might lead to uncomfortable situations as they challenge the status quo, are you not implicitly recognizing that your status quo is broken? And that, more importantly, that you want it to stay broken?

Embrace The Uncomfortable

I have a friend who has the theory that the wages techies earn working for Big Banks is compensation for the work and culture they have to endure. I'm not sure I disagree. But you can still find a way in a stultified culture working with boring projects to embrace technically skilled, entrepreneurial techies.

Entrepreneurial techies like facing new challenges, and continually want to apply their skills to making things better. Surely a Large Teutonic/Yanqui Bank has a lot of challenges? And surely hiring someone because they have the skills to design and build a greenfield project implies that they have skills that probably wouldn't be applicable 5 years down the road as the project is in maintenance mode? Why not allow the employee to continually find challenges internally?

Because speaking for myself, I find working on new challenges inside an organization superior to having to find them outside the organization. Your institutional knowledge, built up over extended work periods, is valuable to both sides; your reputation makes it easier to Get Things Done; your domain skills are continually built up. This makes it easier to apply your skills inside the same organization than constantly switching organizations. Why not encourage that by allowing the techie, every couple of years, to switch to a new challenge where their skills and attitude will make a bigger difference?

Independent-thinking techies of all stripes can also be used to help fix the broken parts of that same culture. With enlightened management, someone pointing out that "although this is the way you've always done it, it doesn't have to be like this" can be exactly the type of kick that an organization needs to actually realize that it's fallen into a process/culture-trap, where the wrong bits of the organization are self-perpetuating rather than the good bits. Questioning what's going on, thinking independently, that's the only way that you can ever break out of the bounds of group-think.

Independent, entrepreneurial techies can actually make the biggest impact in the organizations that fight against them the most: they're the ones that need them the most. Use them as agents for change, challenging assumptions, challenging entrenched attitudes, challenging technical group-think. Otherwise, your worst employees (the ones who can't really get a better job elsewhere) win, and you as an organization fail.

Epilogue: Teutonic Bank Is Still Hiring

When the recruiter told me why they had gone dark and ultimately rejected me, I knew that they would never find a candidate that would satisfy both the hiring manager and his boss; they had completely mutually exclusive requirements for this hire. I told said recruiter "in 3 months when they realize they haven't been able to fill the role and come back asking if I'm available, whether I have a job or not, I'm not available."

It actually took 4 months for that call. I wasn't available.

You can has tweets

Now that my tenure at Big Bank B is drawing to a close (more of which anon when I actually have interesting technical bits to discuss), I've joined up with the global hivemind of 160-character inanity that is Twitter.

Although there have been completely unfounded rumors that I've been on Twitter for quite some time, allow me to reassure my devoted audience that these are completely incorrect. Nothing to see there, move along now...

You can find me tweeting as @kirkwy. (why such a strange handle? because every single other short permutation of my name was taken, and a short name gives massive advantage in tweet-for-retweet optimization). And if anybody knows Monty's handle, send it over so that I can stalk him in Twitter as well as the rest of the internet.

Best Multi-OS AuthN Solution?

Dear Lazyweb,

I'm going to be building a heterogenous network consisting of Linux workstations and servers, Mac workstations and laptops, Windows desktops and laptops (maybe the odd server here or there), and maybe a few fringe operating systems. It's completely Legacy Free: nothing there at all. My goals are to make sure that all my various CIFS/NFS/AFS shares are sharing credentials just fine, and that users don't have to maintain multiple passwords.

What's the current vogue for this? Ideally I'd be running something on !Windows, but if I need to stick a Windows Server somewhere I'll do it. I'd rather not, but I will. If not ActiveDirectory, do I roll with LDAP? Which implementation? On which OS? Do I go with kerberos, or the LDAP/NIS for *nix logins? Remote/semi-connected users?

I can't believe I have to ask, but working for Big Companies has addled my Systems Administration skills slightly.

Thanks in advance,
Kirk

P.S. I tried to ask this in ServerFault and before I could add content it warned me that the question was subjective and likely to be closed. So I didn't bother.