Code of Federal Regulations, Title 14, Section 91, Paragraph 3, Subparagraph a:
"The pilot in command of an aircraft is directly responsible for, and is the final authority as to, the operation of that aircraft."
That one regulation gives a pilot great authority, and also great responsibility.
On the one hand, it means that the pilot can almost never place the blame on somebody else in the case of an accident. There are very few accidents that are not caused by pilot error. There are a few exceptions, but those are rare.
On the other hand, just a couple of sentences down in the regs, a pilot is explictly authorized to violate any regulation necessary in an emergency in order to ensure his aircraft can be operated safely. That means that he can ignore air traffic control, exceed his airplane's design limits, land anywhere, shut down his lights, fly right over the White House, and pretty much do anything necessary to prevent an emergency from becoming an accident.
For instance, if a previously uknown design defect causes control surface failure, than the pilot is not considered at fault, as long as there was nothing he could have done to prevent an accident. Accidents do occur. This wasn't one of them.
In this case, the pilot lost control of the aircraft while performing a routine operation. Yes, that operation involved more than flicking a finger, but it was routine, and should have been something he was proficient in before ever leaving the ground. Period. End of story.
(As a side note, in older cars, turning on the heat involved reaching underneath the dash. If you hit somebody while doing this, it would be 100% your fault. A fickle jury might think otherwise, but I guarantee the police report would be unabiguous about it.)
In the Cessna 152 I am training in, there is no place in the front of the plane for me to put the Pilot's Operating Handbook, which contains FAA-sanctioned emergency proceedures (among other things). The book is stored in a pouch behind the right seat. If I get in an accident because I couldn't access those proceedures quickly enough, tough. I should have prepared better by memorizing them in advance, or keeping a copy of the checklists in an easily accessible place. (In fact, I do keep a copy of the emergency checklists on my kneeboard.)
If I take off when the fuel gauge says I have a full load of gas, but I didn't verify it myself and I run out of gas, again, my fault. (And so the NTSB would rule.) I should have checked it by sticking my finger in the tank. No excuse. The fuel gauge maker isn't responsible for making sure I don't run out of gas, I am.
This is the way aviation works. This is the way the laws work. This is how the FAA works. This is the way pilot's think. I expect that if you described this accident to Mr. Denver the day before he bought that plane, he would have agreed with the NTSB.
From the NTSB accident report: "The National Transportation Safety Board determines the probable cause of this accident was the pilot's diversion of attention from the operation of the airplane and his inadvertent application of right rudder that resulted in the loss of airplane control while attempting to manipulate the fuel selector handle. Also, the Board determines that the pilot's inadequate preflight planning and preparations, specifically his failure to refuel the airplane, was causal. The Board determines that the builder's decision to locate the unmarked fuel selector handle in a hard-to-access position, unmarked fuel quantity sight gauges, inadequate transition training by the pilot, and his lack of total experience in this type of airplane were factors in this accident."
In English, it was his fault. He screwed up his flying and took off with inadequate fuel to boot.
The design and location of the fuel selector were part of the accident, but not considered a cause of the accident. That means that if the "factors" were not there, the accident may not have occured, but it was the pilot's responsiblity to mitigate those factors. They were not the responsibility of the trainer, former owner, designer, or builder.
So says the NTSB, and so would agree any pilot I have ever met.
Mr. Denver made several mistakes. Like almost all accidents, it was percipitated by a chain of events. If any "link" in the chain had been broken, the accident would not have occurred.
1) He ran one of his wing tanks dry. There is no excuse for running either tank completely dry. He should have had gas put in it before he took off. From the accident report, it appears that he only attempted a tank switch when one tank went dry, and the engine starved. 2) He did not practice switching fuel tanks sufficiently. 3) He did not manage to maintain control of the plane during this routine operation.
If he had not run a tank dry, he likely would not have had to rush and sloppily try to change the tanks, a manuver which he did not know how to do well.
In any case, the PILOT is responsible for the safe operation of the aircraft. Not the builder, not the mechanic, not the regulatory agency, not the owner, not the designer, not the flight instructor, not the weather forcaster, the PILOT. If the PILOT can't operate the plane safely, and deal with a design that is not optimal for him, he should not leave the ground. Period. End of Discussion. No excuses.
One of the most important Federal Aviation Regulations (Pilot In Command Responsibility) that is drilled into the head of every single pilot is that there is NO EXCUSE to not operating your craft in a safe manner.
There is NO EXCUSE for one of the fuel tanks running dry. Not even a fuel leak. There is NO EXCUSE for being unable to operate the tank switch valve. If it wasn't in a position he could safely operate it, he shouldn't have flown the plane. There is NO EXCUSE for inadverdently pushing the controls in the wrong direction.
He crashed his airplane, and it was nobody's fault but his own.
Well, as an IBM shill, there are a couple of solutions I could mention that Big Blue offers: (Will these meet your specific requirements? I don't know. I'm just a lowly support engineer.)
1) SAN File System. Your filer (actually the SAN File System nodes) handle requests for data, but the data itself travels directly over the SAN to your clients. (Which obviously need SAN connections.)
2) GPFS. (General Parallel File System) Clients available for AIX and Linux. A pretty decent clustering filesystem, with fairly low overhead and excellent throughput. Somewhat popular in supercomputing applications.
Err... what planet are you from? IBM no longer sells PC's to retail customers at stores. Hardware in general remains about 35-40% of the business. For IBM, that translates to about 30 Billion dollars a year. It makes Sun look positively puny.
Even in PC's IBM sells more laptops to businesses than anyone else. IBM sells more servers than any other company by a significant amount. That is all serious money.
Err... head over to your local University library, and check out the last couple of years of the "IBM Journal of Research and Development" and the "IBM Systems Journal". There is plenty of groundbreaking research going on in operating systems, testing, development, processor architecture, packaging, semiconductor manufacture, security, encryption, collaboration, end-user interafaces, language and compiler development, storage architecture, etc.
Nobody can predict which of those (if any) will become the "big thing". Not me, not you, and unfortunately, not even the scientists at IBM Research. However, the significant dollars poured into research should be good for something.
As a side note, you mention lasers... IBM owns the patent for the Excimer laser used in LASIK.
Di-Hydrogen Monoxide isn't the proper name for water. That would imply a H2 ion bonded to a O ion. IIRC, this is not correcct. It's been ten years since I took chemistry, but shouldn't it really be Hydrogen Hydroxide? (H bonded to OH)
Mainframes do I/O using a "Channel Program". This is a sequence of commands assembled by your system software to perform an I/O task. The task may be made up of hundreds of I/O commands. (which use the Single-Byte-Command-Set architecture.) After the I/O program is built, a single CPU instruction (start subchannel) begins I/O program execution. The processor is not interrupted until the execution of the program is completed. A "channel processor" (these days ususally a PowerPC chip) handles all the actual work.
SCSI is loosely based on the architecture, but does not have the concept of a channel program, so it has none of the CPU conservation benefits.
The advantage of this whole setup is that the box can be doing fantastic amounts of I/O streams simultaneously, since the CPUs do not have to coordinate all of it. We all know that Disk is WAAAYYY slower than memory, so this way you can be doing useful things with a large number of I/O paths until you finally exhuast your quite substantial processor resources. UNIX-style architectures bog down at far slower I/O loads.
The disadvantage is that it blows for charachter-by-character interactive (i.e. Telnet) use, due to the overhead involved in creating the channel program. Transactions actually do okay, as the overhead isn't that terrible, compared with the work usually required to process the transaction itself.
The other disadvantage is you need an expensive box to just get an admin console, since the ONLY way to get I/O in and out is this huge channel system, a RS-232 just doesn't work. (These days, it is an xSeries Pizza Box w/ an ESCON card. It used to be this behemoth about the size of a dorm-room refrigerator.)
Ahhh... the optimistic utopia of fully automated systems. The day they can fully automate network design and troubleshooting is they day that Bill Gates takes over the Linux kernel from Linus.
While things get simpler and simpler for end users and administrators, the back-end protocols to run all this automated spiffiness don't get any easier. I work in Storage Area Network troubleshooting and I spend my days staring at protocol traces, scrutinizing poorly drawn network diagrams, and poring through dense standards documents. This isn't going to change any time soon. While the protocols I work on today (Fibre Channel and SCSI) may be gone in ten years, something no less complicated will take its place.
User administration will become easier and easier as time goes on, and those skills will become less valuable. Hard-core troubleshooting and design are skills that can only be had by "real" engineers, and will always be useful.
IT programming (programming done in IT departments) has always been a "dead" field, as the VAST majority of it requires nothing more than an associates degree. DB apps and churning out SQL all day doesn't require a 4yr college degree. This is the stuff that is being outsourced to India right now. (Along with low-end tech support, but that is almost beneath mention.) This has been the case for a couple of decades, and in fact, is what the majority of programmers do for a living. This stuff has NEVER required a college degree.
The real innovation, and fun, happens at the companies that make all those building blocks, and they aren't going to need an appreciably different mix of engineers in the future. The computer industry will always need program architects, protocol designers, testers, PHDs to design algorithms, etc. None of those people are in your list of "core stuff". While the skills behind each of those professions will change drastically in the next ten years, the professions themselves will still be needed. No, these people are not a huge population, but it is still plenty large enough to soak up the entire compentent output of every single US CS school for the forseeable future.
Err, that sticker is usually on the PS itself, not the chassis as a whole. It is perfectly reasonable to want to swap out the supply, which is a modular part with no warning stickers telling you not to remove it.
Ok, lets go over this years salary changes slowly...
Everybody permanently gets a 3% raise. In return, variable pay went down 3-4%. That means, that you come out more-or-less even. The change was made because most employees would much rather have a larger base pay, and less of my money dependent on sales drones not selling enough.
Here's a cool tip for you. When wiring up electrical outlets, if you reverse the hot and the neutral lines, you actually create a voltage potential between the outlets. I discovered this because I touched the stove and the refridgerator at the same time accidentally. I got a huge jolt, shook a bit, and called the land lord.
You don't just have mis-wired outlets. You also have a defective fridge or stove. The ground/chassis should NEVER be connected to the neutral line of the power circuit. (For exactly this reason.) This means that there is also a short between the power harness of your stove/fridge and the chassis.
All products in country X must meet that countries regulatory requirements. For instance, most industrialized countries each have their own local equivalent of the FCC, which certifies electronic equipment for use. Some countries (like Canada) require that the packaging be in one or more specific languages. The whole catalog may not be available because it is not profitable to create each product in a way that will satisfy worldwide requirements.
The U.S. websites won't ship abroad for many reasons other posters have cited. (Fraud, tax, import/export issues for individual orders, etc.) The abroad websites may not have enough resources to translate the entire product catalog, and maintain a full website for all of those products, (and in the case of computers) each of which has it's own country specific quirks. For instance, one piece of expensive equipment with which I am familiar has 17 different localized power cords, including one that is specific to the U.S. city of Chicago. A retail printer I know of has nine-separate hardware versions (to meet different regulations), including one that is only for Brazil. That is just the base hardware. That doesn't even include the localizing of the manuals, marketing materials, and packaging.
If you actually called your country's branch office, I suspect you would have no problem ordering just about anything it was legal to import. (For the right price of course.) I know that IBM has either a branch office or business partner assigned to EVERY country in which it is legal for a U.S. corporation to do business.
I believe he mis-understands what "on-demand" is all about. He is interpreting it as merely an "enterprise" version of SETI. "On-demand" involves a number of things, including instant provisioning of massive amounts of storage out of a central pool (in the same or multiple locations,depending on requirements), instant steps in CPU and I/O bandwidth, additional server nodes, etc. The SETI style of distributed computing indeed has very limited applications. Being able to quickly increase the size of your IT backend is a bit more useful, and profitable.
Try, just try, to actually GET 21.6GB/s from your external busses with heavy-duty database workloads. SCSI is simply a watered-down version of the OEMI protocol that IBM developed in the late 60's. TCP/IP is no better.
With SCSI, the processor goes out and sends a command to the SCSI controller requesting some small amount of data. The controller sends the request to the target, and the data flows. When the command is complete, the controller will interrupt the processor that sent the request, and patiently wait for the next command. The OS then thrashes through the interrupt processing, and figures out what the next data request will be. This process is repeated until all the data has been retrieved.
With OEMI, and it's successors, ESCON and FICON, things are much different. The processor, produces a list of commands that will retrieve ALL the data necessary for the given operation. Then, a single assembly instruction starts the program. Next, a dedicated "channel processor" takes over. Every last data retrieval command is executed and only when the ENTIRE task is complete is the processor interrupted.
Interrupt processing is expensive, and the S/360, and its successors were built to minimize that. For compute-intensive applications, mainframes suck. If what you are doing is number-crunching, there are not so many interrupts, and it isn't a problem. If what you are doing is performing trivial tasks (like integer math, searching, sorting, etc.) on a crap-load of data, interrupts suck.
Each system has it's own strengths. There are some applications that work best on mainframes, and others that work best on UNIX boxen. That is just the way things are.
Compressing to hard drive takes substantial CPU horsepower. Even a fast processor cannot compress and write to a drive at line rate. With enterprise tape drives, the compression is built into the drive.
No, I'm backing up databases, where the vast majority of IT data that needs backing up resides.2:1 backing up your desktop's hard drive is unrealistic, but for backing up real enterprise workloads, 2:1 is not unusual.
Oops... hit the wrong checkbox... didn't mean to post it as AC
"Most file formats are compressed"?!?!?! Maybe there are more comrpessed formats and maybe most of the data on your desktop are compressed, but the vast majority of data bytes in this world that need backing up are in databases, and those are most definately not comrpessed.
Also, no, you can't just go to the Sony website and order-one. These are industrial-strength drives and to buy one, you usually get one in a library, which is built by a OEM (or Sony). Each OEM is going to charge a different price, depending on the library features.
For a backup of say, the system mentioned in the article, the bandwidth required to back that system up over the internet would be truly a fortune. So, no, for large backups, you cannot cheaply move the data over the internet.
No, you have $150 tapes that hold 1 TB of IT data. They can be written to at 60MB/s. Tape is compact, requrires no power, it is light, transportable and sturdy. The only major drawback as a backup method is the cost of the drives. (Which gets paid off quickly.)
To backup a storage pool with under a couple of TB of storage, tape is indeed stupid. If what you need is truly massive amounts of storage that does not need to be accessed instantaneously, tape cannot be beat.
Right now, Sony is shipping Super-AIT tapes. The cartridges are about 3/8 of an inch thick, and each holds 500GB, before compression (which is integrated in the drive hardware). The drive can read or write at 30MB/s, before compression. With typical IT compression of 2:1, you get just under 60MB/s. The cartridge goes for about $150. Just try and get a terabyte of disk for that much. No, the drives aren't cheap, but they get paid off quickly.
Yes, disk is good if you need instant access to your backup, and for small installations of under a couple of TB, using disk backups make sense, but for larger data pools, tape is far more economical.
Also, as mentioned in the article, disk is terrible if you need off-site backups. In addition, a tape library consumes far less power, takes up less space, and produces less heat than a drive array of the same capacity.
Basically, the death of tape has been predicted for years, but it hasn't happened yet.
Yeah, and there is a spec for CSMA (i.e. passive hubs) for Gigabit Ethernet. Does it exist in actual products? No. Coax is specified in the Fibre Channel Specs, yet I have yet to see a single Coax or Twinax GBIC/SFP or HBA. If you find one, let me know.
When I said Twisted Pair, I meant RJ-45 terminated. Oops. I do know about the DB-9 and HSSDC copper cables.
Slashdot Mirror
Code of Federal Regulations, Title 14, Section 91, Paragraph 3, Subparagraph a:
"The pilot in command of an aircraft is directly responsible for, and is the final authority as to, the operation of that aircraft."
That one regulation gives a pilot great authority, and also great responsibility.
On the one hand, it means that the pilot can almost never place the blame on somebody else in the case of an accident. There are very few accidents that are not caused by pilot error. There are a few exceptions, but those are rare.
On the other hand, just a couple of sentences down in the regs, a pilot is explictly authorized to violate any regulation necessary in an emergency in order to ensure his aircraft can be operated safely. That means that he can ignore air traffic control, exceed his airplane's design limits, land anywhere, shut down his lights, fly right over the White House, and pretty much do anything necessary to prevent an emergency from becoming an accident.
For instance, if a previously uknown design defect causes control surface failure, than the pilot is not considered at fault, as long as there was nothing he could have done to prevent an accident. Accidents do occur. This wasn't one of them.
In this case, the pilot lost control of the aircraft while performing a routine operation. Yes, that operation involved more than flicking a finger, but it was routine, and should have been something he was proficient in before ever leaving the ground. Period. End of story.
(As a side note, in older cars, turning on the heat involved reaching underneath the dash. If you hit somebody while doing this, it would be 100% your fault. A fickle jury might think otherwise, but I guarantee the police report would be unabiguous about it.)
In the Cessna 152 I am training in, there is no place in the front of the plane for me to put the Pilot's Operating Handbook, which contains FAA-sanctioned emergency proceedures (among other things). The book is stored in a pouch behind the right seat. If I get in an accident because I couldn't access those proceedures quickly enough, tough. I should have prepared better by memorizing them in advance, or keeping a copy of the checklists in an easily accessible place. (In fact, I do keep a copy of the emergency checklists on my kneeboard.)
If I take off when the fuel gauge says I have a full load of gas, but I didn't verify it myself and I run out of gas, again, my fault. (And so the NTSB would rule.) I should have checked it by sticking my finger in the tank. No excuse. The fuel gauge maker isn't responsible for making sure I don't run out of gas, I am.
This is the way aviation works. This is the way the laws work. This is how the FAA works. This is the way pilot's think. I expect that if you described this accident to Mr. Denver the day before he bought that plane, he would have agreed with the NTSB.
From the NTSB accident report:
"The National Transportation Safety Board determines the probable cause of this accident was the pilot's diversion of attention from the operation of the airplane and his inadvertent application of right rudder that resulted in the loss of airplane control while attempting to manipulate the fuel selector handle. Also, the Board determines that the pilot's inadequate preflight planning and preparations, specifically his failure to refuel the airplane, was causal. The Board determines that the builder's decision to locate the unmarked fuel selector handle in a hard-to-access position, unmarked fuel quantity sight gauges, inadequate transition training by the pilot, and his lack of total experience in this type of airplane were factors in this accident."
In English, it was his fault. He screwed up his flying and took off with inadequate fuel to boot.
The design and location of the fuel selector were part of the accident, but not considered a cause of the accident. That means that if the "factors" were not there, the accident may not have occured, but it was the pilot's responsiblity to mitigate those factors. They were not the responsibility of the trainer, former owner, designer, or builder.
So says the NTSB, and so would agree any pilot I have ever met.
SirWired
Mr. Denver made several mistakes. Like almost all accidents, it was percipitated by a chain of events. If any "link" in the chain had been broken, the accident would not have occurred.
1) He ran one of his wing tanks dry. There is no excuse for running either tank completely dry. He should have had gas put in it before he took off. From the accident report, it appears that he only attempted a tank switch when one tank went dry, and the engine starved.
2) He did not practice switching fuel tanks sufficiently.
3) He did not manage to maintain control of the plane during this routine operation.
If he had not run a tank dry, he likely would not have had to rush and sloppily try to change the tanks, a manuver which he did not know how to do well.
In any case, the PILOT is responsible for the safe operation of the aircraft. Not the builder, not the mechanic, not the regulatory agency, not the owner, not the designer, not the flight instructor, not the weather forcaster, the PILOT. If the PILOT can't operate the plane safely, and deal with a design that is not optimal for him, he should not leave the ground. Period. End of Discussion. No excuses.
One of the most important Federal Aviation Regulations (Pilot In Command Responsibility) that is drilled into the head of every single pilot is that there is NO EXCUSE to not operating your craft in a safe manner.
There is NO EXCUSE for one of the fuel tanks running dry. Not even a fuel leak.
There is NO EXCUSE for being unable to operate the tank switch valve. If it wasn't in a position he could safely operate it, he shouldn't have flown the plane.
There is NO EXCUSE for inadverdently pushing the controls in the wrong direction.
He crashed his airplane, and it was nobody's fault but his own.
SirWired
I believe he had been indicted years ago. It just took him a while to be caught.
SirWired
Well, as an IBM shill, there are a couple of solutions I could mention that Big Blue offers: (Will these meet your specific requirements? I don't know. I'm just a lowly support engineer.)
1) SAN File System. Your filer (actually the SAN File System nodes) handle requests for data, but the data itself travels directly over the SAN to your clients. (Which obviously need SAN connections.)
2) GPFS. (General Parallel File System) Clients available for AIX and Linux. A pretty decent clustering filesystem, with fairly low overhead and excellent throughput. Somewhat popular in supercomputing applications.
IBM got out of HW,
Err... what planet are you from? IBM no longer sells PC's to retail customers at stores. Hardware in general remains about 35-40% of the business. For IBM, that translates to about 30 Billion dollars a year. It makes Sun look positively puny.
Even in PC's IBM sells more laptops to businesses than anyone else. IBM sells more servers than any other company by a significant amount. That is all serious money.
SirWired
Err... head over to your local University library, and check out the last couple of years of the "IBM Journal of Research and Development" and the "IBM Systems Journal". There is plenty of groundbreaking research going on in operating systems, testing, development, processor architecture, packaging, semiconductor manufacture, security, encryption, collaboration, end-user interafaces, language and compiler development, storage architecture, etc.
Nobody can predict which of those (if any) will become the "big thing". Not me, not you, and unfortunately, not even the scientists at IBM Research. However, the significant dollars poured into research should be good for something.
As a side note, you mention lasers... IBM owns the patent for the Excimer laser used in LASIK.
SirWired
Di-Hydrogen Monoxide isn't the proper name for water. That would imply a H2 ion bonded to a O ion. IIRC, this is not correcct. It's been ten years since I took chemistry, but shouldn't it really be Hydrogen Hydroxide? (H bonded to OH)
SirWired
Mainframes do I/O using a "Channel Program". This is a sequence of commands assembled by your system software to perform an I/O task. The task may be made up of hundreds of I/O commands. (which use the Single-Byte-Command-Set architecture.) After the I/O program is built, a single CPU instruction (start subchannel) begins I/O program execution. The processor is not interrupted until the execution of the program is completed. A "channel processor" (these days ususally a PowerPC chip) handles all the actual work.
SCSI is loosely based on the architecture, but does not have the concept of a channel program, so it has none of the CPU conservation benefits.
The advantage of this whole setup is that the box can be doing fantastic amounts of I/O streams simultaneously, since the CPUs do not have to coordinate all of it. We all know that Disk is WAAAYYY slower than memory, so this way you can be doing useful things with a large number of I/O paths until you finally exhuast your quite substantial processor resources. UNIX-style architectures bog down at far slower I/O loads.
The disadvantage is that it blows for charachter-by-character interactive (i.e. Telnet) use, due to the overhead involved in creating the channel program. Transactions actually do okay, as the overhead isn't that terrible, compared with the work usually required to process the transaction itself.
The other disadvantage is you need an expensive box to just get an admin console, since the ONLY way to get I/O in and out is this huge channel system, a RS-232 just doesn't work. (These days, it is an xSeries Pizza Box w/ an ESCON card. It used to be this behemoth about the size of a dorm-room refrigerator.)
SirWired
Ahhh... the optimistic utopia of fully automated systems. The day they can fully automate network design and troubleshooting is they day that Bill Gates takes over the Linux kernel from Linus.
While things get simpler and simpler for end users and administrators, the back-end protocols to run all this automated spiffiness don't get any easier. I work in Storage Area Network troubleshooting and I spend my days staring at protocol traces, scrutinizing poorly drawn network diagrams, and poring through dense standards documents. This isn't going to change any time soon. While the protocols I work on today (Fibre Channel and SCSI) may be gone in ten years, something no less complicated will take its place.
User administration will become easier and easier as time goes on, and those skills will become less valuable. Hard-core troubleshooting and design are skills that can only be had by "real" engineers, and will always be useful.
IT programming (programming done in IT departments) has always been a "dead" field, as the VAST majority of it requires nothing more than an associates degree. DB apps and churning out SQL all day doesn't require a 4yr college degree. This is the stuff that is being outsourced to India right now. (Along with low-end tech support, but that is almost beneath mention.) This has been the case for a couple of decades, and in fact, is what the majority of programmers do for a living. This stuff has NEVER required a college degree.
The real innovation, and fun, happens at the companies that make all those building blocks, and they aren't going to need an appreciably different mix of engineers in the future. The computer industry will always need program architects, protocol designers, testers, PHDs to design algorithms, etc. None of those people are in your list of "core stuff". While the skills behind each of those professions will change drastically in the next ten years, the professions themselves will still be needed. No, these people are not a huge population, but it is still plenty large enough to soak up the entire compentent output of every single US CS school for the forseeable future.
SirWired
Dry ice is solid Carbon Dioxide, not Nitrogen.
Err, that sticker is usually on the PS itself, not the chassis as a whole. It is perfectly reasonable to want to swap out the supply, which is a modular part with no warning stickers telling you not to remove it.
Ok, lets go over this years salary changes slowly...
Everybody permanently gets a 3% raise. In return, variable pay went down 3-4%. That means, that you come out more-or-less even. The change was made because most employees would much rather have a larger base pay, and less of my money dependent on sales drones not selling enough.
SirWired
LESSON 1: Polarity
Here's a cool tip for you. When wiring up electrical outlets, if you reverse the hot and the neutral lines, you actually create a voltage potential between the outlets. I discovered this because I touched the stove and the refridgerator at the same time accidentally. I got a huge jolt, shook a bit, and called the land lord.
You don't just have mis-wired outlets. You also have a defective fridge or stove. The ground/chassis should NEVER be connected to the neutral line of the power circuit. (For exactly this reason.) This means that there is also a short between the power harness of your stove/fridge and the chassis.
SirWired
All products in country X must meet that countries regulatory requirements. For instance, most industrialized countries each have their own local equivalent of the FCC, which certifies electronic equipment for use. Some countries (like Canada) require that the packaging be in one or more specific languages. The whole catalog may not be available because it is not profitable to create each product in a way that will satisfy worldwide requirements.
The U.S. websites won't ship abroad for many reasons other posters have cited. (Fraud, tax, import/export issues for individual orders, etc.) The abroad websites may not have enough resources to translate the entire product catalog, and maintain a full website for all of those products, (and in the case of computers) each of which has it's own country specific quirks. For instance, one piece of expensive equipment with which I am familiar has 17 different localized power cords, including one that is specific to the U.S. city of Chicago. A retail printer I know of has nine-separate hardware versions (to meet different regulations), including one that is only for Brazil. That is just the base hardware. That doesn't even include the localizing of the manuals, marketing materials, and packaging.
If you actually called your country's branch office, I suspect you would have no problem ordering just about anything it was legal to import. (For the right price of course.) I know that IBM has either a branch office or business partner assigned to EVERY country in which it is legal for a U.S. corporation to do business.
SirWired
I believe he mis-understands what "on-demand" is all about. He is interpreting it as merely an "enterprise" version of SETI. "On-demand" involves a number of things, including instant provisioning of massive amounts of storage out of a central pool (in the same or multiple locations,depending on requirements), instant steps in CPU and I/O bandwidth, additional server nodes, etc. The SETI style of distributed computing indeed has very limited applications. Being able to quickly increase the size of your IT backend is a bit more useful, and profitable.
SirWired
Try, just try, to actually GET 21.6GB/s from your external busses with heavy-duty database workloads. SCSI is simply a watered-down version of the OEMI protocol that IBM developed in the late 60's. TCP/IP is no better.
With SCSI, the processor goes out and sends a command to the SCSI controller requesting some small amount of data. The controller sends the request to the target, and the data flows. When the command is complete, the controller will interrupt the processor that sent the request, and patiently wait for the next command. The OS then thrashes through the interrupt processing, and figures out what the next data request will be. This process is repeated until all the data has been retrieved.
With OEMI, and it's successors, ESCON and FICON, things are much different. The processor, produces a list of commands that will retrieve ALL the data necessary for the given operation. Then, a single assembly instruction starts the program. Next, a dedicated "channel processor" takes over. Every last data retrieval command is executed and only when the ENTIRE task is complete is the processor interrupted.
Interrupt processing is expensive, and the S/360, and its successors were built to minimize that. For compute-intensive applications, mainframes suck. If what you are doing is number-crunching, there are not so many interrupts, and it isn't a problem. If what you are doing is performing trivial tasks (like integer math, searching, sorting, etc.) on a crap-load of data, interrupts suck.
Each system has it's own strengths. There are some applications that work best on mainframes, and others that work best on UNIX boxen. That is just the way things are.
SirWired
Some media... [are] still MUCH faster than tape at current speeds.
Huh? Please point me to the optical drive that can handle write speeds of 70MB/s (using on-board compression). Or 35MB/s for pre-compressed data.
Compressing to hard drive takes substantial CPU horsepower. Even a fast processor cannot compress and write to a drive at line rate. With enterprise tape drives, the compression is built into the drive.
No, I'm backing up databases, where the vast majority of IT data that needs backing up resides.2:1 backing up your desktop's hard drive is unrealistic, but for backing up real enterprise workloads, 2:1 is not unusual.
Oops... hit the wrong checkbox... didn't mean to post it as AC
"Most file formats are compressed"?!?!?! Maybe there are more comrpessed formats and maybe most of the data on your desktop are compressed, but the vast majority of data bytes in this world that need backing up are in databases, and those are most definately not comrpessed.
Also, no, you can't just go to the Sony website and order-one. These are industrial-strength drives and to buy one, you usually get one in a library, which is built by a OEM (or Sony). Each OEM is going to charge a different price, depending on the library features.
Sony. Super-AIT.
For a backup of say, the system mentioned in the article, the bandwidth required to back that system up over the internet would be truly a fortune. So, no, for large backups, you cannot cheaply move the data over the internet.
No, you have $150 tapes that hold 1 TB of IT data. They can be written to at 60MB/s. Tape is compact, requrires no power, it is light, transportable and sturdy. The only major drawback as a backup method is the cost of the drives. (Which gets paid off quickly.)
To backup a storage pool with under a couple of TB of storage, tape is indeed stupid. If what you need is truly massive amounts of storage that does not need to be accessed instantaneously, tape cannot be beat.
Right now, Sony is shipping Super-AIT tapes. The cartridges are about 3/8 of an inch thick, and each holds 500GB, before compression (which is integrated in the drive hardware). The drive can read or write at 30MB/s, before compression. With typical IT compression of 2:1, you get just under 60MB/s. The cartridge goes for about $150. Just try and get a terabyte of disk for that much. No, the drives aren't cheap, but they get paid off quickly.
Yes, disk is good if you need instant access to your backup, and for small installations of under a couple of TB, using disk backups make sense, but for larger data pools, tape is far more economical.
Also, as mentioned in the article, disk is terrible if you need off-site backups. In addition, a tape library consumes far less power, takes up less space, and produces less heat than a drive array of the same capacity.
Basically, the death of tape has been predicted for years, but it hasn't happened yet.
Yeah, and there is a spec for CSMA (i.e. passive hubs) for Gigabit Ethernet. Does it exist in actual products? No. Coax is specified in the Fibre Channel Specs, yet I have yet to see a single Coax or Twinax GBIC/SFP or HBA. If you find one, let me know.
When I said Twisted Pair, I meant RJ-45 terminated. Oops. I do know about the DB-9 and HSSDC copper cables.