• not quite (unregistered)

    "While most computer systems have failure rates on the order of a few days,"

    By which you mean the Personal Computer (IBM-PC). In contrast to the minicomputers of the day which ran for years.

  • (cs) in reply to FredSaw
    FredSaw:
    taylonr:
    This board is not a fan of reading comprehension is it?

    From the article

    When Chris B. first learned of all this, he was more intimidated than impressed. At his new company-a small consulting firm that developed minicomputer systems and software-he'd be the backup to the backup of the primary Tandem Computer guru.
    How many small consulting firms do you know that hire backups to backups as their sole job? Isn't it highly likely that he was hired to do something else (write software perhaps) and was the de facto backup to the backup?

    Yeah, let's fire that software guy who was hired to write software, who botched a hardware issue that WE thrust upon him.

    /I probably wouldn't fire the main guru if it was the first mistake of this kind

    From the article:"Chris B. was hired to write software. In addition, if there ever was a time when the two server gurus were not available, Chris might be called on to help out with any problems there."

    Oh... wait... that isn't what the article said, is it. Reading comprehension, indeed.

    "It's nothing to worry about," Chris's boss told him. "Those things hardly ever have issues. And in the highly unlikely scenario that you'll personally have to deal with one, they've got incredible support to walk you through anything."

    Indeed. It's amazing that someone who was told it would be an "unlikely scenario" by the Guru's backup wasn't more prepared.

    /Comprehension != needing every detail dictated

  • anoncow (unregistered) in reply to FredSaw
    FredSaw:
    taylonr:
    This board is not a fan of reading comprehension is it?

    From the article

    When Chris B. first learned of all this, he was more intimidated than impressed. At his new company-a small consulting firm that developed minicomputer systems and software-he'd be the backup to the backup of the primary Tandem Computer guru.
    How many small consulting firms do you know that hire backups to backups as their sole job? Isn't it highly likely that he was hired to do something else (write software perhaps) and was the de facto backup to the backup?

    Yeah, let's fire that software guy who was hired to write software, who botched a hardware issue that WE thrust upon him.

    /I probably wouldn't fire the main guru if it was the first mistake of this kind

    From the article:"Chris B. was hired to write software. In addition, if there ever was a time when the two server gurus were not available, Chris might be called on to help out with any problems there."

    Oh... wait... that isn't what the article said, is it. Reading comprehension, indeed.

    Ummm. In fact when I submitted the story to Alex I did in fact say that I was hired to write software for these guys. So TRWTF is that Alex's re-writing of the software introduced a few errors :P

    'Chris B'

  • anoncow (unregistered) in reply to anoncow

    Story. I meant 're-writing of the story' not 'software'

    Sigh. It's been a long day.

  • Pfhreak (unregistered) in reply to Morasique
    Morasique:
    A guy that's worked for the company a month goes out on his first repair job and takes down all the ATMs for an entire country. I probably would've fired him too; at the very least you'd think the bank would be more annoyed

    The problem with firing this guy is that he is not the root cause of the problem. Always ask yourself 'Why?' five times. Why did the server go down? Cause some guy flipped the wrong switch. Why is this a problem? Because the server didn't come back up in three minutes. Why didn't it come back up in three minutes or so? Because someone else wasn't doing their job. Why weren't they doing their job? (Here's what I think might be the root cause.) Because there wasn't a well established Process to prevent this kind of thing.

    So firing this guy doesn't really solve anything, you've found a scapegoat, while not touching on the fundamental problem. Chris' error is just a symptom of a deeper root problem.

  • (cs) in reply to Morasique
    Morasique:
    A guy that's worked for the company a month goes out on his first repair job and takes down all the ATMs for an entire country. I probably would've fired him too; at the very least you'd think the bank would be more annoyed
    I know a guy who took an entire country's teller system offline. Not the ATM's, I mean the 'human' type tellers. They didn't fire him either...
  • (cs) in reply to Pfhreak
    Pfhreak:
    Morasique:
    A guy that's worked for the company a month goes out on his first repair job and takes down all the ATMs for an entire country. I probably would've fired him too; at the very least you'd think the bank would be more annoyed

    The problem with firing this guy is that he is not the root cause of the problem. Always ask yourself 'Why?' five times. Why did the server go down? Cause some guy flipped the wrong switch. Why is this a problem? Because the server didn't come back up in three minutes. Why didn't it come back up in three minutes or so? Because someone else wasn't doing their job. Why weren't they doing their job? (Here's what I think might be the root cause.) Because there wasn't a well established Process to prevent this kind of thing.

    So firing this guy doesn't really solve anything, you've found a scapegoat, while not touching on the fundamental problem. Chris' error is just a symptom of a deeper root problem.

    You must be new here. You have to fire the guy who made that mistake because, obviously, only a completely stupid idiot unworthy of breathing our oxygen could ever do something so impossibly stupid. Also, mercy = weakness.

    None of us here have ever made such a mistake, ever, which is why we all still have (and deserve) our jobs. We'd appreciate it if idiots like you would stop cluttering up our forum.*

    *Just in case: I'm not being serious.

  • (cs) in reply to Grovesy

    Oh, I've seen equally crazy stuff, writ somewhat smaller. Old school unix machines took so little maintenance that they often got relegated to old wiring closets, then quietly forgotten. Especially an infrastructure machine; your secondary DNS machines, your NAT load balancer, your DMZ firewall...All functions well suited to being dumped on a headless machine in the phone room, where they will inevitably gather dust and be forgotten.

    This is one of those lessons people need to learn: even if a machine never goes down, you need to bring it down occasionally, in a controlled situation, to make SURE it will come back up in the event of a real failure. Sure, getting 1000+ days back when you type "uptime" is a e-peen extension, but having a machine suffer a catastrophic meltdown because it actually needed to be rebooted later...That's just sloppy.

  • (cs) in reply to anoncow
    anoncow:
    Ummm. In fact when I submitted the story to Alex I did in fact say that I was hired to write software for these guys. So TRWTF is that Alex's re-writing of the software introduced a few errors :P

    'Chris B'

    Where I work there are currently 12 people on the server team, not counting the manager. This does not include the field support team; nor does it include the communications team, which deals with hardware of a different sort. While "backup to the backup to the server guru" is an odd way of describing a position on the server team, it isn't inconceivable that someone would say this simply to emphasize that they were third in line in the event of a problem. Nor is it difficult to conceive that a company which "developed minicomputer systems" would have a server team rather than an individual.

    Being a software developer with little chance of ever having to handle a server problem, it's expected that you wouldn't already know the process from memory. But, to my mind, that's all the more reason for going slowly, double-checking everything before acting.

    But, as someone has said earlier in this thread, once bitten, twice shy. Lesson well learned, eh? Good!

  • Saaid (unregistered) in reply to RJ
    RJ:
    I worked for "a large fast food corporation" that used a Tandem to process data for its company-owned restaurants (never call them stores...).

    As the article said, it was an excellent machine that would continue processing even if there was a problem with some of its hardware. The only problem was that the software had to be written with 'checkpoints' - places where the OS would save information so that if a CPU or memory module went bad it could resume processing from that point. Other hardware issues (Power supply, hard drive, etc) didn't need checkpoints.

    Of course it had a totally proprietary operating system (named Guardian) and a proprietary programing language (TACL) in addition to relatively standard COBOL and C compilers.

    The main issue with this generation of Tandem computers was that it wasn't Unix - they did introduce Unix systems, but IIRC they weren't nearly as popular. The Tandem corporation was bought by Compaq in 1997 - a year before Compaq bought Digital Equipment and 4 years before Compaq 'merged' with HP. (see the Campaq entry at wikipedia for the timetable)

    I'll bite, why was it an 'issue' that they weren't Unix?

  • (cs) in reply to UncleMidriff
    UncleMidriff:

    *Just in case: I'm not being serious.

    What's really sad is that your asterisk is needed

  • Jay (unregistered)

    It seems to me that organizations that have a philosophy of "one mistake and you're fired" are likely to quickly end up with employees who exercise absolutely no initiative. In a case like this of a backup to a backup, the rational response would be to say, "Hey, that's outside my area of expertise, we'd better wait until the regular guy gets back."

    Reminds me of a poster I saw years ago of the Real System Development Life cycle:

    1. Write the code
    2. Collect the requirements
    3. System testing
    4. Growing panic
    5. Project cancellation
    6. Punishment of the innocent
    7. Bonuses and promotions for the non-participants
  • SomeCoder (unregistered) in reply to Saaid
    Saaid:
    I'll bite, why was it an 'issue' that they weren't Unix?

    Well I don't know for sure, but I'd guess that an "issue" would be because they used a proprietary OS. If you advertise for an XYZ OS guru vs a Unix guru, you're going to get a lot more qualified people for the Unix.

  • (cs) in reply to Morasique
    Morasique:
    What's with the sudden Internet trend of making fun of the phrase "mission-critical"? Do people really not know what it means?

    Some people are on a mission to criticize any word that they simply disagree with. Specifically words that are newer to the lexicon. "Mission" can mean a NASA mission or a big secret government project, and that's it. So it's my mission to find any usage of "mission" or "mission-critical" and point out how wrong it is because obviously you aren't doing anything important enough to qualify as a mission. Just like your production database isn't actually producing anything, so it should really be called your "Final Draft Database".

  • Grammar Nazi (unregistered)

    Someone seriously needs to learn how to properly use "-".

  • (cs) in reply to akatherder
    akatherder:
    So it's my mission to find any usage of "mission" or "mission-critical" and point out how wrong it is
    Is your "mission-critical"-critical mission critical?
  • (cs) in reply to Grammar Nazi
    Grammar Nazi:
    Someone seriously needs to learn how to properly use "-".
    "anal-retentive" or "anal retentive"?
  • Ketsuban (unregistered) in reply to Bappi

    Anally-retentive.

  • Turtle (unregistered) in reply to FlyboyFred

    If you taped two tandem machines together...

  • Saaid (unregistered) in reply to Bappi
    Bappi:
    Grammar Nazi:
    Someone seriously needs to learn how to properly use "-".
    "anal-retentive" or "anal retentive"?
    Yes, I'd say so.
  • (cs) in reply to Jay
    Jay:
    1. Write the code 2. Collect the requirements
    This was funny as hell all by itself, in a "sad but true" kind of way.
  • Bowie (unregistered) in reply to anoncow

    Good job, dude. :)

    Don't worry, though.. Boneheaded moves happen to the best of us. I once had to slap a hand away from a reset button at the last second that would have downed an entire hospital, and everything connected/dependent upon it.. (ER doctors not being able to enter/look up patient information = kinda bad. Oh, and when billing goes down? Yeah, the hospital stops making money.) Quite a whoops. And that hand belonged to my team lead, of all people. 20+ years with the company.

    Murphy and his Law are both alive and well.

  • (cs) in reply to Saaid
    Saaid:
    Bappi:
    Grammar Nazi:
    Someone seriously needs to learn how to properly use "-".
    "anal-retentive" or "anal retentive"?
    Yes, I'd say so.
    Say what?
  • Larry Yates (unregistered) in reply to Turtle
    Turtle:
    If you taped two tandem machines together...

    ...actually, you can "tape" several tandem machines together!

  • Platypus (unregistered)

    This is why the rule at several places I've been (I'm an OS developer) was: if you change anything that affects a system's booting or default after-boot state, reboot it at the first opportunity to make sure it boots the way you expect. Hot patches etc. are great, but letting them pile up is a very bad mistake.

  • RJ (unregistered) in reply to SomeCoder
    SomeCoder:
    Saaid:
    I'll bite, why was it an 'issue' that they weren't Unix?

    Well I don't know for sure, but I'd guess that an "issue" would be because they used a proprietary OS. If you advertise for an XYZ OS guru vs a Unix guru, you're going to get a lot more qualified people for the Unix.

    I should have been more clear in my first comment - you're right in that the amount of people who knew Tandem systems was an issue.

    Another is that when Unix became popular in business in the early 1990's, any large system that didn't run Unix (or wasn't capable of running Unix) lost a lot of market share. Tandem never did really recover even though they were an excellent system for the people who needed very high reliability.

    [The only large non-Unix systems that seemed to survive the 90's intact were IBM mainframes (which could run Unix as a guest OS) and IBM's AS400 (which usually seem to be installed in companies that don't have large IS departments). Even DEC's VMS didn't survive the 90's in a healthy state]

  • Crabs (unregistered) in reply to notromda
    notromda:
    I've done a similar thing with RAID drives... Somehow the order of the drives wasn't what it was supposed to be or something... but when you pull one too many drives from a RAID array, it's not too fun.

    It's now a pet peeve of mine that there's not a better feedback system throughout hardware to indicate faults. Why not have a little led on the hard drive, on the bus cable, on the motherboard... some sort of indicator to say "Hey STUPID! The bad part is right here!"

    The Dell Poweredge servers have a small LCD display that tells you exactly what part is broken if there is a hardware problem. It's pretty sweet. A light on the actual piece would be cool, though, but the extra wiring required for that would be a bit of a pain.

  • (cs) in reply to Morasique
    Morasique:
    What's with the sudden Internet trend of making fun of the phrase "mission-critical"? Do people really not know what it means?

    Mission accomplished.

  • (cs) in reply to Jason
    Jason:
    Tandem used to offer these great coffee mugs as swag... they had two handles, one on each side.
    And the souvenir pens had writing points at both ends!
  • (cs) in reply to E
    E:
    The servers had redundant power supplies. The admin who installed them plugged them both into the same power distribution module (basically a fancy power strip) in the rack. The module failed. We lost all of the hosts plugged into it.
    I worked for a small software house using Tandem hardware. One day, an electrician working on another office in our building needed to identify which circuit breaker went with what room. He just flipped each one in turn. I saw the lights in our front room go out, then our side room, and finally our Tandem lab. All power was gone to everything: CPUs, modems, hard drives, everything. The power came back on in a few seconds. The four-CPU Tandem returned to processing at the very next instruction. Nothing, absolutely nothing, was lost.

    Mind you, software on the Tandem had to be written to take advantage of the NonStop hardware and OS. The original post is an example of an improperly configured system. But when you followed Tandem's guidelines, it was a dream of a machine.

  • (cs) in reply to Jay
    Jay:
    1. Write the code 2. Collect the requirements 3. System testing 4. Growing panic 5. Project cancellation 6. Punishment of the innocent 7. Bonuses and promotions for the non-participants
    I've seen this "version" floating around the web and I have to point out that it's horribly misquoted.

    The actual "list" is about projects in general, not the computer field:

    1. Enthusiasm
    2. Disillusionment
    3. Panic [and Hysteria]
    4. Search for the Guilty
    5. Punishment of the Innocent
    6. Praise and Honors for the Non-Participants
  • treasury (unregistered) in reply to sewiv
    sewiv:
    Not quite clear on the WTF here. He flipped the wrong switch, the system went down. He kept his job? Is that the WTF?

    Do you go on Digg and complain about the lack of articles about shovels, too?

  • treasury (unregistered) in reply to sewiv
    sewiv:
    Not quite clear on the WTF here. He flipped the wrong switch, the system went down. He kept his job? Is that the WTF?

    Do you go on Digg and complain about the lack of articles about shovels, too?

  • (cs)

    Well, that goes to teach why there are always two or more computers on hight availability setups, and why you should always restart your computers after big changes.

    Getting just a few or several years of uptime from some computer shouldn't make any difference.

  • BentFranklin (unregistered)

    If anyone should have been fired it should not be Chris, but Chris' boss, or that guy's boss, for letting a newbie go on such an important call by himself.

  • blunder (unregistered) in reply to E

    Redundant power supplies still help if one blows. They don't help when the power goes out, obviously. Would your manager have been cool with buying separate PDUs and wiring the server room with isolated electrical circuits? Or was he the "you've already got one of those, make do" types?

    I wouldn't call what he did a major blunder.

  • Saaid (unregistered) in reply to Flash

    In 1995 I had a job interview at a news and financial information services company that used Tandem computers. The guy interviewing me was so proud of the equipment's ability to withstand hardware failure. He reached over an flipped a switch on the server and their system went dead. The lights on several racks of modems stopped blinking. A major fubar. I did not get that job. A similar failure event happened when someone was showing me how he could hot swap drives on a raid array. Apparently the array was in the middle of rebuilding itself.

    Last place I worked they had procedures in place to take down the mainframe every 60 days. The purpose was to test their restart procedures and prevent problems like the one in the story. The mainframe was critical to their business mission.

  • Ben4jammin (unregistered) in reply to Saaid
    Saaid:
    In 1995 I had a job interview at a news and financial information services company that used Tandem computers. The guy interviewing me was so proud of the equipment's ability to withstand hardware failure. He reached over an flipped a switch on the server and their system went dead. The lights on several racks of modems stopped blinking. A major fubar. I did not get that job. A similar failure event happened when someone was showing me how he could hot swap drives on a raid array. Apparently the array was in the middle of rebuilding itself.

    Last place I worked they had procedures in place to take down the mainframe every 60 days. The purpose was to test their restart procedures and prevent problems like the one in the story. The mainframe was critical to their business mission.

    Other than verifying I can restore from backups every now and again, I would NEVER tempt the networking gods in such a manner. A scheduled test is one thing, trying to show off is just dumb

  • Mission Critic (unregistered) in reply to Saaid
    Saaid:
    The mainframe was critical to their business mission.
    It's a damn good thing you didn't say it was mission critical...
  • Franky (unregistered) in reply to Larry Yates
    Larry Yates:
    HP NonStop (Tandem) computers are *STILL* the most reliable machines in the marketplace for mission critical enterprises.

    Unless your company starts writing a telecom grade application that can handle even more then the Tandem and in the ends realizes that with their own OS for multiple CPUs it gets the job done on COTS hardware. No more Tandem needed :)

  • Steve (unregistered) in reply to Bowie
    Bowie:
    Good job, dude. :)

    ... I once had to slap a hand away from a reset button at the last second that would have downed an entire hospital, and everything connected/dependent upon it..

    I used to joke to my boss that when I went into the plant, I would just hang around the console and if anyone went near it, I would scream "ARE YOU F#$&ING CRAZY?!!!"

  • ChiefCrazyTalk (unregistered) in reply to Markp
    Markp:
    "Mission-critical"?

    What do they think this is, NASA?

    If you are not familiar with the term "Mission Critical" as it applies to software applications, that sir is the real WTF.

  • ChiefCrazyTalk (unregistered) in reply to Bowie
    Bowie:
    Good job, dude. :)

    Don't worry, though.. Boneheaded moves happen to the best of us. I once had to slap a hand away from a reset button at the last second that would have downed an entire hospital, and everything connected/dependent upon it.. (ER doctors not being able to enter/look up patient information = kinda bad. Oh, and when billing goes down? Yeah, the hospital stops making money.) Quite a whoops. And that hand belonged to my team lead, of all people. 20+ years with the company.

    Murphy and his Law are both alive and well.

    My story that should have got me fired (well, I was a grad student - can grad students be fired?) - we had a new HP workstation in the lab, and I wanted to copy the contents of a 5 1/4" floppy to the hard drive. I used the copy *.* command, not realizing that in HP-speak "Copy" would REPLACE the entire contents of the hard drive with what was on the floppy. Basically I ended up reformatting the entire system to act like a 1 MB Drive.
  • Ben4jammin (unregistered) in reply to Steve
    Steve:
    Bowie:
    Good job, dude. :)

    ... I once had to slap a hand away from a reset button at the last second that would have downed an entire hospital, and everything connected/dependent upon it..

    I used to joke to my boss that when I went into the plant, I would just hang around the console and if anyone went near it, I would scream "ARE YOU F#$&ING CRAZY?!!!"

    Fricking awesome. I had fun with a former DIT once. We had a db get corrupt so we needed to restore from a backup (tape backup was all we had at the time). So, I got a broken backup tape and put it back together. So I go into his workstation and as I say "whew...I found the tape" I purposefully fumbled it and it his his desk and broke into pieces. Priceless.

  • (cs) in reply to SomeCoder
    SomeCoder:
    Saaid:
    I'll bite, why was it an 'issue' that they weren't Unix?

    Well I don't know for sure, but I'd guess that an "issue" would be because they used a proprietary OS. If you advertise for an XYZ OS guru vs a Unix guru, you're going to get a lot more qualified people for the Unix.

    You'd think so, wouldn't you?

    Well, you would if you'd never tried it and didn't bother putting the slightest effort into thinking before you comment.

    I'd imagine that XYZ OS gurus are thin on the ground, but if you advertise for a Non-Stop guru, or a VOS guru, or a TPF guru, the chances are that you'll get a sizeable collection of high-quality applicants. (How this is meant to help you when some wet-behind-the-ears guy comes in and pulls boards without thinking is unclear. In my old, VOS, environment, it was at least a salesman. This was good, because we could extort large chunks of his expense account in drunken revenge.)

    Of course, it'll cost you. OS Gurus are different from Enterprise Architects.

    If you advertise for a Unix OS guru, you're in the klartz. First of all, you have to sieve through thousands of flavours of *nix. Then you have to sift through thousands of possible combinations of requirements on your own flavour of *nix.

    Then you have to face up to the fact that 99% of people who claim to be Unix OS gurus are in fact bare-faced lying morons. And it'll still cost you.

    And you won't even get a fault-tolerant system, because you really can't build one of those with standard Unix -- otherwise, the market being the market, somebody would have done so. Double panics all round!

    Why people persist in thinking that Unix is anything other than a clapped-out old 1970s OS in dire need of a bullet through the head (both feet already having been self-sacrificed) is beyond me. I use it, but I don't have to admire it.

  • George Santayana (unregistered) in reply to ChiefCrazyTalk
    ChiefCrazyTalk:
    Markp:
    "Mission-critical"?

    What do they think this is, NASA?

    If you are not familiar with the term "Mission Critical" as it applies to software applications, that sir is the real WTF.

    Those who cannot remember the past WTF comments are condemned to repeat them.

  • (cs) in reply to not quite
    not quite:
    "While most computer systems have failure rates on the order of a few days,"

    By which you mean the Personal Computer (IBM-PC). In contrast to the minicomputers of the day which ran for years.

    There is a difference between MTBF and amortised up-time. "Five nines" never applied to any other minicomputer other than Tandems and Stratus (and Stratus did a far better job of backing this claim up with excellent customer support, which is where they actually made their money. If I'd ever mentioned to my boss that I was going to pick a board up from Stratus Central and install it myself, he'd have laughed in my face and then fired me for smoking the wrong sort of weed).

    Frankly, if the mini stays up for years and then goes down in the middle of the Melbourne Cup and stays down for several hours, I'm not impressed. Five nines translates to five minutes a year -- guaranteed under non-idiot circumstances.

  • (cs) in reply to George Santayana
    George Santayana:
    ChiefCrazyTalk:
    Markp:
    "Mission-critical"?

    What do they think this is, NASA?

    If you are not familiar with the term "Mission Critical" as it applies to software applications, that sir is the real WTF.

    Those who cannot remember the past WTF comments are condemned to repeat them.

    Not an apt reference: the first time around wasn't tragedy.

    Farce, though -- there you may have a point.

    By the way -- did anybody comment that 1 is not a prime number yet?

  • jbinaz (unregistered)

    Prior to software, I once worked for a state criminal justice licensing board. We granted and revoked licenses for police and correctional officers. I had interned at the state agency and then got a part time job after my internship.

    Due to a screw-up on my part, I got a guy fired from his new job at a correctional facility. He and his family had moved to my state from up north specifically for this job. Because I misinterpreted the statue and sent a letter rejecting his permanent license (he was hired on a temporary license), the correctional facility let him go.

    I didn't get fired - I had a very understanding manager who called the hiring guy at the correctional facility and explained my f***-up. They reinstated the guy as if he'd never left. But I felt like crap - I'd gotten this poor guy fired, probably caused his wife a heart attack. "You moved us down here and then got fired?" When I first found out about my screw-up, I found nice solitary place and bawled like a baby over the fact I had nearly cost someone their career. I honestly don't know if I could have lived with myself if the guy hadn't been rehired.

    My whole point? I screwed up big time and got a second chance. I worked there for several years after that and was a great employee (or so I was told). I'm more conscientious about everything I do because of that experience. Once mistake doesn't make you an idiot - it makes you human.

  • blunder (unregistered) in reply to real_aardvark

    He didn't say it was better, just that being anything other than Unix meant that the vendor had a lot less potential customers. I don't like Unix much either, but the truth is, by being seen as portable and off-the-shelf to the tech guys, and enterprise-ready by the managers, it took a huge chunk out of any vendor that didn't join the fun. The fact that is neither of those things was, and still is, irrelevant.

    When the last Unix box is shut down, it won't be because everyone finally acknowledge what an outdated PITA it is. It will be because Linux is a sparkly new PITA that has all of the same "advantages".

    And he's right. There's a huge number of Unix SA's out there. Whether they can walk the walk, especially when it comes to the strange details of a particular variant they haven't used before, is not known or seen by the manager who's deciding what type of system to go with.

Leave a comment on “Designed For Reliability”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article