still, I wonder how far one could get coopting both the EXT connector on the bottom, and the cartridge slot. Use the EXT connecter for IO (including video and SPU channel) and use the cartridge slot for the snes-side program code, ram access, and return communications. A hardware mpeg decoder in the cartridge slot, with the mpeg stream coming in on the ext port or something maybe. Given that the screen resolution isnt so big to begin with, a few hundred kbps would be sufficient. (600 or so, iirc.)
Why somebody would go through all the effort is another matter entirely-- the point was that in theory, one could do this on a cartridge, and never hope to do so over USB.
Clearly, you do not understand the implications of what I said.
USB storage requires an entire operating system to even access. It requires a kernel OS process, a driver for the specific USB chipset attached to the system, and yet another driver for the filesystem stored on the device. In addition to this, it has to have multitasking capabilities to switch between reading and decoding the data on the device, and executing the read program code.
In stark contrast, a game cartridge requires no OS at all. The CPU simply jumps to the address location where the cartridge's ROM chip is logically assigned, and the CPU treats it exactly like it was fetching from RAM. The game is the ONLY thing running.
The better comparison would be "USB is the new data cassette!"
You can put all kinds of crazy things inside a cartridge that you simply could never put inside a USB stick. Things like additional RAM that runs at full speed, Whole new CPUs, an additional peripheral bus connector-- you name it.
In theory, a (crazy) person could take an old SNES console, and with a very purpose built cartridge, turn it into a playstation.
Really, the comparison you are drawing does not really reflect what a cartridge actually is.
Not exactly. A flashdrive is a serial bus peripheral that communicates using an encoded format.
A cartridge is typically little more than an exposed parallel logic bus that directly maps to the console's main memory. (Atari 2600 carts were literally a ROM chip, with its leads exposed on the card edge. Nothing else. http://www.hardwaresecrets.com... )
NES and SNES carts had special purpose chips on them to help page the address of the ROM inside the main CPU's memory space, and even a few special co-processors on occasion, but were still just a direct tie-in to the memory bus.
A DIMM and a cartridge have more in common than a USB stick does with a cartridge.
The theme is there, but it isn't so "In your face", no. When you think about it, the futuristic technology required didn't exist yet in the TOS timeline. They had food slots, but not "Hey bro, I can make any fucking thing you can fit in my compartment!" omni-fabrication like they do in TNG with pattern replicators. This meant that there was still some value for physical possessions and the like. The "Full on" utopia happens in TNG.
However, the underpinnings of that future utopia are present in TOS-- In several episodes the race and gender of Uhura get pulled up, and the crew has to calmly explain how such distinctions are handled in their century.
There are of course, many others where this issue was brought up, and the "Utopian future" vibe was strong.
It was very much a part of TOS.
As for exploding consoles-- I think that was more a gimmick because the viewing audience would not understand "Broken console" without smoke and sparks. Even today, think of the difficulty IT people have explaining things like "Bad capacitors" to non-technical people. ("But it works just fine, then starts to act funny! Can't you fix it!?")-- That is still just a diversion from the original statement though. Star Trek was envisioned as a vehicle for an optimistic future. That vehicle used cheap gimmicks to accomplish that goal, but it still focused on that goal. The new reboot keeps the gimmicks, but sheds that goal.
Because it sheds the ideological purpose that startrek was created for.
Startrek was by design, created to illustrate a damned-near utopian future where all races and genders work together as equals, and accomplish a society that all can be proud of.
In fact, Johnathan Frakes shares this little pearl of wisdom on the subject.
It is for this reason that I do not like the startrek reboot. It has shed its soul, to capitulate to the american audience's desire for boobies and explosions. It is not startrek.
That's unfortunate... I can see why it would be desirable by the manufacturer and dealer, (as it would enable quite a few shady practices by both), but I question how stable EEPROM is compared to PROM in the hazardous environment under the hood or dash. (I know some modern systems are installed under the center console between the front seats, and some are installed under the passenger or driver seat, but this is still a problematical location in terms of operating environment. Still has large fluctuations in ambient temperature and issues with moisture and corrosion.)
I have seen ODBII dongles made specifically for hotrodding that contain new fuel mix tables and timing data for the ignition control system, but havent really seen kits to completely re-flash the ICS's computer.
No need to do such extreme damage, when the same effect can be achieved with a simple fuse on the positive voltage line of the port. Suspicious activity? Burn the fuse-- BAM-- port is dead, but easily fixed.
However, this would require a "smart" component inside the dash, between the actual ignition control system/ACS system, and the ODBII port interface. Such a device would need to have a reference pattern to check current communications against, and would need some level of processing capacity to compare realtime engine diagnostic data and bus activity against the reference. (Does not need to be fancy here, but this does imply the ability to program a new reference pattern later, especially if the system is fully adaptive to changing engine conditions over time.)
This then places some significant implementation considerations on the vehicle manufacturer-- this device has to somehow be able to be field-reset at a dealership if it gets confused after having the engine serviced, and also needs to have nothing but read-only access to the engine's control system. The only thing it should have "write" access to should be the fuse. (And maybe an indicator lamp)
However, given the less than spectacular implementations of integrated devices in modern vehicles (in terms of security, and security oriented design/implementation) I question if such a device would be properly implemented.
I get the sneaky suspicion that the automaker would be... "tempted"... by dealerships and other retailers in the market to integrate lojack functionalty into the security device, thus making it itself into the target of exploits. (Otherwise, the purposeful activation of the intrusion failsafe would render actual lojacks incapable of stopping cars, by disabling the communication bus. This means removing the fuse would essentially disable such countermeasures.) This would then make "remove the dongle" no longer an option.
When presented with a choice between "properly implemented security" and "Pressure from their customers" (Auto manufacturers RARELY, if ever, sell directly to the public. THEIR customers are the dealerships.) , I expect automakers will choose to placate their customers every single time.
except that the firmware in the ignition control system of the vehicle is written on actual PROM chips, not EEPROM chips, because they have to operate in a hazardous environment. (Temperature extremes, moisture intrusion, dirt, corrosion, etc.) Voltage spikes from slowly decaying wiring, or other sources of irregularity can damage an EEPROM's contents, where a PROM will just burp a little, then be fine after the irregularity. (assuming it isnt a very large spike that can kill silicon anyway)
This means that the ODB2 interface (the little connector under the dash) can at best, only be used to circumvent proper engine function when another device is attached to the bus that has such programmability.
There most certainly ARE such devices on the market, such as the lojack type devices used to prevent vehicle theft on vehicles that arent paid off, etc-- used by used car lots and the like, but these are purposefully installed in a fashion that makes physical removal of the device difficult without the correct tools/equipment. The vehicle runs just fine without such devices attached.
In the case of one of these really shitty dongles, physical removal of the dongle should suffice. The vehicle would then operate with no outside manipulation of its ignition control system. They try ransoming the vehicle, just pull the dongle.
The bigger concern is possible malicious actions, such as "Murder by remote" type situations. The vehicle has such an exploitable device (with its lack of challenges against the network it is communicating with), and a murderer chooses to exploit this to make the ignition control system refuse to fire any of the spark plugs, or to drive any of the fuel injectors. The vehicle stalls while driving 70mph (or faster) on a crowded highway during a lane-change, or while passing. Perhaps the antilock brakes (automatic skid control systems have control over braking) are exploited, and the brakes on one side of the vehicle slam down while doing said 70mph, and the vehicle spins out of control or flips over.
Considering that there is absolutely NO protection here, (No challenge/response, no encryption, no verification of remote network authenticity, etc.) there is definitely room in the criminal underworld for such a remote exploit. Professional hitmen, (and government agencies) would love such a toy.
I mention this possible application, because the obvious one of insurance fraud has already been brought up a few times.
Still, the solution is the same. Physical removal of the dongle solves all the problems.
The problem with the latter approach, is that programmers spend time when they arent working, thinking about the problem they are being paid to work on when they are working.
EG, they may have the sudden epiphany while playing super mario brothers, that they have failed to have while sititng in their cublcle, trying so very hard to push that solution out under great duress from their manager.
Or, as archimedes had his epiphanies-- In the tub.
This is not a new thing, and creative problem solving REQUIRES downtime to be effective. The people that insist "You arent applying yourself all the way, therefor I will ding you on your reviews!" are a problem, not a solution.
Usually with the closed source applications, you send in the bug report, and it appears to vanish from your end. There is no feedback from the bug treacking team. There is no update on if the issue is pending more data (which you could supply if they ask. Clearly the bug was severe enough to warrant a report, so clearly you must run into it fairly frequently-- but no-- no access to the bug tracker, so you dont see the comments about "Cant reproduce! closing!" getting thrown about in there) or even if the bug gets closed with "Working as expected, wont fix"
Nope, you get a "Send us a bug report! Fill out this window (which has a max size text field, so keep it contrite!) and hit submit to send it on its way to digital purgatory!
You dont get informed when a fix will be incorporated, you dont get informed of any work arounds. Nada.
Compare that with FOSS bug trackers, and it is night and day.
All you need is a few kilobytes of storage. Most phones have this already in the underlying hardware for use with things like the region ID and the like.
Seriously, each entry in the blacklist needs only the UUID of the blacklisted tower. That's it. Hell, this could live in the damned SIM card.
You havent been following the stories on stingray use, have you?
Law enforcement agencies use them to eavesdrop on multiple cellular devices in the espionage radius, hoping to catch thier perps. the data of innocent civilians driving past also gets logged. this has been reported on. it is not handset specific.
the illegality of the practice does not seem to matter much except when the triale judge demands to know the source of the evidence. Even then, law enforcement frequently LIES about using stingrays.
a community method of tracking and recording stingray deployments in large urban centers that is public domain would open the doors to some serious FOIA request hilarity.
"hello, NYPD? yes, according to OpenTowerMap.Org, it appears that a new cell tower with unique ID XXXXXXXX went into operation in the area near to where your investigation into Nicky the Nose was going on, suspiciously consistent with the length of your investigation. Since your investigation agrainst Mr Nose has concluded, there should be no reason whatsoever to deny my request for any information you have on the use of a cellular monitoring device during that period at that location. Specifically, we want to know how many non-suspects accessed the device, and what the current status of thier records is, and also what degree or level of transparency your agency has taken to inform those innocent citizens that thier data was collected as part of your investigation."
One still needs a way to prevent the cellular device from being pushed to the "New" tower.
Sadly, handset makers and mobile OS makers have not been able to give a "Blacklist tower" feature, or have not been willing to give such a feature. The towers MUST be uniquely identifiable for the tower mesh network to communicate reliably-- so, a means of uniquely identifying and refusing to play ball with a specific "Tower" should absolutely be possible.
Google and Apple should step up to the plate on that.
A better approach would be to keep a triangulation map of available towers over time.
The point of stingrays is that they are mobile. Cell towers are NOT. Similar to older war-driving apps, the app looks for tower broadcast signals, even when it does not intend to hop. It keeps a record of the GPS coordinates of the handset (Seriously, a smartphone without a gps these days?) and the detected signal levels of all towers it sees.
It then builds a virtual geographical map of cellular towers based on its own radio data over time. The sudden, mysterious appearance of a new tower where there previously was not one, (and also where there does not seem to be capacity reason for one to be added, or one with a suspiciously small radius of service) would get flagged, and should get blacklisted by the phone until the user specifically says "No, it's OK to connect" (It may be a microcell at a crowded event or something)
That should allow creation of a stable whitelist over time.
I'm glad that there's a COTS solution for this, but I suspect that a lot more control could be had with an actual logic controller or mini computer. Other than the soundboard/mp3 playback function (are there any good linux applications for this? I know there are many MP3 players that can be invoked from the console (eg, via an SSH session) but the soundboard would be a bit of an issue) a Raspberry Pi or a BeagleBone with a few diodes, transistors and resistors could drive a shitload of lights in obscene complexity. (Over 32 PIO lines on a beaglebone. Using a common ground and switched voltage sources, one could drive 32 strings of lights directly. Accessing the PIO pins is pretty easy, and can be done with a simple shell script; but this gets into programming, which the OP explicitly stated they wanted to avoid. Though I admit controlling all the pins in full parallel may be tricky. May need to sacrifice one of the IO pins to signal the voltage controller to activate/deactivate. That gives 31 strings, and 1 go/stop signal.)
I dont consider shell script all that painful though. Writing some kind of plugin for a commandline based MP3 player? that's gonna take more doing. Glad there is a COTS solution for the OP after-all.
The OP would stand to learn more using the beaglebone though. If he switched from parallel (easier to program) to a serial protocol, his same compute node could drive several million lights, but would need a much more sophisticated voltage switching board.
I am kinda surprised that there isnt already a sheild kit for this.
desalination plants are likely to have some serious issues with CA in general.
1) They arent very pretty, and will HAVE to be on the coast. This makes NIMBYism a very real problem for any project that works with desalinators.
2) CA has some insane environmental effluent rules. Desalination plants dont just wave magic wands at the salt. In addition to concentrating fresh water, they also concentrate salt. This is usually in the form of very briny water if RO desalination is used, and in the form of crude, non-food grade salt id evaporation plants are used. Both are dangerous contaminants that need to be disposed ofl and in large quantities. Simply dumping the salt back into the ocean wont work-- it will kill local marine life.
3) Desalinators will present a major power consumption drain on CA's already overtaxed power and light infrastructure.
4) Logistics and civic planning to have the water pipeleines from the desalinators routed to where the croplands in the valleys impacted by the drought need the water most is not going to be a trivial matter. Expect political BS to delay, delay, delay as everyone tries to get the biggest slice of the water produced, or get consessions for allowing transport.
You seem to have mis-identified my political affiliation. I am not a marxist communist. I have simply read the manifesto, and marx's rhetoric. I was pointing out that the AC above had clearly not done so, having created such a strawman to beat.
Genuine criticisms, such as "You cant cultivate marginal lands as if they were fully arable! It's madness!" are fully fair game, and I apply them with gusto. However, asserting blandly that Marx had not contemplated human nature? That's clearly not supported by his rhetoric, but is rather a consequence of ingesting pre-chewed propaganda pieces.
I value correct, well based arguments. that's why I bothered to read Marx's rhetoric in the first place. It is a necessity to develop and use proper analytic skills.
Does Marxism work? Fuck no. Did Marx think about the freeloader problem? Definitely.
That latter part is all I was trying to point out. It never ceases to amaze me how such a correction makes people instantly apply "You must be a marxist!" as a reactionary measure.
Clearly you have not actually READ the manifesto,or much of Marx's rhetoric. Marx does indeed rail against freeloading, and outright says that any system that permits it cannot be sustained, as the number of freeloaders will rapidly outpace the number of producers, bankrupting the system. (in general in his rhetoric)
In fact, he sets the univeral requirement of *ALL* to labor, as bulleted item #8 in his manifesto.
These measures will of course be different in different countries.
Nevertheless in the most advanced countries, the following will be pretty generally applicable.
1. Abolition of property in land and application of all rents of land to public purposes.
2. A heavy progressive or graduated income tax.
3. Abolition of all right of inheritance.
4. Confiscation of the property of all emigrants and rebels.
5. Centralisation of credit in the hands of the State, by means of a national bank with State capital and an exclusive monopoly.
6. Centralisation of the means of communication and transport in the hands of the State.
7. Extension of factories and instruments of production owned by the State; the bringing into cultivation of waste-lands, and the improvement of the soil generally in accordance with a common plan.
8. Equal liability of all to labour. Establishment of industrial armies, especially for agriculture.
9. Combination of agriculture with manufacturing industries; gradual abolition of the distinction between town and country, by a more equable distribution of the population over the country.
10. Free education for all children in public schools. Abolition of children's factory labour in its present form. Combination of education with industrial production, &c., &c.
(Found in chapter 2 of the manifesto, in case you wondered)
Marx is not strictly against the providence of support for those that are physically unable to labor anymore, he just stresses the insistence that these cases need to be strictly evaluated, and limited in number, otherwise they will overtake production, and the system will collapse. For those that are able to lablor-- even just a little-- Marx asserts that it is their duty to perform such labor. This means that the paraplegic in the wheelchair goes to work doing something with his hands that does not require the use of his legs, and in return, gets the fruits of the redistribution of wealth, same as a person who has legs-- etc. Marxist rhetoric is very much against "Full disability" type welfare, except where it quite literally is true that the person cannot work at all.
And where they have partnerships with other distributors, they pass blame to evade doing either (until you can definitively prove that their appliance is at fault.)
Slashdot Mirror
I said "in theory". The devil's in the details.
still, I wonder how far one could get coopting both the EXT connector on the bottom, and the cartridge slot. Use the EXT connecter for IO (including video and SPU channel) and use the cartridge slot for the snes-side program code, ram access, and return communications. A hardware mpeg decoder in the cartridge slot, with the mpeg stream coming in on the ext port or something maybe. Given that the screen resolution isnt so big to begin with, a few hundred kbps would be sufficient. (600 or so, iirc.)
Why somebody would go through all the effort is another matter entirely-- the point was that in theory, one could do this on a cartridge, and never hope to do so over USB.
Clearly, you do not understand the implications of what I said.
USB storage requires an entire operating system to even access. It requires a kernel OS process, a driver for the specific USB chipset attached to the system, and yet another driver for the filesystem stored on the device. In addition to this, it has to have multitasking capabilities to switch between reading and decoding the data on the device, and executing the read program code.
In stark contrast, a game cartridge requires no OS at all. The CPU simply jumps to the address location where the cartridge's ROM chip is logically assigned, and the CPU treats it exactly like it was fetching from RAM. The game is the ONLY thing running.
The better comparison would be "USB is the new data cassette!"
You can put all kinds of crazy things inside a cartridge that you simply could never put inside a USB stick. Things like additional RAM that runs at full speed, Whole new CPUs, an additional peripheral bus connector-- you name it.
In theory, a (crazy) person could take an old SNES console, and with a very purpose built cartridge, turn it into a playstation.
Really, the comparison you are drawing does not really reflect what a cartridge actually is.
And apparently the site I linked does not like hard links. Meh. Whatever. Just image search for "2600 cartridge interior", you will find it.
Not exactly. A flashdrive is a serial bus peripheral that communicates using an encoded format.
A cartridge is typically little more than an exposed parallel logic bus that directly maps to the console's main memory. (Atari 2600 carts were literally a ROM chip, with its leads exposed on the card edge. Nothing else. http://www.hardwaresecrets.com... )
NES and SNES carts had special purpose chips on them to help page the address of the ROM inside the main CPU's memory space, and even a few special co-processors on occasion, but were still just a direct tie-in to the memory bus.
A DIMM and a cartridge have more in common than a USB stick does with a cartridge.
The theme is there, but it isn't so "In your face", no. When you think about it, the futuristic technology required didn't exist yet in the TOS timeline. They had food slots, but not "Hey bro, I can make any fucking thing you can fit in my compartment!" omni-fabrication like they do in TNG with pattern replicators. This meant that there was still some value for physical possessions and the like. The "Full on" utopia happens in TNG.
However, the underpinnings of that future utopia are present in TOS-- In several episodes the race and gender of Uhura get pulled up, and the crew has to calmly explain how such distinctions are handled in their century.
https://www.youtube.com/watch?...
(Yes-- that is abaham lincoln-- or rather, a facsimile of lincoln made by aliens)
There are of course, many others where this issue was brought up, and the "Utopian future" vibe was strong.
It was very much a part of TOS.
As for exploding consoles-- I think that was more a gimmick because the viewing audience would not understand "Broken console" without smoke and sparks. Even today, think of the difficulty IT people have explaining things like "Bad capacitors" to non-technical people. ("But it works just fine, then starts to act funny! Can't you fix it!?")-- That is still just a diversion from the original statement though. Star Trek was envisioned as a vehicle for an optimistic future. That vehicle used cheap gimmicks to accomplish that goal, but it still focused on that goal. The new reboot keeps the gimmicks, but sheds that goal.
Because it sheds the ideological purpose that startrek was created for.
Startrek was by design, created to illustrate a damned-near utopian future where all races and genders work together as equals, and accomplish a society that all can be proud of.
In fact, Johnathan Frakes shares this little pearl of wisdom on the subject.
https://www.youtube.com/watch?...
It is for this reason that I do not like the startrek reboot. It has shed its soul, to capitulate to the american audience's desire for boobies and explosions. It is not startrek.
That's unfortunate... I can see why it would be desirable by the manufacturer and dealer, (as it would enable quite a few shady practices by both), but I question how stable EEPROM is compared to PROM in the hazardous environment under the hood or dash. (I know some modern systems are installed under the center console between the front seats, and some are installed under the passenger or driver seat, but this is still a problematical location in terms of operating environment. Still has large fluctuations in ambient temperature and issues with moisture and corrosion.)
I have seen ODBII dongles made specifically for hotrodding that contain new fuel mix tables and timing data for the ignition control system, but havent really seen kits to completely re-flash the ICS's computer.
Guess you learn something new every day.
No need to do such extreme damage, when the same effect can be achieved with a simple fuse on the positive voltage line of the port. Suspicious activity? Burn the fuse-- BAM-- port is dead, but easily fixed.
However, this would require a "smart" component inside the dash, between the actual ignition control system/ACS system, and the ODBII port interface. Such a device would need to have a reference pattern to check current communications against, and would need some level of processing capacity to compare realtime engine diagnostic data and bus activity against the reference. (Does not need to be fancy here, but this does imply the ability to program a new reference pattern later, especially if the system is fully adaptive to changing engine conditions over time.)
This then places some significant implementation considerations on the vehicle manufacturer-- this device has to somehow be able to be field-reset at a dealership if it gets confused after having the engine serviced, and also needs to have nothing but read-only access to the engine's control system. The only thing it should have "write" access to should be the fuse. (And maybe an indicator lamp)
However, given the less than spectacular implementations of integrated devices in modern vehicles (in terms of security, and security oriented design/implementation) I question if such a device would be properly implemented.
I get the sneaky suspicion that the automaker would be ... "tempted" ... by dealerships and other retailers in the market to integrate lojack functionalty into the security device, thus making it itself into the target of exploits. (Otherwise, the purposeful activation of the intrusion failsafe would render actual lojacks incapable of stopping cars, by disabling the communication bus. This means removing the fuse would essentially disable such countermeasures.) This would then make "remove the dongle" no longer an option.
When presented with a choice between "properly implemented security" and "Pressure from their customers" (Auto manufacturers RARELY, if ever, sell directly to the public. THEIR customers are the dealerships.) , I expect automakers will choose to placate their customers every single time.
except that the firmware in the ignition control system of the vehicle is written on actual PROM chips, not EEPROM chips, because they have to operate in a hazardous environment. (Temperature extremes, moisture intrusion, dirt, corrosion, etc.) Voltage spikes from slowly decaying wiring, or other sources of irregularity can damage an EEPROM's contents, where a PROM will just burp a little, then be fine after the irregularity. (assuming it isnt a very large spike that can kill silicon anyway)
This means that the ODB2 interface (the little connector under the dash) can at best, only be used to circumvent proper engine function when another device is attached to the bus that has such programmability.
There most certainly ARE such devices on the market, such as the lojack type devices used to prevent vehicle theft on vehicles that arent paid off, etc-- used by used car lots and the like, but these are purposefully installed in a fashion that makes physical removal of the device difficult without the correct tools/equipment. The vehicle runs just fine without such devices attached.
In the case of one of these really shitty dongles, physical removal of the dongle should suffice. The vehicle would then operate with no outside manipulation of its ignition control system. They try ransoming the vehicle, just pull the dongle.
The bigger concern is possible malicious actions, such as "Murder by remote" type situations. The vehicle has such an exploitable device (with its lack of challenges against the network it is communicating with), and a murderer chooses to exploit this to make the ignition control system refuse to fire any of the spark plugs, or to drive any of the fuel injectors. The vehicle stalls while driving 70mph (or faster) on a crowded highway during a lane-change, or while passing. Perhaps the antilock brakes (automatic skid control systems have control over braking) are exploited, and the brakes on one side of the vehicle slam down while doing said 70mph, and the vehicle spins out of control or flips over.
Considering that there is absolutely NO protection here, (No challenge/response, no encryption, no verification of remote network authenticity, etc.) there is definitely room in the criminal underworld for such a remote exploit. Professional hitmen, (and government agencies) would love such a toy.
I mention this possible application, because the obvious one of insurance fraud has already been brought up a few times.
Still, the solution is the same. Physical removal of the dongle solves all the problems.
The problem with the latter approach, is that programmers spend time when they arent working, thinking about the problem they are being paid to work on when they are working.
EG, they may have the sudden epiphany while playing super mario brothers, that they have failed to have while sititng in their cublcle, trying so very hard to push that solution out under great duress from their manager.
Or, as archimedes had his epiphanies-- In the tub.
This is not a new thing, and creative problem solving REQUIRES downtime to be effective. The people that insist "You arent applying yourself all the way, therefor I will ding you on your reviews!" are a problem, not a solution.
Usually with the closed source applications, you send in the bug report, and it appears to vanish from your end. There is no feedback from the bug treacking team. There is no update on if the issue is pending more data (which you could supply if they ask. Clearly the bug was severe enough to warrant a report, so clearly you must run into it fairly frequently-- but no-- no access to the bug tracker, so you dont see the comments about "Cant reproduce! closing!" getting thrown about in there) or even if the bug gets closed with "Working as expected, wont fix"
Nope, you get a "Send us a bug report! Fill out this window (which has a max size text field, so keep it contrite!) and hit submit to send it on its way to digital purgatory!
You dont get informed when a fix will be incorporated, you dont get informed of any work arounds. Nada.
Compare that with FOSS bug trackers, and it is night and day.
Yes. I KNOW.
If you had READ THE WHOLE THING, you would have seen the parenthetical comment at the end about how the micro cell could be at an event!)
For fuck's sake, this is the last comment like this I am going to respond to!
All you need is a few kilobytes of storage. Most phones have this already in the underlying hardware for use with things like the region ID and the like.
Seriously, each entry in the blacklist needs only the UUID of the blacklisted tower. That's it. Hell, this could live in the damned SIM card.
Everything else can live in the app.
You havent been following the stories on stingray use, have you?
Law enforcement agencies use them to eavesdrop on multiple cellular devices in the espionage radius, hoping to catch thier perps. the data of innocent civilians driving past also gets logged. this has been reported on. it is not handset specific.
the illegality of the practice does not seem to matter much except when the triale judge demands to know the source of the evidence. Even then, law enforcement frequently LIES about using stingrays.
a community method of tracking and recording stingray deployments in large urban centers that is public domain would open the doors to some serious FOIA request hilarity.
"hello, NYPD? yes, according to OpenTowerMap.Org, it appears that a new cell tower with unique ID XXXXXXXX went into operation in the area near to where your investigation into Nicky the Nose was going on, suspiciously consistent with the length of your investigation. Since your investigation agrainst Mr Nose has concluded, there should be no reason whatsoever to deny my request for any information you have on the use of a cellular monitoring device during that period at that location. Specifically, we want to know how many non-suspects accessed the device, and what the current status of thier records is, and also what degree or level of transparency your agency has taken to inform those innocent citizens that thier data was collected as part of your investigation."
etc.
I know. the problem is that it is impossible to tell a legit microcell from a totally not legit stingray.
the default should be "suspicious: do not use", with an option to manually enable.
the user will know if they are at a major civic event or not, and hopefully will know when they are under a major emergency situation.
I'd say that depends on the cellular technology in question.
Most likely the signals will be in the 700-850mhz band, or the 1700-2100mhz band, depending on the technology and carrier.
I Do think that this is technically inside the RTL-SDR dongle's reception capabilities.
One still needs a way to prevent the cellular device from being pushed to the "New" tower.
Sadly, handset makers and mobile OS makers have not been able to give a "Blacklist tower" feature, or have not been willing to give such a feature. The towers MUST be uniquely identifiable for the tower mesh network to communicate reliably-- so, a means of uniquely identifying and refusing to play ball with a specific "Tower" should absolutely be possible.
Google and Apple should step up to the plate on that.
A better approach would be to keep a triangulation map of available towers over time.
The point of stingrays is that they are mobile. Cell towers are NOT.
Similar to older war-driving apps, the app looks for tower broadcast signals, even when it does not intend to hop. It keeps a record of the GPS coordinates of the handset (Seriously, a smartphone without a gps these days?) and the detected signal levels of all towers it sees.
It then builds a virtual geographical map of cellular towers based on its own radio data over time. The sudden, mysterious appearance of a new tower where there previously was not one, (and also where there does not seem to be capacity reason for one to be added, or one with a suspiciously small radius of service) would get flagged, and should get blacklisted by the phone until the user specifically says "No, it's OK to connect" (It may be a microcell at a crowded event or something)
That should allow creation of a stable whitelist over time.
I'm glad that there's a COTS solution for this, but I suspect that a lot more control could be had with an actual logic controller or mini computer. Other than the soundboard/mp3 playback function (are there any good linux applications for this? I know there are many MP3 players that can be invoked from the console (eg, via an SSH session) but the soundboard would be a bit of an issue) a Raspberry Pi or a BeagleBone with a few diodes, transistors and resistors could drive a shitload of lights in obscene complexity. (Over 32 PIO lines on a beaglebone. Using a common ground and switched voltage sources, one could drive 32 strings of lights directly. Accessing the PIO pins is pretty easy, and can be done with a simple shell script; but this gets into programming, which the OP explicitly stated they wanted to avoid. Though I admit controlling all the pins in full parallel may be tricky. May need to sacrifice one of the IO pins to signal the voltage controller to activate/deactivate. That gives 31 strings, and 1 go/stop signal.)
I dont consider shell script all that painful though. Writing some kind of plugin for a commandline based MP3 player? that's gonna take more doing. Glad there is a COTS solution for the OP after-all.
The OP would stand to learn more using the beaglebone though. If he switched from parallel (easier to program) to a serial protocol, his same compute node could drive several million lights, but would need a much more sophisticated voltage switching board.
I am kinda surprised that there isnt already a sheild kit for this.
desalination plants are likely to have some serious issues with CA in general.
1) They arent very pretty, and will HAVE to be on the coast. This makes NIMBYism a very real problem for any project that works with desalinators.
2) CA has some insane environmental effluent rules. Desalination plants dont just wave magic wands at the salt. In addition to concentrating fresh water, they also concentrate salt. This is usually in the form of very briny water if RO desalination is used, and in the form of crude, non-food grade salt id evaporation plants are used. Both are dangerous contaminants that need to be disposed ofl and in large quantities. Simply dumping the salt back into the ocean wont work-- it will kill local marine life.
3) Desalinators will present a major power consumption drain on CA's already overtaxed power and light infrastructure.
4) Logistics and civic planning to have the water pipeleines from the desalinators routed to where the croplands in the valleys impacted by the drought need the water most is not going to be a trivial matter. Expect political BS to delay, delay, delay as everyone tries to get the biggest slice of the water produced, or get consessions for allowing transport.
You seem to have mis-identified my political affiliation. I am not a marxist communist. I have simply read the manifesto, and marx's rhetoric. I was pointing out that the AC above had clearly not done so, having created such a strawman to beat.
Genuine criticisms, such as "You cant cultivate marginal lands as if they were fully arable! It's madness!" are fully fair game, and I apply them with gusto. However, asserting blandly that Marx had not contemplated human nature? That's clearly not supported by his rhetoric, but is rather a consequence of ingesting pre-chewed propaganda pieces.
I value correct, well based arguments. that's why I bothered to read Marx's rhetoric in the first place. It is a necessity to develop and use proper analytic skills.
Does Marxism work? Fuck no.
Did Marx think about the freeloader problem? Definitely.
That latter part is all I was trying to point out. It never ceases to amaze me how such a correction makes people instantly apply "You must be a marxist!" as a reactionary measure.
Please avoid doing so in the future. Thank you.
Clearly you have not actually READ the manifesto,or much of Marx's rhetoric. Marx does indeed rail against freeloading, and outright says that any system that permits it cannot be sustained, as the number of freeloaders will rapidly outpace the number of producers, bankrupting the system. (in general in his rhetoric)
In fact, he sets the univeral requirement of *ALL* to labor, as bulleted item #8 in his manifesto.
These measures will of course be different in different countries.
Nevertheless in the most advanced countries, the following will be pretty generally applicable.
1. Abolition of property in land and application of all rents of land to public purposes.
2. A heavy progressive or graduated income tax.
3. Abolition of all right of inheritance.
4. Confiscation of the property of all emigrants and rebels.
5. Centralisation of credit in the hands of the State, by means of a national bank with State capital and an exclusive monopoly.
6. Centralisation of the means of communication and transport in the hands of the State.
7. Extension of factories and instruments of production owned by the State; the bringing into cultivation of waste-lands, and the improvement of the soil generally in accordance with a common plan.
8. Equal liability of all to labour. Establishment of industrial armies, especially for agriculture.
9. Combination of agriculture with manufacturing industries; gradual abolition of the distinction between town and country, by a more equable distribution of the population over the country.
10. Free education for all children in public schools. Abolition of children's factory labour in its present form. Combination of education with industrial production, &c., &c.
(Found in chapter 2 of the manifesto, in case you wondered)
Marx is not strictly against the providence of support for those that are physically unable to labor anymore, he just stresses the insistence that these cases need to be strictly evaluated, and limited in number, otherwise they will overtake production, and the system will collapse. For those that are able to lablor-- even just a little-- Marx asserts that it is their duty to perform such labor. This means that the paraplegic in the wheelchair goes to work doing something with his hands that does not require the use of his legs, and in return, gets the fruits of the redistribution of wealth, same as a person who has legs-- etc. Marxist rhetoric is very much against "Full disability" type welfare, except where it quite literally is true that the person cannot work at all.
Remote activated tazer/stun-gun sounds interesting. Tear gas canister would also be possible I suppose...
Wonder when the hostage crisis teams of the world will start to send in telepresence robots with active weapons systems...
And where they have partnerships with other distributors, they pass blame to evade doing either (until you can definitively prove that their appliance is at fault.)
(But to be fair, VMware does that too.)
(Well, It was "aimed" at kids.. but I wonder...)
"Hey kids, this must be your dad-- I didn't know he was a talking head!"
Prof Membrane shows up as the floating head just as often (if not more often) than not.