The generalised answer, I would think, is "be visible or at least present in the online community that exists around your chosen technologies".
(I didn't post the parent reply, but I did upvote it!)
But if you hit a bug in the kernel, you are probably going to communicate with others (probably on a mailing list) in the process of fixing that bug. Same goes for hitting bugs in any other open-source part of UNIX.
I mean, sure, if you are writing an application, this only applies on the shared library bits. But I was specifically talking about advanced *NIX people... people who would be expected to deal with bugs in open-source products.
Actually, I'm sure you'll notice that I'm more active here than on any of those lists... this is probably a bad thing for my technical career development. (perhaps a good thing for my career development as a business person, though.)
Edit: just to be clear, I'm not saying you should ask an applicant what lists s/he is active on... by itself that won't give you that much information (well, except maybe that if a SysAdmin is not on a bunch of security announce lists, something is very wrong but expecting them to remember this data without going through their mailbox is pretty unreasonable.) you should figure that out. maybe ask them what usernames they use on technical forms that they'd like to share? (note, as an employer, you have to be careful not to be creepy when you do this. Most of us have a 'professional identity' we don't mind sharing... but you don't want to look like the kind of employer who goes through employee's myspace profiles looking for drunken party pictures.)
But all these mailing lists, they take serious time . For me, they're really the first thing to go.
Lists I can ignore (e.g. everything but the security -announce lists) go in their own folders to be ignored, most of the time. but they are a good substitute for HN, if you want a more technically oriented and less business oriented discussion, and they are essential if you really want to figure out a tough bug or add a new feature, so having a presence on the mailing lists (even if you don't read them every day) is really useful.
People who are published usually are a higher pay grade than I'm allowed to hire for, so I don't worry about it too much, but choosing people who are published, I think, would actually be a very similar metric (though, much more expensive) to looking at people's patches.
If they really don't post, then what do they do when they find bugs? fix it and keep it to themselves?
They work around it, or more often they realize that somebody else has found the same bug and just track that. Or they'll feel generous and submit a fix via some bug tracking system other than a mailing list.
If you're using that as a proxy for unix-fu, you should know that it's a REALLY shitty proxy in my (roughly 20 years) of experience.
Although, if your opinion is correct, it doesn't mean anything that I can't look you up online.
Speaking from my lesser experiences, the best professional *nix programmers I have worked with left some traces of themselves online, but I don't think it correlated that closely with their skills. They definitely don't have web sites proclaiming their Ultimate Hacker Ability - why would they need such a thing?
That's on purpose. I establish new HN accounts from time to time because I despise the fact that many people will upvote old users more readily, or will cite 'user for a long/short time' as though it means something.
but yeah, I do think there is something a little fishy about a SysAdmin who doesn't have any public evidence of collaboration. I mean, sure, they could be really good and just have worked places that don't let you give your changes back, but eh, you can say that about any other metric. You must have added a feature to something at some point. You must have been the first user to find a particular bug at some point.
The biggest problem with this metric is that search kind of sucks for mailing lists. I mean, usenet used to be /the place/ for this sort of thing, but usenet is dead, and as far as I can tell, much of the usenet archives that at one point I could access via dejanews are gone (groups.google does not have some of the posts that I know are there.)
1) One individual has final responsibility for our platform. We run a modified version of FreeBSD, which includes both changes that are only appropriate for our own use, and some changes that are more generally applicable.
The other devs and admins submit any patches they need on all the servers to the individual, and he deals with them. Sometimes they stay private, sometimes they go public, but when they go public they go out in his name. He has responsibility of tracking when they're accepted upstream, and when they're included in the base distro.
2) The vast majority of our platform is very, very tried and true. We use a few cutting edge bits of software (new versions and new features), but that's the exception. As such, most of our bugs are found well in advance.
3) The most troublesome bits of our platform are commercial or completely proprietary, so support on those parts doesn't hit a public mailing list anywhere.
I was trying to understand why your response annoyed me so much, and I realized it's because if I had to lay off my best unix guys, you advocate that employers google their name, see nothing on the mailing lists, and pass on them. That annoys me.
I take a lot of pride in being a good employer, and meanwhile you're standing there advocating anally-extracted screening criteria that would hurt my guys.