I'm curious what technical challenges would have to be overcome to actually recover this frozen water. Many parts of the world are undergoing severe freshwater shortages. A very large block of frozen water seems like it could be very useful to answer that problem. Could getting at least part of it into into a reservoir be technically / economically possible?
Off the top of my head, I was musing about getting it into the Great Lakes, but the channels and locks in the Great Lakes Waterway are obviously far too small to move something this size. If it were eventually towed to a port, what could be done with it? How fast would it melt?
I'll withhold judgment seeing how there are a lot of accusations with no actual evidence presented. I wouldn't be surprised if it the school had nothing to do with starting the webcam. Instead, it's entirely possible that the student opened the webcam with something like Photobooth to record/display images and the school was able to see what they were doing via a remote desktop type program. Here's an example of a school doing just that in this Frontline video (skip to 4:37):
When I saw that program on TV a couple weeks ago, it didn't strike me as unusual at all. It's normal for companies (or schools) to keep their own computers communicating with admin servers for updates, management or remote assistance services. Privacy violation wasn't something that jumped out at in me when I saw that as I've always assumed that computers owned & managed by other parties are monitored.
Admins activating a webcam remotely isn't really justifiable unless it's in the pursuit of stolen gear, but keeping an eye on the software, clickstream and desktop is probably within their realm of responsibilities. They would probably be on the receiving end of "You gave my child an evil machine filled with drug recipes and pr0nogrpahy!" lawsuits if they didn't manage the systems.
Kids these days.... Can't even figure out how to boot their own thumbdrive OS to bypass that stuff.:(
Encrypt all sensitive information on the device. (But be warned: In some countries, customs officials may not permit you to enter with encrypted information.)
I'm involved with contributing data to the reports in question. Let me point out that the accusation against the FCC isn't quite right. Submitter claims that the FCC has been collecting data on the "reliability" of different cell phone carriers in the US -- data that could be be invaluable to consumers. The data in question are actually "outage reports" that involve FCC reportable events. These types of events generally involve damage to systems and read like: "911 service down to 175,000 subscribers for 17 hours due to fiber burned in arson event at 777 Bozo St.", or "45,000 subscribers had no services in Deer Meadows when falling tree knocked over Hwy 32 repeater". They describe specific incidents and addresses with number of subscriber minutes affected.
Outage event reports full of acts of God (and acts of vandals) do not provide any data on the actual "reliability" of cell phone carriers as judged by consumers. Consumer reliability is seen as: "How often do my calls drop - how many areas of town have no service - how often do my call attempts say 'try again' or 'network busy'". Knowing that 20,000 users lost long distance service in BFE when an idiot with a backhoe dug up a fiber does not help with those questions -- oversubscribed cell phone towers are not reported as outage events. In short, the FCC does not know who the most "reliable" carriers are -- only which ones sustain the most damage to their facilities.
As for security matters: If anyone wanted to create havoc, they'd take one glance at the report and burn down the sites responsible for the largest outages listed. "National infrastructure" is described in painstaking detail. It wouldn't take a criminal mastermind - only a couple of drunk high school kids.
I would agree with this design and choice of tools. I also build large scalable systems using most of the software and hardware mentioned here. My last project had more than 150,000 users on less than 20 generic Intel server platforms w/RH7.3.
I use an OpenLDAP back end with a master read/write server and replication to a couple of slaves that all the lookups run against. User LDAP records contain fields such as their name/pw, public email addresses and back-end internal addresses.
I use Postfix as the MTA for receiving and moving mail rather than Exim, but that's just because I'm comfortable with it and happy with its performance.
I use Courier-IMAP with Maildirs as it runs well and plays nice with LDAP. Additionally, I use Perdition as the front end POP/IMAP proxy so that users always automatically connect to their own back end server for message retrieval.
My setups involve 3 tiers: Front end platforms for external facing services such as SMTP/POP/IMAP (low powered single cpus/standard ide io), a second layer a servers for filtering and spam markup (moderately powered SMPs w/scsi io power), and back end servers for message storage (strong SMPs with strong scsi io power & raid).
Inbound mail arrives at the front end MTAs. It's accepted and readdressed with its internal back end address, then is delivered to a group of spamassassin/clamav filtering/tagging servers for markup. From there, mail is transported to its appropriate back-end server running Postfix & Courier-IMAP for storage.
To fetch mail users hit Perdition on a front end VIP; it looks up the real back-end server LDAP record and proxies their POP/IMAP requests to that machine.
I use Foundry ServerIron XLs for hardware load balancing the world/user facing services. I just can't give those boxes enough praise.
The simplicity with the design is that each server group runs only a couple of services, and if spam/AV filtering or a back end mail system fails, the messages spool up on the front end or filtering systems until you clear the problem. Nothing is lost and everything arrives asap.
As a side note/gloating point; my uptimes on the Courier-IMAP servers are well over 400 days without a restart of any services. Postfix is equally stable. Everything just works.
Of course, the tricky part will be cutting some code to make some web admin pages or utilities, configuring all the transport maps, figuring out and creating your LDAP schema, working out clamav/spamassassin, the fun with IMAP, etc.;)
I see quite a bit of discussion about how these "back doors" would work, what types of passwords they would use, etc. As someone that works in the broadband industry, let me explain that there is no "back door" or inbound connection made from the agency with the subpoena. With a valid court order, the provider simply configures his router or cable equipment like such (cable example):
The IP address and number shown would be the requesting agency's data collection host & inbound port number. The MAC address is the host target. Each packet sent to or from the target is captured and encapsulated into a UDP packet that is forwarded to the collector. They have software to record the inbound packets and reconstruct them so they can be analyzed like any other packet.
In short, the provider has to take affirmative steps to intentionally pipe your traffic to the feds; they can't just log in and take it themselves, nor can anyone else.
this is one more reason not to have cell phones on airplanes during flight. I worry about the public's lack of concern for science especially given the extreme right wing movements going on
That's complete and total BS. Cell phone use on aircraft has never been proven to cause uncommanded wing or rudder movements -- on either side of the aircraft.
Slashdot Mirror
I'm curious what technical challenges would have to be overcome to actually recover this frozen water. Many parts of the world are undergoing severe freshwater shortages. A very large block of frozen water seems like it could be very useful to answer that problem. Could getting at least part of it into into a reservoir be technically / economically possible?
Off the top of my head, I was musing about getting it into the Great Lakes, but the channels and locks in the Great Lakes Waterway are obviously far too small to move something this size. If it were eventually towed to a port, what could be done with it? How fast would it melt?
I'll withhold judgment seeing how there are a lot of accusations with no actual evidence presented. I wouldn't be surprised if it the school had nothing to do with starting the webcam. Instead, it's entirely possible that the student opened the webcam with something like Photobooth to record/display images and the school was able to see what they were doing via a remote desktop type program. Here's an example of a school doing just that in this Frontline video (skip to 4:37):
http://www.pbs.org/wgbh/pages/frontline/digitalnation/learning/schools/how-google-saved-a-school.html
When I saw that program on TV a couple weeks ago, it didn't strike me as unusual at all. It's normal for companies (or schools) to keep their own computers communicating with admin servers for updates, management or remote assistance services. Privacy violation wasn't something that jumped out at in me when I saw that as I've always assumed that computers owned & managed by other parties are monitored.
Admins activating a webcam remotely isn't really justifiable unless it's in the pursuit of stolen gear, but keeping an eye on the software, clickstream and desktop is probably within their realm of responsibilities. They would probably be on the receiving end of "You gave my child an evil machine filled with drug recipes and pr0nogrpahy!" lawsuits if they didn't manage the systems.
Kids these days.... Can't even figure out how to boot their own thumbdrive OS to bypass that stuff. :(
Encrypt all sensitive information on the device.
(But be warned: In some countries, customs
officials may not permit you to enter with
encrypted information.)
Countries like the United States of America?
I'm involved with contributing data to the reports in question. Let me point out that the accusation against the FCC isn't quite right. Submitter claims that the FCC has been collecting data on the "reliability" of different cell phone carriers in the US -- data that could be be invaluable to consumers. The data in question are actually "outage reports" that involve FCC reportable events. These types of events generally involve damage to systems and read like: "911 service down to 175,000 subscribers for 17 hours due to fiber burned in arson event at 777 Bozo St.", or "45,000 subscribers had no services in Deer Meadows when falling tree knocked over Hwy 32 repeater". They describe specific incidents and addresses with number of subscriber minutes affected.
Outage event reports full of acts of God (and acts of vandals) do not provide any data on the actual "reliability" of cell phone carriers as judged by consumers. Consumer reliability is seen as: "How often do my calls drop - how many areas of town have no service - how often do my call attempts say 'try again' or 'network busy'". Knowing that 20,000 users lost long distance service in BFE when an idiot with a backhoe dug up a fiber does not help with those questions -- oversubscribed cell phone towers are not reported as outage events. In short, the FCC does not know who the most "reliable" carriers are -- only which ones sustain the most damage to their facilities.
As for security matters: If anyone wanted to create havoc, they'd take one glance at the report and burn down the sites responsible for the largest outages listed. "National infrastructure" is described in painstaking detail. It wouldn't take a criminal mastermind - only a couple of drunk high school kids.
I would agree with this design and choice of tools. I also build large scalable systems using most of the software and hardware mentioned here. My last project had more than 150,000 users on less than 20 generic Intel server platforms w/RH7.3.
;)
I use an OpenLDAP back end with a master read/write server and replication to a couple of slaves that all the lookups run against. User LDAP records contain fields such as their name/pw, public email addresses and back-end internal addresses.
I use Postfix as the MTA for receiving and moving mail rather than Exim, but that's just because I'm comfortable with it and happy with its performance.
I use Courier-IMAP with Maildirs as it runs well and plays nice with LDAP. Additionally, I use Perdition as the front end POP/IMAP proxy so that users always automatically connect to their own back end server for message retrieval.
My setups involve 3 tiers: Front end platforms for external facing services such as SMTP/POP/IMAP (low powered single cpus/standard ide io), a second layer a servers for filtering and spam markup (moderately powered SMPs w/scsi io power), and back end servers for message storage (strong SMPs with strong scsi io power & raid).
Inbound mail arrives at the front end MTAs. It's accepted and readdressed with its internal back end address, then is delivered to a group of spamassassin/clamav filtering/tagging servers for markup. From there, mail is transported to its appropriate back-end server running Postfix & Courier-IMAP for storage.
To fetch mail users hit Perdition on a front end VIP; it looks up the real back-end server LDAP record and proxies their POP/IMAP requests to that machine.
I use Foundry ServerIron XLs for hardware load balancing the world/user facing services. I just can't give those boxes enough praise.
The simplicity with the design is that each server group runs only a couple of services, and if spam/AV filtering or a back end mail system fails, the messages spool up on the front end or filtering systems until you clear the problem. Nothing is lost and everything arrives asap.
As a side note/gloating point; my uptimes on the Courier-IMAP servers are well over 400 days without a restart of any services. Postfix is equally stable. Everything just works.
Of course, the tricky part will be cutting some code to make some web admin pages or utilities, configuring all the transport maps, figuring out and creating your LDAP schema, working out clamav/spamassassin, the fun with IMAP, etc.
But that's why they pay you the big bucks.
I see quite a bit of discussion about how these "back doors" would work, what types of passwords they would use, etc. As someone that works in the broadband industry, let me explain that there is no "back door" or inbound connection made from the agency with the subpoena. With a valid court order, the provider simply configures his router or cable equipment like such (cable example):
cable interecpt 00:de:ad:be:ef:00 192.168.44.55 4444
The IP address and number shown would be the requesting agency's data collection host & inbound port number. The MAC address is the host target. Each packet sent to or from the target is captured and encapsulated into a UDP packet that is forwarded to the collector. They have software to record the inbound packets and reconstruct them so they can be analyzed like any other packet.
In short, the provider has to take affirmative steps to intentionally pipe your traffic to the feds; they can't just log in and take it themselves, nor can anyone else.
this is one more reason not to have cell phones on airplanes during flight. I worry about the public's lack of concern for science especially given the extreme right wing movements going on
That's complete and total BS. Cell phone use on aircraft has never been proven to cause uncommanded wing or rudder movements -- on either side of the aircraft.
That was a really bad Haiku.
My head hurts now.