Many people have a very good reasons for not wanting their email linked to a phone number. In places like Syria you could monitor email connections (even if you can't read the content) then use the phone SMS for localization for real time targeting information. This would be a good way to shut down/kill unauthorized and unaware journalists and careless just-in-country NGO personnel, not to mention rebels. You can use a VPN to hide your email connection but then Google goes and phones you back. Then it's fire mission, fire for effect... Not the way I would want to end my day... Perhaps a little dramatic, but the same thing can easily be done to deanonymize anyone...
After reading your references, yes, actually it does look like no one was injured by radiation. There is mention of a 70% higher risk of developing thyroid cancer and a 7% higher risk of leukemia and lower percentages for other cancers. To this level of risk I have to say "so what?". These increases in risk are far far lower than the increased risk of cancer just from being poor, or living down wind of a coal fired power plant, or being an airline pilot. Those are risks we all accept each day. This level of increased risk is laughable. You could probably more than offset this level of risk of death and injury by taking the bus instead of driving in a car for a month. Yes, the article mentions that there might be a lifetime risk of death of 2 to 12 onsite workers, which is immediately followed by a caution that the methodology used in calculating those numbers as a sum of risks for serial low level exposures is unproven and possibly suspect. It's also important to remember that the astronomical radiation levels reported during the event were from short lived isotopes of oxygen (oxygen-15 has a half-life of 122.24 seconds) and nitrogen (nitrogen-13 has a half-life of 9.965 minutes). Tritium with a half-life of 12.32 years was probably the most problematic, but given that it is hydrogen, it would have almost certainly diffused to negligible levels rapidly. Yes there was a release of some cesium-137 with a half-life of 30.17 years and strontium-90 with a half-life of 28.8 years, but we have a lot of experience with mitigating and dealing with the effect of these, to the point where the added risk is practically negligible compared to the other risks we face daily. I would expect the health effects of the panic, relocation, and losing one's home far outweighed any and all radiation risk. Or perhaps that was your point?
Had to do something similar a long time ago. It was a lot of work to set up, but it did work. It went like this:
(1) Set up a server attached to a printer. You probably want to set up a firewall to limit who can connect.
(2) Configure the web server to accept an HTTP POST or PUT. (FTP might also be an option.) You might want to create a simple web page to facilitate the upload.
(3) When you drop a file into the spool directory, it gets scanned for file type. If it's postscript, it gets printed. If it's PDF it gets converted to postscript. If it's text it gets converted to postscript. If it's HTML it gets converted to postscript. There are utilities to perform the conversions on Linux. You just have to write the scripts to scan the spool directory for new files, detect file type, drive the converters, and of course print.
(4) Teach your dad how to perform the PUT or POST to get the document to be printed into the spool directory.
It took a bit of effort to get this working, but eventually it did work and it worked well.
One gotcha we had to deal with was the short attention span of users. They simply wouldn't wait long enough for the process to run, and would frequently drop multiple copies of the same document into the spool directory. To cope with this we captured checksums of each file, and when it's a copy of the file in progress, we deleted it. If it's a file processed within the last minute, we deleted it. This allowed the user to process the same file more than once, but limited the rate to once per minute.
I'm surprised no-one mentioned Brief. Back in the day we had to churn out assembler which was fit for V&V. We only had beige box PCs and built and tested on a separate dedicated machine. The only thing that made it bearable was the speed and flexibility of Brief. It gave us the ability to easily format source code for the V&V tools (via automation) and served as a primitive source code browser. A couple of the guys used vi clones but I grew rather fond of Brief. It got out of the way, let me work on multiple files at once, and yet no matter how complex the edit job it made it easier. I remember it had a stellar macro facility for the time. When I switched to Sun Workstations I switched from Brief to EMACs because it provided the same programmable functionality. It didn't hurt that Brief had employed the basic EMACs command key setup.
So for assembly language, (at least umpteen years ago,) I nominate Brief.
I would use an OpenBSD bridge(4). Get a PC with three network ports. Install OpenBSD. Create a transparent bridge between the two networks and use the third connection for access to local ssh(1). I would then configure the pf(4) firewall to allow limited traffic (such as SSH) to cross the bridge. Since the box is a bridge, it's transparent to network traffic and adds an almost negligible latency. Whenever you want to disconnect traffic, log in using ssh (Putty from a Windows box), and turn off the bridge. With an SSH client on a smart phone, you could turn the network off and on from anywhere in the world within a couple of minutes of receiving a phone call. A timeout is easy. Create scripts to enable/disable the bridge and use cron(8), at(1), or a script to fire off the enable/disable scripts at specific times, dates, or intervals.
I've been through a frontend crash "at speed" complete with airbag deployment. The car was a writeoff afterwards. The impact was right on the nose. I always drive with my seat well back (I have fairly long legs) and a tight seatbelt (if you're going to use it, use it correctly). The little Dodge (and airbag) died saving me from injury. I walked away with a slightly dislocated neck, compressed ribs, and a small burn on the back of one hand from the airbag. Some observations: Holding the wheel at 12 o'clock would have broken my arm. Holding the wheel at 10 and 2 would possibly have broken wrists or arms. Gripping at 9 would probably have damaged my left hand when it hit the door. I *only* hold the wheel at 4-5 and 7-8 (or one hand at 6 on long drives). That still allows me to put more force into the wheel than my wife can in any position. If you need the extra leverage you can apply by holding the wheel at 3 and 9, then you have done something very, very wrong (or worse, stupid). When I drive, I try to avoid doing anything stupid. (And since you have to know, don't ever, ever, assume that a car on the freeway is moving in the direction of traffic.)
My connection is far below 5m and since I don't watch movies, my download speed is usually adequate. However, what I haven't heard mentioned here is *latency*. I do a lot of remote work over the Internet and the latency I get is *abysmal*. It seems that ISPs have been sneaking the latency up (by refusing to tune for latency and using default settings for packet queue management). This results in behavior which, much of the time, makes remote NX/VNC connections almost unusable. You can forget about Video over IP and VoIP. Connections over the Internet pretty much require saying "over" when you stop talking so the remote party knows when they can start speaking. We need to make people aware that there are *two* parameters which define broadband quality. Speed is just one of them.
Slashdot Mirror
Many people have a very good reasons for not wanting their email linked to a phone number. In places like Syria you could monitor email connections (even if you can't read the content) then use the phone SMS for localization for real time targeting information. This would be a good way to shut down/kill unauthorized and unaware journalists and careless just-in-country NGO personnel, not to mention rebels. You can use a VPN to hide your email connection but then Google goes and phones you back. Then it's fire mission, fire for effect... Not the way I would want to end my day... Perhaps a little dramatic, but the same thing can easily be done to deanonymize anyone...
After reading your references, yes, actually it does look like no one was injured by radiation. There is mention of a 70% higher risk of developing thyroid cancer and a 7% higher risk of leukemia and lower percentages for other cancers. To this level of risk I have to say "so what?". These increases in risk are far far lower than the increased risk of cancer just from being poor, or living down wind of a coal fired power plant, or being an airline pilot. Those are risks we all accept each day. This level of increased risk is laughable. You could probably more than offset this level of risk of death and injury by taking the bus instead of driving in a car for a month. Yes, the article mentions that there might be a lifetime risk of death of 2 to 12 onsite workers, which is immediately followed by a caution that the methodology used in calculating those numbers as a sum of risks for serial low level exposures is unproven and possibly suspect. It's also important to remember that the astronomical radiation levels reported during the event were from short lived isotopes of oxygen (oxygen-15 has a half-life of 122.24 seconds) and nitrogen (nitrogen-13 has a half-life of 9.965 minutes). Tritium with a half-life of 12.32 years was probably the most problematic, but given that it is hydrogen, it would have almost certainly diffused to negligible levels rapidly. Yes there was a release of some cesium-137 with a half-life of 30.17 years and strontium-90 with a half-life of 28.8 years, but we have a lot of experience with mitigating and dealing with the effect of these, to the point where the added risk is practically negligible compared to the other risks we face daily. I would expect the health effects of the panic, relocation, and losing one's home far outweighed any and all radiation risk. Or perhaps that was your point?
Had to do something similar a long time ago. It was a lot of work to set up, but it did work. It went like this: (1) Set up a server attached to a printer. You probably want to set up a firewall to limit who can connect. (2) Configure the web server to accept an HTTP POST or PUT. (FTP might also be an option.) You might want to create a simple web page to facilitate the upload. (3) When you drop a file into the spool directory, it gets scanned for file type. If it's postscript, it gets printed. If it's PDF it gets converted to postscript. If it's text it gets converted to postscript. If it's HTML it gets converted to postscript. There are utilities to perform the conversions on Linux. You just have to write the scripts to scan the spool directory for new files, detect file type, drive the converters, and of course print. (4) Teach your dad how to perform the PUT or POST to get the document to be printed into the spool directory. It took a bit of effort to get this working, but eventually it did work and it worked well. One gotcha we had to deal with was the short attention span of users. They simply wouldn't wait long enough for the process to run, and would frequently drop multiple copies of the same document into the spool directory. To cope with this we captured checksums of each file, and when it's a copy of the file in progress, we deleted it. If it's a file processed within the last minute, we deleted it. This allowed the user to process the same file more than once, but limited the rate to once per minute.
I'm surprised no-one mentioned Brief . Back in the day we had to churn out assembler which was fit for V&V. We only had beige box PCs and built and tested on a separate dedicated machine. The only thing that made it bearable was the speed and flexibility of Brief. It gave us the ability to easily format source code for the V&V tools (via automation) and served as a primitive source code browser. A couple of the guys used vi clones but I grew rather fond of Brief. It got out of the way, let me work on multiple files at once, and yet no matter how complex the edit job it made it easier. I remember it had a stellar macro facility for the time. When I switched to Sun Workstations I switched from Brief to EMACs because it provided the same programmable functionality. It didn't hurt that Brief had employed the basic EMACs command key setup. So for assembly language, (at least umpteen years ago,) I nominate Brief.
I would use an OpenBSD bridge(4). Get a PC with three network ports. Install OpenBSD. Create a transparent bridge between the two networks and use the third connection for access to local ssh(1). I would then configure the pf(4) firewall to allow limited traffic (such as SSH) to cross the bridge. Since the box is a bridge, it's transparent to network traffic and adds an almost negligible latency. Whenever you want to disconnect traffic, log in using ssh (Putty from a Windows box), and turn off the bridge. With an SSH client on a smart phone, you could turn the network off and on from anywhere in the world within a couple of minutes of receiving a phone call. A timeout is easy. Create scripts to enable/disable the bridge and use cron(8), at(1), or a script to fire off the enable/disable scripts at specific times, dates, or intervals.
I've been through a frontend crash "at speed" complete with airbag deployment. The car was a writeoff afterwards. The impact was right on the nose. I always drive with my seat well back (I have fairly long legs) and a tight seatbelt (if you're going to use it, use it correctly). The little Dodge (and airbag) died saving me from injury. I walked away with a slightly dislocated neck, compressed ribs, and a small burn on the back of one hand from the airbag. Some observations: Holding the wheel at 12 o'clock would have broken my arm. Holding the wheel at 10 and 2 would possibly have broken wrists or arms. Gripping at 9 would probably have damaged my left hand when it hit the door. I *only* hold the wheel at 4-5 and 7-8 (or one hand at 6 on long drives). That still allows me to put more force into the wheel than my wife can in any position. If you need the extra leverage you can apply by holding the wheel at 3 and 9, then you have done something very, very wrong (or worse, stupid). When I drive, I try to avoid doing anything stupid. (And since you have to know, don't ever, ever, assume that a car on the freeway is moving in the direction of traffic.)
My connection is far below 5m and since I don't watch movies, my download speed is usually adequate. However, what I haven't heard mentioned here is *latency*. I do a lot of remote work over the Internet and the latency I get is *abysmal*. It seems that ISPs have been sneaking the latency up (by refusing to tune for latency and using default settings for packet queue management). This results in behavior which, much of the time, makes remote NX/VNC connections almost unusable. You can forget about Video over IP and VoIP. Connections over the Internet pretty much require saying "over" when you stop talking so the remote party knows when they can start speaking. We need to make people aware that there are *two* parameters which define broadband quality. Speed is just one of them.