That's absurd. If you were trying to save space you could have used 16 bits to store unique dates for almost 180 years. With another 8-bits you could make that 46k years, and still used only half the space per date as the ASCII YYMMDD format.
So if they goal was simply to save space the programmers were retarded. The goal was obviously to make it dates easy to program around/display/etc.; saving space was at best a secondary goal after someone already decided to store the date as an ASCII string.
DSL, while useful at the time, is years out-of-date, and has no intentions of updating. There might still be applications for it, but none where you would be worried about a floppy drive. It's a little like complaining that your C64 requires floppies -- of course it does, because that was the only option at the time it was built.
Ignoring the fact that you can do a full install of almost any linux distro on a $12 flash drive, there are a lot of options for "fits on a X megabyte drive" distros that are newer and easier to load and use than DSL.
They should have just cashed it. I don't know what the rules are in the UK, but around here if it contains the legal elements of a check (i.e. drawn on a bank, unconditional order to pay, etc.) then it's a check, photograph or otherwise.
For that matter, that's more or less the subject of the article -- that more consumer banks are offering the same convenience they've offered to larger customers for years, by allowing them to send pictures of checks instead of the original paper, as pictures are equally valid.
I would never write checks if there were some other way to send money to the government. Of the 63 checks I've written in the past 5 years, 47 of them went to the state or local government. And half the rest probably went to someone that wanted a copy of a check to setup ACH (though why I can't just copy the account number is beyond me).
What's particularly sad for me is that in some cases -- for example, paying withholding tax or collected sales tax through my business -- I am required to use ACH to pay the state. But when I go to file my personal taxes or renew my vehicle registration I have to use a paper check. And don't even get me started on the number of sub-$50 checks I've had to write to file forms and whatnot; around here the county government essentially won't take cash (I'm sure they would if I whined enough, but they sure don't like it), and they won't even look at credit cards, so every time you file form with a $18 fee there's another paper check, which must be made out separately from the one your wrote 5 minutes ago for the last form.
You're making this complicated. Yes, it's worthwhile to have some validity checks on your data to see if the operator is providing conflicting inputs, and to try to infer their meaning when they do something abnormal. But you will get into trouble trying to detect the difference between "unusual but intended operation" and "unusual and unintended operation", which is not trivial. For example, slamming on the brakes is not necessarily an indication that I want my car to be disable -- maybe something ran into the road, or I simply wasn't paying attention -- and disabling the vehicle altogether could be undesired, unexpected, and even dangerous.
There only needs to be one emergency cutout, a big, red, locking emergency-off button, just like we see on all sorts of other equipment. When you add 4 different ways to e-off they car, or try to have it guess at what constitutes an emergency, all you've done is increase the complexity (and therefore decrease the reliability and safety) of the e-off system.
Did you miss that fact that the Cuban embargo itself is a form a censorship? In this case both the US and Cuban governments are in the wrong, and we should defy *both* of them.
Because it's not XML, and it does not need to balance. The closing tag is just there to stop PHP processing and return to normal text mode. If you have no normal text to display it's completely optional. Heck, it might even help keep you from having trailing space/newlines/etc. at the end of your programatic output.
Now I personally prefer to close everything, and would never leave a hanging opening tag, but it's has no benefit toward processing the page.
Get a toll-free number -- they're like DNS for the phone system. Rather than giving out your fixed numeric address you can add a layer of indirection to give you much more control and to hide backend changes from users.
With a toll-free number you can route and/or port wherever you want in short order. Port it to a VoIP provider and have that service forward calls to your actual phone(s). Keep it with a standard long distance provider and have them set the ring-to to your cell phone. Move it between CA and US LD providers willy-nilly (that one probably takes a couple of weeks, but it's easy enough if you're moving at planned times).
The only downside is you have to pay for incoming calls. But you get a number that can be moved anywhere in North America, to any phone service provider, and can ring any phone (or with the right service phones plural) that you like, without anyone having to know that you moved/changed phones/etc.
You realize that both Vioxx and Fen-phen were approved by the FDA, right? And that asbestos is a naturally-occuring, ubiquitous fiber that is not dangerous unless you're exposed to high levels or for an extended period? And that there are many installations of asbestos that are not being removed because they pose no significant danger as installed?
It's not impossible to see what the computer is doing, and done correctly, electronic voting is both a superior input interface AND can provide faster counts AND can provide better audit trails. I agree this isn't what we see done with typical voting machines, but it's hardly impossible task you make it out to be.
You could in make the computer output a human-readable receipt. That could be on paper, it could be emailed, it could be laser-cut into a hunk of steel -- the output mode doesn't really matter. And since the input device is a computer the receipt could include a cryptographic signature (which has some security risks, but keeping one private key per voting machine, generated on the machine on the day of the vote secure for long enough to validate the results is a lot easier than keeping thousands of ballots printed days ahead of time at an off-site location secure). Such a signature could be used to validate the receipt, and to track down the specific machine(s) involved in any discrepancies that might arise.
You could even have a second computer read the receipt from the first and produce its own independent count using different software and hardware run by different staff in another building. Plus if the public keys for the machines were released it would be possible for anyone to independently verify the counts produced by the government, simply by collecting receipts, validating the signatures, and making their own tally -- we could give voters a second copy of their receipt to take home just for this sort of purpose.
Making the games OpenGL instead of DirectX-only certainly makes linux more plausible. I agree it's unlikely that a native X11 app will appear in the near future, but it should be much easier to build a fake-Mac/fake-Win environment under linux given an OpenGL engine.
Refueling could be as simple as pouring more fuel on the nanotubes. But it may also be irrelevant -- not all power systems need to be reusable. For example, an emergency beacon is not likely to be used frequently, so refueling is not nearly as important as shelf life. And even in applications where refueling is desirable, the increased power density may be worth it -- if you phone battery lasted 200 days instead of 2 days you might not care that the battery can only be refueled with special equipment.
That being said, 100x might well be optimistic. Or it might be wildly conservative. Since this is a brand new field it seems unlikely that an estimate will be terribly accurate.
For all the annoyances that Access can create, I actually think it's (and similar platforms) are a great way to quickly create simple interfaces for potentially complex data stores. You should never use Access to actually store data, or to do anything complicated, or probably even anything widely deployed. But if you're just looking for a quick way to pull together easy-to-moderate data views, print pretty reports, and maybe make simple changes to that data, Access is a great tool.
You're making two assumptions here to make the grandparent seem wrong; he's only wrong if your unstated assumptions hold.
1) That "solve a problem for a customer" does not already consider all of a customer's requirements, including safety, over-engineering, environmental responsibility, flexibility, interoperability, or scalability. To the contrary, I'd suggest that all of those consideration are part of "the problem".
2) You're assuming that "most efficient" means "least amount of coding time". I'd argue that "most efficient" could easily include total costs/time not only in the first draft, but over the life of the project, including use of the finished code and future maintenance.
The best engineers, software or otherwise, are often those that can look at a problem and find a way to copy an existing solution with as few changes as possible. Would you rather that your bridges were built by an engineer who "focused on the hard stuff" and invented a totally new bridge design each time, or that he found an existing bridge design that meet the load/span/etc. requirements of the new location and made minor adaptations to the existing, proven design to make it fit the particular application?
Sometimes there are new problems that must be solved in novel ways. Once in a while it's possible to find a new solution to an already-solved problem that's so much better it would be silly to keep doing things the old way. But the majority of good engineering is finding existing solutions to similar problems and making small adaptations.
A) There's not reason to believe the data is any more obfuscated than simply "undocumented". It would be extra work to intentionally hide the data, and it's not clear that Toyota is doing that, or what they would gain from it if they did. All we know is they aren't going to any extra effort to allow other people to read it, and speculation into possible obfuscation is poorly founded.
And I'm just going to pretend that you didn't say encrypted, because even people who well motivated often screw up encryption, so it's incredibly unlikely that Toyota has a correctly-implemented encryption system (which includes things like making sure not all cars have the same key, which would be exceedingly difficult to do correctly).
B) Reverse engineering isn't trivial, but it's not incredible difficult either. "100s of sensors" is not a huge amount, particularly when you can tell what most if not all of those sensors or measuring, and get the analog/digital readings directly from the sensor package to correlate with the output even. You could even take the sensor network and computer out of the car, rig it up to allow a computer to generate billions of different input combinations, and then use automated statistical analysis to find correlated input and output parameters.
There's never a warranty requirement to buy supplies/replacement parts/upgrades/etc. from the warranty vendor so long as the third-party parts you buy are compatible and not themselves responsible for the failure.
Kids these days and their ASBOs. Back in your day the local constabulary just gave you a talking to, or maybe a quick swat upside the head. You didn't get any fancy bracelets, or an indefinitely recorded criminal record. Instead you had to create your own remembrances of youthful, disruptive behavior by painting stripes on the onions on your belt.
That's off-site, but not on-line. It's not even near-line, like a USB drive or a tape. It's completely offline from the moment you box it until someone plugs it back in.
Which sounds like a potential competitive advantage; giving out less coffee while still marketing coffee on the same terms as competitors could reduce costs while maintaining sales.
It's maybe not a customer-friendly policy, but it's not very strong evidence of their negligence toward customer safety either.
McFact No. 1: For years, McDonald's had known they had a problem with the way they make their coffee - that their coffee was served much hotter (at least 20 degrees more so) than at other restaurants.
McObviousNegativeFraming No. 1: Noting that McDonald's "had known they had a problem" and then pretending to support that assertion with an unrelated statement about the relative temperature of their coffee.
McObviousNegativeFraming No. 2: Noting that McDonald's "had known they had a problem" and then stating the very next McFact that they had actually never consulted an expert to confirm any such problem. It might be fair to suggest that they could "know" without an expert, but if you're going to note their failure to consult and expert as negligence then you can't simultaneously claim that they "knew" any related fact.
McObviousNegativeFraming No. 3: Putting a warning about potential burns in small letters on the side of a cup passed through a car window does nothing to protect coffee drinkers, particularly those involved in accidental spill; it only protects McDonalds against lawsuits. Claiming that their failure to include such a warning is negligent only exemplifies the retardedness of this sort of lawsuit.
McObviousNegativeFraming No. 4: Citing revenue numbers and not profits is just a low blow. I know coffee is cheap, but time, labor, energy, buildings, equipment, management, and lawyers are not. McDonald's does not "make" $1.3M/day selling coffee, they just collect that much, based on estimates of annualized sales and the list price of a cup of coffee. And even "collect" is a stretch, because not every cup of coffee sells at list price, and not every cent of every transaction is necessarily collected by McDonalds (e.g. credit card processing fees).
Now it's possible that McDonald's really deserved to lose this case. I'm not convinced of that, but I'm not convinced they weren't negligent either. But your attempt to re-frame the issue is poor at best, and if some lawyer made your argument to me I'd be included to find against them just because of the bad logic and abuse of statistics.
Transformers do contain a lot of wire. But they don't encompass a lot of cross-sectional area, so there's not a lot of induction happening. They're also typically stored in metal housings, which would help mitigate any induction with the actual windings.
You need cross-section to induce a current, so it's not a "long wire" if you keep it spooled up in a 2" box. The transformers are damaged because they're connected to miles-long conductors, not because they contain a lot of tightly-wound wire.
Yes, just like any other dark panel you leave in the sun. Except not as hot, because some of the energy is being exported as electricity. So unless they're flammable at really low temperature we'll probably be okay.
Slashdot Mirror
That's absurd. If you were trying to save space you could have used 16 bits to store unique dates for almost 180 years. With another 8-bits you could make that 46k years, and still used only half the space per date as the ASCII YYMMDD format.
So if they goal was simply to save space the programmers were retarded. The goal was obviously to make it dates easy to program around/display/etc.; saving space was at best a secondary goal after someone already decided to store the date as an ASCII string.
DSL, while useful at the time, is years out-of-date, and has no intentions of updating. There might still be applications for it, but none where you would be worried about a floppy drive. It's a little like complaining that your C64 requires floppies -- of course it does, because that was the only option at the time it was built.
Ignoring the fact that you can do a full install of almost any linux distro on a $12 flash drive, there are a lot of options for "fits on a X megabyte drive" distros that are newer and easier to load and use than DSL.
They should have just cashed it. I don't know what the rules are in the UK, but around here if it contains the legal elements of a check (i.e. drawn on a bank, unconditional order to pay, etc.) then it's a check, photograph or otherwise.
For that matter, that's more or less the subject of the article -- that more consumer banks are offering the same convenience they've offered to larger customers for years, by allowing them to send pictures of checks instead of the original paper, as pictures are equally valid.
I would never write checks if there were some other way to send money to the government. Of the 63 checks I've written in the past 5 years, 47 of them went to the state or local government. And half the rest probably went to someone that wanted a copy of a check to setup ACH (though why I can't just copy the account number is beyond me).
What's particularly sad for me is that in some cases -- for example, paying withholding tax or collected sales tax through my business -- I am required to use ACH to pay the state. But when I go to file my personal taxes or renew my vehicle registration I have to use a paper check. And don't even get me started on the number of sub-$50 checks I've had to write to file forms and whatnot; around here the county government essentially won't take cash (I'm sure they would if I whined enough, but they sure don't like it), and they won't even look at credit cards, so every time you file form with a $18 fee there's another paper check, which must be made out separately from the one your wrote 5 minutes ago for the last form.
You're making this complicated. Yes, it's worthwhile to have some validity checks on your data to see if the operator is providing conflicting inputs, and to try to infer their meaning when they do something abnormal. But you will get into trouble trying to detect the difference between "unusual but intended operation" and "unusual and unintended operation", which is not trivial. For example, slamming on the brakes is not necessarily an indication that I want my car to be disable -- maybe something ran into the road, or I simply wasn't paying attention -- and disabling the vehicle altogether could be undesired, unexpected, and even dangerous.
There only needs to be one emergency cutout, a big, red, locking emergency-off button, just like we see on all sorts of other equipment. When you add 4 different ways to e-off they car, or try to have it guess at what constitutes an emergency, all you've done is increase the complexity (and therefore decrease the reliability and safety) of the e-off system.
Did you miss that fact that the Cuban embargo itself is a form a censorship? In this case both the US and Cuban governments are in the wrong, and we should defy *both* of them.
No closing ?> tag?
Because it's not XML, and it does not need to balance. The closing tag is just there to stop PHP processing and return to normal text mode. If you have no normal text to display it's completely optional. Heck, it might even help keep you from having trailing space/newlines/etc. at the end of your programatic output.
Now I personally prefer to close everything, and would never leave a hanging opening tag, but it's has no benefit toward processing the page.
Get a toll-free number -- they're like DNS for the phone system. Rather than giving out your fixed numeric address you can add a layer of indirection to give you much more control and to hide backend changes from users.
With a toll-free number you can route and/or port wherever you want in short order. Port it to a VoIP provider and have that service forward calls to your actual phone(s). Keep it with a standard long distance provider and have them set the ring-to to your cell phone. Move it between CA and US LD providers willy-nilly (that one probably takes a couple of weeks, but it's easy enough if you're moving at planned times).
The only downside is you have to pay for incoming calls. But you get a number that can be moved anywhere in North America, to any phone service provider, and can ring any phone (or with the right service phones plural) that you like, without anyone having to know that you moved/changed phones/etc.
Radio. It's much easier to get playtime for 4 minutes than 40.
You realize that both Vioxx and Fen-phen were approved by the FDA, right? And that asbestos is a naturally-occuring, ubiquitous fiber that is not dangerous unless you're exposed to high levels or for an extended period? And that there are many installations of asbestos that are not being removed because they pose no significant danger as installed?
It's not impossible to see what the computer is doing, and done correctly, electronic voting is both a superior input interface AND can provide faster counts AND can provide better audit trails. I agree this isn't what we see done with typical voting machines, but it's hardly impossible task you make it out to be.
You could in make the computer output a human-readable receipt. That could be on paper, it could be emailed, it could be laser-cut into a hunk of steel -- the output mode doesn't really matter. And since the input device is a computer the receipt could include a cryptographic signature (which has some security risks, but keeping one private key per voting machine, generated on the machine on the day of the vote secure for long enough to validate the results is a lot easier than keeping thousands of ballots printed days ahead of time at an off-site location secure). Such a signature could be used to validate the receipt, and to track down the specific machine(s) involved in any discrepancies that might arise.
You could even have a second computer read the receipt from the first and produce its own independent count using different software and hardware run by different staff in another building. Plus if the public keys for the machines were released it would be possible for anyone to independently verify the counts produced by the government, simply by collecting receipts, validating the signatures, and making their own tally -- we could give voters a second copy of their receipt to take home just for this sort of purpose.
Making the games OpenGL instead of DirectX-only certainly makes linux more plausible. I agree it's unlikely that a native X11 app will appear in the near future, but it should be much easier to build a fake-Mac/fake-Win environment under linux given an OpenGL engine.
Refueling could be as simple as pouring more fuel on the nanotubes. But it may also be irrelevant -- not all power systems need to be reusable. For example, an emergency beacon is not likely to be used frequently, so refueling is not nearly as important as shelf life. And even in applications where refueling is desirable, the increased power density may be worth it -- if you phone battery lasted 200 days instead of 2 days you might not care that the battery can only be refueled with special equipment.
That being said, 100x might well be optimistic. Or it might be wildly conservative. Since this is a brand new field it seems unlikely that an estimate will be terribly accurate.
For all the annoyances that Access can create, I actually think it's (and similar platforms) are a great way to quickly create simple interfaces for potentially complex data stores. You should never use Access to actually store data, or to do anything complicated, or probably even anything widely deployed. But if you're just looking for a quick way to pull together easy-to-moderate data views, print pretty reports, and maybe make simple changes to that data, Access is a great tool.
You're making two assumptions here to make the grandparent seem wrong; he's only wrong if your unstated assumptions hold.
1) That "solve a problem for a customer" does not already consider all of a customer's requirements, including safety, over-engineering, environmental responsibility, flexibility, interoperability, or scalability. To the contrary, I'd suggest that all of those consideration are part of "the problem".
2) You're assuming that "most efficient" means "least amount of coding time". I'd argue that "most efficient" could easily include total costs/time not only in the first draft, but over the life of the project, including use of the finished code and future maintenance.
The best engineers, software or otherwise, are often those that can look at a problem and find a way to copy an existing solution with as few changes as possible. Would you rather that your bridges were built by an engineer who "focused on the hard stuff" and invented a totally new bridge design each time, or that he found an existing bridge design that meet the load/span/etc. requirements of the new location and made minor adaptations to the existing, proven design to make it fit the particular application?
Sometimes there are new problems that must be solved in novel ways. Once in a while it's possible to find a new solution to an already-solved problem that's so much better it would be silly to keep doing things the old way. But the majority of good engineering is finding existing solutions to similar problems and making small adaptations.
A) There's not reason to believe the data is any more obfuscated than simply "undocumented". It would be extra work to intentionally hide the data, and it's not clear that Toyota is doing that, or what they would gain from it if they did. All we know is they aren't going to any extra effort to allow other people to read it, and speculation into possible obfuscation is poorly founded.
And I'm just going to pretend that you didn't say encrypted, because even people who well motivated often screw up encryption, so it's incredibly unlikely that Toyota has a correctly-implemented encryption system (which includes things like making sure not all cars have the same key, which would be exceedingly difficult to do correctly).
B) Reverse engineering isn't trivial, but it's not incredible difficult either. "100s of sensors" is not a huge amount, particularly when you can tell what most if not all of those sensors or measuring, and get the analog/digital readings directly from the sensor package to correlate with the output even. You could even take the sensor network and computer out of the car, rig it up to allow a computer to generate billions of different input combinations, and then use automated statistical analysis to find correlated input and output parameters.
There's never a warranty requirement to buy supplies/replacement parts/upgrades/etc. from the warranty vendor so long as the third-party parts you buy are compatible and not themselves responsible for the failure.
I know that's not what the sales folk tell you, but that is the law.
http://en.wikipedia.org/wiki/Magnuson–Moss_Warranty_Act
Kids these days and their ASBOs. Back in your day the local constabulary just gave you a talking to, or maybe a quick swat upside the head. You didn't get any fancy bracelets, or an indefinitely recorded criminal record. Instead you had to create your own remembrances of youthful, disruptive behavior by painting stripes on the onions on your belt.
That's off-site, but not on-line. It's not even near-line, like a USB drive or a tape. It's completely offline from the moment you box it until someone plugs it back in.
Which sounds like a potential competitive advantage; giving out less coffee while still marketing coffee on the same terms as competitors could reduce costs while maintaining sales.
It's maybe not a customer-friendly policy, but it's not very strong evidence of their negligence toward customer safety either.
McFact No. 1: For years, McDonald's had known they had a problem with the way they make their coffee - that their coffee was served much hotter (at least 20 degrees more so) than at other restaurants.
McObviousNegativeFraming No. 1: Noting that McDonald's "had known they had a problem" and then pretending to support that assertion with an unrelated statement about the relative temperature of their coffee.
McObviousNegativeFraming No. 2: Noting that McDonald's "had known they had a problem" and then stating the very next McFact that they had actually never consulted an expert to confirm any such problem. It might be fair to suggest that they could "know" without an expert, but if you're going to note their failure to consult and expert as negligence then you can't simultaneously claim that they "knew" any related fact.
McObviousNegativeFraming No. 3: Putting a warning about potential burns in small letters on the side of a cup passed through a car window does nothing to protect coffee drinkers, particularly those involved in accidental spill; it only protects McDonalds against lawsuits. Claiming that their failure to include such a warning is negligent only exemplifies the retardedness of this sort of lawsuit.
McObviousNegativeFraming No. 4: Citing revenue numbers and not profits is just a low blow. I know coffee is cheap, but time, labor, energy, buildings, equipment, management, and lawyers are not. McDonald's does not "make" $1.3M/day selling coffee, they just collect that much, based on estimates of annualized sales and the list price of a cup of coffee. And even "collect" is a stretch, because not every cup of coffee sells at list price, and not every cent of every transaction is necessarily collected by McDonalds (e.g. credit card processing fees).
Now it's possible that McDonald's really deserved to lose this case. I'm not convinced of that, but I'm not convinced they weren't negligent either. But your attempt to re-frame the issue is poor at best, and if some lawyer made your argument to me I'd be included to find against them just because of the bad logic and abuse of statistics.
Transformers do contain a lot of wire. But they don't encompass a lot of cross-sectional area, so there's not a lot of induction happening. They're also typically stored in metal housings, which would help mitigate any induction with the actual windings.
You need cross-section to induce a current, so it's not a "long wire" if you keep it spooled up in a 2" box. The transformers are damaged because they're connected to miles-long conductors, not because they contain a lot of tightly-wound wire.
Yes, just like any other dark panel you leave in the sun. Except not as hot, because some of the energy is being exported as electricity. So unless they're flammable at really low temperature we'll probably be okay.