Trains didn't use mechanical transmissions before diesel-electric. The torque convertor found in every automatic transmission has its roots in train engines. A good torque convertor can transmit over 95% of the drivetrain power to the wheels even at low (or even zero) rpm. That's why a brake-start on a high performance car with an automatic transmission is extremely effective. For a lot of modern cars that are sold with both AT and MT transmissions, the auto is quicker.
No. Torque and horsepower are mathematically related. You cannot increase one without increasing the other. Look at all of the 1/4 mile time estimators - all of them figure out elapsed time using only horsepower and weight.
Actually, a tube frame is the tried-and-true way of making a great handling car. I'm currently building a Factory Five 818, which is based on a steel tube frame. It can easily pull 1.5 lateral G's at track height and 1.3G's at street height. It also is actually available and costs less than $20,000. It also only weighs 400 pounds more than this thing and it has a passenger seat.
Also, this will never be able to be put on the road in most US states without drastically changing the look of the front end. Most states have a minimum headlight height of 22 inches and some have a 24 inch minimum.
I wonder who you have to be to request to have the word "steal" changed so that it rolls in a behavior that you don't like. I hope the answer isn't "The President of Bell Media".
I suggest we all buy a dictionary, plop a bookmark at the word "steal" and mail it to him. Half a million dictionaries should be a poignant message.
It's always been like this. The focus on making new cars cleaner has always had small returns since you are simply making the cars that produce 10% of the pollution better and if you convert them all to "magic pixie dust fuel", you will still be left with the 90% from the broken cars. Previous studies have also shown that the pattern of which 25% isn't obvious. It isn't a simple rule like "old cars produce more NOx". Even a nearly new car can become a polluter without the owner noticing. Fortunately, the solution is both obvious and simple; do a tailpipe emissions test at they yearly inspection.
Because the most reliable way to make sure the magnetron is off is to remove it's power supply. The door switch is a safety feature, so it has to be as reliable as possible.
I'm surprised they lasted that long, but for a specific reason: what they were doing typically breaks microwave ovens. There is a switch that turns the magnetron off when the door is open, but if it opens while there is current flowing, it creates an arc. This arc causes a lot more wear than if the switch had opened with no current flowing.
Not only that... I'm 43 and I consider myself a "Digital Native". At the beginning of my IT career - 1996, I was using workstation virtualization products like Virtual PC and building Intranet applications. Things have changed since then, but I was part of it all and I know it at least as well as any kid whose claim to "Digital Native" is that he used Tumblr and YouTube in high school.
The airlines don't like this, because if you book NY to LA, they can no longer sell the Chicago to LA seat (except at last minute rates or more often push standby passengers onto that flight) that might normally be $150. So not only are they out $50 on you, they're potentially out an additional $150 on the unsold seat.
They already sold the Chicago to LA seat... to you. Why would it be unacceptable to not be able to sell the seat when they had already accepted the idea of flying someone on that leg for money they already collected? There are legitimate arguments to be made for the screwy fare system, but that one seems less than weak.
It's worse than that. If you accept that there is a parallel universe where One Direction didn't break up and decide it matters to you, then you also have to accept that there is a parallel universe where the most heinous thing you can imaging has happened to you. Since you decided to be emotionally invested in what happens in other universes, that should affect you the same way. If not, then the parallel universe thing wasn't science, it was denial.
That was the point. No one is suggesting that the US isn't doing a lot for security, they're suggesting that the US is violating privacy too much in a blind quest for security. Snowden provided proof of this. Anyone who wants more security should move to Russia. Most of us want less, but more focused security. Dragnets aren't a wise use of tax money and aren't very effective.
I'm currently building a car and I found that there is quite a bit of government support for the hobby. Texas recently changed their laws and accidentally made it impossible to register a home-built car - there was a shitstorm and a few months later the laws were fixed to allow it again. Even typically strict California issues 500 "you don't need any emissions equipment" stickers every year.
I live in New York, and we need to keep every emissions control technology that originally came with whatever engine we use. The rules are pretty sane - it doesn't have to be exactly the same equipment, but if the engine came with a catalytic converter, you need one to register it. Same goes for PCV, exhaust air injection, and evap canister purge solenoid.
Some states go as far as "You're building something that's a replica of a pre-1965 car? OK, you don't have to worry about the emissions thing".
It goes further... their scheme requires that the people holding the parts of the key work together regularly whenever access is needed. This is likely to be thousands of times every year. There's no way to keep a secret that needs to be accessed so often by so many. Enigma was broken due to poor operational security, not poor technology. Venona broke one-time pads due to poor OpSec. An encryption scheme used by all authorities wanting decrypts of cell phones would involve tens of thousands of people and would be impossible to carry out without making egregious operational errors. Add to that the fact that none of those who hold the keys have much to lose when they screw up. War time operatives know their way of life depends on them not screwing up. The local FBI office only cares about decrypting the phone, if they screw up, it doesn't hurt them, but it hurts me.
Are you suggesting that Cook should not speak out against any social issue until he fully researches how the issue is handled everywhere in the world and only after he has prepared a complete response that is all-encompassing?
Fiorina's statement is a standard deflection technique to change focus from the good things an opponent does to something less good.
Testing is an integral part of every development step, not something you tack on the end.
Good thing you know that we don't do unit testing... otherwise where we we learn that we were doing it wrong? Are you also going to assuming we don't do everything else I don't mention? I re-read my post and I can't find any part of it that could be used to infer that unit testing isn't part of our process.
Also, if you leave code review until after the product has passed all testing phases, then you have two problems. First, if you change anything after the code review, then you're not done testing, so the only way to do code review last is to magically have code that always zooms through code review with no comments. Second, you'll never get approval to fix more than a trivial amount of code if the pointy-haired boss knows the customer has already signed off; that's the classic path to being forced support bad code.
I have to agree. If it has gotten through "design reviews, code reviews, standards, pair programming, etc..." and doesn't work when it gets to test, you have a problem.
in these cases, "doesn't work" is a matter of interpretation. It's usually a defect or omission in the spec.
You can usually make good fast without much effort. It's often hard to make fast code good. Prioritizing speed above all else is a recipe for disaster.
Whether it works is orthogonal to quality. Good code can be fixed easily, so good code is always a short distance from "it works". Bad code can quickly go from "it works" to "it doesn't work and I don't know why" with just a simple change in requirements.
One of my rules is that the customer is the judge of whether is works or not, but the team is the judge of whether it is good or not. If the only person to evaluate the product is the customer, then you are pretty much guaranteed to have bad code. Code quality management comes before testing in the form of design reviews, code reviews, standards, pair programming, etc...
But, the main use of cracked offline passwords is to use that password on other services. The current service is already compromised as the person doing offline cracking has the database already. As long as you don't re-use passwords, it doesn't matter that much.
Hammond likes American cars - and he likes them for what they are, not just when they pretend to be European cars. He even gave the Dodge Challenger a good review for being a fun to drive muscle car, even though it's not a very good car from a statistics perspective.
All candidates had to go through HR. HR only had two approved vendors for the "IT Contractors" category. We had over four thousand IT contractors on staff at any one time company wide. My group hired about fifteen per year. With this much contracting, there was still more of a focus on cutting costs by reducing vendor count than on getting quality candidates. Both of the contract vendors were type that says "Ohhh... you're not from India, we'll just put you on the bottom of the pile".
if you lie on anything that can be verified, you're disqualified.
Tried that. Most of the candidates said they were the primary developer using a technology that, after two minutes of questioning, they had obviously never used before. I had several instances where the person I interviewed wasn't the person that showed up for the job.
The perceived wisdom is still correct as long as you don't make a grievous implementation error in one of the two things you are comparing. All that they demonstrated is "It is possible to do memory access so badly that it's slower than disk".
It's dumber than that. They didn't even do it right in Java. There is a note near the end of the paper that says "However, using a mutable data type such as StringBuilder or StringBuffer dramatically improved the results". They didn't present the numbers, but what they really meant was "The performance problems we saw were entirely due to our not using StringBuilder or StringBuffer, this paper shows no meaningful difference in performance between memory-then-disk and disk-only access once the algorithm is fixed."
Slashdot Mirror
Trains didn't use mechanical transmissions before diesel-electric. The torque convertor found in every automatic transmission has its roots in train engines. A good torque convertor can transmit over 95% of the drivetrain power to the wheels even at low (or even zero) rpm. That's why a brake-start on a high performance car with an automatic transmission is extremely effective. For a lot of modern cars that are sold with both AT and MT transmissions, the auto is quicker.
No. Torque and horsepower are mathematically related. You cannot increase one without increasing the other. Look at all of the 1/4 mile time estimators - all of them figure out elapsed time using only horsepower and weight.
Actually, a tube frame is the tried-and-true way of making a great handling car. I'm currently building a Factory Five 818, which is based on a steel tube frame. It can easily pull 1.5 lateral G's at track height and 1.3G's at street height. It also is actually available and costs less than $20,000. It also only weighs 400 pounds more than this thing and it has a passenger seat.
Also, this will never be able to be put on the road in most US states without drastically changing the look of the front end. Most states have a minimum headlight height of 22 inches and some have a 24 inch minimum.
I wonder who you have to be to request to have the word "steal" changed so that it rolls in a behavior that you don't like. I hope the answer isn't "The President of Bell Media".
I suggest we all buy a dictionary, plop a bookmark at the word "steal" and mail it to him. Half a million dictionaries should be a poignant message.
It's always been like this. The focus on making new cars cleaner has always had small returns since you are simply making the cars that produce 10% of the pollution better and if you convert them all to "magic pixie dust fuel", you will still be left with the 90% from the broken cars. Previous studies have also shown that the pattern of which 25% isn't obvious. It isn't a simple rule like "old cars produce more NOx". Even a nearly new car can become a polluter without the owner noticing. Fortunately, the solution is both obvious and simple; do a tailpipe emissions test at they yearly inspection.
Because the most reliable way to make sure the magnetron is off is to remove it's power supply. The door switch is a safety feature, so it has to be as reliable as possible.
I'm surprised they lasted that long, but for a specific reason: what they were doing typically breaks microwave ovens. There is a switch that turns the magnetron off when the door is open, but if it opens while there is current flowing, it creates an arc. This arc causes a lot more wear than if the switch had opened with no current flowing.
Not only that... I'm 43 and I consider myself a "Digital Native". At the beginning of my IT career - 1996, I was using workstation virtualization products like Virtual PC and building Intranet applications. Things have changed since then, but I was part of it all and I know it at least as well as any kid whose claim to "Digital Native" is that he used Tumblr and YouTube in high school.
The airlines don't like this, because if you book NY to LA, they can no longer sell the Chicago to LA seat (except at last minute rates or more often push standby passengers onto that flight) that might normally be $150. So not only are they out $50 on you, they're potentially out an additional $150 on the unsold seat.
They already sold the Chicago to LA seat... to you. Why would it be unacceptable to not be able to sell the seat when they had already accepted the idea of flying someone on that leg for money they already collected? There are legitimate arguments to be made for the screwy fare system, but that one seems less than weak.
It's worse than that. If you accept that there is a parallel universe where One Direction didn't break up and decide it matters to you, then you also have to accept that there is a parallel universe where the most heinous thing you can imaging has happened to you. Since you decided to be emotionally invested in what happens in other universes, that should affect you the same way. If not, then the parallel universe thing wasn't science, it was denial.
That was the point. No one is suggesting that the US isn't doing a lot for security, they're suggesting that the US is violating privacy too much in a blind quest for security. Snowden provided proof of this. Anyone who wants more security should move to Russia. Most of us want less, but more focused security. Dragnets aren't a wise use of tax money and aren't very effective.
I'm currently building a car and I found that there is quite a bit of government support for the hobby. Texas recently changed their laws and accidentally made it impossible to register a home-built car - there was a shitstorm and a few months later the laws were fixed to allow it again. Even typically strict California issues 500 "you don't need any emissions equipment" stickers every year.
I live in New York, and we need to keep every emissions control technology that originally came with whatever engine we use. The rules are pretty sane - it doesn't have to be exactly the same equipment, but if the engine came with a catalytic converter, you need one to register it. Same goes for PCV, exhaust air injection, and evap canister purge solenoid.
Some states go as far as "You're building something that's a replica of a pre-1965 car? OK, you don't have to worry about the emissions thing".
It goes further... their scheme requires that the people holding the parts of the key work together regularly whenever access is needed. This is likely to be thousands of times every year. There's no way to keep a secret that needs to be accessed so often by so many. Enigma was broken due to poor operational security, not poor technology. Venona broke one-time pads due to poor OpSec. An encryption scheme used by all authorities wanting decrypts of cell phones would involve tens of thousands of people and would be impossible to carry out without making egregious operational errors. Add to that the fact that none of those who hold the keys have much to lose when they screw up. War time operatives know their way of life depends on them not screwing up. The local FBI office only cares about decrypting the phone, if they screw up, it doesn't hurt them, but it hurts me.
Are you suggesting that Cook should not speak out against any social issue until he fully researches how the issue is handled everywhere in the world and only after he has prepared a complete response that is all-encompassing?
Fiorina's statement is a standard deflection technique to change focus from the good things an opponent does to something less good.
If you trust him, work through his last days as usual, just switch him to hand-over tasks instead of new work.
If you don't trust him, walk him out now and revoke all access.
Testing is an integral part of every development step, not something you tack on the end.
Good thing you know that we don't do unit testing... otherwise where we we learn that we were doing it wrong? Are you also going to assuming we don't do everything else I don't mention? I re-read my post and I can't find any part of it that could be used to infer that unit testing isn't part of our process.
Also, if you leave code review until after the product has passed all testing phases, then you have two problems. First, if you change anything after the code review, then you're not done testing, so the only way to do code review last is to magically have code that always zooms through code review with no comments. Second, you'll never get approval to fix more than a trivial amount of code if the pointy-haired boss knows the customer has already signed off; that's the classic path to being forced support bad code.
I have to agree. If it has gotten through "design reviews, code reviews, standards, pair programming, etc..." and doesn't work when it gets to test, you have a problem.
in these cases, "doesn't work" is a matter of interpretation. It's usually a defect or omission in the spec.
You can usually make good fast without much effort. It's often hard to make fast code good. Prioritizing speed above all else is a recipe for disaster.
Whether it works is orthogonal to quality. Good code can be fixed easily, so good code is always a short distance from "it works". Bad code can quickly go from "it works" to "it doesn't work and I don't know why" with just a simple change in requirements.
One of my rules is that the customer is the judge of whether is works or not, but the team is the judge of whether it is good or not. If the only person to evaluate the product is the customer, then you are pretty much guaranteed to have bad code. Code quality management comes before testing in the form of design reviews, code reviews, standards, pair programming, etc...
But, the main use of cracked offline passwords is to use that password on other services. The current service is already compromised as the person doing offline cracking has the database already. As long as you don't re-use passwords, it doesn't matter that much.
Hammond likes American cars - and he likes them for what they are, not just when they pretend to be European cars. He even gave the Dodge Challenger a good review for being a fun to drive muscle car, even though it's not a very good car from a statistics perspective.
All candidates had to go through HR. HR only had two approved vendors for the "IT Contractors" category. We had over four thousand IT contractors on staff at any one time company wide. My group hired about fifteen per year. With this much contracting, there was still more of a focus on cutting costs by reducing vendor count than on getting quality candidates. Both of the contract vendors were type that says "Ohhh... you're not from India, we'll just put you on the bottom of the pile".
if you lie on anything that can be verified, you're disqualified.
Tried that. Most of the candidates said they were the primary developer using a technology that, after two minutes of questioning, they had obviously never used before. I had several instances where the person I interviewed wasn't the person that showed up for the job.
The perceived wisdom is still correct as long as you don't make a grievous implementation error in one of the two things you are comparing. All that they demonstrated is "It is possible to do memory access so badly that it's slower than disk".
It's dumber than that. They didn't even do it right in Java. There is a note near the end of the paper that says "However, using a mutable data type such as StringBuilder or StringBuffer dramatically improved the results". They didn't present the numbers, but what they really meant was "The performance problems we saw were entirely due to our not using StringBuilder or StringBuffer, this paper shows no meaningful difference in performance between memory-then-disk and disk-only access once the algorithm is fixed."