One of the greatest misconceptions about Linux is that the free availability of its source code ensures that the "many eyes" with access to it will surely find any attempt at sabotage. Yet, despite the "many eyes," new security vulnerabilities are found in Linux every week in addition to dozens of other bugs. Many of these flaws have eluded detection for years. It is ridiculous to claim that the open source process can eradicate all of the cleverly hidden intentional bugs when it can't find thousands of unintentional bugs left lying around in the source code.
These are old FUD arguments. Newsflash: For any non-trivial piece of code, it's impossible to prove that there are no bugs. If you do some bug tests and don't discover any, you haven't proven that the code is bug-free, merely that you haven't come up with a comprehensive enough test. The same problem exists with proprietary code, only it doesn't have the luxury of having widespread peer review of the code, by definition. Security through obscurity sucks.
It's true, just because there are "many eyes" reviewing the code won't make it bulletproof. But it'll make it a helluva lot more bullet-resistant when compared to code which is under the purview of a select few.
But, feel free to don the blindfold of ignorance, and just keep chanting, "my code is bug-free, my code is bug-free." Say it often enough, and you'll actually believe it.;-)
I wouldn't say it's booming, per se, but I'd say things are better here in the USA.
I used to work in Toronto for many years, so I feel your pain. Since making the jump, the first thing I noticed was that my peers were brilliant. Not to say that those in Toronto weren't, but rather more of a difference between "just doing what's necessary" compared to "breaking new ground". When I was working for a Very Large Bank in Toronto, there was an overriding theme of "don't change anything because something might break." Compare that to "let's bite the bullet and change this so we can fix nuisance issues today and plan for tomorrow." In Toronto, I usually found that innovation wasn't actively encouraged, and at times discouraged.
If this is starting to sound interesting, start reading up on what it takes to get your TN visa, here: www.grasmick.com
I'm referring of course to the core theme over at the Infrastructures.org web site.
If anything, the article's emphasis is on desktop support and the end-user experience.
Any seasoned sysadmin will have war stories to share regarding how servers drift out of sync (just the o/s, ignore anything else for now) over time, not just from a baseline, but from other servers which are meant to be identical. Read Steve Traugott's white paper on Turing Equivalence in Automated Systems Administration if you want to get a better feel for the issue.
This one needs to be shared (as told to me many years ago by a former co-worker). This is back in the days of dumb terminals; in the case of this application, the space bar could be used to jump from one field to the next:
Support: Support, can I help you?
Female user: Yes, I'm trying to do data entry, but the first screen doesn't give me a chance to enter the data, and immediately puts me at the second screen.
Support guy tries the application on his own terminal, finds it to be working normally.
Support: Hmm... I don't seem to be able to reproduce the problem. Try it again.
Female user: [pause] Yup, it did it again.
Support: Okay, I'll be down in a few minutes.
The support guy suspects that maybe the space bar is sticking. On arriving, he asked the user to let him sit down and try. He went to the screen in question and had no troubles entering the data. Both agreed it was strange. Support guy returns to his desk. Then his phone rings again.
Female user: It's doing it again!
Support: Hmm. Okay, I'll be right back down.
By now, the support guy is determined to watch what the user is doing. Or not doing. He gets to the user's terminal and asks her to show him what she's doing.
At this point it's worth noting that this user is *very* busty. As she went to do her work, he noticed her, erm, assets were resting on the space bar, causing the cursor to jump from field to field, then eventually to the next screen.
Needless to say, there was an 'Aha!' moment on the part of the support guy. His politically-correct fix? He adjusted the user's seat so she wasn't sitting quite so close to the terminal.
HEC Montréal is Canada's first management school, founded in 1907. More than 11,000 students and 220 professors use HEC's e-mail system every year. Unfortunately, the proprietary e-mail system did not evolve and as the load started to increase, the infrastructure could no longer keep up with requirements.
[snip]
HEC Montréal is a tough e-mail problem: 35,000 users and more than 600,000 spam messages a week.
One company I worked for about 10 years ago, one of the developers posted a question to Usenet, and had his answer in 45 minutes. It was his educated opinion that had he gone to Sun with the same question, first he would have had to deal with the phone drones and their canned list of questions, before eventually getting through to the people who he knew could really answer the question, and guesstimated that resolution path at hours, not minutes. 45 minutes vs. a few hours. You be the judge.
Having said that, I'm all for getting support from closed-source solutions such as the Veritas product line. But trying to compare BIND (open-source, many many years, many platforms, comparatively smaller code base, etc) to, say, Veritas Volume Manager (closed-source, not as many years, not as many platforms) is like comparing apples to pianos: sure, they both come from trees, but that's where the similarity ends.
If the goal of purchasing support is for the placebo effect, then by all means, ante up.
Still not convinced? Then why not a support contract for every daemon that runs on the server (eg, sendmail, ntpd, (x)inetd, NFS, etc)? Every instance of awk, grep, sed, etc? After all, why take a chance that any one of these is anything less than perfect?
Okay, I'll play along and test your silly straw man argument.
Let's shift focus to the vendor (insert name; say Novell) and see which argument is easier to defend:
1) (After escalating past the phone drones): "hmm... my team is working as much as they can on it. It'll be resolved soon, after we RTFM, dredge through the Internet, and otherwise play the role of a savvy sysadmin."
OR
2) "The problem is being dealt with. Our vendor... oh wait, do we have a vendor we can delegate this problem to?"
You see, the buck has to stop somewhere. Granted, if all the company has is a trained monkey for a sysadmin, then buying support and passing the buck makes perfect sense.
But if the company is already paying serious scratch for a (team of) seasoned sysadmins, then why fork over even more cash?
I've had the pleasure of working with experienced sysadmins who know the drill and can resolve problems more quickly than the vendor. I myself have figured things out where the vendor was flailing. Food for thought.
Scientists have discovered that shooting snail mail from a cannon at a mailbox proves that arming posties with rail guns will not realistically improve the speed of delivery.;^)
I thought that the B character was historically the result of writing two 's' characters, one on top of the other...? My memory fails me in this regard....
I do recall that all the umlauted words (using a, o, u) is the result of writing a small 'e' on top of the vowel in question. Hence the reason why words like offnen are acceptably transcribed as "oeffnen" when the means to add an umlaut isn't available.
(Didn't start German in Gr. 6, although I was repeatedly exposed to it early on enough. Started German officially in Gr. 10, went on to get a Bachelors in German, and another in Linguistics.;-)
Heck, when my son Sean was born, because of my Irish heritage, I was tempted to name him Sean (or maybe it was Sean... too many years ago, now). But then I got to thinking about things like computerized forms, transcription errors, that sort of thing. Decided to spare him.:P
It's not entirely clear what communication problem you're trying to solve, other than "our mail server is overloaded, we're looking for a (likely alternative) solution".
At my last company, one group had set up a Jabber server, although very few folks in my business unit were using it (in favour of AIM). However, our group ran into an e-mail problem and Jabber just happened to be part of the solution.
The problem: Code builds were happening on one server (which I owned from a sysadmin POV), but the e-mails which were autogenerated were forwarded to the corporate mail gateway, and filtered into an Exchange server at some point. Ordinarily this path would take less than 10 seconds to deliver, but frequently it was taking anywhere from 20 mins to a few hours. Naturally the code builders were getting a little irate. Unfortunately, all I could do was open a Help Desk ticket with the hope that the Exchange monkeys could get the problem resolved. Setting up a POP/IMAP server could have been a solution, but would likely have met with considerable resistance.
One rather bright coder who sat in the cube next to me had the idea of using a Perl module to connect to the corporate Jabber server and send status msgs to a conference room. (I should mention that the S2S Jabber feature was disabled.) Users could join that room and see the current status, and act accordingly.
Nice features of this approach include: low bandwidth; the conference room buffers the last handful of lines, so new users joining will get a bit of history.
Don't fret. First, learn to say 'Fedora' where you used to say 'cheap-to-run Red Hat', and learn to say 'Red Hat Enterprise Linux' where you used to say 'outrageously expensive Red Hat Linux that I refuse to buy'.
Third, where you used to say 'up2date', start saying 'apt-get' or 'yum'.
Once you start using apt-get (or yum) for Red Hat *cough* I mean Fedora like you used to use up2date, you'll be grinning so hard, your face will cramp.:)
Chant the mantra baby, chant the mantra. "apt-get is good, apt-get is great, apt-get is good, apt-get is great...".
IM means Instant Message, or Instant Messenger. Some (not necessarily all) of the major players (in terms of unique protocols) are: AIM (AOL Instant Messenger), YM (Yahoo! Messenger), MSN (Microsoft's client), ICQ (from Mirabilis, arguably losing popularity), and the only open source contender I'm aware of is Jabber (www.jabber.org). There are also a number of multiprotocol IM clients, which (strive to) support most or all of the above, such as Gaim, Trillian, Miranda, just to name a few.
Just go to http://freshrpms.net/ and install the apt RPM. Do it. Do it now. Then do an "apt-get update; apt-get dist-upgrade". Assuming that your RHL install is reasonably sane, you won't see it suggesting that it's about to uninstall large numbers of useful packages. But you should see it offering to upgrade quite a few of your existing packages.
Once you've got that done, set up a cronjob to run "apt-get update; apt-get dist-upgrade -dy" every night. Check the output first thing in the morning, and so long as the output doesn't suggest that it's about to do anything silly, run a script to do "apt-get dist-upgrade -y". Now sit back and try not to get a cramp in your face from smiling so hard.
Now chant the mantra baby, chant the mantra: "apt-get is good, apt-get is great, apt-get is good, apt-get is great"....;)
Our server lab has a combination of Suns and Dell hardware. On the Sun side, we have an E250, some 420's, a couple of 450's, a 280, a couple 4500's and a couple 6500's. In all the time I've been with this organization (19 months) we've had all manner of failures, namely disks, controllers, CPUs and memory. I don't think we've ever had an event-free month, and at times we have multiple failures the same week.
Compare that with the Dell boxes (such as the 2450's) running mostly Win2k but also Linux. I'm told by my co-worker that over the course of 4 years, we've had 3 disk failures, a SCSI backplane failure, and a fan failure. Between our Windows sysadmin and our desktop support guy, they *constantly* chant the "go Dell" mantra. And between myself and the other Sun/Solaris sysadmin, we're quite disillusioned with Sun's hardware.
From an ease-of-administration point of view, I used to think that Red Hat was a PITA for keeping all the RPMs up to snuff. Yeah, I'm aware of up2date, but have become a full convert of apt-get for RPM (http://freshrpms.net/). Now life is good.:) If you like Solaris, I suppose you can always go to http://www.sunfreeware.com/ and install pkg-get.
As an aside, check out http://www.infrastructures.org/ to get some good ideas on how to administer that size of an environment. And get on the mailing list; it's not too chatty, but when an interesting subject comes up, there's lots of great input.
I feel your pain. My penmanship always sucked. Then again, I learned to write with my right hand, my mother was left-handed, my father's father was left-handed, and my father (a doctor) once told me he discovered he could do a surgical square knot with his left hand easier than with his right. (It was required of surgeons to learn how to tie a square knot with one hand.) My mother hinted that perhaps I was 'coaxed' into writing with my right hand. I do various other things like a 'lefty'.... It was during HS/university that my cursive became a hybrid of cursive/printed.:P
And if we're going to question cursive penmanship, try learning to read German cursive! I studied German for many years, and their cursive is substantially different, enough to make you want to grind your teeth in your sleep. If anything, our cursive looks historically much more similar to French cursive.
Big fun.:P
As we like to chant around here whenever our RH boxes get automagically updated, "apt-get is great, apt-get is good, apt-get is great, apt-get is good...";)
Back around 1994 I was installing an IP-based printserver dongle on the network. The example they had in their installation booklet for testing network connectivity was based on a fictitious node name of 'elvis', thusly:
Slashdot Mirror
These are old FUD arguments. Newsflash: For any non-trivial piece of code, it's impossible to prove that there are no bugs. If you do some bug tests and don't discover any, you haven't proven that the code is bug-free, merely that you haven't come up with a comprehensive enough test. The same problem exists with proprietary code, only it doesn't have the luxury of having widespread peer review of the code, by definition. Security through obscurity sucks.
It's true, just because there are "many eyes" reviewing the code won't make it bulletproof. But it'll make it a helluva lot more bullet-resistant when compared to code which is under the purview of a select few.
But, feel free to don the blindfold of ignorance, and just keep chanting, "my code is bug-free, my code is bug-free." Say it often enough, and you'll actually believe it. ;-)
Barnes & Noble has announced paperbacks which crumble to dust after 48 hours, hoping to drive up demand for hardcover versions. :P
I used to work in Toronto for many years, so I feel your pain. Since making the jump, the first thing I noticed was that my peers were brilliant. Not to say that those in Toronto weren't, but rather more of a difference between "just doing what's necessary" compared to "breaking new ground". When I was working for a Very Large Bank in Toronto, there was an overriding theme of "don't change anything because something might break." Compare that to "let's bite the bullet and change this so we can fix nuisance issues today and plan for tomorrow." In Toronto, I usually found that innovation wasn't actively encouraged, and at times discouraged.
If this is starting to sound interesting, start reading up on what it takes to get your TN visa, here: www.grasmick.com
Best of luck. :)
If anything, the article's emphasis is on desktop support and the end-user experience.
Any seasoned sysadmin will have war stories to share regarding how servers drift out of sync (just the o/s, ignore anything else for now) over time, not just from a baseline, but from other servers which are meant to be identical. Read Steve Traugott's white paper on Turing Equivalence in Automated Systems Administration if you want to get a better feel for the issue.
Support: Support, can I help you?
Female user: Yes, I'm trying to do data entry, but the first screen doesn't give me a chance to enter the data, and immediately puts me at the second screen.
Support guy tries the application on his own terminal, finds it to be working normally.
Support: Hmm... I don't seem to be able to reproduce the problem. Try it again.
Female user: [pause] Yup, it did it again.
Support: Okay, I'll be down in a few minutes.
The support guy suspects that maybe the space bar is sticking. On arriving, he asked the user to let him sit down and try. He went to the screen in question and had no troubles entering the data. Both agreed it was strange. Support guy returns to his desk. Then his phone rings again.
Female user: It's doing it again!
Support: Hmm. Okay, I'll be right back down.
By now, the support guy is determined to watch what the user is doing. Or not doing. He gets to the user's terminal and asks her to show him what she's doing.
At this point it's worth noting that this user is *very* busty. As she went to do her work, he noticed her, erm, assets were resting on the space bar, causing the cursor to jump from field to field, then eventually to the next screen.
Needless to say, there was an 'Aha!' moment on the part of the support guy. His politically-correct fix? He adjusted the user's seat so she wasn't sitting quite so close to the terminal.
Quote:
HEC Montréal is Canada's first management school, founded in 1907. More than 11,000 students and 220 professors use HEC's e-mail system every year. Unfortunately, the proprietary e-mail system did not evolve and as the load started to increase, the infrastructure could no longer keep up with requirements.
[snip]
HEC Montréal is a tough e-mail problem: 35,000 users and more than 600,000 spam messages a week.
Read on for the details.
User: "Why is the network so slow?"
My Friend (pointing at the CN Tower): "Do you see the CN Tower over there?"
User: "Yes."
My Friend (said with a straight face): "Well all the network traffic has to bounce off the CN Tower and back again. That's why the network's slow."
User buys the explanation, and my friend has a story to tell, to this day.
One company I worked for about 10 years ago, one of the developers posted a question to Usenet, and had his answer in 45 minutes. It was his educated opinion that had he gone to Sun with the same question, first he would have had to deal with the phone drones and their canned list of questions, before eventually getting through to the people who he knew could really answer the question, and guesstimated that resolution path at hours, not minutes. 45 minutes vs. a few hours. You be the judge.
Having said that, I'm all for getting support from closed-source solutions such as the Veritas product line. But trying to compare BIND (open-source, many many years, many platforms, comparatively smaller code base, etc) to, say, Veritas Volume Manager (closed-source, not as many years, not as many platforms) is like comparing apples to pianos: sure, they both come from trees, but that's where the similarity ends.
If the goal of purchasing support is for the placebo effect, then by all means, ante up.
Still not convinced? Then why not a support contract for every daemon that runs on the server (eg, sendmail, ntpd, (x)inetd, NFS, etc)? Every instance of awk, grep, sed, etc? After all, why take a chance that any one of these is anything less than perfect?
ObSig: A fool and his money are soon parted.
Let's shift focus to the vendor (insert name; say Novell) and see which argument is easier to defend: 1) (After escalating past the phone drones): "hmm... my team is working as much as they can on it. It'll be resolved soon, after we RTFM, dredge through the Internet, and otherwise play the role of a savvy sysadmin."
OR
2) "The problem is being dealt with. Our vendor... oh wait, do we have a vendor we can delegate this problem to?"
You see, the buck has to stop somewhere. Granted, if all the company has is a trained monkey for a sysadmin, then buying support and passing the buck makes perfect sense.
But if the company is already paying serious scratch for a (team of) seasoned sysadmins, then why fork over even more cash?
I've had the pleasure of working with experienced sysadmins who know the drill and can resolve problems more quickly than the vendor. I myself have figured things out where the vendor was flailing. Food for thought.
30 seconds??
Wow... you've never had to deal with support from Monolithic Corporation Inc., have you? ;-)
Scientists have discovered that shooting snail mail from a cannon at a mailbox proves that arming posties with rail guns will not realistically improve the speed of delivery. ;^)
I do recall that all the umlauted words (using a, o, u) is the result of writing a small 'e' on top of the vowel in question. Hence the reason why words like offnen are acceptably transcribed as "oeffnen" when the means to add an umlaut isn't available. (Didn't start German in Gr. 6, although I was repeatedly exposed to it early on enough. Started German officially in Gr. 10, went on to get a Bachelors in German, and another in Linguistics. ;-)
Heck, when my son Sean was born, because of my Irish heritage, I was tempted to name him Sean (or maybe it was Sean... too many years ago, now). But then I got to thinking about things like computerized forms, transcription errors, that sort of thing. Decided to spare him. :P
At my last company, one group had set up a Jabber server, although very few folks in my business unit were using it (in favour of AIM). However, our group ran into an e-mail problem and Jabber just happened to be part of the solution.
The problem: Code builds were happening on one server (which I owned from a sysadmin POV), but the e-mails which were autogenerated were forwarded to the corporate mail gateway, and filtered into an Exchange server at some point. Ordinarily this path would take less than 10 seconds to deliver, but frequently it was taking anywhere from 20 mins to a few hours. Naturally the code builders were getting a little irate. Unfortunately, all I could do was open a Help Desk ticket with the hope that the Exchange monkeys could get the problem resolved. Setting up a POP/IMAP server could have been a solution, but would likely have met with considerable resistance.
One rather bright coder who sat in the cube next to me had the idea of using a Perl module to connect to the corporate Jabber server and send status msgs to a conference room. (I should mention that the S2S Jabber feature was disabled.) Users could join that room and see the current status, and act accordingly.
Nice features of this approach include: low bandwidth; the conference room buffers the last handful of lines, so new users joining will get a bit of history.
Second, go check out Fedora.
Third, where you used to say 'up2date', start saying 'apt-get' or 'yum'.
Once you start using apt-get (or yum) for Red Hat *cough* I mean Fedora like you used to use up2date, you'll be grinning so hard, your face will cramp. :)
Chant the mantra baby, chant the mantra. "apt-get is good, apt-get is great, apt-get is good, apt-get is great...".
IM means Instant Message, or Instant Messenger. Some (not necessarily all) of the major players (in terms of unique protocols) are: AIM (AOL Instant Messenger), YM (Yahoo! Messenger), MSN (Microsoft's client), ICQ (from Mirabilis, arguably losing popularity), and the only open source contender I'm aware of is Jabber (www.jabber.org). There are also a number of multiprotocol IM clients, which (strive to) support most or all of the above, such as Gaim, Trillian, Miranda, just to name a few.
As soon as I read the description, I was reminded of BEHEMOTH, or "Big Electronic Human-Energized Machine ...Only Too Heavy".
Once you've got that done, set up a cronjob to run "apt-get update; apt-get dist-upgrade -dy" every night. Check the output first thing in the morning, and so long as the output doesn't suggest that it's about to do anything silly, run a script to do "apt-get dist-upgrade -y". Now sit back and try not to get a cramp in your face from smiling so hard.
Now chant the mantra baby, chant the mantra: "apt-get is good, apt-get is great, apt-get is good, apt-get is great".... ;)
Compare that with the Dell boxes (such as the 2450's) running mostly Win2k but also Linux. I'm told by my co-worker that over the course of 4 years, we've had 3 disk failures, a SCSI backplane failure, and a fan failure. Between our Windows sysadmin and our desktop support guy, they *constantly* chant the "go Dell" mantra. And between myself and the other Sun/Solaris sysadmin, we're quite disillusioned with Sun's hardware.
From an ease-of-administration point of view, I used to think that Red Hat was a PITA for keeping all the RPMs up to snuff. Yeah, I'm aware of up2date, but have become a full convert of apt-get for RPM (http://freshrpms.net/). Now life is good. :) If you like Solaris, I suppose you can always go to http://www.sunfreeware.com/ and install pkg-get.
As an aside, check out http://www.infrastructures.org/ to get some good ideas on how to administer that size of an environment. And get on the mailing list; it's not too chatty, but when an interesting subject comes up, there's lots of great input.
Food for thought.
In case nobody's mentioned it yet, let's not forget The Chronicles of George, where "George is, quite simply, the worst helpdesk technician ever."
I feel your pain. My penmanship always sucked. Then again, I learned to write with my right hand, my mother was left-handed, my father's father was left-handed, and my father (a doctor) once told me he discovered he could do a surgical square knot with his left hand easier than with his right. (It was required of surgeons to learn how to tie a square knot with one hand.) My mother hinted that perhaps I was 'coaxed' into writing with my right hand. I do various other things like a 'lefty'.... It was during HS/university that my cursive became a hybrid of cursive/printed. :P
And if we're going to question cursive penmanship, try learning to read German cursive! I studied German for many years, and their cursive is substantially different, enough to make you want to grind your teeth in your sleep. If anything, our cursive looks historically much more similar to French cursive.
Big fun. :P
Actually, there is an apt-get for Red Hat:
;)
http://freshrpms.net/
As we like to chant around here whenever our RH boxes get automagically updated, "apt-get is great, apt-get is good, apt-get is great, apt-get is good..."
If you're considering djbdns for your zone server, you might want to consider the complementary dnscache as your cache/forwarder server.
# ping elvis
elvis is alive
If you're a sysadmin who's convinced "there's got to be a better way", check out www.infrastructures.org