And I can see why people are upset, but don't really agree with them.
If you are somebody who likes to speed on the highway, you're not going to get the sticker MPG of 48 to happen. You'll end up somewhere around 40 MPG. The test was of course dome at 65 MPH, if you drive that speed most of the time you'll have a chance to hit 47 MPG.
If idle at all at any time in city driving, you're going to take an MPG hit. The EPA's rating of 48 MPG is clearly based on the fact that you'll be able be able to use the auto stop feature all the time. In the real world, you don't... in crawling traffic you need to wait until there's a 2-car length gap before you move forward or otherwise the auto stop will not reset and you'll have to idle. If it's colder than 40 degrees outside, auto stop is dead on arrival and in city performace you'll have to settle for about 38 MPG.
Wanna use the A/C? That'll be 3 MPG off your total, please drive around.
Still, if you know that EPA tests cars in a lab environment rather than the real world, you'd be surprised that they didn't publish higher numbers. On a day that you can roll down the windows and fully use the auto-stop, I've seen 55 MPG show up on the dashboard. It can be done, you just have to be aware of when you're using fuel and try not to get into situations where you're wasteful.
It's a typical follow-the-money situation. If the malware writer isn't getting a kickback from the phone company, just how else are they getting paid for doing this scheme?
People may have a legit reason to want a data connect with the given countries, and it usually is a violation of privacy law to do such detection without the customer wanting it. It's a great tech solution but a dumb policy.
Still, a phone company somewhere has to be offering the billing service that these dialers are using to cash in. Either it's an interational call to a phone operator that's in on the scheme, or it's the local version of 1-900 area code or 976 exchange pay services.
I'd estimate that in the case of these smaller places, a majority of the phone calls they were getting from Telus were being disputed as illegitimate. Countries with larger populations would have more legit calls being made to it, and therefore it'd take many more problem calls to get to the same percentage ratio.
Telus's CallGate service costs $3.95 (Canadian, of course) and gives the option configure it to block 1-900 calls, toll calls, a list of 25 specific numbers or such.
It's interesting that they're asking people to pay to be not able to dial given numbers. You'd think a hardware device on the user's side could provide the same functionality for less...
Commonly, the way that these international calling scams work is that the monopoly carrier of the foriegn country charges obscenely high rates by most standards, and then the malware writer leases lines close to the point of entry so that the carrier doesn't have to do much work once the call enters their system. The malware writer is then given a piece of the international call toll for attracting the business.
In short, the phone companies in these developing nations are usually in on the scheme and profit just as much as the malware operators do from the increased call volume. They have no interest in stopping calls that way.
I wouldn't be opposed to giving such companies an international telecom death penality of simply not routing calls their way. If the only phone operator in a country can't properly keep scam artists out of their network, and furthermore aids such scam artists, that country really doesn't have much of a phone system to begin with... an electronic embargo might get the government there to get a clue.
All three channels are a mix of news and opinion programs, and have been that way from the start. Crossfire has always been the debate show on CNN's lineup, and Larry King has always been a softball interviewer.
The key is that when you give a child access to the Internet, you're the one giving them access to all bad things on the Internet too. The responsiblity starts and ends at the parents.
That's where the "allowed to physically possess" part comes in. Your employer can ban all such devices from the premises on the grounds of security. However, they can't tell Verizon, Cingular, T-Mobile, and company not to paint their workplace with signal, and they can't put up jamming devices to block signals either.
The Expo event planners could have their security people treat WiFi equipment as a contraband item and lock out all WiFi devices at teh door, what the FCC is effectively saying is that once you allow such things into your building, you can't go saying "Don't use that unless you pay to be part of our bandwidth allocation system! If you all use your devices you'll cause interference with each other." because if there's really an interference problem that's something that should be brought to the FCC.
The FCC said that they "reaffirmed" that they have jurisdiction, anybody who's saying "ruled" is using a word that nobody at the FCC said on the record. Typical journalistic oversimplification.
By extention, this basically says that users are allowed to operate any Part 15 compliant devices anywhere they're allowed to physically possess them... and anybody who wants to resolve conflicts in a high-traffic area must go through the FCC if they want anything more binding than handshakes.
When the FCC gives bandwidth space to the people, it belongs to the people.
This makes it clear... anybody has the right to operate a WiFi device within the FCC-set limits, and if it bothers your WiFi device then well tough. It's unlicensed, but not unregulated.
For those of you outside of Massachusetts reading here...
"Massport"... sounds like it's a business or something, but it's just a trendy name for the Massachusetts Port Authority, which is just a branch of the state government trying to sound a little more important than they really are.
This kind of database is only as good as its input. If the public records of any given community are wrong, that mistake will flow into the database...
I don't think terrorists are going to hijack an airplane and fly it into a building again because they know we won't fall for that one twice. However, knowing who is passing through our airports is still important because that is effectively a border point. We want to keep the known terrorists outside of the country.
Where this technology comes in is that a cop can instantly test a person's claimed identity against the public records that idendity should have created... if things aren't matching up, this could lead to some questions that they'll want answers to.
A: This service has zero info that you shouldn't have. It's all public records, the scary part of this service is that they seem to have most of the nation's public records about individuals assembled in an easy-to-query form.
B: Since this company charges by the query, too many queries from a device will likely cause that device quickly be deauthorized by whomever's paying the bill.
I'm a pretty good software developer, but if someone doesn't explain to me what the argument is in plain english without extreme haughtiness, I'm going to write off this whole issue as a pissing contest.
The issues in dispute can't be expressed in plain english. That's why we need to upgrade to haughtiness and phase out plain english immediately.
1) You can write a given query and number of different ways. This is not necessarily a SQL problem but due to this the query optimizers have to be enormously complex to handle complicated queries and by association you can have queries which describes two identical sets but have vastly different runtimes/costs. Just because two queries return the same results today do not mean that they will continue to do so in the future. If a value that used to be bounded from 1 to 10 suddenly is declared to be allowed to be cranked to 11, then suddenly "equal or greater than 9" and "equal to 9 or equal to 10" will have gone from always returning the same results to now specifying different sets. Clearly, the more specific code will execute faster, but if an assumed boundry no longer holds in the future, the program will become obsoleted and require revision to the less specific version. This isn't a language-specific issue, it's just a problem that crops up whenever a computer program encounters a situation its designer wasn't expecting.
2) Little/No support for relational domains (e.g. complex data types) Not a bug, it's a feature. The S in SQL is for "structure"... go hammer out your data into a structured format rather than a complex one and then come back.
3) Non-updateable views (partially due to duplicate handling and/or allowing relations with no primary key) Totals will always be a non-updatable view. You can't change the number of objects you have without creating some new objects or chosing to get rid of some existing objects. Fields in a one-to-many relationship cannot be changed because to do so would be ambigious... do you want to create a new entry in the other table, or do you want to rename an existing entry in the other table. Go do what you meant to do, then refresh your view.
4) Weak support for complex integrity constraints (e.g. business rules) That's more an issue for applications rather than databases. The program or user that's creating the query should know what's allowed by business rules, because if the database is going to refuse a query due to business rule violations, that query shouldn't have been offered to the database in the first place. Those errors should be trapped upstream before they get that far. SQL triggers for business rules should be a last line of defense, not something that should be regularly asked to function.
5) No support for entity sub/supertype relationships Plenty of support, just not intrinsically. Just use a one-to-many relationship in your DB structure and go along your way.
6) Supports NULLs (Date/Pascal/Darwin do not like NULLs) That's like trying to do math without a concept of zero. Sometimes, things just don't apply and we put "N/A" on the form and "NULL" in the database.
The main complant I'm seeing is that an SQL-based database doesn't exactly support a tree-based structure "out of the box". However, isn't using linked tables to make a one-to-many relationships one of the first things anybody's taught in a basic how-to-make-a-database class?
To me, these people drank too much XML Kool-aid...
Most of the problems that I've seen with SQL commands that are more complex than they really should be are a result of mistaken assumptions made during the design phase of the database. As a result, extra tables get added late, and therefore create new "features" that code then has to be revised to take advantage of...
XML's going to be no better in this area. Mistakes made during the design phase will always come back to haunt while implementing and using the system. If a single query can't return the results desired, then that should have been thought of while designing the tables of the DB. Trying to get a query to specify "All things that are red" like Pascal suggests is only going to work if all objects implement the "color" property the same way. If somebody uses CMYK, somebody else uses RGB, and a third uses Play-Doh color names, it's still gonna be a mess that requires code to figure out who really matches whom.
I don't see how this "new model" fixes the real problems with working with SQL between databases that weren't designed to work with each other.
Slashdot Mirror
And I can see why people are upset, but don't really agree with them.
If you are somebody who likes to speed on the highway, you're not going to get the sticker MPG of 48 to happen. You'll end up somewhere around 40 MPG. The test was of course dome at 65 MPH, if you drive that speed most of the time you'll have a chance to hit 47 MPG.
If idle at all at any time in city driving, you're going to take an MPG hit. The EPA's rating of 48 MPG is clearly based on the fact that you'll be able be able to use the auto stop feature all the time. In the real world, you don't... in crawling traffic you need to wait until there's a 2-car length gap before you move forward or otherwise the auto stop will not reset and you'll have to idle. If it's colder than 40 degrees outside, auto stop is dead on arrival and in city performace you'll have to settle for about 38 MPG.
Wanna use the A/C? That'll be 3 MPG off your total, please drive around.
Still, if you know that EPA tests cars in a lab environment rather than the real world, you'd be surprised that they didn't publish higher numbers. On a day that you can roll down the windows and fully use the auto-stop, I've seen 55 MPG show up on the dashboard. It can be done, you just have to be aware of when you're using fuel and try not to get into situations where you're wasteful.
It's a typical follow-the-money situation. If the malware writer isn't getting a kickback from the phone company, just how else are they getting paid for doing this scheme?
Telus isn't a government, it's just the monopoly phone provider in the western sections of Canada...
People may have a legit reason to want a data connect with the given countries, and it usually is a violation of privacy law to do such detection without the customer wanting it. It's a great tech solution but a dumb policy.
Still, a phone company somewhere has to be offering the billing service that these dialers are using to cash in. Either it's an interational call to a phone operator that's in on the scheme, or it's the local version of 1-900 area code or 976 exchange pay services.
I'd estimate that in the case of these smaller places, a majority of the phone calls they were getting from Telus were being disputed as illegitimate. Countries with larger populations would have more legit calls being made to it, and therefore it'd take many more problem calls to get to the same percentage ratio.
Telus's CallGate service costs $3.95 (Canadian, of course) and gives the option configure it to block 1-900 calls, toll calls, a list of 25 specific numbers or such.
It's interesting that they're asking people to pay to be not able to dial given numbers. You'd think a hardware device on the user's side could provide the same functionality for less...
Commonly, the way that these international calling scams work is that the monopoly carrier of the foriegn country charges obscenely high rates by most standards, and then the malware writer leases lines close to the point of entry so that the carrier doesn't have to do much work once the call enters their system. The malware writer is then given a piece of the international call toll for attracting the business.
In short, the phone companies in these developing nations are usually in on the scheme and profit just as much as the malware operators do from the increased call volume. They have no interest in stopping calls that way.
I wouldn't be opposed to giving such companies an international telecom death penality of simply not routing calls their way. If the only phone operator in a country can't properly keep scam artists out of their network, and furthermore aids such scam artists, that country really doesn't have much of a phone system to begin with... an electronic embargo might get the government there to get a clue.
All three channels are a mix of news and opinion programs, and have been that way from the start. Crossfire has always been the debate show on CNN's lineup, and Larry King has always been a softball interviewer.
The key is that when you give a child access to the Internet, you're the one giving them access to all bad things on the Internet too. The responsiblity starts and ends at the parents.
A full Faraday cage building would most likely be illegal due to lack of windows and doors...
That's where the "allowed to physically possess" part comes in. Your employer can ban all such devices from the premises on the grounds of security. However, they can't tell Verizon, Cingular, T-Mobile, and company not to paint their workplace with signal, and they can't put up jamming devices to block signals either.
Then, uh, why are you reading slashdot comments anyway? Please stop.
The Expo event planners could have their security people treat WiFi equipment as a contraband item and lock out all WiFi devices at teh door, what the FCC is effectively saying is that once you allow such things into your building, you can't go saying "Don't use that unless you pay to be part of our bandwidth allocation system! If you all use your devices you'll cause interference with each other." because if there's really an interference problem that's something that should be brought to the FCC.
The FCC said that they "reaffirmed" that they have jurisdiction, anybody who's saying "ruled" is using a word that nobody at the FCC said on the record. Typical journalistic oversimplification.
By extention, this basically says that users are allowed to operate any Part 15 compliant devices anywhere they're allowed to physically possess them... and anybody who wants to resolve conflicts in a high-traffic area must go through the FCC if they want anything more binding than handshakes.
When the FCC gives bandwidth space to the people, it belongs to the people.
This makes it clear... anybody has the right to operate a WiFi device within the FCC-set limits, and if it bothers your WiFi device then well tough. It's unlicensed, but not unregulated.
For those of you outside of Massachusetts reading here...
"Massport"... sounds like it's a business or something, but it's just a trendy name for the Massachusetts Port Authority, which is just a branch of the state government trying to sound a little more important than they really are.
This kind of database is only as good as its input. If the public records of any given community are wrong, that mistake will flow into the database...
I don't think terrorists are going to hijack an airplane and fly it into a building again because they know we won't fall for that one twice. However, knowing who is passing through our airports is still important because that is effectively a border point. We want to keep the known terrorists outside of the country.
Where this technology comes in is that a cop can instantly test a person's claimed identity against the public records that idendity should have created... if things aren't matching up, this could lead to some questions that they'll want answers to.
A: This service has zero info that you shouldn't have. It's all public records, the scary part of this service is that they seem to have most of the nation's public records about individuals assembled in an easy-to-query form.
B: Since this company charges by the query, too many queries from a device will likely cause that device quickly be deauthorized by whomever's paying the bill.
I'm a pretty good software developer, but if someone doesn't explain to me what the argument is in plain english without extreme haughtiness, I'm going to write off this whole issue as a pissing contest.
The issues in dispute can't be expressed in plain english. That's why we need to upgrade to haughtiness and phase out plain english immediately.
1) You can write a given query and number of different ways. This is not necessarily a SQL problem but due to this the query optimizers have to be enormously complex to handle complicated queries and by association you can have queries which describes two identical sets but have vastly different runtimes/costs.
Just because two queries return the same results today do not mean that they will continue to do so in the future. If a value that used to be bounded from 1 to 10 suddenly is declared to be allowed to be cranked to 11, then suddenly "equal or greater than 9" and "equal to 9 or equal to 10" will have gone from always returning the same results to now specifying different sets. Clearly, the more specific code will execute faster, but if an assumed boundry no longer holds in the future, the program will become obsoleted and require revision to the less specific version. This isn't a language-specific issue, it's just a problem that crops up whenever a computer program encounters a situation its designer wasn't expecting.
2) Little/No support for relational domains (e.g. complex data types)
Not a bug, it's a feature. The S in SQL is for "structure"... go hammer out your data into a structured format rather than a complex one and then come back.
3) Non-updateable views (partially due to duplicate handling and/or allowing relations with no primary key)
Totals will always be a non-updatable view. You can't change the number of objects you have without creating some new objects or chosing to get rid of some existing objects. Fields in a one-to-many relationship cannot be changed because to do so would be ambigious... do you want to create a new entry in the other table, or do you want to rename an existing entry in the other table. Go do what you meant to do, then refresh your view.
4) Weak support for complex integrity constraints (e.g. business rules)
That's more an issue for applications rather than databases. The program or user that's creating the query should know what's allowed by business rules, because if the database is going to refuse a query due to business rule violations, that query shouldn't have been offered to the database in the first place. Those errors should be trapped upstream before they get that far. SQL triggers for business rules should be a last line of defense, not something that should be regularly asked to function.
5) No support for entity sub/supertype relationships
Plenty of support, just not intrinsically. Just use a one-to-many relationship in your DB structure and go along your way.
6) Supports NULLs (Date/Pascal/Darwin do not like NULLs)
That's like trying to do math without a concept of zero. Sometimes, things just don't apply and we put "N/A" on the form and "NULL" in the database.
The main complant I'm seeing is that an SQL-based database doesn't exactly support a tree-based structure "out of the box". However, isn't using linked tables to make a one-to-many relationships one of the first things anybody's taught in a basic how-to-make-a-database class?
To me, these people drank too much XML Kool-aid...
Most of the problems that I've seen with SQL commands that are more complex than they really should be are a result of mistaken assumptions made during the design phase of the database. As a result, extra tables get added late, and therefore create new "features" that code then has to be revised to take advantage of...
XML's going to be no better in this area. Mistakes made during the design phase will always come back to haunt while implementing and using the system. If a single query can't return the results desired, then that should have been thought of while designing the tables of the DB. Trying to get a query to specify "All things that are red" like Pascal suggests is only going to work if all objects implement the "color" property the same way. If somebody uses CMYK, somebody else uses RGB, and a third uses Play-Doh color names, it's still gonna be a mess that requires code to figure out who really matches whom.
I don't see how this "new model" fixes the real problems with working with SQL between databases that weren't designed to work with each other.