If you read the grandparent post, you'd realize that Open Source folks do not necessarily work "for free". I've been doing Free Software in one form or another for years -- and getting paid for it (almost) all the while.
Have you considered that writing an open source JSP container may actually result in more people being hired than would be the case if that JSP container didn't exist? After all, the companies that use it heavily need to have someone on staff who knows the thing to maintain and support it -- and they've got money left in their budget over that they wouldn't have if they'd sent it off to some big software house writes commercial JSP containers (and has a big sales/marketing infrastructure, and owners who want dividends, and lots of other overhead that would otherwise be avoided). Alternately, if they don't want to have someone on staff, they can buy support -- and that results in more folks having jobs, too.
Well, my real break was getting a position at MontaVista, and that was really more a who-you-know bit than anything else (one of my schoolmates was Employee #7 or so when they were first getting started). For the rest of it... I met my contact at the school district at a LUG installfest where I was helping out (incidentally, he also happened to own a small chain of beauty salons, and I got a bit of extra work from them). The car dealership position I also got through a schoolmate (who had accepted the contract but found his skills inadequate to finish it on time without help; after that contract was completed, they decided they wanted to keep me on for other things).
My current job is really the only one I can think of offhand where I didn't have some kind of reputation or other prior relationship helping out (as I'd moved halfway across the country, and MontaVista's suits had and have an annoying policy of not giving out references for their ex-employees). In this case it was just my resume, a good interview and willingness to work for cheap that hooked 'em. (The CEO told me that the engineering staff had reccomended me out of the interview pool, despite not having finished my degree and being up against folks with PHDs; in my estimation, the reason I got that thumbs-up was the range of areas I was competant in -- or at least competant enough to discuss them clearly in the interview. They also badly needed a new sysadmin at the time, and my ability to fill in that role as well as the application development position I'd originally applied for weighed in heavily as well).
Incidentally, btw, I just got an offer of a rather interesting part-time contract position within the last few days... and received it largely as a matter of knowing the right people (as well as, of course, having the requisite skills). One part of the contract involves a set of proprietary legacy software; modernizing it (and adding the requested features and platform support) will involve first porting it to work on a Free compiler and operating system. In the process, this porting implies the use of a few BSD-licensed libraries to replace platform-dependent functionality -- and while the BSD license doesn't *require* contributing back any changes, it's probably something I'll end up doing to avoid the expense of reimplementing my changes should it ever be decided to use a newer version of the libraries in question. (Incidentally, the eventual target platform is non-Free... but the easiest way to get there from here is to move to complete platform independance first, and the platform with the best development toolset right now is Free).
So, Duff's tips for finding interesting work:
Know a bit of everything. It's much more valuable to know enough to be a decent sysadmin and a decent embedded systems programmer and a decent app developer and have a really wide variety of programming languages that you're at least halfway handy with than to have absolute mastery of just one or two or subfields. (Not that specialists aren't valuable -- my workplace has a number of them, a few of whom are downright essential -- but we're far harder up for good generalists, as those we have are overworked and we can't afford to hire a specialist to cover everything we touch). Even if you're a specialist, try to branch out a bit -- a DBA who has basic system administration skills is handy in a far wider set of situations than someone who *only* knows how to care and feed for their one app.
Making a habit of learning a new technology every few months also makes it easier to pick up something new you need for work -- if you're always learning new languages then figuring out that proprietary 4GL that a potential employer has 80Klocs of code in will be a lot less painful. It also helps prevent tunnel vision -- someone who also knows C and C++ and Lisp and Scheme and shell and Python is less likely to choose Java as the right tool for a project where it isn't. (Of course, being able to choose Java, or whatever else, as the right
WTF? I've been hired by a company to circumvent an anti-piracy measure on a piece of accounting software they purchased legally but could no longer access because the dongle broke (and the company that made it the software was out of business, so they couldn't get a new one). This was before the DMCA, so it was entirely legal.
The paradigm where things start and end free just means developers never get paid.
My last job paid for writing and supporting Free Software because that's what the company did (and does -- they're still around, and I understand in better financial shape now than when I left). My current job is at a company that writes proprietary software -- but we use Free Software to do it, so when we need a bugfix or an extension, my present employer, a proprietary software company, still pays me to work on Free Software.
My employer before the last two was a car dealership; they hired me as a contractor to move their base platform to Free Software. Before that I spent some time helping a school district set up some servers running on (you guessed it) Free Software. Same kind of business: They hit a bug or need a feature, I'm the guy to write it. (Not that either of those two *did* hit bugs or missing features, but the capability was one of the things they got when they hired me).
This myth that folks never get paid for working on Free Software is just that -- a myth -- and needs to die.
So install RH9 on the other machines and replace key RPMs with RHEL's.
At least on RHEL 2.1 (which is what we've got currently), the differences are *far* to great to do that, particularly if one expects to have a stable system afterwards.
As for RHEL 3, I don't believe the version of Oracle we run is certified for it, and getting Oracle support for the OS is the whole bloody point of this exercise anyhow.
(How can we afford Oracle if we need to quibble about the OS pricing? Discounts... veeeery big discounts, which will no doubt disappear as soon as we're suitably locked into it as a platform and have enough money in the bank to pay full price... damn suits).
So in other words if I never buy a copy of RH but procure it in some other way then I am not bound by the terms of the support contract since I never agreed to it?
Yup, that's about the size of it.
The issue is that if you *do* buy a copy, unless you let all your subscriptions lapse (ie. never buy another one for a 1-year period), you're obligated to buy a support contract for any additional copies, no matter how they're procured. We made that mistake (of buying the first copy, because we needed it *right now*!), and in doing so we (well, one of the suits) agreed to the support contract, so now we're stuck with it.
As for professionals in the computer industry: there is one skill that all system admins must have. That is the ability to search. In your example, the higher abstractions "break". If they broke for them, it would have broke for others too. As a sysad, you must either "reinvent the wheel" by taking waay too much time coding, or searching for 30 minutes to find and implement others solutions on the problem. Fixing and submitting is a last resort.
Yes, if I were looking for a sysadmin, I'd take off the kernel requirements and most of the C. This is a "senior Linux expert", though: "Linux expert", not "Linux sysadmin" or even "expert Linux sysadmin".
A linux sysadmin can get away with knowing how to... well... administrate systems. A linux expert, OTOH, should be a generalist -- and that means, among other things, development and debugging skills.
Such people aren't impossible to find: The current senior sysadmin where I work has roughly the skillset I described, plus almost all of what you mentioned, plus a bunch of additional skills on the side (his personal projects have ranged from building some rather fancy revision control system tools to semi-maintainership of a microkernel OS targeting embedded work; his previous job experience includes everything from Java development to database administration to building and writing software for compute clusters).
Perhaps I've gotten spoiled by working with such people (MontaVista Software, my previous employer, had a number of them) -- but I'm now hesitant to call anyone with a substantially lesser range of skills a true "Linux expert". (I suspect part of their ability to attrack such people may have been related to being a shop whose core business was improving Linux and related Free Software -- at least a few of my coworkers said outright their primary motivation in choosing MontaVista as an employer was not at all the pay).
And finally... well, sometimes there just aren't others' solutions to implement. Having someone who can do the fix-and-submit routine in those cases is part of what one hires experts for.
(As for the scheduler, btw, I'd gladly accept an approximation: Someone who says "no, I'm not familiar with that, *but*..." and can go on to describe a sane scheduling algorithm and what kinds of problems it's prone to passes that question with flying colors, even if they don't happen to know what Linux is doing this week).
Personally, I'd think that any two MTAs are enough -- I wouldn't require 4. And NIS? Gads, no -- that's what Kerberos and LDAP are for, damnit!:)
Webmin I'd call strictly optional, bash (and POSIX sh) I'd assumed as don't-get-in-the-door-without items... OTOH, you point out some very good spots I missed (security tools, cluster management, content management tools, DNS and the like).
As for the 6 figures... maybe in some places, but I'm located in Austin, which has both a much, much lower cost-of-living and a much lower expected salary than a great many other geek meccas. (The "much lower expected salary" is especially so post-bust; Austin's been taking longer to recover than a lot of other areas, and is pretty much just pulling out now).
As for the never-use-this bits... the point of checking for a substantial part of that stuff was not because the specific knowledge will come in handy, but because people who have that knowledge will be the same kinds of folks who are completely unfazed when the higher-level abstractions they depend upon break. (And that said, one never knows when things'll be useful -- I briefly found my embedded-systems background to come in handy at the medical software house where I work when one of our potential suppliers was being a little too slow with bug fixes to the wireless client hardware samples they'd loaned us).
Do you mean a "novel" environment or a "Novell" environment? They're quite different things.:)
Seriously, though: Folks with serious low-level skills are the folks who have the background to fix high-level problems when the abstractions start to leak. Folks who only understand the high-level abstractions are fine as far as they go -- but when they experience problems in the deepest layer of the software they're familiar with, they just don't have the toolset to go deeper.
Contrieved example: I'm a Python coder. I'm using C module $FOO. I'm pretty damned good with Python, and I'm getting code out at a terrific pace until I hit a point in my code where the Python interpreter segfaults. Now, all of a sudden, unless I know C, I'm out of my depth. But then, let's say I *do* know C. Great, I debug the module (and let's say it's interacting with the framebuffer), and it turns out that the segfault is because the some ioctl is returning a structure with a clearly invalid value in it. Now, all of a sudden, unless I know kernel development, I'm out of my depth. But then, let's say I *do* know kernel development. Great, I debug the driver, and either I can fix it there or it's a *really* hard problem.:)
My point here is that having the higher-level knowledge (knowing Python, in my little example) is good enough 95% of the time -- but that other 5%, you *REALLY* want a guru around to fix it. Now, if I'm calling someone a specialist and giving them some certification, they'd damn well better be an *expert*, capable of debugging problems not where they first expose themselves but also a few levels down through the stack.
how well can you answer these on the spur of a moment?
If I were on the receiving end of that interview, I might flub some of the harder linker questions (my memory of the environment variables it uses only go as far as LD_LIBRARY_PATH and LD_PRELOAD, and I'm not entirely certain I recall the list of hardcoded search paths not needed in/etc/ld.so.conf -- or a whole lot on ELF format in general wrt regard to relocation and such), and I'd also be a little sketchy on the scheduling algorithm -- but that said, I'm pretty sure I'd come out all right.
Most of the really, really good Linux folks I've dealt with have been people involved with embedded systems or OS-level programming as well as a reasonable level of sysadmin-style and coding skills.
If I were grilling someone for a "senior Linux expert" position, my interview would probably include the following:
- Describe the scheduling algorithm the Linux kernel presently uses. - Describe the differences between NFS, CIFS, AFS, Coda, Intermezzo -- and how you'd pick the appropriate one for a given environment. - Answer a pop quiz about the kernel itself (How is the input core designed? Which filesystems have no limit on the number of inodes? How does the preemptive scheduling algorithm work? Under what circumstances is it undesirable? What's the first thing you do if you get an OOPS?) - Be familiar with the system's boot process and how to resolve problems relating to it. (What search order does the kernel use when searching for an "init" process?) - Be able to build an initrd to preload I/O drivers (ie. for booting off a firewire drive) - Have a solid understanding of the linker, the environment variables and search paths it uses, etc. - Be able to track down simple bugs in kernel drivers (implications: the candidate must be fluent in C, have some familiarity with the kernel's source base, and know how to use tools such as ksymoops and possibly one of the available kernel debuggers)
Of course I'd also be looking for fluency in at least a few scripting languages (and LDAP queries), an understanding of the tools and libraries underlying GNOME (which we use here) [so I'd want someone understanding GConf, Bonobo, and the like], and so forth. Personally, I'd probably include a series of questions about revision control tools as well, and I'd look for at least a passing fluency with SQL (as a great many popular services backend into SQL databases, it's become rather necessary as a sysadmin skill as well as something important to developers and DB specialists).
Now, are all these skills going to be needed on a regular basis in someone who's just (say) in a sysadmin role? Of course not. On the other hand, the advantage of having someone who understands how things work under the hood is that when they *do* get something really weird jumping out at them, they'll be able to understand what the problem is and *get it fixed*.
Personally, though, I'm not sure what value I see in the whole certification thing. Someone with the kind of skill range I mentioned above typically won't *need* a piece of paper to demonstrate what they know -- it'll be visible in the code they release, in their posts to public mailing lists (Google is your friend!), and in their survival of an actual, proper, face-to-face grilling.
Even if it's fines as opposed to prison, I don't see the reason for processing such things criminally as opposed to via a civil suit. Giving folks a criminal record for what is traditionally -- and makes sense as -- a civil infraction just Doesn't Make Sense from where I stand.
Kernels and drivers are hardly areas where I have much knowledge, but as far as I could understand, the reputedly poor networking performance in BeOS before b.o.n.e. was introduced was due to user space network drivers, which might make this a less good idea?
Depends on what you're doing.
Let's say your networking code is implemented as a user-space, in-process library. Suddenly, because there's no kernel component at all, there's no context switch needed for networking -- so it gets faster than it'd be otherwise.
On the other hand, let's say your apps call through to your kernel which then in turn calls through to userspace again... that's slower than a kernelspace implementation.
Another situation (and a more likely one) is a case where you've got an application which manages your networking device (and has direct access to the hardware to do so), and other applications do message-passing to talk with it. As long as your message-passing is fast, this can be a very speedy solution... then, that's true for quite a bit about a microkernel OS; very very low-cost message passing is one of those things a microkernel *has* to get right if it's to have reasonable performance.
Also, how would wrapping drivers affect networking performance? You would think adding a layer would slow stuff down a bit. Sure, a slow but working network card is better than a non functional, but not by far.
Depends on how thick the wrapper has to be, of course. If it's in the tens of instructions per interrupt (which it *could* be), then it wouldn't be all that bad at all.
yah, but finding people who know how to fix uncommon issues is a different thing.
Hire a good senior Unix sysadmin, and more than half the time you'll have someone who's also part systems-level programmer, part integration engineer, part deployment engineer, part revision control specialist, part... well, you get the idea. At my workplace the senior sysad is writing some in-house web-based user management software for HR, setting up several other departments with Plone-based intranet portals, and finishing the spit-and-polish on the automatic installation procedure he set up (grab a new machine, throw a CD in the drive and an ethernet connection in the back, turn it on, walk away for 20 minutes, and it's installed with all the software we use and configured for our network). He's showed up our Oracle DBA with regards to deep understanding why raw partitions are a useful feature (this included an in-depth discussion of the kernel's I/O elevator algorithm), personally wrote the drivers for the CD jukebox that was offered us for backup storage, is working on an embedded operating system in his spare time, and is otherwise a flat-out badass.
I'm currently the primary deployment engineer; I also sometimes serve as junior sysad (and was primary sysad before this guy was hired). A few days ago I wrote some in-house crypto-enabled backup software such that the business-type responsible for transporting materials to our off-site vault could burn their own CDs with our revision-control repository -- encrypted such that even should the CD (or the ISO it's burned from) be captured, there's no actual risk of data theft. Right now I'm at work (on a weekend) rewriting some integration code one of the application developers generated. I wrote the applet we use in-house for displaying the amount of time on a user's Kerberos ticket; In my spare time I also maintain some Free Software (which aforementioned lead sysadmin originally wrote) for converting CVS repositories to Arch format.
I've dealt with senior Windows sysad types on occasion -- and while they may be cheap, most of them don't have half the range of skills a good UNIX admin has. Hell, not even close to half.
I'll take good support at $.25 a dozen over someone who knows how to say "okay, reboot your machine... okay, we'll need to reinstall the OS" for $.10. (Further, given present economic conditions, Unix folks are much cheaper than was the case a few years ago -- indeed, if yer willing to deal with the new kids who just do Linux, I'd expect them to start getting cheaper than MCSEs real soon now... though you might not get quite the same range of skills and experience as the old UNIX longhairs in that case).
It's *very* interesting in the case of Broadcom's programmable wireless chipsets -- Broadcom has been pressured by the gubmint to avoid giving out programming specs as their networking cards are in fact fully programmable software radios (and could be used to break all kinds of FCC regulations); for that reason, the likelihood of open source drivers being forthcoming is quite low.
Even if your system is a headless server? Not everyone is dependent on having a running GUI.
Also, remember: On Linux your "video driver" is running inside a separate program (the X server); forcefully restarting that program will very, very frequently fix involved problems.
This is part of why I think it would be interesting to port DriverLoader's technology to a microkernel OS (such that they can be Just Another Process, like any other, instead of running the ported driver in kernel space).
BTW, if looking for a modern, efficient, fast, non-bloated open source microkernel OS [read: not the HURD], consider VSTa.
I have been at this for 30 years. I have never seen a case where emulation does not entail a performance hit. If you can show me a case I would be really interested.
Providing a compatible interface isn't necessarily "emulation".
Consider WINE: Its implimentation of some parts of the win32 API is faster than the Microsoft implementation of those same functions; for that reason, apps running against WINE are sometimes faster than their native equivalents.
It's been a few years since I've written anything in Solaris... but the primary thing I recall was that their ferror() call's actual behaviour *didn't match the man page*. Supposedly ferror returns 0 on success... right? Solaris's was returning -1. If you're going to behave differently than everyone else, fine... but at least get it right in the man page!
Linux distributions come with a better set of scripting languages (and extensions for the same), generally have a better set of packaged IDEs, and are all-round much easier to do development work with. Most of those who say different are likely just running off nostalgia.
If I want a big-budget, rock-solid enterprise database server, then no, Linux isn't what I'll use. For a development workstation, OTOH, it's perhaps right now the best platform available.
Now, on some levels this could be great (i.e. weeding out inferior gene stock etc..) however we would be drastically reducing our labor market.. So, who is going to empty your trashcan and "biggie-size" that for you?
Eh? This insinuation that people on the lower end of the labor market tend to be more prone to genetic issues is... well... silly. Anyhow, any event which resulted in a substantial population decrease (and I'm *not* accepting that this is in fact the case) wouldn't necessarily result in a misbalanced society: Folks with good genes can empty trashcans and "biggie-size" burgers as well as anyone else.
In any event, I know of fairly few people who've been at high risk of premature death due to genetic issues -- and if there were a demand for it, don't you expect that insurance companies would offer a coverage option which covers *non*-genetic-related health issues? I wouldn't expect anything nearly as drastic as your comment indicates to result from health insurance being substantially more expensive to those who pose a higher risk of genetic health issues.
But, every time/. posts something about patents, it serves its purpose by prompting a few hundred posts from the braindead among us who decide that the concept of patents is evil just because the open source demigods tell them to hate software patents.
Damn, but that's a gross -- and offensive -- overgeneralization. Could you consider that, perhaps, some subset (perhaps even a *large* subset) among us dislike software patents on their own merits?
Which is to say: If I understand an argument well enough to articulate it fluently in my own words, and actively defend it against someone who disagrees -- without strictly parroting the words of another -- am I still a member of the "braindead" set who holds the argument because someone else tells them to? To me, the contrary seems obvious.
With regard to software patents in particular, I'm concerned about them not strictly as an open source developer but also as an employee-shareholder of a startup getting ready to release our first product. While our product is indeed innovative and probably patent-worthy in a few respects, our interests are better served by focus on getting the product out the door with as much polish as possible. Given the number of man-years that have gone into building the thing, and the specialized expertise that has accrued in the process, we already have a natural advantage over any competitors in the field -- even one with far greater financial resources. I'm far, far more concerned about some opponent who comes up with a patent on some obvious technology our core product infringes than I am about one who decides they're going to "steal our idea"; as promulgated in A Good Hard Kick in the Ass, good ideas are a dime a dozen; making a profitable business is the hard part.
The problem is almost akin to copyright violation. Our CEO is quite severely concerned about the data our application runs on -- itself the product of multiple man-years by domain specialists -- being stolen by a third party who then starts a competing business. I'm less concerned: Someone who suddenly possesses the data -- or even the code -- without the knowledge used to create it, update it or fix the bugs would be at a tremendous disadvantage compared to the original team who understands both application and data intimately.
My point here is thus: Having a set of bytes or having a Good Idea is not enough to make money; one needs the infrastructure -- the people, the contacts, the skills -- to run a business. Focusing on the "intellectual property" is thus really a red herring with regard to where a company's value is -- even a company whose sole product is built around that "intellectual property".
I've had them outright fail on multiple occasions, and the programming interface for dealing with USB input devices is much much more fun (okay, once the full input core, rather than the subset that got merged in 2.4, is in the kernel, this is less of an issue). USB keyboards can have extra goodies onboard (ranging from USB hubs to all the niftiness that is a Touchstream keyboard),.. and USB mice have a higher poll rate than their PS/2 equivalents, so cursor movements are less choppy (well, as long as the rest of the system keeps up).
But then, I've got more than 2 USB ports, so saving them for other things is less of an issue.
Slashdot Mirror
If you read the grandparent post, you'd realize that Open Source folks do not necessarily work "for free". I've been doing Free Software in one form or another for years -- and getting paid for it (almost) all the while.
Have you considered that writing an open source JSP container may actually result in more people being hired than would be the case if that JSP container didn't exist? After all, the companies that use it heavily need to have someone on staff who knows the thing to maintain and support it -- and they've got money left in their budget over that they wouldn't have if they'd sent it off to some big software house writes commercial JSP containers (and has a big sales/marketing infrastructure, and owners who want dividends, and lots of other overhead that would otherwise be avoided). Alternately, if they don't want to have someone on staff, they can buy support -- and that results in more folks having jobs, too.
But then, you're a troll and I'm biting. *sigh*.
My current job is really the only one I can think of offhand where I didn't have some kind of reputation or other prior relationship helping out (as I'd moved halfway across the country, and MontaVista's suits had and have an annoying policy of not giving out references for their ex-employees). In this case it was just my resume, a good interview and willingness to work for cheap that hooked 'em. (The CEO told me that the engineering staff had reccomended me out of the interview pool, despite not having finished my degree and being up against folks with PHDs; in my estimation, the reason I got that thumbs-up was the range of areas I was competant in -- or at least competant enough to discuss them clearly in the interview. They also badly needed a new sysadmin at the time, and my ability to fill in that role as well as the application development position I'd originally applied for weighed in heavily as well).
Incidentally, btw, I just got an offer of a rather interesting part-time contract position within the last few days... and received it largely as a matter of knowing the right people (as well as, of course, having the requisite skills). One part of the contract involves a set of proprietary legacy software; modernizing it (and adding the requested features and platform support) will involve first porting it to work on a Free compiler and operating system. In the process, this porting implies the use of a few BSD-licensed libraries to replace platform-dependent functionality -- and while the BSD license doesn't *require* contributing back any changes, it's probably something I'll end up doing to avoid the expense of reimplementing my changes should it ever be decided to use a newer version of the libraries in question. (Incidentally, the eventual target platform is non-Free... but the easiest way to get there from here is to move to complete platform independance first, and the platform with the best development toolset right now is Free).
So, Duff's tips for finding interesting work:
Making a habit of learning a new technology every few months also makes it easier to pick up something new you need for work -- if you're always learning new languages then figuring out that proprietary 4GL that a potential employer has 80Klocs of code in will be a lot less painful. It also helps prevent tunnel vision -- someone who also knows C and C++ and Lisp and Scheme and shell and Python is less likely to choose Java as the right tool for a project where it isn't. (Of course, being able to choose Java, or whatever else, as the right
WTF? I've been hired by a company to circumvent an anti-piracy measure on a piece of accounting software they purchased legally but could no longer access because the dongle broke (and the company that made it the software was out of business, so they couldn't get a new one). This was before the DMCA, so it was entirely legal.
Not all cracking is illegal or illegitimate.
The paradigm where things start and end free just means developers never get paid.
My last job paid for writing and supporting Free Software because that's what the company did (and does -- they're still around, and I understand in better financial shape now than when I left). My current job is at a company that writes proprietary software -- but we use Free Software to do it, so when we need a bugfix or an extension, my present employer, a proprietary software company, still pays me to work on Free Software.
My employer before the last two was a car dealership; they hired me as a contractor to move their base platform to Free Software. Before that I spent some time helping a school district set up some servers running on (you guessed it) Free Software. Same kind of business: They hit a bug or need a feature, I'm the guy to write it. (Not that either of those two *did* hit bugs or missing features, but the capability was one of the things they got when they hired me).
This myth that folks never get paid for working on Free Software is just that -- a myth -- and needs to die.
...and the support (from Oracle, not Red Hat) is the thing I care about; otherwise I'd be perfectly happy without having RHEL at all.
*sigh*.
So install RH9 on the other machines and replace key RPMs with RHEL's.
At least on RHEL 2.1 (which is what we've got currently), the differences are *far* to great to do that, particularly if one expects to have a stable system afterwards.
As for RHEL 3, I don't believe the version of Oracle we run is certified for it, and getting Oracle support for the OS is the whole bloody point of this exercise anyhow.
(How can we afford Oracle if we need to quibble about the OS pricing? Discounts... veeeery big discounts, which will no doubt disappear as soon as we're suitably locked into it as a platform and have enough money in the bank to pay full price... damn suits).
So in other words if I never buy a copy of RH but procure it in some other way then I am not bound by the terms of the support contract since I never agreed to it?
Yup, that's about the size of it.
The issue is that if you *do* buy a copy, unless you let all your subscriptions lapse (ie. never buy another one for a 1-year period), you're obligated to buy a support contract for any additional copies, no matter how they're procured. We made that mistake (of buying the first copy, because we needed it *right now*!), and in doing so we (well, one of the suits) agreed to the support contract, so now we're stuck with it.
Heckuvadeal, eh?
Not to worry, it's merely "everything but". :P
As for professionals in the computer industry: there is one skill that all system admins must have. That is the ability to search. In your example, the higher abstractions "break". If they broke for them, it would have broke for others too. As a sysad, you must either "reinvent the wheel" by taking waay too much time coding, or searching for 30 minutes to find and implement others solutions on the problem. Fixing and submitting is a last resort.
Yes, if I were looking for a sysadmin, I'd take off the kernel requirements and most of the C. This is a "senior Linux expert", though: "Linux expert", not "Linux sysadmin" or even "expert Linux sysadmin".
A linux sysadmin can get away with knowing how to... well... administrate systems. A linux expert, OTOH, should be a generalist -- and that means, among other things, development and debugging skills.
Such people aren't impossible to find: The current senior sysadmin where I work has roughly the skillset I described, plus almost all of what you mentioned, plus a bunch of additional skills on the side (his personal projects have ranged from building some rather fancy revision control system tools to semi-maintainership of a microkernel OS targeting embedded work; his previous job experience includes everything from Java development to database administration to building and writing software for compute clusters).
Perhaps I've gotten spoiled by working with such people (MontaVista Software, my previous employer, had a number of them) -- but I'm now hesitant to call anyone with a substantially lesser range of skills a true "Linux expert". (I suspect part of their ability to attrack such people may have been related to being a shop whose core business was improving Linux and related Free Software -- at least a few of my coworkers said outright their primary motivation in choosing MontaVista as an employer was not at all the pay).
And finally... well, sometimes there just aren't others' solutions to implement. Having someone who can do the fix-and-submit routine in those cases is part of what one hires experts for.
(As for the scheduler, btw, I'd gladly accept an approximation: Someone who says "no, I'm not familiar with that, *but*..." and can go on to describe a sane scheduling algorithm and what kinds of problems it's prone to passes that question with flying colors, even if they don't happen to know what Linux is doing this week).
Personally, I'd think that any two MTAs are enough -- I wouldn't require 4. And NIS? Gads, no -- that's what Kerberos and LDAP are for, damnit! :)
Webmin I'd call strictly optional, bash (and POSIX sh) I'd assumed as don't-get-in-the-door-without items... OTOH, you point out some very good spots I missed (security tools, cluster management, content management tools, DNS and the like).
As for the 6 figures... maybe in some places, but I'm located in Austin, which has both a much, much lower cost-of-living and a much lower expected salary than a great many other geek meccas. (The "much lower expected salary" is especially so post-bust; Austin's been taking longer to recover than a lot of other areas, and is pretty much just pulling out now).
As for the never-use-this bits... the point of checking for a substantial part of that stuff was not because the specific knowledge will come in handy, but because people who have that knowledge will be the same kinds of folks who are completely unfazed when the higher-level abstractions they depend upon break. (And that said, one never knows when things'll be useful -- I briefly found my embedded-systems background to come in handy at the medical software house where I work when one of our potential suppliers was being a little too slow with bug fixes to the wireless client hardware samples they'd loaned us).
Heh.
The job position is "senior Linux expert", not "lead sysadmin". Different jobs, different requirements.
Seriously, though: Folks with serious low-level skills are the folks who have the background to fix high-level problems when the abstractions start to leak. Folks who only understand the high-level abstractions are fine as far as they go -- but when they experience problems in the deepest layer of the software they're familiar with, they just don't have the toolset to go deeper.
Contrieved example: I'm a Python coder. I'm using C module $FOO. I'm pretty damned good with Python, and I'm getting code out at a terrific pace until I hit a point in my code where the Python interpreter segfaults. Now, all of a sudden, unless I know C, I'm out of my depth. But then, let's say I *do* know C. Great, I debug the module (and let's say it's interacting with the framebuffer), and it turns out that the segfault is because the some ioctl is returning a structure with a clearly invalid value in it. Now, all of a sudden, unless I know kernel development, I'm out of my depth. But then, let's say I *do* know kernel development. Great, I debug the driver, and either I can fix it there or it's a *really* hard problem.
My point here is that having the higher-level knowledge (knowing Python, in my little example) is good enough 95% of the time -- but that other 5%, you *REALLY* want a guru around to fix it. Now, if I'm calling someone a specialist and giving them some certification, they'd damn well better be an *expert*, capable of debugging problems not where they first expose themselves but also a few levels down through the stack.
how well can you answer these on the spur of a moment?
/etc/ld.so.conf -- or a whole lot on ELF format in general wrt regard to relocation and such), and I'd also be a little sketchy on the scheduling algorithm -- but that said, I'm pretty sure I'd come out all right.
If I were on the receiving end of that interview, I might flub some of the harder linker questions (my memory of the environment variables it uses only go as far as LD_LIBRARY_PATH and LD_PRELOAD, and I'm not entirely certain I recall the list of hardcoded search paths not needed in
If I were grilling someone for a "senior Linux expert" position, my interview would probably include the following:
- Describe the scheduling algorithm the Linux kernel presently uses.
- Describe the differences between NFS, CIFS, AFS, Coda, Intermezzo -- and how you'd pick the appropriate one for a given environment.
- Answer a pop quiz about the kernel itself (How is the input core designed? Which filesystems have no limit on the number of inodes? How does the preemptive scheduling algorithm work? Under what circumstances is it undesirable? What's the first thing you do if you get an OOPS?)
- Be familiar with the system's boot process and how to resolve problems relating to it. (What search order does the kernel use when searching for an "init" process?)
- Be able to build an initrd to preload I/O drivers (ie. for booting off a firewire drive)
- Have a solid understanding of the linker, the environment variables and search paths it uses, etc.
- Be able to track down simple bugs in kernel drivers (implications: the candidate must be fluent in C, have some familiarity with the kernel's source base, and know how to use tools such as ksymoops and possibly one of the available kernel debuggers)
Of course I'd also be looking for fluency in at least a few scripting languages (and LDAP queries), an understanding of the tools and libraries underlying GNOME (which we use here) [so I'd want someone understanding GConf, Bonobo, and the like], and so forth. Personally, I'd probably include a series of questions about revision control tools as well, and I'd look for at least a passing fluency with SQL (as a great many popular services backend into SQL databases, it's become rather necessary as a sysadmin skill as well as something important to developers and DB specialists).
Now, are all these skills going to be needed on a regular basis in someone who's just (say) in a sysadmin role? Of course not. On the other hand, the advantage of having someone who understands how things work under the hood is that when they *do* get something really weird jumping out at them, they'll be able to understand what the problem is and *get it fixed*.
Personally, though, I'm not sure what value I see in the whole certification thing. Someone with the kind of skill range I mentioned above typically won't *need* a piece of paper to demonstrate what they know -- it'll be visible in the code they release, in their posts to public mailing lists (Google is your friend!), and in their survival of an actual, proper, face-to-face grilling.
Even if it's fines as opposed to prison, I don't see the reason for processing such things criminally as opposed to via a civil suit. Giving folks a criminal record for what is traditionally -- and makes sense as -- a civil infraction just Doesn't Make Sense from where I stand.
It seems the issue here is not as much of performance...
Then you're in the wrong thread -- this one is (or was, up to this point) about performance.
Kernels and drivers are hardly areas where I have much knowledge, but as far as I could understand, the reputedly poor networking performance in BeOS before b.o.n.e. was introduced was due to user space network drivers, which might make this a less good idea?
Depends on what you're doing.
Let's say your networking code is implemented as a user-space, in-process library. Suddenly, because there's no kernel component at all, there's no context switch needed for networking -- so it gets faster than it'd be otherwise.
On the other hand, let's say your apps call through to your kernel which then in turn calls through to userspace again... that's slower than a kernelspace implementation.
Another situation (and a more likely one) is a case where you've got an application which manages your networking device (and has direct access to the hardware to do so), and other applications do message-passing to talk with it. As long as your message-passing is fast, this can be a very speedy solution... then, that's true for quite a bit about a microkernel OS; very very low-cost message passing is one of those things a microkernel *has* to get right if it's to have reasonable performance.
Also, how would wrapping drivers affect networking performance? You would think adding a layer would slow stuff down a bit. Sure, a slow but working network card is better than a non functional, but not by far.
Depends on how thick the wrapper has to be, of course. If it's in the tens of instructions per interrupt (which it *could* be), then it wouldn't be all that bad at all.
yah, but finding people who know how to fix uncommon issues is a different thing.
Hire a good senior Unix sysadmin, and more than half the time you'll have someone who's also part systems-level programmer, part integration engineer, part deployment engineer, part revision control specialist, part... well, you get the idea. At my workplace the senior sysad is writing some in-house web-based user management software for HR, setting up several other departments with Plone-based intranet portals, and finishing the spit-and-polish on the automatic installation procedure he set up (grab a new machine, throw a CD in the drive and an ethernet connection in the back, turn it on, walk away for 20 minutes, and it's installed with all the software we use and configured for our network). He's showed up our Oracle DBA with regards to deep understanding why raw partitions are a useful feature (this included an in-depth discussion of the kernel's I/O elevator algorithm), personally wrote the drivers for the CD jukebox that was offered us for backup storage, is working on an embedded operating system in his spare time, and is otherwise a flat-out badass.
I'm currently the primary deployment engineer; I also sometimes serve as junior sysad (and was primary sysad before this guy was hired). A few days ago I wrote some in-house crypto-enabled backup software such that the business-type responsible for transporting materials to our off-site vault could burn their own CDs with our revision-control repository -- encrypted such that even should the CD (or the ISO it's burned from) be captured, there's no actual risk of data theft. Right now I'm at work (on a weekend) rewriting some integration code one of the application developers generated. I wrote the applet we use in-house for displaying the amount of time on a user's Kerberos ticket; In my spare time I also maintain some Free Software (which aforementioned lead sysadmin originally wrote) for converting CVS repositories to Arch format.
I've dealt with senior Windows sysad types on occasion -- and while they may be cheap, most of them don't have half the range of skills a good UNIX admin has. Hell, not even close to half.
I'll take good support at $.25 a dozen over someone who knows how to say "okay, reboot your machine... okay, we'll need to reinstall the OS" for $.10. (Further, given present economic conditions, Unix folks are much cheaper than was the case a few years ago -- indeed, if yer willing to deal with the new kids who just do Linux, I'd expect them to start getting cheaper than MCSEs real soon now... though you might not get quite the same range of skills and experience as the old UNIX longhairs in that case).
It's *very* interesting in the case of Broadcom's programmable wireless chipsets -- Broadcom has been pressured by the gubmint to avoid giving out programming specs as their networking cards are in fact fully programmable software radios (and could be used to break all kinds of FCC regulations); for that reason, the likelihood of open source drivers being forthcoming is quite low.
Even if your system is a headless server? Not everyone is dependent on having a running GUI.
Also, remember: On Linux your "video driver" is running inside a separate program (the X server); forcefully restarting that program will very, very frequently fix involved problems.
This is part of why I think it would be interesting to port DriverLoader's technology to a microkernel OS (such that they can be Just Another Process, like any other, instead of running the ported driver in kernel space).
BTW, if looking for a modern, efficient, fast, non-bloated open source microkernel OS [read: not the HURD], consider VSTa.
I have been at this for 30 years. I have never seen a case where emulation does not entail a performance hit. If you can show me a case I would be really interested.
Providing a compatible interface isn't necessarily "emulation".
Consider WINE: Its implimentation of some parts of the win32 API is faster than the Microsoft implementation of those same functions; for that reason, apps running against WINE are sometimes faster than their native equivalents.
It's been a few years since I've written anything in Solaris... but the primary thing I recall was that their ferror() call's actual behaviour *didn't match the man page*. Supposedly ferror returns 0 on success... right? Solaris's was returning -1. If you're going to behave differently than everyone else, fine... but at least get it right in the man page!
Linux distributions come with a better set of scripting languages (and extensions for the same), generally have a better set of packaged IDEs, and are all-round much easier to do development work with. Most of those who say different are likely just running off nostalgia.
If I want a big-budget, rock-solid enterprise database server, then no, Linux isn't what I'll use. For a development workstation, OTOH, it's perhaps right now the best platform available.
Now, on some levels this could be great (i.e. weeding out inferior gene stock etc..) however we would be drastically reducing our labor market.. So, who is going to empty your trashcan and "biggie-size" that for you?
Eh? This insinuation that people on the lower end of the labor market tend to be more prone to genetic issues is... well... silly. Anyhow, any event which resulted in a substantial population decrease (and I'm *not* accepting that this is in fact the case) wouldn't necessarily result in a misbalanced society: Folks with good genes can empty trashcans and "biggie-size" burgers as well as anyone else.
In any event, I know of fairly few people who've been at high risk of premature death due to genetic issues -- and if there were a demand for it, don't you expect that insurance companies would offer a coverage option which covers *non*-genetic-related health issues? I wouldn't expect anything nearly as drastic as your comment indicates to result from health insurance being substantially more expensive to those who pose a higher risk of genetic health issues.
Damn, but that's a gross -- and offensive -- overgeneralization. Could you consider that, perhaps, some subset (perhaps even a *large* subset) among us dislike software patents on their own merits?
Which is to say: If I understand an argument well enough to articulate it fluently in my own words, and actively defend it against someone who disagrees -- without strictly parroting the words of another -- am I still a member of the "braindead" set who holds the argument because someone else tells them to? To me, the contrary seems obvious.
With regard to software patents in particular, I'm concerned about them not strictly as an open source developer but also as an employee-shareholder of a startup getting ready to release our first product. While our product is indeed innovative and probably patent-worthy in a few respects, our interests are better served by focus on getting the product out the door with as much polish as possible. Given the number of man-years that have gone into building the thing, and the specialized expertise that has accrued in the process, we already have a natural advantage over any competitors in the field -- even one with far greater financial resources. I'm far, far more concerned about some opponent who comes up with a patent on some obvious technology our core product infringes than I am about one who decides they're going to "steal our idea"; as promulgated in A Good Hard Kick in the Ass, good ideas are a dime a dozen; making a profitable business is the hard part.
The problem is almost akin to copyright violation. Our CEO is quite severely concerned about the data our application runs on -- itself the product of multiple man-years by domain specialists -- being stolen by a third party who then starts a competing business. I'm less concerned: Someone who suddenly possesses the data -- or even the code -- without the knowledge used to create it, update it or fix the bugs would be at a tremendous disadvantage compared to the original team who understands both application and data intimately.
My point here is thus: Having a set of bytes or having a Good Idea is not enough to make money; one needs the infrastructure -- the people, the contacts, the skills -- to run a business. Focusing on the "intellectual property" is thus really a red herring with regard to where a company's value is -- even a company whose sole product is built around that "intellectual property".
...except that PS/2 ports *suck*.
I've had them outright fail on multiple occasions, and the programming interface for dealing with USB input devices is much much more fun (okay, once the full input core, rather than the subset that got merged in 2.4, is in the kernel, this is less of an issue). USB keyboards can have extra goodies onboard (ranging from USB hubs to all the niftiness that is a Touchstream keyboard),.. and USB mice have a higher poll rate than their PS/2 equivalents, so cursor movements are less choppy (well, as long as the rest of the system keeps up).
But then, I've got more than 2 USB ports, so saving them for other things is less of an issue.