If you like SNOBOL, you'll like REXX (several flavors, like regina, available for Linux). Flexible typing, and the PARSE statement operates very similarly to the SNOBOL pattern match.
As each section is turned up, you have to take the time to "stabilize" the environment (insuring reliable signalling, preventing false signals). You can code around false signals with two way X10 devices, or use feedback from sensors to confirm. I use a combination of 1-way, 2-way, PIR motion, light detect, cams, magnetic, PIR, glass breakage, (hardwired wireless and carrier current) controlled, of course, by an old laptop running Linux with Bottle Rocket, Heyu and Xtend software (driving TCL and BASH scripts) and cron jobs. I recommend a laptop because of the low power requirement (runs a loooong time on UPS).
It needs an RJ45 for Ethernet (10/100), to record mpeg directly onto it's media, and an FTP server so I can pull the videos off. I want to be able to "close" an mpeg video and start a new one (i.e., multiple videos on the media, uniquely named for ftp). This will let me use the device with any machine having an Ethernet card. No BlueTooth, 802.11b, iLink needed, and much cheaper (and faster). Keep it simple; the device has a simple purpose. You can add functionality without complexity, but that doesn't seem to be the way these things are done.
While the two are essentially the same in functionality from a user perspective, the commercial version does have a nice GUI. While it may not sound like much, it improves the usability, and probably reduces support costs.
There must be a direct correlation with (undirected; i.e, no Yagi) range and power, if the laws of physics aren't going to be broken. Going from 30 foot range to 300 foot range requires 12-15 times the power; reducing the range provides comparable savings. Most final stage amps on these low power transmitters are very simple, and very easy to control. The complexity is in controlling the information tranmitted, which I'm not suggesting any change to (wouldn't be compliant).
I agree, as currently implemented, 802.11b devices use too much power. That's why I proposed reducing the tranmission power when there is reasonable proximity to the target. Because tranmit power obeys inverse-square, the majority of the power used by 802.11b goes towards reaching the 300 foot range.
A simple method for assigning IP addresses? Use the same one that comes with most access points -- DHCP in a private address range (usually 192.168.1.1-254). Your keyboard asks for it's IP configuration, and it's on the net. Your PC broadcasts to the private net for an appropriate device. Conceptually, this is actually very similar to the way USB devices work.
Actually, putting those devices on the network will eliminate KVM switches for both local and remote equipment. It would be very neat to be able to "attach" your joystick to a game machine in another country.:-) A simple thing to do with 802.11b, but kludgy with Bluetooth.
Back when machines came with 4K of memory (yes, K, not M), but could address 64K, it wasn't uncommon to memory map devices. It was an easy thing to do; a few discrete nand gates (7400 series ICs) for decode logic and you were done. Since a lot of the code was written in assembler then, it was easy to move stuff in and out of the memory locations.
Everything old is new again... I wonder how many other ancient techniques would be useful now...
Anyone remember hardware memory swaping (bank switching)? You could take that machine with a measly 8GB memory limit and expand to 256 banks of 8GB for 2TB of memory (assuming you could afford all that) with a single memory mapped bank select byte. Only 1 memory access cycle to swap 8GB.
I'm not sure I would agree with wanting both. Streaming IP based protocols, low power consumption and lower cost (don't need two wireless subsystems) means to me that Bluetooth is a lost cause. The intent of Bluetooth is easily achieved with a low power consumption version of 802.11b. There's no specification change needed, since the tranmit power is perceived as variable to the receiver anyway based on distance. Reduce the transmit power and you have the benefit of Bluetooth (dramatically reduced power consumption), but the advantages of 802.11b (increased range on demand and bandwidth).
By using well known and standardized IP protocols, existing wired (Ethernet) implementations can easily be extended to wireless with a layer 1 change. Little or no new development is required, depending on the supported protocols in the existing stack. 802.11b is already becoming widely deployed; what value would Bluetooth add?
Solar Cells and Bluetooth
on
The Dream Handheld
·
· Score: 2, Insightful
I'd suggest making the cover clear, and using back-to-back solar cells, so the unit charges open or closed.
Skip bluetooth, and use low/high power 802.11b. Low power when you're close to the access point to conserve power, high power when you need range. Bluetooth seems redundant and unnecessary these days.
When I put this message on my answering machine, we went from 6 telemarketing calls a day to 0 in less than 2 weeks:
"Thank you for your $50 contribution to the National Rifle Association! Your contribution will appear on your next telephone bill. If you've called this number in error, please leave your name and number after the tone."
You can't imagine the funny and desperate messages that that I got.:-)
Of course, remember to tell your friends and family (or not, your choice:-)
These are an example (they even have Linux drivers), but an 8GB unit is still over $20k (see CDW). It's going to be a while until this is affordable (2 orders of magnitude price reduction).
Threading isn't always scalable; if the inter-thread communication that would result from threading an application is disproportionately high, then the efficiency of the application is maximized by minimizing threading. There are many such commercial/scientific applications. The solution to these problems is larger CPUs, not more small ones. That's the reason mainframes still exist; there is a class of problem that they are very efficient at solving:-)
While Sun has increased the number of CPUs, they still don't have a good solution to address the large monolithic type of workload. IBM and others have them there, with very large CPUs available on the S/390 series, for example. I've had difficulty finding comparison benchmarks between the UltraSparc III 900 and Intel's high-end Xeon CPUs. Does anyone know how they stack up against each other?
OK, I know this isn't going to be a popular position, but I have to state it anyway. About 10 years ago, I had a manager refuse to allow a syslog to be enabled on a system. My reason for asking for it was security; there could be breaches taking place without anyones knowledge, leaving no trace. His response was "show me the security breach, and how the syslog will address it, then you can enable the syslog". Eventually, our corporate security forced the issue and syslog was enabled. We identified an employee stealing company secrets by mounting tapes and dumping information, hacker access attempts (some successful), etc.
The point is, having access to the information is good. It may be very hard up front to identify the nature of the information or specific issue that will be identified, or the specific problems that will be avoided, since the neccesary supporting information is not available. How many admins would consider running their systems and services without logs, and just turning them on when there is a problem?
Likewise, how can we ask the intelligence agencies to protect us from the activities that would undermine our nation (from any aspect), without allowing some reasonable level of monitoring.
I understand the argument that, human nature being what it is, abuses will happen. I for one would be willing to accept the monitoring, and subsequent reduction in privacy, if the penalties against abuse of the information was severe. Something on the order of 10 year minimum mandatory jail sentences, with reparation to the victims of the abuse.
I don't think that the average NSA/CIA/whatever agent would have a problem with that. Their resulting efficiency should be improved so greatly they would be too busy.:-)
I hate the idea that someone is watching me post to a political discussion like this, or emailing my friend about my gout. But I really hate the idea that someone could be poisoning my water supply, shipping bombs to my office, or worse, even more.
In this country, we generally give our law enforcement and emergency personnel some legal flexibility to do their jobs. Those that abuse that privilege bring shame and disgrace to their peers, and are punished as criminals. Why would this be any different?
Even though the power requirement is higher, it's still negligible. For the most severely power constrained devices (PDAs, cell phones, etc.), the IR transmissions are brief (beam a document, hot sync). Devices that may maintain a long term connection, like laptop to IR Ethernet, the power requirement is not significant since they have big batteries and/or are AC powered. In addition, power output could be ramped up/down based on signal feedback from the far end making close proximity transmissions nearly as power efficient as existing IR. Imagine *securely* beaming a document to a friend in an adjacent building! It seems sad to abandon a technology with so much potential.
Indeed, the primary complaint I hear against IRDA is short distance. While Bluetooth will adress this somewhat, simply replacing the infrared LED with a laser LED (like those in cheap laser pointers) would extend the range of IRDA beyond that of 802.11b. I LIKE the requirement for line-of-sight; knowing that the communication is intrinsically secure is a major benefit. Improvements in the application level protocols would allow improved recovery from signal interruptions (like someone walking between the IRDA units). Palm pilots do this pretty well now.
It seems that instead of evolving existing facilities, the are introduced and then discarded in favor of the next big thing. This make consumers even more hesitant to adopt technology for fear of obsolescence.
Shortly after I posted this, Cablevision did the same thing, blocking port 80. It was extremely effective at stopping the Code Red activity. I thank them for returning stability to the network, even though I'm sure they will receive some negative feedback from a few customers. I got to try out my suggestion, and it worked as expected. My friends and family never saw the change in port number, and it took all of 5 minutes to reconfigure the web server and URL mapping. All in all, it was probably easier than applying the patch to IIS would have been (wouldn't know, never tough the stuff:-)
It's not that hard, and it can be made transparent to your users by mapping the URL with an intermediate service. If that's the only port Code Red is looking at, it seems easy enough. Or just install Apache. I count myself in the cadre of fscking newbies, but if this is too difficult for you, you probably shouldn't be running a server anyway. Code Red will be the least of your problems over time...
Quantum computers and quantum computing factoring algorithms clearly allow the circumvention of many current standard encryption protection methods. Why don't we just round up all the IBM and AT&T Labs developers and put them in jail too? The DMCA doesn't have exemptions for them, does it? I didn't think so. Hey, we can't have these wanton crimallys wandering the halls, can we? Hey, wait! Math and physics teachers are spreading the information need to build these circumvention devices! Round them up too! M-o-r-o-n-s - don't decode that (it's copyrighted and encrypted by my secret dash insertion algorithm).
The components for voice annoucement are certainly inexpensive enough at this point that a smoke detector can say "Fire! Fire!" or cell phone "Telephone call", "A message has arrived", or whatever. About a year ago, one of my alarms went off; I couldn't tell if it was a fire, carbon monoxide, or a burglar; they all sound similar (especially when awakened at 3am).
Much of today's business uses filesharing software. The protocols are all very different, but basically the function is the same. A user wanting a file or files connects to a server. The server provides access to files that have been made available, in turn, by other users. The user requesting the file(s) can in turn make their own files available for sharing. The model is the same, only the protocols and terminolgy have been changed (mostly for marketing purposes). After all, if Napster had announced "Look, we have NFS!!!" would anyone have been interested? I doubt it.
Slashdot Mirror
If you like SNOBOL, you'll like REXX (several flavors, like regina, available for Linux). Flexible typing, and the PARSE statement operates very similarly to the SNOBOL pattern match.
As each section is turned up, you have to take the time to "stabilize" the environment (insuring reliable signalling, preventing false signals). You can code around false signals with two way X10 devices, or use feedback from sensors to confirm. I use a combination of 1-way, 2-way, PIR motion, light detect, cams, magnetic, PIR, glass breakage, (hardwired wireless and carrier current) controlled, of course, by an old laptop running Linux with Bottle Rocket, Heyu and Xtend software (driving TCL and BASH scripts) and cron jobs. I recommend a laptop because of the low power requirement (runs a loooong time on UPS).
Start small, build slowly.
It needs an RJ45 for Ethernet (10/100), to record mpeg directly onto it's media, and an FTP server so I can pull the videos off. I want to be able to "close" an mpeg video and start a new one (i.e., multiple videos on the media, uniquely named for ftp). This will let me use the device with any machine having an Ethernet card. No BlueTooth, 802.11b, iLink needed, and much cheaper (and faster). Keep it simple; the device has a simple purpose. You can add functionality without complexity, but that doesn't seem to be the way these things are done.
While the two are essentially the same in functionality from a user perspective, the commercial version does have a nice GUI. While it may not sound like much, it improves the usability, and probably reduces support costs.
It's world government, the first step towards the United Federation of Planets.
Wait... which reality is this?
There must be a direct correlation with (undirected; i.e, no Yagi) range and power, if the laws of physics aren't going to be broken. Going from 30 foot range to 300 foot range requires 12-15 times the power; reducing the range provides comparable savings. Most final stage amps on these low power transmitters are very simple, and very easy to control. The complexity is in controlling the information tranmitted, which I'm not suggesting any change to (wouldn't be compliant).
I agree, as currently implemented, 802.11b devices use too much power. That's why I proposed reducing the tranmission power when there is reasonable proximity to the target. Because tranmit power obeys inverse-square, the majority of the power used by 802.11b goes towards reaching the 300 foot range.
A simple method for assigning IP addresses? Use the same one that comes with most access points -- DHCP in a private address range (usually 192.168.1.1-254). Your keyboard asks for it's IP configuration, and it's on the net. Your PC broadcasts to the private net for an appropriate device. Conceptually, this is actually very similar to the way USB devices work.
Actually, putting those devices on the network will eliminate KVM switches for both local and remote equipment. It would be very neat to be able to "attach" your joystick to a game machine in another country. :-) A simple thing to do with 802.11b, but kludgy with Bluetooth.
Back when machines came with 4K of memory (yes, K, not M), but could address 64K, it wasn't uncommon to memory map devices. It was an easy thing to do; a few discrete nand gates (7400 series ICs) for decode logic and you were done. Since a lot of the code was written in assembler then, it was easy to move stuff in and out of the memory locations.
:-)
Everything old is new again... I wonder how many other ancient techniques would be useful now...
Anyone remember hardware memory swaping (bank switching)? You could take that machine with a measly 8GB memory limit and expand to 256 banks of 8GB for 2TB of memory (assuming you could afford all that) with a single memory mapped bank select byte. Only 1 memory access cycle to swap 8GB.
Actually, that might be pretty cool.
I'm not sure I would agree with wanting both. Streaming IP based protocols, low power consumption and lower cost (don't need two wireless subsystems) means to me that Bluetooth is a lost cause. The intent of Bluetooth is easily achieved with a low power consumption version of 802.11b. There's no specification change needed, since the tranmit power is perceived as variable to the receiver anyway based on distance. Reduce the transmit power and you have the benefit of Bluetooth (dramatically reduced power consumption), but the advantages of 802.11b (increased range on demand and bandwidth).
By using well known and standardized IP protocols, existing wired (Ethernet) implementations can easily be extended to wireless with a layer 1 change. Little or no new development is required, depending on the supported protocols in the existing stack. 802.11b is already becoming widely deployed; what value would Bluetooth add?
I'd suggest making the cover clear, and using back-to-back solar cells, so the unit charges open or closed.
Skip bluetooth, and use low/high power 802.11b. Low power when you're close to the access point to conserve power, high power when you need range. Bluetooth seems redundant and unnecessary these days.
When I put this message on my answering machine, we went from 6 telemarketing calls a day to 0 in less than 2 weeks:
:-)
:-)
"Thank you for your $50 contribution to the National Rifle Association! Your contribution will appear on your next telephone bill. If you've called this number in error, please leave your name and number after the tone."
You can't imagine the funny and desperate messages that that I got.
Of course, remember to tell your friends and family (or not, your choice
...I think the message is clear: "We are being made to protest, but our sentiments are with the Americans".
Alternatively, It could be a signal from Bin Laden to his moles, expected to be overlooked.
Either way, I very sincerely doubt that anyone would risk this if it were not very important.
These are an example (they even have Linux drivers), but an 8GB unit is still over $20k (see CDW). It's going to be a while until this is affordable (2 orders of magnitude price reduction).
Threading isn't always scalable; if the inter-thread communication that would result from threading an application is disproportionately high, then the efficiency of the application is maximized by minimizing threading. There are many such commercial/scientific applications. The solution to these problems is larger CPUs, not more small ones. That's the reason mainframes still exist; there is a class of problem that they are very efficient at solving :-)
While Sun has increased the number of CPUs, they still don't have a good solution to address the large monolithic type of workload. IBM and others have them there, with very large CPUs available on the S/390 series, for example. I've had difficulty finding comparison benchmarks between the UltraSparc III 900 and Intel's high-end Xeon CPUs. Does anyone know how they stack up against each other?
The point is, having access to the information is good. It may be very hard up front to identify the nature of the information or specific issue that will be identified, or the specific problems that will be avoided, since the neccesary supporting information is not available. How many admins would consider running their systems and services without logs, and just turning them on when there is a problem?
Likewise, how can we ask the intelligence agencies to protect us from the activities that would undermine our nation (from any aspect), without allowing some reasonable level of monitoring.
I understand the argument that, human nature being what it is, abuses will happen. I for one would be willing to accept the monitoring, and subsequent reduction in privacy, if the penalties against abuse of the information was severe. Something on the order of 10 year minimum mandatory jail sentences, with reparation to the victims of the abuse.
I don't think that the average NSA/CIA/whatever agent would have a problem with that. Their resulting efficiency should be improved so greatly they would be too busy. :-)
I hate the idea that someone is watching me post to a political discussion like this, or emailing my friend about my gout. But I really hate the idea that someone could be poisoning my water supply, shipping bombs to my office, or worse, even more.
In this country, we generally give our law enforcement and emergency personnel some legal flexibility to do their jobs. Those that abuse that privilege bring shame and disgrace to their peers, and are punished as criminals. Why would this be any different?
Even though the power requirement is higher, it's still negligible. For the most severely power constrained devices (PDAs, cell phones, etc.), the IR transmissions are brief (beam a document, hot sync). Devices that may maintain a long term connection, like laptop to IR Ethernet, the power requirement is not significant since they have big batteries and/or are AC powered. In addition, power output could be ramped up/down based on signal feedback from the far end making close proximity transmissions nearly as power efficient as existing IR. Imagine *securely* beaming a document to a friend in an adjacent building! It seems sad to abandon a technology with so much potential.
Spread on a laser is controlled by the focus optics. A 3 foot spread at 100 feet would be a reasonable tradeoff in distance, while allowing easy aim.
Indeed, the primary complaint I hear against IRDA is short distance. While Bluetooth will adress this somewhat, simply replacing the infrared LED with a laser LED (like those in cheap laser pointers) would extend the range of IRDA beyond that of 802.11b. I LIKE the requirement for line-of-sight; knowing that the communication is intrinsically secure is a major benefit. Improvements in the application level protocols would allow improved recovery from signal interruptions (like someone walking between the IRDA units). Palm pilots do this pretty well now.
It seems that instead of evolving existing facilities, the are introduced and then discarded in favor of the next big thing. This make consumers even more hesitant to adopt technology for fear of obsolescence.
Shortly after I posted this, Cablevision did the same thing, blocking port 80. It was extremely effective at stopping the Code Red activity. I thank them for returning stability to the network, even though I'm sure they will receive some negative feedback from a few customers. I got to try out my suggestion, and it worked as expected. My friends and family never saw the change in port number, and it took all of 5 minutes to reconfigure the web server and URL mapping. All in all, it was probably easier than applying the patch to IIS would have been (wouldn't know, never tough the stuff :-)
It's not that hard, and it can be made transparent to your users by mapping the URL with an intermediate service. If that's the only port Code Red is looking at, it seems easy enough. Or just install Apache. I count myself in the cadre of fscking newbies, but if this is too difficult for you, you probably shouldn't be running a server anyway. Code Red will be the least of your problems over time...
Quantum computers and quantum computing factoring algorithms clearly allow the circumvention of many current standard encryption protection methods. Why don't we just round up all the IBM and AT&T Labs developers and put them in jail too? The DMCA doesn't have exemptions for them, does it? I didn't think so. Hey, we can't have these wanton crimallys wandering the halls, can we? Hey, wait! Math and physics teachers are spreading the information need to build these circumvention devices! Round them up too! M-o-r-o-n-s - don't decode that (it's copyrighted and encrypted by my secret dash insertion algorithm).
The components for voice annoucement are certainly inexpensive enough at this point that a smoke detector can say "Fire! Fire!" or cell phone "Telephone call", "A message has arrived", or whatever. About a year ago, one of my alarms went off; I couldn't tell if it was a fire, carbon monoxide, or a burglar; they all sound similar (especially when awakened at 3am).
Much of today's business uses filesharing software. The protocols are all very different, but basically the function is the same. A user wanting a file or files connects to a server. The server provides access to files that have been made available, in turn, by other users. The user requesting the file(s) can in turn make their own files available for sharing. The model is the same, only the protocols and terminolgy have been changed (mostly for marketing purposes). After all, if Napster had announced "Look, we have NFS!!!" would anyone have been interested? I doubt it.