Phoenix isn't really at risk from any sort of common natural disaster (barring meteorites or something like that). The only real risk is heat, but datacenters have redundant air conditioners for a reason./not associated with PhoenixNAP//hosts at a facility in Baltimore
You're referring to "selective availability" which hasn't been operational since the Clinton administration (and the new satellites intentionally lack SA-capable hardware).
Most of the uncertainty in civilian GPS receivers is due to the relatively low data rate of the civilian signal and the lack of knowledge of ionospheric conditions. The ionosphere issue can be compensated for with WAAS/EGNOS, though having dual-frequency receivers work better.
The "modernized" civilian GPS service will have civilian signals on three frequencies, so that alone should increase the accuracy of civilian receivers. The other improvements will also help.
DGPS can provide much more accurate positioning, particularly for local areas (like a racetrack or farm field). This is indeed useful.
Naturally, using other navigation systems like Galileo (once it's available) and GLONASS can help with navigational accuracy.
Having large quantities of pressurized natural gas can be an explosion risk. Diesel's just a fire risk. Storing pressurized natural gas likely involves a lot of regulatory issues that diesel doesn't.
Also, natural gas is not very efficient volumetrically: diesel has 37.3 MJ/liter. Natural gas at normal pressure has 0.0364 MJ/liter. Even compressed to 250 bar (3,600 psi), a non-trivial pressure, it only has an energy density of 9 MJ/liter. Liquified natural gas at -160C has an energy density of 22.2 MJ/liter. Assuming they use your idea of using natural gas, they'd need roughly 4 times the storage tanks to hold the same amount of fuel. Not very efficient or cost-effective, particularly in areas with high real-estate costs like NYC.
There are also navigation systems that use geostationary satellites, e.g. Egnos and Inmarsat.
EGNOS augments other satellite navigation systems (GPS, GLONASS, Galileo) by providing ionospheric correction data and other relevant information. It is not a full-fledged navigation system in its own right -- it cannot be used for navigation on its own.
Is there any practical way of shooting down satellites in medium earth orbit? GPS satellites orbit around 20,000km -- that's a long way for any anti-satellite missile.
While "selective availability" (the intentional degradation of civilian signals to roughly 100m accuracy) has been disabled for a while and the new satellites don't have the capability for implementing it, the military does indeed have separate signals for civilian and military users.
Referring to the wikipedia, the civilian signal ("C/A") is only transmitted on the L1 band at 1575.42 MHz. The encrypted precision codes (for the military) are transmitted on both L1 and L2 at 1227.60 MHz. The military signal is indeed quite a bit more accurate than the civilian signal: by itself, the civilian GPS signal is only accurate to around 3 meters. The military signal is accurate to around 30cm.
With current civilian signals only transmitted on a single frequency, receivers cannot correct for ionospheric conditions (which composes a major part of the current uncertainty in measurements) as doing so requires two frequencies. Military signals are transmitted on two frequencies so receivers can correct for ionospheric delay. The military signal is also transmitted at a much higher rate (10x the civilian rate), yielding proportional increases in accuracy.
Currently there are systems like WAAS (North America) and EGNOS (Europe) that provide augmentation in the form of corrections for ionospheric delays (and some other information, like current "health" status of the satellites). This can improve accuracy even more (my handheld civilian unit is able to compute position with an uncertainty of 2 meters). EGNOS also provides an internet feed of the augmentation data so one doesn't have to have a clear view of the geostationary satellites that provide the augmentation. WAAS only augments GPS, but EGNOS augments GPS, GLONASS, and Galileo (for what it's worth at present).
The GPS upgrades will add more detailed signals (the civilian signal will be broadcast on L1 and L2 as well as safety-of-life signal on L5 at 1176.45 MHz). The military codes will also get an upgrade as well, but that won't really matter for civilian users. With the civilian signals being transmitted on a total of three frequencies it will be possible for receivers to account for ionospheric delay and other factors. Overall, things will get considerably more accurate.
You recall incorrectly - the GPS constellation has never had any birds in polar orbit, and has always provided poor coverage at very high latitudes.
On a more detailed note, GPS satellites are in inclined orbits at 55 degrees. This means that a receiver at the pole would only ever see a satellite reach a maximum altitude of 55 degrees over the horizon.
While is certainly isn't as great as at lower latitudes, it's more than adequate to provide location information -- it's not like the poles have huge buildings and whatnot that would obstruct the view. I wouldn't really consider that to be "poor" coverage, but your mileage may vary.
The Russian GLONASS system has satellites in inclined orbits at 64.8 degrees as Russia is located at higher latitudes than the continental US. This can get proportionally better coverage at higher latitudes.
More seriously, though, China has its own spy satellites and certainly has detailed aerial imagery of Taiwan probably in excess of the quality available to commercial imaging satellites. This information being known to the public isn't really going to change anything -- it's not like the average person is going to be able to do anything to a radar installation on a military base.
Doubtful. Youtube is on a separate domain outside of google.com and AFAIK the domain is not encrypted by HTTPS.
...and yet, if you go to https://www.youtube.com/ you can connect to YouTube over HTTPS and you get a certificate with SubjectAltNames including:
Not Critical DNS Name: *.google.com DNS Name: google.com DNS Name: *.youtube.com DNS Name: youtube.com DNS Name: *.youtube-nocookie.com DNS Name: youtu.be DNS Name: *.ytimg.com DNS Name: *.google.com.br DNS Name: *.google.co.in DNS Name: *.google.es DNS Name: *.google.co.uk DNS Name: *.google.ca DNS Name: *.google.fr DNS Name: *.google.pt DNS Name: *.google.it DNS Name: *.google.de DNS Name: *.google.cl DNS Name: *.google.pl DNS Name: *.google.nl DNS Name: *.google.com.au DNS Name: *.google.co.jp DNS Name: *.google.hu DNS Name: *.google.com.mx DNS Name: *.google.com.ar DNS Name: *.google.com.co DNS Name: *.google.com.vn DNS Name: *.google.com.tr DNS Name: *.android.com DNS Name: android.com DNS Name: *.googlecommerce.com DNS Name: googlecommerce.com DNS Name: *.url.google.com DNS Name: *.urchin.com DNS Name: urchin.com DNS Name: *.google-analytics.com DNS Name: google-analytics.com DNS Name: *.cloud.google.com DNS Name: goo.gl DNS Name: g.co DNS Name: *.gstatic.com DNS Name: *.googleapis.cn
While it appears that my earlier statement that Gmail and YouTube share the "same certificate" is not correct, I never said that both Gmail (or other Google services) and YouTube are accessible at the same URL or under the same domain. It's quite possible to have a certificate be valid for numerous domains, as YouTube's certificate is.
It wouldn't surprise me if the Iranians, being unable to effectively differentiate between HTTPS connections to Gmail or YouTube (from my location in Switzerland, both mail.google.com and www.youtube.com resolve to the same/24 block of IPv4 addresses), simply blocked all HTTPS connections to Google netblocks.
Sure, smartcards aren't 100% foolproof, but they're purpose-designed for this sort of thing, are tamper-resistant, have widespread support from a variety of vendors, are cheap (I recently bought a new USB token [with integrated smartcard] for 17 EUR), and there's standardized interfaces for communicating with them.
For general online authentication, use something like OATH one-time passwords (such as produced by hardware tokens, Google Authenticator, or other compatible code generators). It makes password guessing infeasible. For high-security things, smartcards are a better way to go.
This research is interesting, certainly, but there's already much more practical and widespread methods of authenticating users (even though weak passwords seem to be the standard these days), so why bother with a new method that is less flexible than existing methods?
I don't think they intended to block Gmail, but since both Gmail and YouTube are accessible over HTTPS (which I presume the Iranian government cannot sniff without setting off the MITM alarms in browsers) and both sites share the same certificate, they probably just blocked all connections based on the SSL cert being used and didn't notice that they also blocked Gmail.
GPS transmits at modest powers at the source but the signals are extremely weak by the time they reach the earth. GPS signals can't penetrate building materials thicker than a modest window (and even then signal is attenuated significantly) -- LightSquared transmitting at power levels that would have similar signal strength for receivers on the ground would have no functional purpose for terrestrial transmitters.
Also, GPS transmits at extremely low data rates because it is impractical to transmit at high speeds with very low signal strength where you have to do all sorts of magic to get any sort of signal at all.
LightSquared was issued a provisional license to use terrestrial transmitters on those frequencies on the condition that their signals would not interfere with GPS. Their signals did interfere with GPS, therefore they cannot use that spectrum with terrestrial transmitters. Simple as that.
Exactly. This seems like a good idea, and a balance between the.US TLD policy (all information is public) and the.SE TLD policy (no information other than a unique ID string is available to the public with no contact information -- not even an email is available).
I rather like the implementation of whois privacy used by Gandi.net (a French registrar who handles registration for a bunch of TLDs): for domains that are private-by-default (.SE,.uk for individuals, etc.) then they use the registry for privacy and include no information in whois. For domains where whois privacy is available (.com/net/org, etc.) they include the registrant's full name (so it's clear that they are the ones who legally own the domain) and then provide the Gandi postal address where all mail is presumably shredded. They also provide a unique, randomly-generated email address to protect against spam: if you get spam to that address you can simply push a button and a new, random address is created. Legitimate mail is forwarded on to the contact while spam is filtered out.
Gandi offers these privacy services to individuals only: companies and organizations are assumed to be less in need of privacy protecting services and must include their regular contact information.
I have no problem with law enforcement being able to get the details with a warrant issued by a relevant court, but I think the time for having all personal contact information being made public in whois has passed. It used to be that the name and contact information corresponded to a technical contact at an organization responsible for that domain but now many domains are owned by private individuals and this assumption can no longer hold.
Of course, even with a warrant the whois information for suspected bad guys is unlikely to be of use: I doubt the bad guys put in accurate and correct whois information or pay using their personal credit cards (as opposed to anonymous prepaid cards).
Why would a publicly-facing web server be behind NAT? That doesn't make any sense. NAT offers no security benefits.
Please note that "NAT" != "stateful firewall", though the two functions are often combined in a single piece of hardware.
My home network has been dual-stack for years (with NATed IPv4 and IPv6). All the systems on the network are behind a stateful firewall and even though my internal devices have globally-unique IPv6 addresses none of them are accessible from the outside world.
What happens when governments decide it's time to tamper with or block GPS signals?
To what end? What possible purpose would that serve other than to interfere with critical systems like aircraft and marine navigation? (Yes, I know that aircraft and ships have backup means of navigation but it would still cause significant disruption.)
GPS certainly has other uses, precision timekeeping among them, and disruption of GPS would interfere with surveying, time transfer, and a variety of other functions. Pretty much any modern country uses GPS in some way and would suffer from disruption (it's for that very reason that the Russians have built GLONASS and the Europeans are building Galileo -- to provide some degree of independence and redundancy), so anyone looking to tamper with GPS signals would likely be shooting themselves in the foot.
This. My lab works in UHV (~5e-11 mbar): we have a lot of difficulty pumping hydrogen with turbomolecular pumps -- it can backflow through the turbo. We have some big getters to keep it under control, but it's still the largest fraction of residual gas in the system.
Helium's a bit better, in that we can pump it (but a tiny fraction backflows if we're not careful). I don't know how impermeable they are over long timescales (months and years) but Conflat flanges seem to be impermeable to helium for the timescales that we need (hours) -- we have no noticeable increase in helium-3 or -4 during multi-hour measurements without pumping.
First, a RAID array does not "[run] with a hotspare." When a failure occurs, the hotspare becomes a fully integrated member of the array, at which point you would be running without a hotspare, which on a redundant array isn't that much of a problem considering the Dell replacement would be there within 4 hours of reporting/determining a hardware failure.
It took Sun 3+ weeks to send us a replacement hard disk under warranty and required multiple phone calls. This happened on multiple occasions and was one of the main reasons we decided to stop buying Sun servers.
Yes, the spare became an integrated member of the array. That's true. My point was that the hot spare was now a member of the array and we had no remaining spare disks in the array. Since the server hardware only allowed drives with the Sun firmware, we couldn't keep a supply of spare disks around to swap into the arrays as needed.
Second, Dell servers do not have "firmware-locked disks." I've never heard of such a thing. It's a pretty absurd concept that you could only have OEM hard disks in your box, and an unrealistic expectation that clients would comply.
They did: "In the case of Dell's PERC RAID controllers, we began informing customers when a non-Dell drive was detected with the introduction of PERC5 RAID controllers in early 2006. With the introduction of the PERC H700/H800 controllers, we began enabling only the use of Dell qualified drives."
Same thing with Sun, at least at that point in time.
Finally, hardware RAID is leaps and bounds above software RAID. There's a reason it's cheaper to go with software...
Software RAID was perfectly adequate for our needs: as backup servers they didn't need to have the utmost performance. As a bonus, we weren't reliant on a specific make and model of hardware RAID card: we could connect the array to any system running MD. Even under heavy load the demand on the CPU was negligible.
The Sun server was the main Samba share for the lab: lab instruments would write data to it and researchers would access that data on their desktops. It also used software RAID with multiple arrays set up. CPU usage was similarly low, even at high loads, and it worked quite satisfactorily for the lab.
You might have saved money up front, but over the life of the server, you could potentially lose much more when you consider catastrophic hardware failure which would be fully covered under the warranty of the Dell box.
SuperMicro offered a comparable warranty, so that wasn't really an issue.
I'm only really familiar with SuperMicro products, but they offer a pretty standard warranty for their servers. Since they use pretty standard components, rather than vendor-specific stuff or firmware-locked drives (see my other post), spare parts are pretty easy to come by. They had all the standard features like IPMI ("Lights Out"), redundant power supplies, etc.
RMAing broken hard disks to Sun was an exercise in frustration and delays. It literally took weeks to get a hard disk replaced under warranty.
Dell premium support (whatever they call it) for their Optiplex systems was great, but we didn't use Dell servers because they were too expensive. Only downside: their desktops used some Dell-specific variant on the ATX power supply plugs: if we had issues on an out-of-warranty system we'd have to buy a new power supply at an inflated price. It made testing potentially-broken systems considerably difficult.
Why bother with branded parts made by an ODM when you can buy directly from the ODM?
My old workplace had (has, probably) a fairly beefy Sun server with a whole bunch of disks. They used it as a RAID-based storage server for a bunch of lab data. As they do on occasion, a hard disk would crap out. The server wouldn't take ordinary disks, though: it would only accept Western Digital disks with some Sun ID code baked into the firmware -- rather than simply being able to buy a few WD RAID-friendly disks ahead of time, we had to jump through Sun's hoops to get disks replaced under warranty. This usually was a multi-week process, during the array with the failed disk was running with a hot spare -- hardly ideal. That was the last time we bought Sun systems.
At some other point, we were planning on setting up a few more storage servers for backup data. Dell's price for a storage system, including firmware-locked drives, was about triple the cost of doing it ourselves with SuperMicro servers, MD-based software RAID, and RAID-friendly disks. We ended up buying two of the SuperMicro-based systems and putting them in different buildings for semi-offsite backup (the concern was if the server room caught fire, not if a meteor affected the whole city). The only extra step during the setup was putting the disks in their caddies: the Dell systems came with the disks pre-installed. That took about 5 minutes per server. Whoop-dee-doo.
The Dell servers restricted our (with firmware-locked disks) options and cost substantially more than doing it in-house. We'd be stupid to go with their products, as we'd be locked to that vendor for the life of the servers.
Sure, we had Dell Optiplex systems as the desktop workstations for researchers as they were inexpensive, reliable in the lab, and essentially identical (useful for restoring system images from one computer to another), but their server stuff is stupidly overpriced.
The SuperMicro servers were much more "open" in that they used pretty bog-standard parts and didn't have stupid anti-features like firmware locking.
He was a "diplomat" in EVE Online. In real life, he did IT work for the consulate -- he wasn't a diplomat nor any particularly wealthy, privileged person. He's just an ordinary guy doing IT work.
I dunno, I have a ruggedized Samsung mobile phone. It's waterproof to 1 meter, dustproof, vibration resistant, etc. The microphone and speaker are behind impermeable membranes while the battery compartment and microUSB charging port are behind separate gasketed panels.
Every time I open the charging panel I put wear and tear on the gasket material. If I could wirelessly charge it then I'd only ever need to open it if I needed to change SIM cards, the battery, or the rare occasion where I'd need to plug it into the computer for some reason. Wireless charging, even on a charging pad, has some appeal to me.
Slashdot Mirror
Phoenix isn't really at risk from any sort of common natural disaster (barring meteorites or something like that). The only real risk is heat, but datacenters have redundant air conditioners for a reason. /not associated with PhoenixNAP //hosts at a facility in Baltimore
GPS isn't "scrambled in the lower bits".
You're referring to "selective availability" which hasn't been operational since the Clinton administration (and the new satellites intentionally lack SA-capable hardware).
Most of the uncertainty in civilian GPS receivers is due to the relatively low data rate of the civilian signal and the lack of knowledge of ionospheric conditions. The ionosphere issue can be compensated for with WAAS/EGNOS, though having dual-frequency receivers work better.
The "modernized" civilian GPS service will have civilian signals on three frequencies, so that alone should increase the accuracy of civilian receivers. The other improvements will also help.
DGPS can provide much more accurate positioning, particularly for local areas (like a racetrack or farm field). This is indeed useful.
Naturally, using other navigation systems like Galileo (once it's available) and GLONASS can help with navigational accuracy.
Having large quantities of pressurized natural gas can be an explosion risk. Diesel's just a fire risk. Storing pressurized natural gas likely involves a lot of regulatory issues that diesel doesn't.
Also, natural gas is not very efficient volumetrically: diesel has 37.3 MJ/liter. Natural gas at normal pressure has 0.0364 MJ/liter. Even compressed to 250 bar (3,600 psi), a non-trivial pressure, it only has an energy density of 9 MJ/liter. Liquified natural gas at -160C has an energy density of 22.2 MJ/liter. Assuming they use your idea of using natural gas, they'd need roughly 4 times the storage tanks to hold the same amount of fuel. Not very efficient or cost-effective, particularly in areas with high real-estate costs like NYC.
There are also navigation systems that use geostationary satellites, e.g. Egnos and Inmarsat.
EGNOS augments other satellite navigation systems (GPS, GLONASS, Galileo) by providing ionospheric correction data and other relevant information. It is not a full-fledged navigation system in its own right -- it cannot be used for navigation on its own.
Is there any practical way of shooting down satellites in medium earth orbit? GPS satellites orbit around 20,000km -- that's a long way for any anti-satellite missile.
While "selective availability" (the intentional degradation of civilian signals to roughly 100m accuracy) has been disabled for a while and the new satellites don't have the capability for implementing it, the military does indeed have separate signals for civilian and military users.
Referring to the wikipedia, the civilian signal ("C/A") is only transmitted on the L1 band at 1575.42 MHz. The encrypted precision codes (for the military) are transmitted on both L1 and L2 at 1227.60 MHz. The military signal is indeed quite a bit more accurate than the civilian signal: by itself, the civilian GPS signal is only accurate to around 3 meters. The military signal is accurate to around 30cm.
With current civilian signals only transmitted on a single frequency, receivers cannot correct for ionospheric conditions (which composes a major part of the current uncertainty in measurements) as doing so requires two frequencies. Military signals are transmitted on two frequencies so receivers can correct for ionospheric delay. The military signal is also transmitted at a much higher rate (10x the civilian rate), yielding proportional increases in accuracy.
Currently there are systems like WAAS (North America) and EGNOS (Europe) that provide augmentation in the form of corrections for ionospheric delays (and some other information, like current "health" status of the satellites). This can improve accuracy even more (my handheld civilian unit is able to compute position with an uncertainty of 2 meters). EGNOS also provides an internet feed of the augmentation data so one doesn't have to have a clear view of the geostationary satellites that provide the augmentation. WAAS only augments GPS, but EGNOS augments GPS, GLONASS, and Galileo (for what it's worth at present).
The GPS upgrades will add more detailed signals (the civilian signal will be broadcast on L1 and L2 as well as safety-of-life signal on L5 at 1176.45 MHz). The military codes will also get an upgrade as well, but that won't really matter for civilian users. With the civilian signals being transmitted on a total of three frequencies it will be possible for receivers to account for ionospheric delay and other factors. Overall, things will get considerably more accurate.
You recall incorrectly - the GPS constellation has never had any birds in polar orbit, and has always provided poor coverage at very high latitudes.
On a more detailed note, GPS satellites are in inclined orbits at 55 degrees. This means that a receiver at the pole would only ever see a satellite reach a maximum altitude of 55 degrees over the horizon.
While is certainly isn't as great as at lower latitudes, it's more than adequate to provide location information -- it's not like the poles have huge buildings and whatnot that would obstruct the view. I wouldn't really consider that to be "poor" coverage, but your mileage may vary.
The Russian GLONASS system has satellites in inclined orbits at 64.8 degrees as Russia is located at higher latitudes than the continental US. This can get proportionally better coverage at higher latitudes.
Galileo is planned with a 56 degree inclination.
Indeed.
More seriously, though, China has its own spy satellites and certainly has detailed aerial imagery of Taiwan probably in excess of the quality available to commercial imaging satellites. This information being known to the public isn't really going to change anything -- it's not like the average person is going to be able to do anything to a radar installation on a military base.
Doubtful. Youtube is on a separate domain outside of google.com and AFAIK the domain is not encrypted by HTTPS.
...and yet, if you go to https://www.youtube.com/ you can connect to YouTube over HTTPS and you get a certificate with SubjectAltNames including:
Not Critical
DNS Name: *.google.com
DNS Name: google.com
DNS Name: *.youtube.com
DNS Name: youtube.com
DNS Name: *.youtube-nocookie.com
DNS Name: youtu.be
DNS Name: *.ytimg.com
DNS Name: *.google.com.br
DNS Name: *.google.co.in
DNS Name: *.google.es
DNS Name: *.google.co.uk
DNS Name: *.google.ca
DNS Name: *.google.fr
DNS Name: *.google.pt
DNS Name: *.google.it
DNS Name: *.google.de
DNS Name: *.google.cl
DNS Name: *.google.pl
DNS Name: *.google.nl
DNS Name: *.google.com.au
DNS Name: *.google.co.jp
DNS Name: *.google.hu
DNS Name: *.google.com.mx
DNS Name: *.google.com.ar
DNS Name: *.google.com.co
DNS Name: *.google.com.vn
DNS Name: *.google.com.tr
DNS Name: *.android.com
DNS Name: android.com
DNS Name: *.googlecommerce.com
DNS Name: googlecommerce.com
DNS Name: *.url.google.com
DNS Name: *.urchin.com
DNS Name: urchin.com
DNS Name: *.google-analytics.com
DNS Name: google-analytics.com
DNS Name: *.cloud.google.com
DNS Name: goo.gl
DNS Name: g.co
DNS Name: *.gstatic.com
DNS Name: *.googleapis.cn
While it appears that my earlier statement that Gmail and YouTube share the "same certificate" is not correct, I never said that both Gmail (or other Google services) and YouTube are accessible at the same URL or under the same domain. It's quite possible to have a certificate be valid for numerous domains, as YouTube's certificate is.
It wouldn't surprise me if the Iranians, being unable to effectively differentiate between HTTPS connections to Gmail or YouTube (from my location in Switzerland, both mail.google.com and www.youtube.com resolve to the same /24 block of IPv4 addresses), simply blocked all HTTPS connections to Google netblocks.
Sure, smartcards aren't 100% foolproof, but they're purpose-designed for this sort of thing, are tamper-resistant, have widespread support from a variety of vendors, are cheap (I recently bought a new USB token [with integrated smartcard] for 17 EUR), and there's standardized interfaces for communicating with them.
For general online authentication, use something like OATH one-time passwords (such as produced by hardware tokens, Google Authenticator, or other compatible code generators). It makes password guessing infeasible. For high-security things, smartcards are a better way to go.
This research is interesting, certainly, but there's already much more practical and widespread methods of authenticating users (even though weak passwords seem to be the standard these days), so why bother with a new method that is less flexible than existing methods?
I don't think they intended to block Gmail, but since both Gmail and YouTube are accessible over HTTPS (which I presume the Iranian government cannot sniff without setting off the MITM alarms in browsers) and both sites share the same certificate, they probably just blocked all connections based on the SSL cert being used and didn't notice that they also blocked Gmail.
If so, it clearly didn't work as planned.
As does Gandi and Hover (customer only, no other affiliation).
GPS transmits at modest powers at the source but the signals are extremely weak by the time they reach the earth. GPS signals can't penetrate building materials thicker than a modest window (and even then signal is attenuated significantly) -- LightSquared transmitting at power levels that would have similar signal strength for receivers on the ground would have no functional purpose for terrestrial transmitters.
Also, GPS transmits at extremely low data rates because it is impractical to transmit at high speeds with very low signal strength where you have to do all sorts of magic to get any sort of signal at all.
LightSquared was issued a provisional license to use terrestrial transmitters on those frequencies on the condition that their signals would not interfere with GPS. Their signals did interfere with GPS, therefore they cannot use that spectrum with terrestrial transmitters. Simple as that.
Exactly. This seems like a good idea, and a balance between the .US TLD policy (all information is public) and the .SE TLD policy (no information other than a unique ID string is available to the public with no contact information -- not even an email is available).
I rather like the implementation of whois privacy used by Gandi.net (a French registrar who handles registration for a bunch of TLDs): for domains that are private-by-default (.SE, .uk for individuals, etc.) then they use the registry for privacy and include no information in whois. For domains where whois privacy is available (.com/net/org, etc.) they include the registrant's full name (so it's clear that they are the ones who legally own the domain) and then provide the Gandi postal address where all mail is presumably shredded. They also provide a unique, randomly-generated email address to protect against spam: if you get spam to that address you can simply push a button and a new, random address is created. Legitimate mail is forwarded on to the contact while spam is filtered out.
Gandi offers these privacy services to individuals only: companies and organizations are assumed to be less in need of privacy protecting services and must include their regular contact information.
I have no problem with law enforcement being able to get the details with a warrant issued by a relevant court, but I think the time for having all personal contact information being made public in whois has passed. It used to be that the name and contact information corresponded to a technical contact at an organization responsible for that domain but now many domains are owned by private individuals and this assumption can no longer hold.
Of course, even with a warrant the whois information for suspected bad guys is unlikely to be of use: I doubt the bad guys put in accurate and correct whois information or pay using their personal credit cards (as opposed to anonymous prepaid cards).
Why would a publicly-facing web server be behind NAT? That doesn't make any sense. NAT offers no security benefits.
Please note that "NAT" != "stateful firewall", though the two functions are often combined in a single piece of hardware.
My home network has been dual-stack for years (with NATed IPv4 and IPv6). All the systems on the network are behind a stateful firewall and even though my internal devices have globally-unique IPv6 addresses none of them are accessible from the outside world.
What happens when governments decide it's time to tamper with or block GPS signals?
To what end? What possible purpose would that serve other than to interfere with critical systems like aircraft and marine navigation? (Yes, I know that aircraft and ships have backup means of navigation but it would still cause significant disruption.)
GPS certainly has other uses, precision timekeeping among them, and disruption of GPS would interfere with surveying, time transfer, and a variety of other functions. Pretty much any modern country uses GPS in some way and would suffer from disruption (it's for that very reason that the Russians have built GLONASS and the Europeans are building Galileo -- to provide some degree of independence and redundancy), so anyone looking to tamper with GPS signals would likely be shooting themselves in the foot.
Marking that NSFW would have been nice. Normally the Onion is pretty clean and work-safe. That image was not.
This. My lab works in UHV (~5e-11 mbar): we have a lot of difficulty pumping hydrogen with turbomolecular pumps -- it can backflow through the turbo. We have some big getters to keep it under control, but it's still the largest fraction of residual gas in the system.
Helium's a bit better, in that we can pump it (but a tiny fraction backflows if we're not careful). I don't know how impermeable they are over long timescales (months and years) but Conflat flanges seem to be impermeable to helium for the timescales that we need (hours) -- we have no noticeable increase in helium-3 or -4 during multi-hour measurements without pumping.
Those are heavier than helium, which likely defeats the purpose stated in the summary.
"AR" generally means "a rifle based on the Armalite Rifle (e.g. AR-15, M-16, etc.) pattern", and not "Assault Rifle".
First, a RAID array does not "[run] with a hotspare." When a failure occurs, the hotspare becomes a fully integrated member of the array, at which point you would be running without a hotspare, which on a redundant array isn't that much of a problem considering the Dell replacement would be there within 4 hours of reporting/determining a hardware failure.
It took Sun 3+ weeks to send us a replacement hard disk under warranty and required multiple phone calls. This happened on multiple occasions and was one of the main reasons we decided to stop buying Sun servers.
Yes, the spare became an integrated member of the array. That's true. My point was that the hot spare was now a member of the array and we had no remaining spare disks in the array. Since the server hardware only allowed drives with the Sun firmware, we couldn't keep a supply of spare disks around to swap into the arrays as needed.
Second, Dell servers do not have "firmware-locked disks." I've never heard of such a thing. It's a pretty absurd concept that you could only have OEM hard disks in your box, and an unrealistic expectation that clients would comply.
They did: "In the case of Dell's PERC RAID controllers, we began informing customers when a non-Dell drive was detected with the introduction of PERC5 RAID controllers in early 2006. With the introduction of the PERC H700/H800 controllers, we began enabling only the use of Dell qualified drives."
Same thing with Sun, at least at that point in time.
Finally, hardware RAID is leaps and bounds above software RAID. There's a reason it's cheaper to go with software...
Software RAID was perfectly adequate for our needs: as backup servers they didn't need to have the utmost performance. As a bonus, we weren't reliant on a specific make and model of hardware RAID card: we could connect the array to any system running MD. Even under heavy load the demand on the CPU was negligible.
The Sun server was the main Samba share for the lab: lab instruments would write data to it and researchers would access that data on their desktops. It also used software RAID with multiple arrays set up. CPU usage was similarly low, even at high loads, and it worked quite satisfactorily for the lab.
You might have saved money up front, but over the life of the server, you could potentially lose much more when you consider catastrophic hardware failure which would be fully covered under the warranty of the Dell box.
SuperMicro offered a comparable warranty, so that wasn't really an issue.
I'm only really familiar with SuperMicro products, but they offer a pretty standard warranty for their servers. Since they use pretty standard components, rather than vendor-specific stuff or firmware-locked drives (see my other post), spare parts are pretty easy to come by. They had all the standard features like IPMI ("Lights Out"), redundant power supplies, etc.
RMAing broken hard disks to Sun was an exercise in frustration and delays. It literally took weeks to get a hard disk replaced under warranty.
Dell premium support (whatever they call it) for their Optiplex systems was great, but we didn't use Dell servers because they were too expensive. Only downside: their desktops used some Dell-specific variant on the ATX power supply plugs: if we had issues on an out-of-warranty system we'd have to buy a new power supply at an inflated price. It made testing potentially-broken systems considerably difficult.
Why bother with branded parts made by an ODM when you can buy directly from the ODM?
My old workplace had (has, probably) a fairly beefy Sun server with a whole bunch of disks. They used it as a RAID-based storage server for a bunch of lab data. As they do on occasion, a hard disk would crap out. The server wouldn't take ordinary disks, though: it would only accept Western Digital disks with some Sun ID code baked into the firmware -- rather than simply being able to buy a few WD RAID-friendly disks ahead of time, we had to jump through Sun's hoops to get disks replaced under warranty. This usually was a multi-week process, during the array with the failed disk was running with a hot spare -- hardly ideal. That was the last time we bought Sun systems.
At some other point, we were planning on setting up a few more storage servers for backup data. Dell's price for a storage system, including firmware-locked drives, was about triple the cost of doing it ourselves with SuperMicro servers, MD-based software RAID, and RAID-friendly disks. We ended up buying two of the SuperMicro-based systems and putting them in different buildings for semi-offsite backup (the concern was if the server room caught fire, not if a meteor affected the whole city). The only extra step during the setup was putting the disks in their caddies: the Dell systems came with the disks pre-installed. That took about 5 minutes per server. Whoop-dee-doo.
The Dell servers restricted our (with firmware-locked disks) options and cost substantially more than doing it in-house. We'd be stupid to go with their products, as we'd be locked to that vendor for the life of the servers.
Sure, we had Dell Optiplex systems as the desktop workstations for researchers as they were inexpensive, reliable in the lab, and essentially identical (useful for restoring system images from one computer to another), but their server stuff is stupidly overpriced.
The SuperMicro servers were much more "open" in that they used pretty bog-standard parts and didn't have stupid anti-features like firmware locking.
He was a "diplomat" in EVE Online. In real life, he did IT work for the consulate -- he wasn't a diplomat nor any particularly wealthy, privileged person. He's just an ordinary guy doing IT work.
I dunno, I have a ruggedized Samsung mobile phone. It's waterproof to 1 meter, dustproof, vibration resistant, etc. The microphone and speaker are behind impermeable membranes while the battery compartment and microUSB charging port are behind separate gasketed panels.
Every time I open the charging panel I put wear and tear on the gasket material. If I could wirelessly charge it then I'd only ever need to open it if I needed to change SIM cards, the battery, or the rare occasion where I'd need to plug it into the computer for some reason. Wireless charging, even on a charging pad, has some appeal to me.