If things like the ReadyNAS Duo or NV+ are vulnerable that's an even bigger problem, because they're even less likely to be patched than the models used by businesses.
That's a good point, which I didn't make before (mostly) because I didn't think of it and (partially) because I don't know much about the technical details of USB and figured it might be possible for the controller chip to support mass storage devices but not printers (i.e., some sort of "limited USB host").
I've told him many times that he should use a word processor, but he just doesn't understand. I tell him time and again where the office program is, and when prodded to try it, he still hunts through Firefox's menus trying to find the office program. The closest he gets to using a word processor is an input box in Firefox, which causes other problems. The worst is that it is too easy to lose a document. Sometimes just navigating to another page, even with just the back button, is enough to lose an hour of labor
Point him at a "cloud" word processing app like Google Docs or something.
Yes, if an only if your router includes "print server" as an advertised feature. Otherwise the printer's plug will fit, but the router won't know what to do with it.
You do have a point, though: I guess there's some argument to be made in favor of touch typing so that you can continue thinking about the problem while you type (instead of having to think about typing)...
It's a law about how a car manufacturer is supposed to work with the public, eg through independently owned dealerships.
Right. And my question is "why are car manufacturers different than everything else?" Is Apple not allowed to operate Apple Stores in Texas? Is Sears not allowed to sell Craftsman or Kenmore in Texas? Is Wal-Mart not allowed to sell Great Value brand products in Texas?
If all of these things are allowed, then car manufacturers (including not just Tesla, but the likes of Ford, VW and Toyota too) should also be able to operate corporate-owned stores in Texas. And contrapositively, if it's OK to disallow it for cars, then it should be OK to disallow it for any of the other things previously mentioned (a reductio ad absurdum, obviously).
Cars already have the equipment required, and the collection mechanism is already implemented:
Step 1: Look up the vehicle's odometer reading from the yearly emissions inspection.
Step 2: Subtract the odometer reading from the year before, multiply by the tax rate
Step 3: Distribute the money to jurisdictions weighted by the amount of traffic in each jurisdiction (based on the yearly per-road-segment vehicle counts that the DOT already collects)
Maybe you might argue the court didn't really have reasonable suspicion, but thats for the defendant's lawyer to argue.
Well, you see, the defendant's lawyer never had the opportunity to argue because the defendant wasn't just ordered to give the hard drive up but rather was raided by police with no warning. That's kind of the entire problem...
Essentially, the guy allegedly stole^W copyright-infringed his employer's software because he had a philosophical difference with how the company should be handling the source code and went to offer it himself. And his personal effects were raided by police over what by all rights should be a civil matter to begin with.
Well, preventing monopolies is a good thing in my book, but the monopoly would have to be over cars in general -- a manufacturer choosing to sell it's own product only directly is not a monopoly by definition, unless it's the only company in the entire industry (and the product is important enough to cause hardship if the customers can't buy it).
Besides, every other product is sold in normal third-party stores and may also be available straight from the manufacturer -- I just don't understand why it's magically different for cars. I mean, if I'm selling some widget over the Internet (maybe even something as trivial as a sweater on Etsy or something), do I have to first wholesale it to some third-party distributor in Texas? If not, why are the rules different Tesla?
By the same logic, California has an illegal restraint of trade against any state that manufactures certain firearms and firearm accessories...
I don't know what California's gun laws are like, but maybe that's true too!
...and most states would have an illegal restraint of trade against Colorado by not allowing CO pot growers to sell there
No, because the laws preventing interstate sale of marijuana are Federal. (They may still be unconstitutional, but not because of the Interstate Commerce Clause.)
Perhaps it's not that young folks have never heard of the IRA, but rather that they didn't realize they attacked not only in Northern Ireland, but England itself too.
(I have to admit, the first thing I think of when the topic is brought up is Burn Notice, followed by Delorean.)
What gives Texas the authority to prevent any manufacturer -- of cars or otherwise -- from selling their products in the state? Couldn't this be construed as an illegal restraint of trade against the State of California?
Oh. Sorry, in that case the answer was "I don't really care what the purpose as expressed in TFA is, I care about what vehicle detection systems are good for in general."
Besides, "mak[ing] traffic signal settings based on (the information)" as the article talks about is a flexible enough idea that it could encompass ad-hoc manual adjustments where speed-only data would be useful (although you'd still want to look at the cameras while you're doing it) as well as longer term design-and-engineer-a-better-default-timing kind of adjustments, where having the counts would be very helpful (particularly if you wanted to make them the input to a real-time signal adjustment algorithm -- in fact, in that case what I'd really want would be intersection movement counts, not just segment directional counts).
Long term, I'd suggest that the best plan would be to take the induction loops (which you need anyway for actuated signal timing) and hook them up to the traffic management software.
But then that makes me think... if he can already control the signals remotely, then the induction loop data should already be available too. I guess they haven't hooked the systems together yet (which was also the case where I worked: I could operate cameras and changeable message signs using the main application, but I had to fire up something else if I wanted to mess with a ramp meter).
This is different from reading license plates in that it's a lot less effective for tracking people (since bluetooth MAC addresses aren't tied to people's identities in a government database from the get-go like license plates are). It's also likely much cheaper.
One thing you should know is that I'm probably just as paranoid as you, but have also worked in the ITS (Intelligent Transportation Systems) field. I feel a lot more comfortable with Bluetooth-based vehicle detection systems (VDS) than I would with any of the alternatives you've proposed, from a privacy standpoint. (I still like "traditional-vision" or EM loop detection better, though.)
First of all, for the implementation of Bluetooth VDS I worked with, all we at the DOT had access to was the end-result vehicle speed data. I don't think any MAC addresses even got out of the vendor's systems.
Second, DOTs country-wide are chronically underfunded. It takes literally years to get simple things done, like replacing burnt-out projector screens in the monitoring center, let alone anything complicated like setting up a huge nefarious tracking database.
Third, beyond simply not caring about tracking individual cars (except maybe for origin-destination analysis), DOTs actively avoid retaining that kind of data. Even though the regular traffic cameras can record, it was policy not to use that function except for specific limited purposes (e.g. recording an exceptionally severe accident to analyze emergency response performance) because the DOT didn't want to have to process subpoenas for it later. And even if that were okay, if they routinely retained data but somehow lost the particular piece that was subpoenaed it'd be even worse.
Vehicle counts start to matter as soon as you want to do any kind of deeper engineering analysis or design. For example, you might want to be able to answer questions like "how do speeds correlate with volume -- do they drop linearly, or suddenly at some 'critical' volume?" or "how much excess capacity does my road have?" or "did this change I made to the road actually increase capacity, or did speeds just seem to improve because fewer people happen to be driving on it this week?"
In general, it's a lot more fun (as a traffic engineer) to have real-time data than it is to send somebody out in the field count data for one day out of a year (especially when, for all you know, that one day might be an outlier).
Not to mention, asking a traffic engineer to do anything without knowing vehicle counts is kind of like asking an electrical engineer to design a device without knowing how many amps it uses.
Look at the word "engineer" It is literally engine-er; one who [does] engines.
Back in the day, when engines were a new thing, the same guy who designed the engine would also build it, run it and maintain it. So the word engineer was fine to describe him.
In the real "back in the day," "engines" were siege engines (e.g. ballistas and trebuchets). Civil engineers (who built everything except engines) are named such in order to distinguish them from military engineers.
[I]t amazes me how many programmers can't do things like... touch type.
Although I completely agree with your point, I feel to need to point out that if your programming speed is constrained by your typing speed, you're not doing nearly enough thinking.
Axle counters can tell you the volume of traffic, but don't really tell you the speed of the traffic (does a count of zero axles in 30 seconds mean no traffic, or traffic at a dead stop?)
Axle counters (and magnetic field loop detection and computer-vision-based detection, both of which are more common for the application we're talking about) do tell you the speed of the vehicles in every situation except for a major accident with all lanes blocked. And you can tell when that happens because the map turned from green to yellow to red before the data stopped.
How this is better than the current axle counters they have I don't know, in fact I see it as probably worse. since it's not quite as accurate. maybe easier to plug into the traffic control systems.
It's worse, but cheaper. I don't know about the relative accuracy for reporting speeds, but it has the substantial disadvantage of not being able to report vehicle counts (since you don't know how many vehicles are traveling without using Bluetooth).
Slashdot Mirror
If things like the ReadyNAS Duo or NV+ are vulnerable that's an even bigger problem, because they're even less likely to be patched than the models used by businesses.
That's a good point, which I didn't make before (mostly) because I didn't think of it and (partially) because I don't know much about the technical details of USB and figured it might be possible for the controller chip to support mass storage devices but not printers (i.e., some sort of "limited USB host").
Point him at a "cloud" word processing app like Google Docs or something.
Yes, if an only if your router includes "print server" as an advertised feature. Otherwise the printer's plug will fit, but the router won't know what to do with it.
Let them claim an exemption and tell them to keep their receipts.
Make them either fix it or pay based on some assumed/average number of miles?
[citation needed]
Real programmers don't need to type fast.
You do have a point, though: I guess there's some argument to be made in favor of touch typing so that you can continue thinking about the problem while you type (instead of having to think about typing)...
Right. And my question is "why are car manufacturers different than everything else?" Is Apple not allowed to operate Apple Stores in Texas? Is Sears not allowed to sell Craftsman or Kenmore in Texas? Is Wal-Mart not allowed to sell Great Value brand products in Texas?
If all of these things are allowed, then car manufacturers (including not just Tesla, but the likes of Ford, VW and Toyota too) should also be able to operate corporate-owned stores in Texas. And contrapositively, if it's OK to disallow it for cars, then it should be OK to disallow it for any of the other things previously mentioned (a reductio ad absurdum, obviously).
We're debating the article, which barely mentions odometers (and even then, in the context of being connected to a GPS).
Well, you see, the defendant's lawyer never had the opportunity to argue because the defendant wasn't just ordered to give the hard drive up but rather was raided by police with no warning. That's kind of the entire problem...
Fixed that for you.
Well, preventing monopolies is a good thing in my book, but the monopoly would have to be over cars in general -- a manufacturer choosing to sell it's own product only directly is not a monopoly by definition, unless it's the only company in the entire industry (and the product is important enough to cause hardship if the customers can't buy it).
Besides, every other product is sold in normal third-party stores and may also be available straight from the manufacturer -- I just don't understand why it's magically different for cars. I mean, if I'm selling some widget over the Internet (maybe even something as trivial as a sweater on Etsy or something), do I have to first wholesale it to some third-party distributor in Texas? If not, why are the rules different Tesla?
I don't know what California's gun laws are like, but maybe that's true too!
No, because the laws preventing interstate sale of marijuana are Federal. (They may still be unconstitutional, but not because of the Interstate Commerce Clause.)
Perhaps it's not that young folks have never heard of the IRA, but rather that they didn't realize they attacked not only in Northern Ireland, but England itself too.
(I have to admit, the first thing I think of when the topic is brought up is Burn Notice, followed by Delorean.)
What gives Texas the authority to prevent any manufacturer -- of cars or otherwise -- from selling their products in the state? Couldn't this be construed as an illegal restraint of trade against the State of California?
Why do you say that? Given how terse C is, what I said should be even more true. Now maybe Cobol or Basic, on the other hand...
Oh. Sorry, in that case the answer was "I don't really care what the purpose as expressed in TFA is, I care about what vehicle detection systems are good for in general."
Besides, "mak[ing] traffic signal settings based on (the information)" as the article talks about is a flexible enough idea that it could encompass ad-hoc manual adjustments where speed-only data would be useful (although you'd still want to look at the cameras while you're doing it) as well as longer term design-and-engineer-a-better-default-timing kind of adjustments, where having the counts would be very helpful (particularly if you wanted to make them the input to a real-time signal adjustment algorithm -- in fact, in that case what I'd really want would be intersection movement counts, not just segment directional counts).
Long term, I'd suggest that the best plan would be to take the induction loops (which you need anyway for actuated signal timing) and hook them up to the traffic management software.
But then that makes me think... if he can already control the signals remotely, then the induction loop data should already be available too. I guess they haven't hooked the systems together yet (which was also the case where I worked: I could operate cameras and changeable message signs using the main application, but I had to fire up something else if I wanted to mess with a ramp meter).
This is different from reading license plates in that it's a lot less effective for tracking people (since bluetooth MAC addresses aren't tied to people's identities in a government database from the get-go like license plates are). It's also likely much cheaper.
One thing you should know is that I'm probably just as paranoid as you, but have also worked in the ITS (Intelligent Transportation Systems) field. I feel a lot more comfortable with Bluetooth-based vehicle detection systems (VDS) than I would with any of the alternatives you've proposed, from a privacy standpoint. (I still like "traditional-vision" or EM loop detection better, though.)
First of all, for the implementation of Bluetooth VDS I worked with, all we at the DOT had access to was the end-result vehicle speed data. I don't think any MAC addresses even got out of the vendor's systems.
Second, DOTs country-wide are chronically underfunded. It takes literally years to get simple things done, like replacing burnt-out projector screens in the monitoring center, let alone anything complicated like setting up a huge nefarious tracking database.
Third, beyond simply not caring about tracking individual cars (except maybe for origin-destination analysis), DOTs actively avoid retaining that kind of data. Even though the regular traffic cameras can record, it was policy not to use that function except for specific limited purposes (e.g. recording an exceptionally severe accident to analyze emergency response performance) because the DOT didn't want to have to process subpoenas for it later. And even if that were okay, if they routinely retained data but somehow lost the particular piece that was subpoenaed it'd be even worse.
Vehicle counts start to matter as soon as you want to do any kind of deeper engineering analysis or design. For example, you might want to be able to answer questions like "how do speeds correlate with volume -- do they drop linearly, or suddenly at some 'critical' volume?" or "how much excess capacity does my road have?" or "did this change I made to the road actually increase capacity, or did speeds just seem to improve because fewer people happen to be driving on it this week?"
In general, it's a lot more fun (as a traffic engineer) to have real-time data than it is to send somebody out in the field count data for one day out of a year (especially when, for all you know, that one day might be an outlier).
Not to mention, asking a traffic engineer to do anything without knowing vehicle counts is kind of like asking an electrical engineer to design a device without knowing how many amps it uses.
In the real "back in the day," "engines" were siege engines (e.g. ballistas and trebuchets). Civil engineers (who built everything except engines) are named such in order to distinguish them from military engineers.
Although I completely agree with your point, I feel to need to point out that if your programming speed is constrained by your typing speed, you're not doing nearly enough thinking.
Axle counters (and magnetic field loop detection and computer-vision-based detection, both of which are more common for the application we're talking about) do tell you the speed of the vehicles in every situation except for a major accident with all lanes blocked. And you can tell when that happens because the map turned from green to yellow to red before the data stopped.
It's worse, but cheaper. I don't know about the relative accuracy for reporting speeds, but it has the substantial disadvantage of not being able to report vehicle counts (since you don't know how many vehicles are traveling without using Bluetooth).