Oh, yes, and if the cell isn't defective, laptop-style Lithium ion batteries shouldn't experience thermal runaway until somewhere in the 250-300 degree Fahrenheit range. Even a sealed automobile in 125 degree outdoor heat won't get much hotter than about 150-160 degrees Fahrenheit.
Put simply, unless the battery is being charged at the time, a non-defective Lithium ion cell should never explode unless you toss it in an oven.
Actually, if the batteries vent their gas, the reactions stop cold. That's why some lithium ion batteries have pressure relief valves.
Also, are you sure about the hydrogen thing? I know lead acid and NiMH batteries vent hydrogen, and some lithium ion batteries vent HCN (hydrogen cyanide), which burns pretty easily, but I couldn't find anything about any of them venting hydrogen....
Try the inside of a parked car sitting out in the summer sun.
Uh, the inside of a car is hardly a natural environment.:-)
Besides, planes aren't made of glass, and this is talking about fires during flight, not on the ground. Most of the time, they're flying at 30,000 feet or so, where the ambient air temperature is well into the negative double digits (like fifty or sixty degrees below zero Fahrenheit).... The only way I can think of that they could get to 140 degrees would be if they did something insane like pressurizing the air without cooling it. And in that case, it would be way hotter than 140. In fact, it would make an excellent kiln.
I think you got the conversion math wrong. It's (9/5)C + 32, not 2C + 32.
According to answers.com, the highest natural temperature ever recorded on Earth was a mere 136 degrees Fahrenheit. Also, unless you're on the ground, it's gonna be a lot colder than that. For a cargo hold in flight, I've read that the temperatures typically range between about 30 degrees Fahrenheit and 70 degrees Fahrenheit---in other words, much colder than inside the passenger compartment, not hotter.
How hot are we talking about? The safe maximum operating temperature for discharging a Lithium ion battery is typically 140 degrees Fahrenheit. There's no place on Earth that gets that hot naturally....
The notion that heat in cargo holds might ignite laptop batteries is patently absurd unless the cargo hold is on fire. It's more accurate to say that heat from an actively failing battery can start nearby cells on fire, which is a great big "duh".
Lithium ion battery fires are usually caused by dendritic growth inside the cell. There's no good way to determine when this might occur short of scanning electron microscopy, and there is no safe temperature at which this is not a problem....
The only time heat is a factor in Lithium cell failure is typically during a charge cycle (or occasionally during a very fast discharge cycle), when temperatures shoot way up into the mid 100s Fahrenheit. If they go way outside that range, they can go through thermal runaway.
That said, the charge circuits in the battery packs normally make this impossible unless a cell is defective. They shut down in such a way that the pack cannot be charged if the cell voltage drops below a minimum threshold because the charge current required would be high enough to pose a fire risk. Similarly, they disable charging above a maximum threshold to keep the batteries from becoming overcharged.
In short, if these things are burning up in flight, the cells were defective to begin with, period, and odds are good that they were improperly charged, too. There's just no way the cargo hold of an airplane gets hot enough to be a problem unless one of the cells shorts out internally, at which point the temperature really doesn't matter much anyway.
Gather a panel of people with a typical level of knowledge in the field.
Ensure that none of them are aware of the invention.
Tell them the problem the invention is trying to solve.
Give them any building blocks used.
See if they can replicate the invention or a close approximation thereof.
If so, reject the patent.
The problem is that 99% of "inventions" are nothing of the sort. They're little more than ideas that are obvious as soon as you are told the problem that you're trying to solve, and the only reason they weren't invented decades earlier is that nobody was trying to solve that problem yet because the problem space itself did not exist.
For example, a patent on how to take bids via the Internet could not reasonably be invented prior to the Internet. But ask ten people how they would set up an auction site on the Internet, and even if they've never used eBay or heard people describe how it works, they'll still describe most of it pretty accurately. As such, it's obvious to even a nimrod who knows how the Internet works and wants to conduct auctions online. Since the core purpose of patents is to protect an inventor's exclusivity temporarily in exchange for publishing how something works instead of keeping it a trade secret, and since a patent on that concept would contribute nothing of consequence to the general understanding of technology, such a patent should be soundly rejected.
Further, any patent on any software technology that does not include the corresponding source code to demonstrate how something is done should be rejected. And again, if the source code is obvious once you've been told its inputs and expected outputs, the patent should similarly be rejected.
It should not be enough to be the first to think of doing something. The patent should at a minimum provide some significant insight that would not be obvious to a typical person who has been exposed to the problem. Most patents do not, and as such, most patents are junk.
IMHO, you should not be allowed to build a home outside a fire protection district in the first place unless you demonstrate that you can provide adequate fire protection yourself. It's reckless and irresponsible. That said, I can at least halfway accept it in Idaho, given the population density in many of those areas.
This isn't like that, though. We're not talking about somewhere out in the middle of nowhere. I grew up about ten minutes from there. It's within single-digit miles of three towns totaling about 30,000 people, give or take, including one of the University of Tennessee campuses. It's not city, mind you, but it certainly isn't out in the sticks. There's no place in that area that isn't within a few minutes from a town. Further, the firemen were already there responding to the next door neighbor, who had paid the protection fee, so no additional effort was required other than pointing the hose a different direction and staying there a little longer. The neighbor even volunteered to let them use his pool water, and the homeowner volunteered to pay the cost. No, this was just a case of spite, pure and simple. Obion County is one of the few counties in that region that lacks rural fire protection. There's really no excuse for it.
There's something truly ironic about residents in the volunteer state saying, "Sure, we'll volunteer, but only if you pay us." That's just messed up. Worse, this is the second time this has happened in South Fulton in just a couple of years. It would be nice if this is enough to light a fire under the a**es of the inept bureaucrats who let this happen, but I'm not holding my breath. I understand their fire chief was assaulted shortly thereafter over this, though, so maybe there's hope.
The City of South Fulton doesn't have the authority to issue fines to people who don't live in their town.
Sure, they do. It's a fee for services rendered at the person's request. The guy did offer to pay for them to put out the fire.
And the argument that there weren't hydrants is complete crap. Out in the county in Tennessee, houses with swimming pools are required to have pipes set up so that the fire department can pump the pool dry to obtain extra water (and most of the trucks carry water tanks anyway). You're never too far from a source of water, and the fire protection depends on that.
Also, maybe you missed that the next door neighbor had paid the fee, and called for the fire department to protect his house, sothe fire trucks were ALREADY THERE keeping that house from burning and simply stood by and WATCHED THE OTHER HOUSE BURN. There was no extra truck roll; there was no significant extra cost involved to the fire department. They just followed the lead of a bunch of bureaucrats who decided to "show him" for not paying his protection money. That's just one step shy of the freaking mafia. If the fire department were to... accidentally... set a few fires, it would complete the analogy....
The real problem here is that Tennessee tries to rely on a sales tax for almost all of the state's revenue, and in times like this, they get massively screwed by that overreliance. The result is that they don't have a proper state response fire program. Fire protection costs should have been part of his property taxes to the state/county, and the state/county should have had an agreement in place to reimburse whatever fire department was closest and was able to respond first. The fact that this is not the case is an egregious sign of gross incompetence on the part of everyone involved in setting fire protection policies at the city, count, and state levels.
It's truly mind boggling that in this modern day and age, there are people who do not enjoy even the most basic public safety protections that our government can afford its citizens. For shame, Tennessee.
The saddest thing is that this is what many libertarian/tea party people seem to want. See how well non-socialist fire protection works? There's a reason we don't give people the choice of whether to pay for fire protection in most civilized parts of the world. It leads to horrific stories like this one.
Yes, but a targeted attack on computers requires hiring shady programmers for probably a few hundred grand. A targeted attack on mail-in ballots could be done by going to each city and hiring either one unscrupulous illegal immigrant with a car or a handful of not-so-bright kids with bicycles for a few bucks a day.
And with many counties in California having vote-by-mail rates as high as 50%, it's much easier to skew their results far enough to affect the election results without people noticing than it is to skew the votes of overseas military far enough with only their mere five or six percent of total votes to work with.
The difference is that if somebody hijacks the client's machine, that person's ballot might be forged. If somebody hijacks the servers, everyone's ballots might be forged. Also, a properly written (non-web) client can take a lot of steps to secure itself from malware corrupting the results, starting with not allowing keyboard input, using positional randomization to thwart any preprogrammed click event modification, and having dozens of internal consistency checks throughout the code to detect tampering, ending by sending a complete memory image of the process address space (instead of just sending the result data), signed with the user's key and letting the remote end do a final verification and throwing out any results from altered executables. Foolproof, no, but orders of magnitude harder to compromise than even the best web clients (which are inherently a joke, security-wise).
Of course, to be secure, we would need a national public key infrastructure in which people could preregister their public keys used for signing the ballots... the lack of which is just one of the many reasons that vote-by-electronic-ballot isn't going to be all that secure. On the flip side, neither is vote-by-mail. Someone could easily tamper with the ballot or even intercept it, fill it out, and send it in, and many people would never even notice. And since they're sent out on the same day... a guy with a pickup truck driving from mailbox to mailbox is really not that improbable an attack vector.
One of the articles mentioned that some browsers submitted blank forms because they don't support inline PDF forms. Who, exactly, thought that using PDF was a good idea? The whole point of the web is that it provides layout standards. Why even bother using a web browser if you're just going to try to hack around it by using a completely different content format, PDF, shoved in using browser plug-ins. It might has well have been Flash. Use the web or do not. There is no halfway.
And of course, their servers were obviously insecure, as evidenced by someone managing to alter content on the servers.
What does all this tell us? Well, it tells us that:
For anything approaching secure content delivery, the actual content (the HTML pages, the javascript files, etc.) must be signed prior to installation on the servers, not signed by the servers that provide it.
Web-based clients lack the infrastructure to verify signatures on the content itself except for the signatures provided by the servers.
Web-based clients are therefore inherently insecure.
Not that this shouldn't have been anything less than obvious to anyone with even a basic understanding of computer security.... Real secure networks built on top of HTTP use client applications that verify signatures on the content that the servers provide, ensuring that it is legitimate before acting on it. This also, of course, requires that people obtain the client software in a secure fashion, which is a problem in and of itself, in much the same way that obtaining the client on-the-fly from a web server is a problem, and for precisely the same reason.
I'm curious for a similar reason. MythTV, despite supporting multiple tuner types, doesn't fully support multiple tuner types at once (you can't create recording profiles for anything but the first device), so my HD-PVR is stuck recording at the default: 1080i with about 9Mbps average data rate, baseline profile. It is right up against the bounds of what is practical to play back without GPU acceleration, and even then, it sucks up between 1.25 and 1.5 cores of a 2.25 GHz Core 2 Duo.
BTW, if anybody knows a hack to either get proper second tuner profile support in MythTV or to work around the lack thereof, let me know. This one megabyte per second stuff is for the birds.
Except that embryonic stem cell lines typically come from discarded in vitro embryos, not abortion. So really you're just going to see the tissue discarded instead of being used for medical research. Not that this is really any worse, but it isn't significantly better as you seem to believe.
Still, in my mind, the notion of true embryonic stem cell research always seemed... well, nuts, to put it mildly. You're talking about taking cells from one organism and trying to use them to repair/replace tissue in another organism. Yes, we've come a long way when it comes to anti-rejection drugs, but at some point you really have to step back and say to yourself, "There must be a more rational way to proceed."
Ostensibly, if this problem were refactored into a work-unit-based API like GCD, then yes, there would be a thread to manage the queues, and it would hop from core to core as needed, and the details would depend a lot on the thread scheduling algorithm, and the optimal number of cores would be equal to the maximum number of concurrent work units that might be available to run at any given time plus one for queue management, in which case that management thread would sit on its own core.
The real problem is that they didn't divide up the problem into dependency-free work units. At least in theory, if adding more cores slows down performance, then somebody wrote the code wrong. A slowdown means one of two things: either A. that somebody is depending on somebody else's computation but is sucking off cycles while it does so or that B. the problem is infinitely parallelizable but the time required to reassemble the final result ends up being a hard lower bound to the algorithm. Oh, or C. that they haven't properly separated input pages from output pages and the cache coherency overhead is killing them.
If the problem is A., then if work is divided properly, it should simply stop speeding up (provided that the kernel isn't doing something silly like ignoring processor affinity for the work threads or running into some limitation of the VM system or scheduler design) because it should not be possible to have more threads than there are work units available to run, and it should not be possible for work units to share data in a way that hurts performance. Unfortunately, most software isn't written this way.
If the problem is B., then it still isn't something the OS can really guess until the computation is done, at which point it is too late to do anything about it. It would be algorithm-dependent, and would basically be bounded by performance of the final series of memcpy operations or whatever at the end.
At that point, you're probably bounded by raw memory bandwidth more than anything else. Either way, the OS can't possibly guess whether adding more cores will help because it can't know that the threads are all going to have to perform one high-contention serialization of the results at the end or whatever. Maybe the OS could provide some services to help the application author determine the optimal number of pieces to split the work into, but at least in my mind, it seems likely that it's just too algorithm-dependent for the responsibility to fall anywhere but on the app writer at that point.
To give an analogy, imagine that you are building a wall. You have a brick layer and ten servants to carry concrete blocks, each of whom can carry only one block at a time. You upgrade to thirty younger, smaller servants, but each can now carry only a block of half the size. So you've increased the rate at which the blocks get there by half, but you've now made twice as much work for the brick layer putting it together, and since the entire task is still serialized on the single brick layer, performance drops in that step. At some point, if you keep decreasing the size of the blocks and increasing the number of workers, the extra time that the brick layer takes at the end cancels out the time saved in moving the blocks, and beyond that point, the total construction time starts to get longer again. This is not at all an unusual situation in computer science. Many problems end with certain tasks that can't be parallelized very easily or that become progressively less parallelizable as the data trickles from the leaves of some sort of dependency tree to the root.
Now imagine that the brick layer won't arrive until the servants have moved all the bricks or blocks. An outside observer looking only at the bricks would see that more blocks are getting there faster and will naively assume that the task will get done faster with more pieces. That's the extent to which the OS can realistically have insight into the process; it can only see what is happening, not what will eventually happen. T
False. Equipment fails, and a crash at 120 has four times the energy of a crash at 60, not double. We have the speed limits we have because they have been statistically shown to decrease deaths.
Actually, the statistics really don't show that. What you say was true back before seat belts and air bags. Now they're basically all about either traffic flow management or revenue. Less than 5% of all traffic accidents are caused by equipment failure, and even most of the remaining 5% can in many cases be avoided by minor changes, such as:
Mandate that all new tires sold be of the run-flat variety
Mandate tire pressure and temperature sensors to tell the car's guidance system to pull over to the side of the road in the event of a puncture or other high-risk situation. (Pressure sensors are already mandatory in the U.S.)
Mandate sensors that detect low brake pad thickness to warn drivers, followed by preventing the vehicle from operating when they wear beyond a certain point.
Make a basic axle check part of the biennial inspection process.
Heck, just getting rid of driver fatigue alone would cut accident rates by 30-50%.... That one change alone would completely overshadow any increase in deaths due to even quadrupling the number of deaths in the 5% of accidents that are caused by equipment failure.... Keep in mind that you're talking about quadrupling a rate that got smaller by a factor of 20, and that should put things back in the proper perspective.
But the mileage is a very real problem too. The most aerodynamic cars seem to get their best mileage around 80 mph, like my (past) 1989 240SX or my 1982 300SD. The rest get it around 55 or 60, like my 1992 F250. None of them get it at 120, nor ever will.
Gas mileage is at best a temporary concern. We'll be all-electric by then anyway, at which point it becomes a question of energy production, which does not inherently require fossil fuels.
Certainly. I/O in general is highly parallelizable because it involves working with individual chunks of data that have little or no dependency on any other data around them, at least up to the point where you have to have those packets assembled in order in an mbuf chain or whatever. At some point, ordering has to be enforced, and I'd expect this to become a bottleneck, though admittedly you could still parallelize throughput up to the point where you have one thread per open socket.
Slashdot Mirror
Oh, yes, and if the cell isn't defective, laptop-style Lithium ion batteries shouldn't experience thermal runaway until somewhere in the 250-300 degree Fahrenheit range. Even a sealed automobile in 125 degree outdoor heat won't get much hotter than about 150-160 degrees Fahrenheit.
Put simply, unless the battery is being charged at the time, a non-defective Lithium ion cell should never explode unless you toss it in an oven.
Actually, if the batteries vent their gas, the reactions stop cold. That's why some lithium ion batteries have pressure relief valves.
Also, are you sure about the hydrogen thing? I know lead acid and NiMH batteries vent hydrogen, and some lithium ion batteries vent HCN (hydrogen cyanide), which burns pretty easily, but I couldn't find anything about any of them venting hydrogen....
And I repeat: There's no place on Earth that gets that hot naturally.... A car is not natural.
Uh, the inside of a car is hardly a natural environment. :-)
Besides, planes aren't made of glass, and this is talking about fires during flight, not on the ground. Most of the time, they're flying at 30,000 feet or so, where the ambient air temperature is well into the negative double digits (like fifty or sixty degrees below zero Fahrenheit).... The only way I can think of that they could get to 140 degrees would be if they did something insane like pressurizing the air without cooling it. And in that case, it would be way hotter than 140. In fact, it would make an excellent kiln.
I think you got the conversion math wrong. It's (9/5)C + 32, not 2C + 32.
According to answers.com, the highest natural temperature ever recorded on Earth was a mere 136 degrees Fahrenheit. Also, unless you're on the ground, it's gonna be a lot colder than that. For a cargo hold in flight, I've read that the temperatures typically range between about 30 degrees Fahrenheit and 70 degrees Fahrenheit---in other words, much colder than inside the passenger compartment, not hotter.
How hot are we talking about? The safe maximum operating temperature for discharging a Lithium ion battery is typically 140 degrees Fahrenheit. There's no place on Earth that gets that hot naturally....
The notion that heat in cargo holds might ignite laptop batteries is patently absurd unless the cargo hold is on fire. It's more accurate to say that heat from an actively failing battery can start nearby cells on fire, which is a great big "duh".
Lithium ion battery fires are usually caused by dendritic growth inside the cell. There's no good way to determine when this might occur short of scanning electron microscopy, and there is no safe temperature at which this is not a problem....
The only time heat is a factor in Lithium cell failure is typically during a charge cycle (or occasionally during a very fast discharge cycle), when temperatures shoot way up into the mid 100s Fahrenheit. If they go way outside that range, they can go through thermal runaway.
That said, the charge circuits in the battery packs normally make this impossible unless a cell is defective. They shut down in such a way that the pack cannot be charged if the cell voltage drops below a minimum threshold because the charge current required would be high enough to pose a fire risk. Similarly, they disable charging above a maximum threshold to keep the batteries from becoming overcharged.
In short, if these things are burning up in flight, the cells were defective to begin with, period, and odds are good that they were improperly charged, too. There's just no way the cargo hold of an airplane gets hot enough to be a problem unless one of the cells shorts out internally, at which point the temperature really doesn't matter much anyway.
And, of course, the way it should work is this:
The problem is that 99% of "inventions" are nothing of the sort. They're little more than ideas that are obvious as soon as you are told the problem that you're trying to solve, and the only reason they weren't invented decades earlier is that nobody was trying to solve that problem yet because the problem space itself did not exist.
For example, a patent on how to take bids via the Internet could not reasonably be invented prior to the Internet. But ask ten people how they would set up an auction site on the Internet, and even if they've never used eBay or heard people describe how it works, they'll still describe most of it pretty accurately. As such, it's obvious to even a nimrod who knows how the Internet works and wants to conduct auctions online. Since the core purpose of patents is to protect an inventor's exclusivity temporarily in exchange for publishing how something works instead of keeping it a trade secret, and since a patent on that concept would contribute nothing of consequence to the general understanding of technology, such a patent should be soundly rejected.
Further, any patent on any software technology that does not include the corresponding source code to demonstrate how something is done should be rejected. And again, if the source code is obvious once you've been told its inputs and expected outputs, the patent should similarly be rejected.
It should not be enough to be the first to think of doing something. The patent should at a minimum provide some significant insight that would not be obvious to a typical person who has been exposed to the problem. Most patents do not, and as such, most patents are junk.
Yeah, but you've gotta admit that it's a really funny choice of words. Reminds me of a joke that I won't repeat....
IMHO, you should not be allowed to build a home outside a fire protection district in the first place unless you demonstrate that you can provide adequate fire protection yourself. It's reckless and irresponsible. That said, I can at least halfway accept it in Idaho, given the population density in many of those areas.
This isn't like that, though. We're not talking about somewhere out in the middle of nowhere. I grew up about ten minutes from there. It's within single-digit miles of three towns totaling about 30,000 people, give or take, including one of the University of Tennessee campuses. It's not city, mind you, but it certainly isn't out in the sticks. There's no place in that area that isn't within a few minutes from a town. Further, the firemen were already there responding to the next door neighbor, who had paid the protection fee, so no additional effort was required other than pointing the hose a different direction and staying there a little longer. The neighbor even volunteered to let them use his pool water, and the homeowner volunteered to pay the cost. No, this was just a case of spite, pure and simple. Obion County is one of the few counties in that region that lacks rural fire protection. There's really no excuse for it.
There's something truly ironic about residents in the volunteer state saying, "Sure, we'll volunteer, but only if you pay us." That's just messed up. Worse, this is the second time this has happened in South Fulton in just a couple of years. It would be nice if this is enough to light a fire under the a**es of the inept bureaucrats who let this happen, but I'm not holding my breath. I understand their fire chief was assaulted shortly thereafter over this, though, so maybe there's hope.
Maybe the GP is just defending a region in France....
Sure, they do. It's a fee for services rendered at the person's request. The guy did offer to pay for them to put out the fire.
And the argument that there weren't hydrants is complete crap. Out in the county in Tennessee, houses with swimming pools are required to have pipes set up so that the fire department can pump the pool dry to obtain extra water (and most of the trucks carry water tanks anyway). You're never too far from a source of water, and the fire protection depends on that.
Also, maybe you missed that the next door neighbor had paid the fee, and called for the fire department to protect his house, sothe fire trucks were ALREADY THERE keeping that house from burning and simply stood by and WATCHED THE OTHER HOUSE BURN. There was no extra truck roll; there was no significant extra cost involved to the fire department. They just followed the lead of a bunch of bureaucrats who decided to "show him" for not paying his protection money. That's just one step shy of the freaking mafia. If the fire department were to... accidentally... set a few fires, it would complete the analogy....
The real problem here is that Tennessee tries to rely on a sales tax for almost all of the state's revenue, and in times like this, they get massively screwed by that overreliance. The result is that they don't have a proper state response fire program. Fire protection costs should have been part of his property taxes to the state/county, and the state/county should have had an agreement in place to reimburse whatever fire department was closest and was able to respond first. The fact that this is not the case is an egregious sign of gross incompetence on the part of everyone involved in setting fire protection policies at the city, count, and state levels.
It's truly mind boggling that in this modern day and age, there are people who do not enjoy even the most basic public safety protections that our government can afford its citizens. For shame, Tennessee.
The saddest thing is that this is what many libertarian/tea party people seem to want. See how well non-socialist fire protection works? There's a reason we don't give people the choice of whether to pay for fire protection in most civilized parts of the world. It leads to horrific stories like this one.
Yes, but a targeted attack on computers requires hiring shady programmers for probably a few hundred grand. A targeted attack on mail-in ballots could be done by going to each city and hiring either one unscrupulous illegal immigrant with a car or a handful of not-so-bright kids with bicycles for a few bucks a day.
And with many counties in California having vote-by-mail rates as high as 50%, it's much easier to skew their results far enough to affect the election results without people noticing than it is to skew the votes of overseas military far enough with only their mere five or six percent of total votes to work with.
The difference is that if somebody hijacks the client's machine, that person's ballot might be forged. If somebody hijacks the servers, everyone's ballots might be forged. Also, a properly written (non-web) client can take a lot of steps to secure itself from malware corrupting the results, starting with not allowing keyboard input, using positional randomization to thwart any preprogrammed click event modification, and having dozens of internal consistency checks throughout the code to detect tampering, ending by sending a complete memory image of the process address space (instead of just sending the result data), signed with the user's key and letting the remote end do a final verification and throwing out any results from altered executables. Foolproof, no, but orders of magnitude harder to compromise than even the best web clients (which are inherently a joke, security-wise).
Of course, to be secure, we would need a national public key infrastructure in which people could preregister their public keys used for signing the ballots... the lack of which is just one of the many reasons that vote-by-electronic-ballot isn't going to be all that secure. On the flip side, neither is vote-by-mail. Someone could easily tamper with the ballot or even intercept it, fill it out, and send it in, and many people would never even notice. And since they're sent out on the same day... a guy with a pickup truck driving from mailbox to mailbox is really not that improbable an attack vector.
He's just afraid they'll take him literally when he says "f*** the children" and jail him for conspiracy to commit child rape.
Err.. it might as well have been Flash. Stupid typos.
One of the articles mentioned that some browsers submitted blank forms because they don't support inline PDF forms. Who, exactly, thought that using PDF was a good idea? The whole point of the web is that it provides layout standards. Why even bother using a web browser if you're just going to try to hack around it by using a completely different content format, PDF, shoved in using browser plug-ins. It might has well have been Flash. Use the web or do not. There is no halfway.
And of course, their servers were obviously insecure, as evidenced by someone managing to alter content on the servers.
What does all this tell us? Well, it tells us that:
Not that this shouldn't have been anything less than obvious to anyone with even a basic understanding of computer security.... Real secure networks built on top of HTTP use client applications that verify signatures on the content that the servers provide, ensuring that it is legitimate before acting on it. This also, of course, requires that people obtain the client software in a secure fashion, which is a problem in and of itself, in much the same way that obtaining the client on-the-fly from a web server is a problem, and for precisely the same reason.
I'm curious for a similar reason. MythTV, despite supporting multiple tuner types, doesn't fully support multiple tuner types at once (you can't create recording profiles for anything but the first device), so my HD-PVR is stuck recording at the default: 1080i with about 9Mbps average data rate, baseline profile. It is right up against the bounds of what is practical to play back without GPU acceleration, and even then, it sucks up between 1.25 and 1.5 cores of a 2.25 GHz Core 2 Duo.
BTW, if anybody knows a hack to either get proper second tuner profile support in MythTV or to work around the lack thereof, let me know. This one megabyte per second stuff is for the birds.
Yeah. In this day and age, what with time travel and all, heck, she might even be her own mother, and that might be her grandmother.
No, no, you send in gorillas to kill the snakes. Then, in the winter, the gorillas simply freeze to death....
I'd guess the odds are at least as good that it's the author's birthday.
Except that embryonic stem cell lines typically come from discarded in vitro embryos, not abortion. So really you're just going to see the tissue discarded instead of being used for medical research. Not that this is really any worse, but it isn't significantly better as you seem to believe.
Still, in my mind, the notion of true embryonic stem cell research always seemed... well, nuts, to put it mildly. You're talking about taking cells from one organism and trying to use them to repair/replace tissue in another organism. Yes, we've come a long way when it comes to anti-rejection drugs, but at some point you really have to step back and say to yourself, "There must be a more rational way to proceed."
Ostensibly, if this problem were refactored into a work-unit-based API like GCD, then yes, there would be a thread to manage the queues, and it would hop from core to core as needed, and the details would depend a lot on the thread scheduling algorithm, and the optimal number of cores would be equal to the maximum number of concurrent work units that might be available to run at any given time plus one for queue management, in which case that management thread would sit on its own core.
The real problem is that they didn't divide up the problem into dependency-free work units. At least in theory, if adding more cores slows down performance, then somebody wrote the code wrong. A slowdown means one of two things: either A. that somebody is depending on somebody else's computation but is sucking off cycles while it does so or that B. the problem is infinitely parallelizable but the time required to reassemble the final result ends up being a hard lower bound to the algorithm. Oh, or C. that they haven't properly separated input pages from output pages and the cache coherency overhead is killing them.
If the problem is A., then if work is divided properly, it should simply stop speeding up (provided that the kernel isn't doing something silly like ignoring processor affinity for the work threads or running into some limitation of the VM system or scheduler design) because it should not be possible to have more threads than there are work units available to run, and it should not be possible for work units to share data in a way that hurts performance. Unfortunately, most software isn't written this way.
If the problem is B., then it still isn't something the OS can really guess until the computation is done, at which point it is too late to do anything about it. It would be algorithm-dependent, and would basically be bounded by performance of the final series of memcpy operations or whatever at the end.
At that point, you're probably bounded by raw memory bandwidth more than anything else. Either way, the OS can't possibly guess whether adding more cores will help because it can't know that the threads are all going to have to perform one high-contention serialization of the results at the end or whatever. Maybe the OS could provide some services to help the application author determine the optimal number of pieces to split the work into, but at least in my mind, it seems likely that it's just too algorithm-dependent for the responsibility to fall anywhere but on the app writer at that point.
To give an analogy, imagine that you are building a wall. You have a brick layer and ten servants to carry concrete blocks, each of whom can carry only one block at a time. You upgrade to thirty younger, smaller servants, but each can now carry only a block of half the size. So you've increased the rate at which the blocks get there by half, but you've now made twice as much work for the brick layer putting it together, and since the entire task is still serialized on the single brick layer, performance drops in that step. At some point, if you keep decreasing the size of the blocks and increasing the number of workers, the extra time that the brick layer takes at the end cancels out the time saved in moving the blocks, and beyond that point, the total construction time starts to get longer again. This is not at all an unusual situation in computer science. Many problems end with certain tasks that can't be parallelized very easily or that become progressively less parallelizable as the data trickles from the leaves of some sort of dependency tree to the root.
Now imagine that the brick layer won't arrive until the servants have moved all the bricks or blocks. An outside observer looking only at the bricks would see that more blocks are getting there faster and will naively assume that the task will get done faster with more pieces. That's the extent to which the OS can realistically have insight into the process; it can only see what is happening, not what will eventually happen. T
Actually, the statistics really don't show that. What you say was true back before seat belts and air bags. Now they're basically all about either traffic flow management or revenue. Less than 5% of all traffic accidents are caused by equipment failure, and even most of the remaining 5% can in many cases be avoided by minor changes, such as:
Heck, just getting rid of driver fatigue alone would cut accident rates by 30-50%.... That one change alone would completely overshadow any increase in deaths due to even quadrupling the number of deaths in the 5% of accidents that are caused by equipment failure.... Keep in mind that you're talking about quadrupling a rate that got smaller by a factor of 20, and that should put things back in the proper perspective.
Gas mileage is at best a temporary concern. We'll be all-electric by then anyway, at which point it becomes a question of energy production, which does not inherently require fossil fuels.
Certainly. I/O in general is highly parallelizable because it involves working with individual chunks of data that have little or no dependency on any other data around them, at least up to the point where you have to have those packets assembled in order in an mbuf chain or whatever. At some point, ordering has to be enforced, and I'd expect this to become a bottleneck, though admittedly you could still parallelize throughput up to the point where you have one thread per open socket.
Ouch. :-)
By "video compression", I was thinking more about actual, optimized, shipping codecs that are not computationally intractable. :-D