Contemporary electronics are fairly reliable. The chances of the camera failing at the exact moment of confrontation further diminish by a few orders of magnitude the likelihood that a just-in-time malfunction isn't due to intentional tampering with evidence. Cops can't but know that should any court case result from a confrontation, their camera footage is evidence, and if you tamper with it, the court should be handing you your ass on a platter. You're entirely wrong that we don't need the courts now, we need courts precisely so that people who tamper with evidence, no matter what the profession is, are to be held accountable.
Better than break even energy production is somewhat irrelevant at the atomic scale. We're talking here about system efficiency. Yes of course if it's worse than break even at atomic scale, it has no chance of break even at system scale, but the inverse holds true only when you retain the word "chance". If it has net energy production at atomic scale, it has a chance to work as a system. Then you need some very hard engineering to extract that energy, and to provide initial energy to the reaction in such a way that things work as they should.
Do you know about the errors since you inspect some error status or get exceptions? Does the data returned look like garbage as well, or is it a case of good data with incorrect error feedback?
except if you try to talk via Microsoft's.net serial libraries which weirdly introduce random framing errors
In asynchronous serial terms, a framing error other than a break condition can only be generated by malfunctioning hardware, EMI or a collision on a multi-node bus. A.net library can't do it, because the underlying OS API doesn't expose any interfaces for you to do it. Now the UART hardware of course has transmitter and receiver enable bits that you could flip to simulate a framing error, but that's not what's happening here. Now if you refer to the fact that just because you write() some bytes, they aren't necessarily contiguous on the wire (without pauses) - then well, you never were supposed to depend on that anyway. A lot of serial protocol implementations are done by people who have never bothered to look at the wire with an oscilloscope, and who never understood the limitations of the medium. It is "simple", so people stop thinking - yeah, it's simple, so we do whatever the heck we want 'cuz it's so simple.
Not so. Serial stacks on most modern OSes give you zero guarantees as to segmentation of the data. That means that if you write() a certain amount of bytes, for all you know they may be sent on the wire one-by-one with several ms worth of a pause between them. There's simply no guarantee in the design of the protocol stack to protect you from that. It's not ethernet. You can expect certain idle time limits to be reasonable, and exceeding them can be considered an error that you then recover from by re-sending whatever it was that has failed. But then your protocol better had numbered packets, numbered replies, a sliding window, and well defined semantics of what happens upon an error. For some applications discarding all further packets until the bad one is re-sent is the right thing to do. For other applications sending that one packet later while accepting the other ones is the way to go. It needs to be figured on a case-by-case basis.
Same limitations apply to the receive direction. A number of bytes sent contiguously on the wire by the device can be chopped up and have to be read in multiple read()s. When you receive data, you need to acquire timestamps after each read and keep track of timeout counters. Some serial APIs help with that, but you need to be clever and validate the implementations to make sure they perform the way you think they do. Some APIs only have timing accurate to the system timer tick; on Windows it will usually be more than 10ms. There's no way around the engineering process here: instead of just brushing things off as "simple", you have to characterize the performance of the system you depend on, and then implement the code and the protocol so that it works in presence of those limitations.
I've been dealing with various industrial and ad-hoc communication protocols for the last decade, and all I know is that most protocols are designed by people who have no idea about what it is that they are doing. I know this partly because I've at first committed the same mistakes I now know to avoid. You'd think, though, that serious established companies out there can afford people who know what they are doing.
I think those devices have transceiver chips that are broken, because the RS-232 specification for the receiver certainly requires it to work with +/-3V levels - those are considered the minimum levels, in fact. Anything between +3 to +15V and -3V to -15V is a valid logic level. If you have an RS-232 receiver that doesn't work with +/-6V signals, it's broken, plain and simple. I've designed some RS232-powered devices and they obviously had to work through the range of allowed logic level voltages. There's good engineering, then there's cargo cultism. I prefer the former.
This is some serious bullshit about the FTDI drivers, and I don't like them but you just don't know what you're talking about I think.
On linux you have two "ftdi" drivers: there's the open source one that's part of the kernel and it shouldn't be problematic. It's maintained and it uses the usbserial infrastructure that's used for many other devices. I can't see it having such problems. The FTDI-provided "driver" is 100% userspace and uses libusb, so if that leaks kernel resources, man, you better posted about it on LKML or something.
On Mac OS X, the FTDI driver is, again, userspace-only and uses libusb. Now libusb on OS X is a horrible hack IMHO, but that's besides the point. If it leaks kernel resources, you better file a bug with Apple.
As for Windows FTDI driver - it's semi-reasonable.
I think that you've got FTDI's chip mixed up with another popular chip that's available from multiple sources and there indeed the driver situation is bad.
You can still buy USB floppy drives. They were very popular when macs dropped internal floppy drives. Mac-based labs were full of those things back around 2000.
It could probably be done very nicely using today's components. You'd pretty much need distributed I/O, and one modern PC-based PLC would take care of keeping things running. Compared to legacy hardware, a codesys environment running on a modern i7 or Xeon box can really do what dozens of legacy PLCs had to do before. It's much easier to develop since everything is on one system, and you have modern IP-based communications available to tweak things.
An RS232-to-Ethernet device is should be essentially a hardened Raspberry Pi running a modern Linux, configured for security. The communications should be established using ssh configured for login only using known keys. This can be set up relatively easily to be pretty foolproof and can probably beat 99.99% of commercial products out there when it comes to security. It's really not that hard.
From what I'm reading it seems that a runaway neutron-producing reaction that could cost millions USD in cleanup can be done with readily available materials in milligram quantities. A few micrograms worth of slow neutrons injected into stuff around you is seriously bad news.
I'm not in the minority due to my vision, but due to knowledge of what's there and how artifacts look. People who know a bit about video encoding make extremely poor test subjects - their results are always worse than general public's. People just don't care and don't know, that's all.
If the shutter spends too much of its time closed, the illusion of motion is lost.
Nope, the image simply gets progressively darker. This analogy doesn't apply to monitors that usually don't blank the LED backlight while the pixels change state. Now they obviously could blank the backlight since LEDs are more than fast enough. You'd trade off reduced perceived image intensity for crisper, less "muddy" image as you wouldn't be seeing the desired pixel values averaged with values from the transition.
Bullshit. At 10 feet from a 32" screen I can not only tell the difference between a DVD and a 720p, I can also tell the difference between high and low bitrate SD on cable channels. Different channels have different bitrates, my provider for example likes absolutely killing content for children of all ages. Sometimes it looks as bad as Indeo-encoded samples that came with Windows 95, if people still remember that:)
Chip layout could use such monitors, as long as you have good vision; good vision with corrective lenses is of course fine, too. Perhaps GIS applications, and maybe some kinds of CAD as well. Just off the top of my head.
The last thing a street thug expects is a stun grenade blowing up nearby. The element of surprise is enough. Since you expect it detonating within a second or two, you wrap your arms around your ears, and that's sufficient protection. All the while you keep going forward. As for the taser, I'm talking of one that has fixed electrodes and is used at close range. Those are quite safe for the one wielding them, and there's no such thing as them not working. As long as you can get into close proximity so that you can touch it to the body of the perp, that's it. Sometimes it's even lethal, if you're unlucky. A few seconds is enough to get to your target and tase him. I've been through such "treatment" myself as an experiment, and as long as you're not expecting it, it's about as effective as a temporary paralysis. Hitting a brick wall while walking would be a more pleasant experience I'd think. You'd need to be trained to recover from such situations. I doubt that most home invaders have such training. If they had some training, they'd know how to take you down without you noticing what hit you.
Detecting a particular sink that you've used is an option that may or may not work in a particular environment. Detecting washing hands is, from what I've looked at, a foregone conclusion.
Discrete problems are often approximations of some continuous problems, and the continuous problems may be easier to pose or easier to make proofs about. So, here comes one of my favorite Feynman stories:
The router of the Connection Machine was the part of the hardware that allowed the processors to communicate. It was a complicated device; by comparison, the processors themselves were simple. Connecting a separate communication wire between each pair of processors was impractical since a million processors would require 1E12 wires. Instead, we planned to connect the processors in a 20-dimensional hypercube so that each processor would only need to talk to 20 others directly. Because many processors had to communicate simultaneously, many messages would contend for the same wires. The router's job was to find a free path through this 20-dimensional traffic jam or, if it couldn't, to hold onto the message in a buffer until a path became free. Our question to Richard Feynman was whether we had allowed enough buffers for the router to operate efficiently.
During those first few months, Richard began studying the router circuit diagrams as if they were objects of nature. He was willing to listen to explanations of how and why things worked, but fundamentally he preferred to figure out everything himself by simulating the action of each of the circuits with pencil and paper.
[...]
By the end of that summer of 1983, Richard had completed his analysis of the behavior of the router, and much to our surprise and amusement, he presented his answer in the form of a set of partial differential equations. To a physicist this may seem natural, but to a computer designer, treating a set of boolean circuits as a continuous, differentiable system is a bit strange. Feynman's router equations were in terms of variables representing continuous quantities such as "the average number of 1 bits in a message address." I was much more accustomed to seeing analysis in terms of inductive proof and case analysis than taking the derivative of "the number of 1's" with respect to time. Our discrete analysis said we needed seven buffers per chip; Feynman's equations suggested that we only needed five. We decided to play it safe and ignore Feynman.
The decision to ignore Feynman's analysis was made in September, but by next spring we were up against a wall. The chips that we had designed were slightly too big to manufacture and the only way to solve the problem was to cut the number of buffers per chip back to five. Since Feynman's equations claimed we could do this safely, his unconventional methods of analysis started looking better and better to us. We decided to go ahead and make the chips with the smaller number of buffers.
Fortunately, he was right. When we put together the chips the machine worked. The first program run on the machine in April of 1985 was Conway's game of Life.
given a perfectly efficient pump of HP x and a cylindrical container of dimensions x and y filled to height z how long would it take to drain to level z-b
Interesting - that's the kind of stuff the brighter students at my high school were expected to be able to do in grade 11:/
Functional programming is a bit of a fad right now
Functional programming's main benefit is that it's much easier to prove theorems about functional programming code. If you want a hard-core mathematical proof that your code fulfills certain post-conditions etc., there's a large body of knowledge about how to go about it when the problem is posed in a functional programming language. Doing it to an otherwise unconstrained piece of C code is much harder.
Yeah, and for this you need not only math, but an intuitive understanding of modern computer architecture. You've discovered, as many previously have as well, that memory is much slower than most computation. Doing a few adds and multiplies is almost always faster than pulling in a fresh cache line. This especially if your lookup table access is sparse and you're paying the penalty of fetching an entire cache line just to look up one number (a float is just 1/16th of a cache line). Sparse table lookup of floats generates 16x higher memory bandwidth that what one may naively expect.
Memory is slow. Adders and multipliers are pretty damn fast. You're also possibly reinventing the wheel:)
Slashdot Mirror
Contemporary electronics are fairly reliable. The chances of the camera failing at the exact moment of confrontation further diminish by a few orders of magnitude the likelihood that a just-in-time malfunction isn't due to intentional tampering with evidence. Cops can't but know that should any court case result from a confrontation, their camera footage is evidence, and if you tamper with it, the court should be handing you your ass on a platter. You're entirely wrong that we don't need the courts now, we need courts precisely so that people who tamper with evidence, no matter what the profession is, are to be held accountable.
Better than break even energy production is somewhat irrelevant at the atomic scale. We're talking here about system efficiency. Yes of course if it's worse than break even at atomic scale, it has no chance of break even at system scale, but the inverse holds true only when you retain the word "chance". If it has net energy production at atomic scale, it has a chance to work as a system. Then you need some very hard engineering to extract that energy, and to provide initial energy to the reaction in such a way that things work as they should.
reads a response full of random framing errors
Do you know about the errors since you inspect some error status or get exceptions? Does the data returned look like garbage as well, or is it a case of good data with incorrect error feedback?
except if you try to talk via Microsoft's .net serial libraries which weirdly introduce random framing errors
In asynchronous serial terms, a framing error other than a break condition can only be generated by malfunctioning hardware, EMI or a collision on a multi-node bus. A .net library can't do it, because the underlying OS API doesn't expose any interfaces for you to do it. Now the UART hardware of course has transmitter and receiver enable bits that you could flip to simulate a framing error, but that's not what's happening here. Now if you refer to the fact that just because you write() some bytes, they aren't necessarily contiguous on the wire (without pauses) - then well, you never were supposed to depend on that anyway. A lot of serial protocol implementations are done by people who have never bothered to look at the wire with an oscilloscope, and who never understood the limitations of the medium. It is "simple", so people stop thinking - yeah, it's simple, so we do whatever the heck we want 'cuz it's so simple.
Not so. Serial stacks on most modern OSes give you zero guarantees as to segmentation of the data. That means that if you write() a certain amount of bytes, for all you know they may be sent on the wire one-by-one with several ms worth of a pause between them. There's simply no guarantee in the design of the protocol stack to protect you from that. It's not ethernet. You can expect certain idle time limits to be reasonable, and exceeding them can be considered an error that you then recover from by re-sending whatever it was that has failed. But then your protocol better had numbered packets, numbered replies, a sliding window, and well defined semantics of what happens upon an error. For some applications discarding all further packets until the bad one is re-sent is the right thing to do. For other applications sending that one packet later while accepting the other ones is the way to go. It needs to be figured on a case-by-case basis.
Same limitations apply to the receive direction. A number of bytes sent contiguously on the wire by the device can be chopped up and have to be read in multiple read()s. When you receive data, you need to acquire timestamps after each read and keep track of timeout counters. Some serial APIs help with that, but you need to be clever and validate the implementations to make sure they perform the way you think they do. Some APIs only have timing accurate to the system timer tick; on Windows it will usually be more than 10ms. There's no way around the engineering process here: instead of just brushing things off as "simple", you have to characterize the performance of the system you depend on, and then implement the code and the protocol so that it works in presence of those limitations.
I've been dealing with various industrial and ad-hoc communication protocols for the last decade, and all I know is that most protocols are designed by people who have no idea about what it is that they are doing. I know this partly because I've at first committed the same mistakes I now know to avoid. You'd think, though, that serious established companies out there can afford people who know what they are doing.
Get an oscilloscope and look at it.
It should be eminently doable to software-simulate it on modern hardware. Simulate everything including custom hardware they have.
I think those devices have transceiver chips that are broken, because the RS-232 specification for the receiver certainly requires it to work with +/-3V levels - those are considered the minimum levels, in fact. Anything between +3 to +15V and -3V to -15V is a valid logic level. If you have an RS-232 receiver that doesn't work with +/-6V signals, it's broken, plain and simple. I've designed some RS232-powered devices and they obviously had to work through the range of allowed logic level voltages. There's good engineering, then there's cargo cultism. I prefer the former.
This is some serious bullshit about the FTDI drivers, and I don't like them but you just don't know what you're talking about I think.
On linux you have two "ftdi" drivers: there's the open source one that's part of the kernel and it shouldn't be problematic. It's maintained and it uses the usbserial infrastructure that's used for many other devices. I can't see it having such problems. The FTDI-provided "driver" is 100% userspace and uses libusb, so if that leaks kernel resources, man, you better posted about it on LKML or something.
On Mac OS X, the FTDI driver is, again, userspace-only and uses libusb. Now libusb on OS X is a horrible hack IMHO, but that's besides the point. If it leaks kernel resources, you better file a bug with Apple.
As for Windows FTDI driver - it's semi-reasonable.
I think that you've got FTDI's chip mixed up with another popular chip that's available from multiple sources and there indeed the driver situation is bad.
USB guarantees latency if you have control of the entire stack :)
You can still buy USB floppy drives. They were very popular when macs dropped internal floppy drives. Mac-based labs were full of those things back around 2000.
It could probably be done very nicely using today's components. You'd pretty much need distributed I/O, and one modern PC-based PLC would take care of keeping things running. Compared to legacy hardware, a codesys environment running on a modern i7 or Xeon box can really do what dozens of legacy PLCs had to do before. It's much easier to develop since everything is on one system, and you have modern IP-based communications available to tweak things.
You need to reverse engineer whatever runs on those PLCs and implement using something contemporary and off-the-shelf. Pronto.
An RS232-to-Ethernet device is should be essentially a hardened Raspberry Pi running a modern Linux, configured for security. The communications should be established using ssh configured for login only using known keys. This can be set up relatively easily to be pretty foolproof and can probably beat 99.99% of commercial products out there when it comes to security. It's really not that hard.
Having a nuclear fusion reaction, in other words a nuclear synthesis reaction, is orthogonal to having break even energy production.
From what I'm reading it seems that a runaway neutron-producing reaction that could cost millions USD in cleanup can be done with readily available materials in milligram quantities. A few micrograms worth of slow neutrons injected into stuff around you is seriously bad news.
I'm not in the minority due to my vision, but due to knowledge of what's there and how artifacts look. People who know a bit about video encoding make extremely poor test subjects - their results are always worse than general public's. People just don't care and don't know, that's all.
If the shutter spends too much of its time closed, the illusion of motion is lost.
Nope, the image simply gets progressively darker. This analogy doesn't apply to monitors that usually don't blank the LED backlight while the pixels change state. Now they obviously could blank the backlight since LEDs are more than fast enough. You'd trade off reduced perceived image intensity for crisper, less "muddy" image as you wouldn't be seeing the desired pixel values averaged with values from the transition.
Bullshit. At 10 feet from a 32" screen I can not only tell the difference between a DVD and a 720p, I can also tell the difference between high and low bitrate SD on cable channels. Different channels have different bitrates, my provider for example likes absolutely killing content for children of all ages. Sometimes it looks as bad as Indeo-encoded samples that came with Windows 95, if people still remember that :)
Chip layout could use such monitors, as long as you have good vision; good vision with corrective lenses is of course fine, too. Perhaps GIS applications, and maybe some kinds of CAD as well. Just off the top of my head.
The last thing a street thug expects is a stun grenade blowing up nearby. The element of surprise is enough. Since you expect it detonating within a second or two, you wrap your arms around your ears, and that's sufficient protection. All the while you keep going forward. As for the taser, I'm talking of one that has fixed electrodes and is used at close range. Those are quite safe for the one wielding them, and there's no such thing as them not working. As long as you can get into close proximity so that you can touch it to the body of the perp, that's it. Sometimes it's even lethal, if you're unlucky. A few seconds is enough to get to your target and tase him. I've been through such "treatment" myself as an experiment, and as long as you're not expecting it, it's about as effective as a temporary paralysis. Hitting a brick wall while walking would be a more pleasant experience I'd think. You'd need to be trained to recover from such situations. I doubt that most home invaders have such training. If they had some training, they'd know how to take you down without you noticing what hit you.
Detecting a particular sink that you've used is an option that may or may not work in a particular environment. Detecting washing hands is, from what I've looked at, a foregone conclusion.
Discrete problems are often approximations of some continuous problems, and the continuous problems may be easier to pose or easier to make proofs about. So, here comes one of my favorite Feynman stories:
The router of the Connection Machine was the part of the hardware that allowed the processors to communicate. It was a complicated device; by comparison, the processors themselves were simple. Connecting a separate communication wire between each pair of processors was impractical since a million processors would require 1E12 wires. Instead, we planned to connect the processors in a 20-dimensional hypercube so that each processor would only need to talk to 20 others directly. Because many processors had to communicate simultaneously, many messages would contend for the same wires. The router's job was to find a free path through this 20-dimensional traffic jam or, if it couldn't, to hold onto the message in a buffer until a path became free. Our question to Richard Feynman was whether we had allowed enough buffers for the router to operate efficiently.
During those first few months, Richard began studying the router circuit diagrams as if they were objects of nature. He was willing to listen to explanations of how and why things worked, but fundamentally he preferred to figure out everything himself by simulating the action of each of the circuits with pencil and paper.
[...]
By the end of that summer of 1983, Richard had completed his analysis of the behavior of the router, and much to our surprise and amusement, he presented his answer in the form of a set of partial differential equations. To a physicist this may seem natural, but to a computer designer, treating a set of boolean circuits as a continuous, differentiable system is a bit strange. Feynman's router equations were in terms of variables representing continuous quantities such as "the average number of 1 bits in a message address." I was much more accustomed to seeing analysis in terms of inductive proof and case analysis than taking the derivative of "the number of 1's" with respect to time. Our discrete analysis said we needed seven buffers per chip; Feynman's equations suggested that we only needed five. We decided to play it safe and ignore Feynman.
The decision to ignore Feynman's analysis was made in September, but by next spring we were up against a wall. The chips that we had designed were slightly too big to manufacture and the only way to solve the problem was to cut the number of buffers per chip back to five. Since Feynman's equations claimed we could do this safely, his unconventional methods of analysis started looking better and better to us. We decided to go ahead and make the chips with the smaller number of buffers.
Fortunately, he was right. When we put together the chips the machine worked. The first program run on the machine in April of 1985 was Conway's game of Life.
given a perfectly efficient pump of HP x and a cylindrical container of dimensions x and y filled to height z how long would it take to drain to level z-b
Interesting - that's the kind of stuff the brighter students at my high school were expected to be able to do in grade 11 :/
Functional programming is a bit of a fad right now
Functional programming's main benefit is that it's much easier to prove theorems about functional programming code. If you want a hard-core mathematical proof that your code fulfills certain post-conditions etc., there's a large body of knowledge about how to go about it when the problem is posed in a functional programming language. Doing it to an otherwise unconstrained piece of C code is much harder.
Yeah, and for this you need not only math, but an intuitive understanding of modern computer architecture. You've discovered, as many previously have as well, that memory is much slower than most computation. Doing a few adds and multiplies is almost always faster than pulling in a fresh cache line. This especially if your lookup table access is sparse and you're paying the penalty of fetching an entire cache line just to look up one number (a float is just 1/16th of a cache line). Sparse table lookup of floats generates 16x higher memory bandwidth that what one may naively expect.
Memory is slow. Adders and multipliers are pretty damn fast. You're also possibly reinventing the wheel :)