propofol is already one of the most widely used anesthetics (if i remember correctly, its actually a hyponotic, but thats beside the point). Using a mixture of gases and injection reduces the dosage required for any individual drug drastically, meaning less of a reaction to any given drug. It spreads it around so to speak.
Not why. In surgery, some drugs are "background" drugs to keep you always anesthesized. Some are stronger and shorter-acting, and are meant to keep you actually half-dead, requiring closer monitoring. But the background drugs ensure that you're still on something when they back off of the serious ones.
Nitrous and Propofol are in the 'background' drug category. Longer acting and less strong.
So like 99% of the nitrous you breath in, you end up breathing back out
You waste your $5 that way. Take small breaths, mix it with some air so you can hold it it in longer. SIT DOWN before you fall down. Wrap the balloon end around your finger so you don't slip and lose any. Don't breathe out until you have to.
By your definition, there is hardly any mature code out in userland.
Of course not.
Name a nontrivial example of mature code in wide use anywhere today.
Not a single legacy system. Not a few lines of code in a huge application or OS. An actual complete mature application in use today. Name one.
It doesn't take quibbling over the definition of mature for this to be readily apparent. If you're finding bugs in it yourself, if bugs aren't fixed because there are higher priority bugs to fix - it isn't mature!
As long as the message is not addressed to "the person's telephone number", and it's also not an "electronic mail", it's legal. Instant messages seem OK, unless "electronic mail" is defined elsewhere to include them. Regardless, there's enough room in this law to devise an application for smartphones that allows you to communicate via typing without breaking the law.
(b) "Text messaging" means a communication in the form of electronic text or one or more electronic images sent by the actor from a telephone or computer to another person's telephone or computer by addressing the communication to the person's telephone number.
(c) except as provided in Subsection (3), uses a handheld wireless communication
55 device for text messaging or electronic mail communication while operating a moving motor
56 vehicle upon a highway in this state.
Phone records show that you sent a text message 15 seconds before the accident? It's pretty easy to prove, actually.
Plus all these phones have GPS in them these days. It won't be long before they know you were doing 60 mph when you sent that message.
It's possible now that your phone is reporting you every time you do this. You would have no way of knowing.
And if I sent a text message while stopped, pull out of a parking lot or away from a just-changed light, and am involved in an accident, why should the recent text message subject me to a lifetime of anal rape in a cage?
Previously, the Mythbusters (and other scientific studies) has shown that talking on a cell phone while driving is worse than driving while legally drunk. Texting is far more distracting than talking on a cell phone, so this legislation seems more than appropriate.
What could possibly be so vitally important that it has to be texted right now, yet not so important that you can't pull over to do it?
Are you sure it's safer to pull over rather than to stay on the road?
I think it's interesting how we lowered the "legally drunk" limit to a point where a person isn't even intoxicated when they're above the limit. And now that's the threshold for being excessively distracted.
Most filtered water is not better nor worse than tap water. A lot of the bottling facilities get their water from municipal water systems!
Well the taste is certainly different. And if the tap water tastes so bad that I can't drink it, I'm probably not going to get a sufficient amount of water.
And although our water system repeatedly tells us that brown muddy water is "safe to drink", I really find this impossible to believe.
The world of SPARC has changed a LOT since the days of the E10K. First, the high end server line went to the 15K/25K which is much more reliable though at 5 years old our 15Ks are starting to occasionally have memory failures. Who needs a huge machine that you can scale? Um, three words: Oracle Data Warehouse. Think billion-row joins on multi-terabyte databases.
Oviously this is workload dependent, but I've seen the workload you describe succeed on an HP DL580 G5 with Equallogic ISCSI storage. Also, Oracle RAC makes a lot more sense and actually costs a reasonable amount when compared to an E15k.
Why? Fraud detection through data mining is one application. There's a whole world of High End Scientific computing out there. True, much of that has gone to distributed parallel computing but some applications want one big machine rather than a lot of little ones.
Oracle's not one. They'll push you towards RAC rather than an E15k.
The CoolThreads machines aren't quite as fast per-core as the fastest Ultra IV (1.4 vs 1.8 GHz) but for a modest price you get a LOT of them:
Here's my problem. Every time Sun tells me that their model is to deliver more cores at a slower speed, I'm stuck with the fact that I can buy more cores at a faster speed from HP or Dell. I'm stuck with applications that, while seemingly quite parallel, actually end up with single-CPU bottlenecks.
a 5240 is 128 CPU hardware threads of execution (2 chips) with 128GB RAM capacity.
Not 128 full CPUs, though. It's similar to Hyperthreading.
HP can deliver 128GB RAM in a 2U machine.
I'm extremely disappointed at the death of Sun, Sparc, and the fact that Solaris never had a chance to become a good OS (two novel features does not qualify). But when buying such expensive machines, businesses often want testing/benchmarking and facts.
They said the disk failure rates were lower on the Sun too, but I don't know by how much.
You should be aware that neither Intel nor Sun make disk drives. The most likely explanation for this is manufacturer lot variance, or just luck.
C//
The most likely explanation is the difference in how controllers handle a marginal drive. For example, 10 years ago it was rare to have a RAID solution that re-wrote a bad block rather than just failing out the whole drive.
I have pulled a lot of 'failed' drives out of RAID arrays to check the SMART data, and even in modern arrays, a good portion of those drives are mostly OK.
Sometimes it's a controller that is too quick to kick out a drive, other times it is a controller that decides a drive is no good if it occasionally freezes for a couple seconds. So I won't use the drive failure rate to determine which RAID array is better.
Also, vibration is quite significant (remember, all drives seek together in many setups), as is cooling.
When we went to Intel hardware, we would have needed a $250k Sun machine and $250k SAN storage to perform comparably to a $50k Intel machine including internal storage.
Thank you for posting some real facts about Sun hardware, performance, maintenance, and support. The Sun zealotry around here needs a balanced perspective.
Yah, fair and balanced, or it supports what you want to believe?
Are you telling me that you suspect I may have fabricated those performance comparisons?
I was actually generous. I included FusionIO cards in the cost I quoted, but not in the performance comparison. Adding those cards results in a solution that is so much faster, I did actually worry people would think it is a fabrication.
It's a niche product, doesn't and probably can't make enough money to support itself.
Openoffice was sadly never any good. It was never even good enough for them to have leapfrogging MS Office as a goal, they just had to play catch-up from years behind.
Look how much better Excel 2007 was than the previous versions. (I don't know what version exactly had the tremendous UI change). This looked like a new product, the usability was greatly enhanced. Any other spreadsheet manufacturer could have done this. All were so caught up in playing catch-up with Excel that they never thought to sit down and redesign a good portion of the UI.
My leaky memory says that 40% of Oracle's income (profit?) comes from Oracle on SPARC, and another 20% from Oracle on other Unix.
I did the migration of the last Oracle Sparc to Oracle Linux system at my previous employer a couple years ago. Before this migration, it had moved to Fujitsu from Sun several years previous. (Oracle on Linux just wasn't there yet, a high-performance 8-CPU Intel machine monopolizing a whole SAN for performance reasons was full of race conditions because driver developers never had seen a machine or storage that powerful).
Sun just couldn't compete. For Sparc stuff, we would have needed a $5 million machine to outperform the $500k Fujitsu. The diminishing returns from the supposedly scalable Sun systems meant we had to skip two entire product lines. Unfortunately we couldn't test the next level up, and our experience with the E10K (64 CPUs underperforming 12) was that Sun machines don't always scale like this.
When we went to Intel hardware, we would have needed a $250k Sun machine and $250k SAN storage to perform comparably to a $50k Intel machine including internal storage.
We gave Sun a really good chance to compete each time, everyone involved had a strong personal attachment to making it work and had not yet accepted that Sun had failed as a business. We allways talk about that initial revelation that if Sun couldn't compete for our setup, they probably couldn't compete anywhere unless this is just a temporary gap in the product offering.
The Sun machines were the least reliable compared to the Fujitsu and Intel solutions. Random were weekly events on the Sun machines (e.g. [456]500s, E10Ks), every few months on the Fujitsu Primepower 850 machines, and hasn't happened ONCE after two years on the Intel machines. And I'm comparing it to a MUCH larger population of Intel machines (we added dev, qa for each of app groups, sysadmins, DBAs, "yesterday's data" for support people, added another server for performance, and then duplicated the entire 5-server setup when we took over another business unit's almost identical application.
Although I could say in theory I miss being able to identify and replace failed hardware components easily, the reality is that the HP servers identify the part that caused a crash with a fault light most of the time. Sun needed a case to be opened with them to explain a complicated error. This changes the hardware fix from under 5 minutes - a datacenter tech can do it himself - to hours at minimum, and days if their support screws you around.
Being able to do the hardware replacement faster also means no second downtime to do the actual fix. And the confidence level from a clear fault light is huge versus a vendor's first line support that is known for lying when decoding an error message based on what looked "obvious", not based on the real complexities involved.
Actually the advantage is a fast backplane, not the memory. You may remember they bought the rights to the Cray asynchronous (really packet-switch-like) backplane quite a number of years ago, and have been expanding on it since.
Just to clarify - faster can mean higher bandwidth or lower latency. Sun really screwed themselves by building machines that had bad memory latency, but good bandwidth. Real-world appplications like transactional databases care more about memory latency than bandwidth.
Unfortunately said Pentium 4s also would fail 10x more often.
I don't know if you've worked (ie, have had direct administrative experience) with any of the larger Sun hardware such as E2900 and above, or even the Ex500's from back in the day, but if you did you'd also know that these servers have a knack for uptime and resiliency that x86 servers, even to this day, have never had. There was a reason for those higher costs.
At the same time, the application landscape changed to prefer scalability that allowed servers to be down without impacting the whole system. A single machine no longer was so important.
And up until a few years ago, people still went with Sun when they had a single important node.
The choice became between more servers that will crash slightly more often with less overall impact to the application, and more servers that will crash slighly less often.
Larger Sun hardware was never amazingly reliable anyway. What it did have over Intel hardware was a greater chance of indentifying why it crashed. An Intel machine that crashes randomly is not unheard of. I've only had a few Sun machines in my life that required me to change more than a couple parts to stop a random crashing problem. (Except the E10K and Ex500 series, which were particularly bad, and the 420R, which had bad hardware by design).
What happens when he has a typo or transcribes a column wrong and borks an entire train? Customers get angry because they miss expected connections and blame MTA not Schoenfeld.
This is bullshit. When they arrive at the station and their train is not there, usually they'll ask someone working there or start to complain to someone working there, at which point they'll get informed about the facts of life.
The problem is, a third party service is required to spread the information. In the UK, there are at least 10 different websites, where you can search, book and print anything you could possibly need (including a bus service or a taxi at the destination), and if you're on the move already, you can just send an SMS, and they'll text you back with the information you need.
I don't even understand the basis for the assumption that a mass transit provider is responsible for notifying riders of issues, providing a reliable up-to-date Internet-accessible map, etc.
Where did this come from? Has any mass-transit system actually been required by law to provide this, or beeen successfully sued for a failure to?
If the MTA does have such a responsibility, the courts won't look kindly upon them attacking a third party for taking over something that they are failing at. And if they don't have such a responsibility, the logic is...what..again?
The reason this bug was not detected sooner is that there was a check for a null pointer, which GCC optimized out! No one is checking for these kind of bugs - ones where analysis of the source code does not match what was compiled.
Time to re-read Reflections on Trusting Trust http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
And here's the quote that it wouldn't have happened if not for gcc:
http://lwn.net/Articles/342420/ Yet another link in the chain of failure is the removal of the null-pointer check by the compiler. This check would have stopped the attack, but GCC optimized it out on the theory that the pointer could not (by virtue of already having been dereferenced) be NULL. GCC (naturally) has a flag which disables that particular optimization; so, from now on, kernels will, by default, be compiled with the -fno-delete-null-pointer-checks flag. Given that NULL might truly be a valid pointer value in the kernel, it probably makes sense to disable this particular optimization indefinitely.
Every couple months I make a trivial change to an article to correct a serious error. Basically that's the only kind of change that motivates me to contribute - one where a few minutes of my time can help the world at large.
I have about a 50% revert rate. Usually it's for not citing sources. I fully support and agree with the rationale for preferring well-cited works. But when I'm replacing misinformation with what is correct, and the misinformation had no citation either, I can't see how that is a legitimate complaint.
Indeed, so far no one has posted the answer. And even though the total of the articles on wikipedia seems to be the most concise yet thorough explanation I can find, it fails to impart an actual understanding.
I doubt anyone can explain why the sky is blue in a way that doesn't involve a partial explanation. I doubt anyone here could explain it to a child in a way that the first child could explain it to another.
Just saying "Rayleigh scattering" doesn't answer it. Nor does copying the formula for it or being able to calculate the formula. None of this contributes to actually understanding it.
Baghdad is hands-down the most complicated airspace in the world, with multiple simultaneous UAVs at any given time, plus rotary-wing and fixed-wing assets flying constantly, some which are engaging in real-world operations, like dropping bombs. The deconfliction that needs to be done with assets that are collecting, assets that are targeting, assets picking up or dropping off troops, Iraqi commercial aircraft, VIP aircraft, ad nausem is just mind-boggling. The ATC there does this every day. Why is flying one UAV in the US that big a deal?
I don't think Iraq is significantly infected with NIMBYism.
An unmanned aircraft can survive much higher stresses than manned aircraft, so you could essentially make the unmanned aircraft drop out of the sky rather than collide. Maybe it can pull a 300G turn to avoid the collision. It's sensor package and avionics would react much faster than those controlled by humans.
Not according to FAA officials, says the article:
FAA officials also point out that TCAS computes collision avoidance solutions based on characteristics of manned aircraft, and does not incorporate unmanned aircraft's slower turn and climb rates in developing conflict solutions.
There were blatantly obvious signs of how much trouble we were in, as far back as the Enron scandal. A decent economist with a real education should have seen what was happening as much as 5 years before the Enron scandal broke.
What? I think this is a great example of the lack of understanding about economics that lets these professional US-based scammers get away with it.
If Enron is the earliest sign of the current financial disaster, then years are being forgotten.
How an economist could identify the Enron scam as it was being built up, that's just a strange statement. I'm not sure you even understand the nature of what was going on at Enron to make a statement like that.
Enron lied and left huge gaps in their SEC filings. You can't uncover lies by reading the same document more carefully. It's like proving or disproving the Bible with it as your only resource. And just because there's a gap in their explanation doesn't mean there's a massive business-destroying fraud going on. It's normal to leave big gaps in the quarterly/annual reports and balance sheets.
I also don't think you understand what an economist does...
You know, RedHat ES is only $349 a year. You could just migrate to RedHat ES and enjoy full support while still having the same features and environment as CentOS...
The support is useless in most cases. With 1000 servers, you're talking about a lot of money.
Slashdot Mirror
propofol is already one of the most widely used anesthetics (if i remember correctly, its actually a hyponotic, but thats beside the point). Using a mixture of gases and injection reduces the dosage required for any individual drug drastically, meaning less of a reaction to any given drug. It spreads it around so to speak.
Not why. In surgery, some drugs are "background" drugs to keep you always anesthesized. Some are stronger and shorter-acting, and are meant to keep you actually half-dead, requiring closer monitoring. But the background drugs ensure that you're still on something when they back off of the serious ones.
Nitrous and Propofol are in the 'background' drug category. Longer acting and less strong.
So like 99% of the nitrous you breath in, you end up breathing back out
You waste your $5 that way. Take small breaths, mix it with some air so you can hold it it in longer. SIT DOWN before you fall down. Wrap the balloon end around your finger so you don't slip and lose any. Don't breathe out until you have to.
By your definition, there is hardly any mature code out in userland.
Of course not.
Name a nontrivial example of mature code in wide use anywhere today.
Not a single legacy system. Not a few lines of code in a huge application or OS. An actual complete mature application in use today. Name one.
It doesn't take quibbling over the definition of mature for this to be readily apparent. If you're finding bugs in it yourself, if bugs aren't fixed because there are higher priority bugs to fix - it isn't mature!
As long as the message is not addressed to "the person's telephone number", and it's also not an "electronic mail", it's legal. Instant messages seem OK, unless "electronic mail" is defined elsewhere to include them. Regardless, there's enough room in this law to devise an application for smartphones that allows you to communicate via typing without breaking the law.
(b) "Text messaging" means a communication in the form of electronic text or one or more electronic images sent by the actor from a telephone or computer to another person's telephone or computer by addressing the communication to the person's telephone number.
http://le.utah.gov/~2009/bills/hbillint/hb0290s01.htm
(c) except as provided in Subsection (3), uses a handheld wireless communication
55 device for text messaging or electronic mail communication while operating a moving motor
56 vehicle upon a highway in this state.
Phone records show that you sent a text message 15 seconds before the accident? It's pretty easy to prove, actually.
Plus all these phones have GPS in them these days. It won't be long before they know you were doing 60 mph when you sent that message.
It's possible now that your phone is reporting you every time you do this. You would have no way of knowing.
And if I sent a text message while stopped, pull out of a parking lot or away from a just-changed light, and am involved in an accident, why should the recent text message subject me to a lifetime of anal rape in a cage?
Previously, the Mythbusters (and other scientific studies) has shown that talking on a cell phone while driving is worse than driving while legally drunk. Texting is far more distracting than talking on a cell phone, so this legislation seems more than appropriate.
What could possibly be so vitally important that it has to be texted right now, yet not so important that you can't pull over to do it?
Are you sure it's safer to pull over rather than to stay on the road?
I think it's interesting how we lowered the "legally drunk" limit to a point where a person isn't even intoxicated when they're above the limit. And now that's the threshold for being excessively distracted.
Most filtered water is not better nor worse than tap water. A lot of the bottling facilities get their water from municipal water systems!
Well the taste is certainly different. And if the tap water tastes so bad that I can't drink it, I'm probably not going to get a sufficient amount of water.
And although our water system repeatedly tells us that brown muddy water is "safe to drink", I really find this impossible to believe.
The world of SPARC has changed a LOT since the days of the E10K. First, the high end server line went to the 15K/25K which is much more reliable though at 5 years old our 15Ks are starting to occasionally have memory failures. Who needs a huge machine that you can scale? Um, three words: Oracle Data Warehouse. Think billion-row joins on multi-terabyte databases.
Oviously this is workload dependent, but I've seen the workload you describe succeed on an HP DL580 G5 with Equallogic ISCSI storage. Also, Oracle RAC makes a lot more sense and actually costs a reasonable amount when compared to an E15k.
Why? Fraud detection through data mining is one application. There's a whole world of High End Scientific computing out there. True, much of that has gone to distributed parallel computing but some applications want one big machine rather than a lot of little ones.
Oracle's not one. They'll push you towards RAC rather than an E15k.
The CoolThreads machines aren't quite as fast per-core as the fastest Ultra IV (1.4 vs 1.8 GHz) but for a modest price you get a LOT of them:
Here's my problem. Every time Sun tells me that their model is to deliver more cores at a slower speed, I'm stuck with the fact that I can buy more cores at a faster speed from HP or Dell. I'm stuck with applications that, while seemingly quite parallel, actually end up with single-CPU bottlenecks.
a 5240 is 128 CPU hardware threads of execution (2 chips) with 128GB RAM capacity.
Not 128 full CPUs, though. It's similar to Hyperthreading.
HP can deliver 128GB RAM in a 2U machine.
I'm extremely disappointed at the death of Sun, Sparc, and the fact that Solaris never had a chance to become a good OS (two novel features does not qualify). But when buying such expensive machines, businesses often want testing/benchmarking and facts.
They said the disk failure rates were lower on the Sun too, but I don't know by how much.
You should be aware that neither Intel nor Sun make disk drives. The most likely explanation for this is manufacturer lot variance, or just luck.
C//
The most likely explanation is the difference in how controllers handle a marginal drive. For example, 10 years ago it was rare to have a RAID solution that re-wrote a bad block rather than just failing out the whole drive.
I have pulled a lot of 'failed' drives out of RAID arrays to check the SMART data, and even in modern arrays, a good portion of those drives are mostly OK.
Sometimes it's a controller that is too quick to kick out a drive, other times it is a controller that decides a drive is no good if it occasionally freezes for a couple seconds. So I won't use the drive failure rate to determine which RAID array is better.
Also, vibration is quite significant (remember, all drives seek together in many setups), as is cooling.
When we went to Intel hardware, we would have needed a $250k Sun machine and $250k SAN storage to perform comparably to a $50k Intel machine including internal storage.
Thank you for posting some real facts about Sun hardware, performance, maintenance, and support. The Sun zealotry around here needs a balanced perspective.
Yah, fair and balanced, or it supports what you want to believe?
Are you telling me that you suspect I may have fabricated those performance comparisons?
I was actually generous. I included FusionIO cards in the cost I quoted, but not in the performance comparison. Adding those cards results in a solution that is so much faster, I did actually worry people would think it is a fabrication.
It's a niche product, doesn't and probably can't make enough money to support itself.
Openoffice was sadly never any good. It was never even good enough for them to have leapfrogging MS Office as a goal, they just had to play catch-up from years behind.
Look how much better Excel 2007 was than the previous versions. (I don't know what version exactly had the tremendous UI change). This looked like a new product, the usability was greatly enhanced. Any other spreadsheet manufacturer could have done this. All were so caught up in playing catch-up with Excel that they never thought to sit down and redesign a good portion of the UI.
What a morale destroyer this must have been.
My leaky memory says that 40% of Oracle's income (profit?) comes from Oracle on SPARC, and another 20% from
Oracle on other Unix.
I did the migration of the last Oracle Sparc to Oracle Linux system at my previous employer a couple years ago. Before this migration, it had moved to Fujitsu from Sun several years previous. (Oracle on Linux just wasn't there yet, a high-performance 8-CPU Intel machine monopolizing a whole SAN for performance reasons was full of race conditions because driver developers never had seen a machine or storage that powerful).
Sun just couldn't compete. For Sparc stuff, we would have needed a $5 million machine to outperform the $500k Fujitsu. The diminishing returns from the supposedly scalable Sun systems meant we had to skip two entire product lines. Unfortunately we couldn't test the next level up, and our experience with the E10K (64 CPUs underperforming 12) was that Sun machines don't always scale like this.
When we went to Intel hardware, we would have needed a $250k Sun machine and $250k SAN storage to perform comparably to a $50k Intel machine including internal storage.
We gave Sun a really good chance to compete each time, everyone involved had a strong personal attachment to making it work and had not yet accepted that Sun had failed as a business. We allways talk about that initial revelation that if Sun couldn't compete for our setup, they probably couldn't compete anywhere unless this is just a temporary gap in the product offering.
The Sun machines were the least reliable compared to the Fujitsu and Intel solutions. Random were weekly events on the Sun machines (e.g. [456]500s, E10Ks), every few months on the Fujitsu Primepower 850 machines, and hasn't happened ONCE after two years on the Intel machines. And I'm comparing it to a MUCH larger population of Intel machines (we added dev, qa for each of app groups, sysadmins, DBAs, "yesterday's data" for support people, added another server for performance, and then duplicated the entire 5-server setup when we took over another business unit's almost identical application.
Although I could say in theory I miss being able to identify and replace failed hardware components easily, the reality is that the HP servers identify the part that caused a crash with a fault light most of the time. Sun needed a case to be opened with them to explain a complicated error. This changes the hardware fix from under 5 minutes - a datacenter tech can do it himself - to hours at minimum, and days if their support screws you around.
Being able to do the hardware replacement faster also means no second downtime to do the actual fix. And the confidence level from a clear fault light is huge versus a vendor's first line support that is known for lying when decoding an error message based on what looked "obvious", not based on the real complexities involved.
Actually the advantage is a fast backplane, not the memory. You may remember they bought the rights to the
Cray asynchronous (really packet-switch-like) backplane quite a number of years ago, and have been expanding on it since.
Just to clarify - faster can mean higher bandwidth or lower latency. Sun really screwed themselves by building machines that had bad memory latency, but good bandwidth. Real-world appplications like transactional databases care more about memory latency than bandwidth.
Unfortunately said Pentium 4s also would fail 10x more often.
I don't know if you've worked (ie, have had direct administrative experience) with any of the larger Sun hardware such as E2900 and above, or even the Ex500's from back in the day, but if you did you'd also know that these servers have a knack for uptime and resiliency that x86 servers, even to this day, have never had. There was a reason for those higher costs.
At the same time, the application landscape changed to prefer scalability that allowed servers to be down without impacting the whole system. A single machine no longer was so important.
And up until a few years ago, people still went with Sun when they had a single important node.
The choice became between more servers that will crash slightly more often with less overall impact to the application, and more servers that will crash slighly less often.
Larger Sun hardware was never amazingly reliable anyway. What it did have over Intel hardware was a greater chance of indentifying why it crashed. An Intel machine that crashes randomly is not unheard of. I've only had a few Sun machines in my life that required me to change more than a couple parts to stop a random crashing problem. (Except the E10K and Ex500 series, which were particularly bad, and the 420R, which had bad hardware by design).
That's the one thing that confuses me. He still hasn't turned over any passwords, right? Why not?
I don't know whether he is. But if he is supposed to, who is he supposed to turn them over to, and would this be legal?
What happens when he has a typo or transcribes a column wrong and borks an entire train? Customers get angry because they miss expected connections and blame MTA not Schoenfeld.
This is bullshit. When they arrive at the station and their train is not there, usually they'll ask someone working there or start to complain to someone working there, at which point they'll get informed about the facts of life.
The problem is, a third party service is required to spread the information. In the UK, there are at least 10 different websites, where you can search, book and print anything you could possibly need (including a bus service or a taxi at the destination), and if you're on the move already, you can just send an SMS, and they'll text you back with the information you need.
I don't even understand the basis for the assumption that a mass transit provider is responsible for notifying riders of issues, providing a reliable up-to-date Internet-accessible map, etc.
Where did this come from? Has any mass-transit system actually been required by law to provide this, or beeen successfully sued for a failure to?
If the MTA does have such a responsibility, the courts won't look kindly upon them attacking a third party for taking over something that they are failing at. And if they don't have such a responsibility, the logic is...what..again?
The reason this bug was not detected sooner is that there was a check for a null pointer, which GCC optimized out! No one is checking for these kind of bugs - ones where analysis of the source code does not match what was compiled.
Time to re-read Reflections on Trusting Trust http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
And here's the quote that it wouldn't have happened if not for gcc:
http://lwn.net/Articles/342420/
Yet another link in the chain of failure is the removal of the null-pointer check by the compiler. This check would have stopped the attack, but GCC optimized it out on the theory that the pointer could not (by virtue of already having been dereferenced) be NULL. GCC (naturally) has a flag which disables that particular optimization; so, from now on, kernels will, by default, be compiled with the -fno-delete-null-pointer-checks flag. Given that NULL might truly be a valid pointer value in the kernel, it probably makes sense to disable this particular optimization indefinitely.
Every couple months I make a trivial change to an article to correct a serious error. Basically that's the only kind of change that motivates me to contribute - one where a few minutes of my time can help the world at large.
I have about a 50% revert rate. Usually it's for not citing sources. I fully support and agree with the rationale for preferring well-cited works. But when I'm replacing misinformation with what is correct, and the misinformation had no citation either, I can't see how that is a legitimate complaint.
Indeed, so far no one has posted the answer. And even though the total of the articles on wikipedia seems to be the most concise yet thorough explanation I can find, it fails to impart an actual understanding.
I doubt anyone can explain why the sky is blue in a way that doesn't involve a partial explanation. I doubt anyone here could explain it to a child in a way that the first child could explain it to another.
Just saying "Rayleigh scattering" doesn't answer it. Nor does copying the formula for it or being able to calculate the formula. None of this contributes to actually understanding it.
Baghdad is hands-down the most complicated airspace in the world, with multiple simultaneous UAVs at any given time, plus rotary-wing and fixed-wing assets flying constantly, some which are engaging in real-world operations, like dropping bombs. The deconfliction that needs to be done with assets that are collecting, assets that are targeting, assets picking up or dropping off troops, Iraqi commercial aircraft, VIP aircraft, ad nausem is just mind-boggling. The ATC there does this every day. Why is flying one UAV in the US that big a deal?
I don't think Iraq is significantly infected with NIMBYism.
Actually, that's not too far from the truth.
An unmanned aircraft can survive much higher stresses than manned aircraft, so you could essentially make the unmanned aircraft drop out of the sky rather than collide. Maybe it can pull a 300G turn to avoid the collision. It's sensor package and avionics would react much faster than those controlled by humans.
Not according to FAA officials, says the article:
FAA officials also point out that TCAS computes collision avoidance solutions based on characteristics of manned aircraft, and does not incorporate unmanned aircraft's slower turn and climb rates in developing conflict solutions.
Heck with the way things are now, the Auto Pilot can nearly land a plane by itself.
The idea isn't too far off, but to an extent, we already have an "Auto flying" system currently in use.
Nearly land by itself? It's commonly done. The majority of landings for big commercial jets for sure.
Africa is a shit-hole because it is infested with niggers.
This is why the entire question of "reparations" for slavery offends me. If money changed hands to rebalance things, who owes who?
There were blatantly obvious signs of how much trouble we were in, as far back as the Enron scandal. A decent economist with a real education should have seen what was happening as much as 5 years before the Enron scandal broke.
What? I think this is a great example of the lack of understanding about economics that lets these professional US-based scammers get away with it.
If Enron is the earliest sign of the current financial disaster, then years are being forgotten.
How an economist could identify the Enron scam as it was being built up, that's just a strange statement. I'm not sure you even understand the nature of what was going on at Enron to make a statement like that.
Enron lied and left huge gaps in their SEC filings. You can't uncover lies by reading the same document more carefully. It's like proving or disproving the Bible with it as your only resource. And just because there's a gap in their explanation doesn't mean there's a massive business-destroying fraud going on. It's normal to leave big gaps in the quarterly/annual reports and balance sheets.
I also don't think you understand what an economist does...
You know, RedHat ES is only $349 a year. You could just migrate to RedHat ES and enjoy full support while still having the same features and environment as CentOS...
The support is useless in most cases. With 1000 servers, you're talking about a lot of money.