Offspec is good if the player is skilled. For example, a healadin as main spec and a generic DPS for off.
However, in EQ2 and WoW, if you have an offspec, you should have an equipment change to back it up. If, for example, I went out as a DPS role with all my equipment sporting +INT and +heal stats on a WoW paladin, I'd be asked to swap specs, or leave. Similar if an Everquest 2 guardian or WoW warrior was wanting to tank a raid encounter with his high DPS 3h weapon as opposed to a decent sword/shield combination.
The biggest problem I see with offspec stuff is that players tend to not know their alternate spec well. This happens often with people whose primary spec is DPS, and the secondary spec is healing or tanking. They know their DPS spec well and the exact rotation to use to keep their numbers high, but if they are asked to step up to the plate and be a meat shield, their timing is poor, and knowing what to throw when you need to throw it is everything. For example, if you know a boss is going to pop off a nasty attack on the tank very shortly (decimate on Gluth is a good example), you have your long casting, high hit point heal being cast so it lands just after the damage is done. Not having this timing in place can turn a normally successful raid into a record stock dividend for the NPC armor repairer's guild.
I say it depends on the app. If the app were like the above, "find me a Chinese food place that scored 85+ on the health inspection", either a Web app that was cached, or a native app (binary, or running in a VM like Dalvik or a true JVM) would be just fine.
If I wanted an app that would encrypt databases on my device when I am not using them, I would want that to be completely native with no reliance on anything Web based for maximum security. Same with a utility that mounts a file as a filesystem (TrueCrypt). I wouldn't want this to be a web app where it could be yanked and changed without my permission, or even notice.
If I wanted an app that did something very intricate, I would want it to be a locally installed binary, because with web apps, I have no guarentee about the version I did a project in will be the same version I open it up tomorrow, and there might have been some glitches in regression testing that would make a project done in an earlier version not work properly.
If I wanted an app that would point me to the nearest theater playing the latest blockbuster flick and also having Guinness on tap, I'd almost certainly want this to be a Web app because this is almost exactly what this is made for, because this info is always dynamically updated. Same with an app that fetches me tickets. I want this to be dynamic because ticket ordering systems change, and I want the latest version on my device no matter what.
So, both native apps and Web apps both have a place on a device, depending on their function.
You hit the nail on the head. If one uses these, they should either use an alias (I know Hushmail and Yahoo both offer alias functionality) that they can filter incoming mail with.
Even better, because Gravatar is essentially Alice and Bob, they should have gone with either a salt (64 bits is "meh", 128 is decent, 256 is good for the forseeable future), SHA-256, and toss in a site key that only their backend database knows. This way, it would be immensely difficult to associate the hash with an E-mail address even if the attacker suspected both were connected.
Best of all would just to have Gravatar use random nonces and have their backend database store the nonce -> user tuple. This way, there is no algorithm that would allow an attacker to correlate decisively the pictures and E-mail addresses. Even better would be a many to one ratio so a user can have hundreds of nonces, so an attacker couldn't use frequency guessing to figure out an E-mail address.
I disagree here. About five months ago, a friend of mine bought an unlocked GSM phone, went to AT&T and he got a month to month plan at their standard rates, with no contracts. The only thing he had to pay for was the $20 for the SIM card. I'm sure AT&T wasn't happy not selling a phone, but better a constant revenue stream from a paying customer on their network than no customer at all.
T-Mobile is another example. When I needed a second line for a family member, I generously relieved a generic GSM phone of its SIM lock, and obtained a non contract plan for multiple devices from T-Mobile. They threw in the SIM card gratis.
CDMA carriers might be a different story. I was browsing random Web forums and people were stating that certain CDMA carriers have a blanket policy of not letting any device on their network that do not have their logo on it. This may not be the case today.
If one travels abroad, GSM capability does mean a lot. One can either use a GSM provider such as T-Mobile that has towers in the destination country, or if the phone is unlocked, swap the SIM card out for a local provider and go that route. A number of countries tend to go with pay-as-you-go SIM cards where one buys the SIM at a store with x amount of time on it and uses that until it is depleted.
Even in the US, there isn't a real alternative. Until both the CDMA providers here support R-UIM cards (unlikely, but it might happen when they get rolling to 4G), you have to get authorization to have a phone's ESN put onto a CDMA provider's network (and from what various forums state, getting authorization for a phone may not be easy). Even if one is able to bypass the lock (generally more difficult than the average SIM card unlocking), moving a phone across the American CDMA providers is nowhere as easy as GSM technology.
If in the US, I'd probably say none of this matters, because not many people (relatively) buy unlocked phones and then shop for a provider. Unless someone has an existing contract, Americans tend to buy a phone and deal with the provider secondary, as opposed to other parts of the world where one shops for a phone, then shops for a provider. This isn't to say people don't do that in the US, but it is more difficult to find a phone and match it to a provider (US GSM is wonky with its oddball frequency ranges used) than it is to either find a provider you like and shop from their phone collection, or find a phone you like and deal with the carrier.
As it stands in the US, there are two well entrenched market niches for smartphones. The first of which are the unlocked phones (or the phones one pays full retail price for from a provider.) This is about $400-$600. The second is the provider sponsored phone where one pays the cost of the phone via a contract. The price ceiling in the US is effectively set for this by Apple at around $200.
The ads wouldn't be welcomed in the unlocked phone arena. If I pay the premium price tag for an unlocked phone, I won't be buying one that slings ads at me. If the contract changes while I have the phone, I'll be rooting the device and yanking that "functionality" out, or not accepting the changes in my contract and will toss the phone in the garbage. Then I will go with a provider who wouldn't pull that on me.
If I were paying for a phone subsidized over 2 years, ads are not welcome here either. If my phone gets an OTA update to become an ad vomiter, that is a change in my contract that I do not have to accept, and I will trash the phone and change providers.
So, where would the ad-supported device model come to play? I see only one place, and that is the low end market, such as the prepaid phones one sees for sale for $15-$30, or the "free" phones that come with a 1-2 year contract. Maybe this market is what Google might be aiming for, where people would tolerate ads in return for a smartphone that costs $20.
Problem is, is the mostly compatible nature. If someone is familar with Pozidriv heads and uses the right tool, it works out. However, someone not familar with it and not noticing the four marks that show the differences might just reach for a Phillips screwdriver and likely cam it out.
This is why I like Torx or Robertson (square heads), because to cam it out, it takes more than reaching for something that "mostly fits" to trash things, although having the wrong sized screwdriver might do some damage.
Blecch, the Phillips screwdriver is one of the most brain damaged things ever invented, much less standardized. Torx is far better, spline drive and Bristol set can handle serious torque without rounding out, and even the old square (Robertson) head at least doesn't strip a screw after a few cycles of opening and tightening down. The only reason why that type of screw head became prominent is because it would cam out and strip the screw as opposed to snapping off the screw head, which was important in factories with workers new to the technology, and the fact torque measurements back then were "tighten until it strips then back off a quarter turn".
I'd like to see a standard in batteries, but it would also have to be expandable. As batteries get embedded controllers to help fine tune the power output from individual cells, what might be a good, standard connector last year may not support the micromanagement needed for optimal power tuning in years to come.
That right there is why I like T-Mobile. After a while in a contract, their CS will most likely be kind enough to give one an unlock code, especially if one is traveling abroad. This is a courtesy that I don't often see with other providers, and this is one reason I have stayed with them for so long. T-Mobile is the best provider in the US to get if you have an unlocked GSM phone, want to plunk down $20 for a SIM card, and start rolling with a plan.
I REALLY hope T-Mobile gets the Milestone (GSM version of the Droid) if they don't get the Nexus One. In the US, T-Mobile's biggest weakness is that their phones tend to be a half generation to a generation behind everyone else's. Right now, Verizon has the Droid, Sprint has the Moment, AT&T has the iPhone, and there is no real front running star of the show in T-Mobile's lineup if one is shopping for a phone first, network second. T-Mobile needs a kick butt phone desperately.
Exactly. I have been a long (7 years) T-Mobile customer, and have been OOC since '07. I'm debating myself between three things, either buying a subsdized phone and a two year contract (paying a bit more monthly to amortize the phone's subsidy), buying a phone at retail price and staying OOC (out of contract), or just hitting Google up for an ADP2, dropping a SIM card in and going that route. Since the retail price of the MyTouch 3G, and Google's ADP2 are very close, I may just buy the ADP2 (both are rebranded HTC Magics.)
What makes me wonder if Google would offer the Nexus One phone as an ADP3, unlocked and allowing root access so I can put a custom OS build on it. Except for the fact that this phone doesn't have a slide out keyboard (which does make a difference when you have a ssh client up), it would be an ideal thing to have all around.
How about instead of a title, they either send an unlock code/OTA unlock the phone when the contract ends, or the ETF is paid? That would be only fair.
For CDMA phones, this isn't an issue as much, but for GSM phones, it would be nice to pick up a SIM card in Elbonia when travelling there and use that provider's network rather than hoping for coverage from a US place.
Maybe a compromise would be to have multiple repositories in tiers:
A tier 1 repository would be packages that come with the OS, of known good quality stuff. gcc, the kernel, GNOME/KDE libraries, Open Office, etc. In RedHat, this would be stuff signed with the distribution key.
A tier 2 repository would be packages that have been vetted by an independant person, where the package had the source code examined and was built from source by a third party. Problem is that this takes time and lots of eyeballs, and time is money. Volunteers might help, but it might take an actual revenue stream to make this doable, most likely by donations and ad revenue. These packages would be signed by the independant distributor.
A tier 3 repository would be a free for all, have a disclaimer that you have zero clue what you are getting, so examine the source code. Signing would either be missing altogether, or done by the author.
The problem is that Linux historically has had clean repositories since its inception. It is very rare for someone to drop malware into the "food supply" of distros. People write a utility, post it on freshmeat, people toy with it, and if the program is good, the author may get some help, or it may become a distinct project in its own right. Its just not heard of for someone to write a Trojan in this fashion, even though its something that isn't a complete surprise.
Of course, we can go to a third party dedicated to vetting software, but then it becomes an arms race of who can write the most obfuscated code to get tricks and traps past the people viewing who might not be dedicated security experts and who might miss a pointer arithmetic error that later on down the line might give an intruder a backdoor.
It is a cool excercise in geekdom to have that though. Plus, another advantage of having the WPA2 password change every so often is that you can give your LAB party guests the WPA password for that interval of time and know that as soon as the cronjob fires to change the router's key, their access automatically gets pulled. Without the cryptographic nonce, they have no way of figuring out what the n+1 phrase is.
If I read TFA right, he is implying that "don't put anything on the Internet you don't want personally associated with you, even by your worst enemies", a good slogan to think about before clicking "send" on a Web page, a Slashdot post, a Facebook entry, etc.
If this is correct, then its understandable. Companies can be coerced to not just hand over information, but to actively be a partner in a civil/criminal case with a gag order put on them.
That could be a decently secure system if done right. Have a program running on each of the boxes that takes the year, date, day of week, and hour (perhaps having a value for quarter hour, but you don't want to granular because machines may not be that tightly timesynced). Then add a secret key value. 128 bits would be minimum, best would be something 512 bits of cryptographically strong unpredictable data.
SHA-512 the date info + the random secret key, and convert the info to a WPA2 key format by getting 63 usable characters and dropping the rest, and you have a decent key that changes with time, but in a way that no attacker could duplicate or know what a future change would be. Since they don't have the nonce value that is appended, they have no way of knowing what the result will be, even if they know your date format.
Of course, your weakest link will then become one of your hosts because if an attacker roots one, they can grab the secret key.
I personally don't change my WPA2 key that often (every six months or when I reinstall a laptop), mainly because there are not any feasible attacks, even in theory, that can break a key over time that there are with WEP, or perhaps WPA. I could be wrong though. Maybe its time to move to WPA2 Enterprise sooner or later so the weak link isn't the shared secret.
If an attacker can get at my machine's clipboard, then I have far bigger problems to worry about other than how sturdy my WPA2 key is. That's akin to worrying if someone is fretting about using Medeco M3, Abloy PROTEC, or Evva MKS on the front door when a robber just smashed into the living room with a pickup truck.
The weakest point of the WPA2 implementation is that every machine on the SSID has to know that key. So if one laptop gets compromised and the attacker is able to extract the key, they have a ticket to entry as long as the MAC address is changable to mimic ones in use. If you want better security, there is always WPA2-Enterprise (EAP-TLS or PEAP) and running your own RADIUS server. The best security is running WPA2-Enterprise, EAP-TLS, and having the client key be on a smart card. This way, even if an attacker steals the laptop, smart card, and smart card PIN, it can be booted off the network access list without affecting any other hosts. Instead of a separate smart card, an on board TPM also works well, allowing transparent network use, but preventing someone from spoofing unless a laptop is compromised [1]. Another way to mitigate loss of a WPA2 key is to use multiple wireless networks, and to put each machine on its own SSID. Of course, on home equipment, this requires an AP per SSID, and on business class routers, you might be limited to only 16 SSIDs.
Oh, one last thing... turning off SSID broadcasting does almost nothing for security. Focus on making the WPA2 key secure instead.
[1]: Wireless security can't help if a laptop is compromised, similar to an ignition lock doesn't help protect a house window (obligatory car analogy). There are other technologies to use to prevent that, disk encryption, antivirus software, two factor authentication, and running a separate user on machines for administrative work versus everyday use on a machine [2].
[2]: Some people say that a standard is "username" for the general use user and "aausername" for the user with admin rights.
Believe it or not, there are some embedded devices which don't have the CPU juice for WPA2, so they were given a BIOS update so they can run something better than WEP as some form of security. WPA has its issues, but it sure beats WEP.
The best wireless setup is to have two wireless SSIDs. Your internal one that runs off of WPA2-Enterprise, RADIUS server, and smart cards. Then an external one that has a stern packet filter and throttling mechanism. This way, people can log on your open wireless to check E-mail, but Limewire and other P2P apps will be stopped. Of course, someone can jump that, but if they do that, its not your problem anymore.
I do see one use for MAC address security, and its more of a legal thing than computer protection. If a security breach criminal case winds up in court, and you can prove a potential intruder was bypassing your MAC security, it might land a conviction. Otherwise, someone can make up a story of you allowing people to have your WPA2 passwords, etc.
Even better, use a utility that gets random data without going through the Internet. Here, I use KeePass, tell it to make a 63 character random string, wiggle the mouse and type in some keys.
Then I paste the string into my router, put a copy of the string on a file in a TC protected container. That I copy to a USB flash drive and manually copy and paste that into the rest of my boxes' WPA2 config.
If I forget the WPA2 password, who cares. I log on the router via a hardwired connection, repeat the above process. I also repeat the above every so often (about once or twice yearly).
If someone can brute force a cryptographically secure 63 digit password to get on my WPA2 subnet, they must be very desperate.
The trick is: You do not have to remember the 63 digit string. This means you can use a phrase without worry about trying to keep it in your head. You just need to have it stored in a secure place so you can cut and paste it to all your machines.
RAIT? There are some larger tape units that support striping across multiple drives similar to RAID 1 and 5. There is even RAID across multiple libraries (RAIL) where you have multiple libraries. However, RAIT and RAIL are extremely rare these days, and tend to not to be used.
As for backup programs supporting this, Amanda has been known to have this functionality to my knowledge. I'm sure TSM, Networker, and others do as well.
Fortunately, newer versions of TC have two headers, so if the main one is scrozzled, you can check the "use backup header embedded in the volume if available" under Mount Options and have a second chance of mounting the volume.
With modern compression and encryption algorithms, a single bit flipped can mean a *lot* of downstream corruption, especially in video that uses deltas, or encryption algorithms that are stream based, so all bits upstream have some effect as the file gets encrypted. A single bit flipped will render an encrypted file completely unusable.
Having ECC in metadata is fine, but in a perfect world, applications shouldn't ignore ECC. Especially when a file is being used and modified. Instead, either the app should update the ECC records when any writes are performed, or at least when the file is being closed.
I agree with you about ZFS. Getting Sun to dual license it under the GPL would mean it becoming a de facto standard everywhere but Macs and Windows. However, we should have ECC in the file format, so regardless of what type of machine a file is stored on, there is a good chance of repairs for a file.
On an ISO basis, one can use a utility like DVDDisaster to append ECC info to the end of an ISO file before burning to CD or DVD. Since this is transparent to user action, the use of the added ECC only really comes into play if a MD5 hash check fails.
The problem we face is that ECC file formats are rare that store the error correction in the same file, unless one breaks up a file and uses.PAR files. You have winRAR, StuffIt, and WinACE which all have user selectable levels of ECC [2], but all the three formats are proprietary. What is needed is an open specification like gzip, 7zip, or bzip2 to have not just build in ECC, but user selectable. Reason? Some cases, just 1% of ECC is more than enough. Other cases, having the file almost 2-3 times its original size [1] may not be enough, especially for long term archiving of large files onto WORM media for long term storage (50 years if a business is under FCC laws, 7 years in most cases.)
The solution: A format that is licensed under either the Creative Commons and is not subject to patents where it allows the user to select where the ECC coding is added (just appended versus interspersed through the file), how much ECC is added, and perhaps various HMACs (SHA-256) so the decoding part can immediately check for damage. Then have both a dedicated utility that is dual licensed under GPL/BSD, and have the functionaly available as an option in bzip2, tar, gzip, 7zip, and other compression methods, just like encryption is available. Even the OpenPGP format should have ECC as an option after signing and encrypting the packet.
The key to this is standardization, both across platforms, and throughout time. We don't need differing ECC utility standards. We need -ONE- ECC standard for a file format and no others. This ensures that if I encode a file on a Mac today, 20 years from now, I decode it using a ringtop display projecting into the air, it will decode with no problems or incompatibilities.
[1]: Sometimes it is better to have one file with twice the space of ECC than it is to have two files. The reason for this is that two files would have to be constantly diffed, and one wouldn't know which was corrupted. Plus, file manipulation is easier with just one.
[2]: Sometimes it helps for a user to select how the ECC is distributed. Some media might have large bursts of errors such as a uncorrectable scratch in a CD. Other media might have a lot of random noise that is scattered. Having methods to be able to deal with both conditions in general, but yet optimize for one of them might be a good thing, especially for a long term format.
Five releases for clients, with general features added (IIRC):
Windows 2000 Workstation -- came out early and was the successor for NT. Had decent DirectX support while NT had rudimentary at best. First plug and play OS, allowing for removable drive support. Supported AD and GPOs. Came with EFS. Built in Web server. Dynamic volumes. A mechanism for getting updates via the Web.
Windows ME -- From Windows 98, a few UI changes, a DRM stack (Protected Audio Path) ensuring that non trusted sound card drivers would not be able to decode songs, and a OS rollback mechanism.
Windows XP -- Fundamentally Windows 2000, except with a decorative UI change, the same Protected Audio Path as ME, activation (unless a VL copy), incoming firewall (it was in since the OS release, but SP3 made the XP firewall a lot more prominent), volume snapshots (for being able to back up open files), another version of DirectX, ability to roll back drivers, and the ability to work well with USB flash media. Better EFS implementation (allowing multiple users access to encrypted files, as well as allowing for no data recovery agent by default.)
Windows Vista -- Previous version functionality, better separated user/admin roles, a lot of security behind the scenes (ASLR), incoming/outgoing firewall, better concurrent user functionality, and BitLocker. Image based installs. Better functionality with SATA and RAID units, so one doesn't need to provide a floppy during install time. A move away from using the Web browser for getting product updates.
Windows 7 -- BitLocker To Go, AppLocker, much less resource use, more behind the scenes security, ability to combine the EFS Data Recovery agent with BitLocker's recovery needs, innate OS virtualization, and a recovery partition installed by default.
Server operating systems since 2000 are similar:
Windows Server 2000 -- same codebase as Windows 2000 Workstation, first iteration of Active Directory, IPSEC, built in Web server. Built in mechanism for updating manually via the Web (then later on automatically.)
Windows Server 2003 -- Previous Versions functionality, upgraded group policies, activation in non VL editions, Secure Audio Path, VSS (volume snapshots), dynamic volumes with RAID 5 support.
Windows Server 2008 -- Image based incremental backups, BitLocker, better support for SATA and RAID installs, a lot of behind the scenes security (ASLR, etc), NAC, clustering of virtualization with Hyper-V, read-only domain controllers, ability to turn off Active Directory services, better UPS support, and self-healing NTFS.
Windows Server 2008 R2 -- Better use of resources, more behind the scenes security, BitLocker To Go added, native support of VHD volumes, better caching functionality, enhanced Hyper-V support, better power management, and the Active Directory recycle bin.
The LapLink mover (especially the Enterprise version) is a good idea for this case.
Call me an old coot, but I just do not like, in any fashion, an OS upgrade between versions (especially for production critical machines.) Installing on a bare metal machine means that there is no cruft, half-configured files, broken Registry/ODM/NetInfo entries, or anything else on the OS partitions that might cause problems. Plus, if there is an application issue, it is easier to find conflicts.
Of course, the nice by-product of a complete bare metal install is the ability to re-partition the OS drives, so if a machine should have the OS drive mirrored, this is a good time to find another disk to drop in, change the OS drives to RAID candidates on a RAID card, and install.
There are of course exceptions. On non-production systems (read, systems I don't need to have an auditable documentation trail), I used to be able to upgrade RedHat versions by a simple manual RPM install of the core "redhat-release" RPM, then run yum -y upgrade from a repository on the LAN and let it run. In a few hours, most likely I'd end up with either the latest version of the OS. The cases it didn't work, I'd end up with some RPM dependency that would need to be cleared up, and then it would finish the upgrade cycle.
Slashdot Mirror
Offspec is good if the player is skilled. For example, a healadin as main spec and a generic DPS for off.
However, in EQ2 and WoW, if you have an offspec, you should have an equipment change to back it up. If, for example, I went out as a DPS role with all my equipment sporting +INT and +heal stats on a WoW paladin, I'd be asked to swap specs, or leave. Similar if an Everquest 2 guardian or WoW warrior was wanting to tank a raid encounter with his high DPS 3h weapon as opposed to a decent sword/shield combination.
The biggest problem I see with offspec stuff is that players tend to not know their alternate spec well. This happens often with people whose primary spec is DPS, and the secondary spec is healing or tanking. They know their DPS spec well and the exact rotation to use to keep their numbers high, but if they are asked to step up to the plate and be a meat shield, their timing is poor, and knowing what to throw when you need to throw it is everything. For example, if you know a boss is going to pop off a nasty attack on the tank very shortly (decimate on Gluth is a good example), you have your long casting, high hit point heal being cast so it lands just after the damage is done. Not having this timing in place can turn a normally successful raid into a record stock dividend for the NPC armor repairer's guild.
I say it depends on the app. If the app were like the above, "find me a Chinese food place that scored 85+ on the health inspection", either a Web app that was cached, or a native app (binary, or running in a VM like Dalvik or a true JVM) would be just fine.
If I wanted an app that would encrypt databases on my device when I am not using them, I would want that to be completely native with no reliance on anything Web based for maximum security. Same with a utility that mounts a file as a filesystem (TrueCrypt). I wouldn't want this to be a web app where it could be yanked and changed without my permission, or even notice.
If I wanted an app that did something very intricate, I would want it to be a locally installed binary, because with web apps, I have no guarentee about the version I did a project in will be the same version I open it up tomorrow, and there might have been some glitches in regression testing that would make a project done in an earlier version not work properly.
If I wanted an app that would point me to the nearest theater playing the latest blockbuster flick and also having Guinness on tap, I'd almost certainly want this to be a Web app because this is almost exactly what this is made for, because this info is always dynamically updated. Same with an app that fetches me tickets. I want this to be dynamic because ticket ordering systems change, and I want the latest version on my device no matter what.
So, both native apps and Web apps both have a place on a device, depending on their function.
You hit the nail on the head. If one uses these, they should either use an alias (I know Hushmail and Yahoo both offer alias functionality) that they can filter incoming mail with.
Even better, because Gravatar is essentially Alice and Bob, they should have gone with either a salt (64 bits is "meh", 128 is decent, 256 is good for the forseeable future), SHA-256, and toss in a site key that only their backend database knows. This way, it would be immensely difficult to associate the hash with an E-mail address even if the attacker suspected both were connected.
Best of all would just to have Gravatar use random nonces and have their backend database store the nonce -> user tuple. This way, there is no algorithm that would allow an attacker to correlate decisively the pictures and E-mail addresses. Even better would be a many to one ratio so a user can have hundreds of nonces, so an attacker couldn't use frequency guessing to figure out an E-mail address.
I disagree here. About five months ago, a friend of mine bought an unlocked GSM phone, went to AT&T and he got a month to month plan at their standard rates, with no contracts. The only thing he had to pay for was the $20 for the SIM card. I'm sure AT&T wasn't happy not selling a phone, but better a constant revenue stream from a paying customer on their network than no customer at all.
T-Mobile is another example. When I needed a second line for a family member, I generously relieved a generic GSM phone of its SIM lock, and obtained a non contract plan for multiple devices from T-Mobile. They threw in the SIM card gratis.
CDMA carriers might be a different story. I was browsing random Web forums and people were stating that certain CDMA carriers have a blanket policy of not letting any device on their network that do not have their logo on it. This may not be the case today.
If one travels abroad, GSM capability does mean a lot. One can either use a GSM provider such as T-Mobile that has towers in the destination country, or if the phone is unlocked, swap the SIM card out for a local provider and go that route. A number of countries tend to go with pay-as-you-go SIM cards where one buys the SIM at a store with x amount of time on it and uses that until it is depleted.
Even in the US, there isn't a real alternative. Until both the CDMA providers here support R-UIM cards (unlikely, but it might happen when they get rolling to 4G), you have to get authorization to have a phone's ESN put onto a CDMA provider's network (and from what various forums state, getting authorization for a phone may not be easy). Even if one is able to bypass the lock (generally more difficult than the average SIM card unlocking), moving a phone across the American CDMA providers is nowhere as easy as GSM technology.
If in the US, I'd probably say none of this matters, because not many people (relatively) buy unlocked phones and then shop for a provider. Unless someone has an existing contract, Americans tend to buy a phone and deal with the provider secondary, as opposed to other parts of the world where one shops for a phone, then shops for a provider. This isn't to say people don't do that in the US, but it is more difficult to find a phone and match it to a provider (US GSM is wonky with its oddball frequency ranges used) than it is to either find a provider you like and shop from their phone collection, or find a phone you like and deal with the carrier.
As it stands in the US, there are two well entrenched market niches for smartphones. The first of which are the unlocked phones (or the phones one pays full retail price for from a provider.) This is about $400-$600. The second is the provider sponsored phone where one pays the cost of the phone via a contract. The price ceiling in the US is effectively set for this by Apple at around $200.
The ads wouldn't be welcomed in the unlocked phone arena. If I pay the premium price tag for an unlocked phone, I won't be buying one that slings ads at me. If the contract changes while I have the phone, I'll be rooting the device and yanking that "functionality" out, or not accepting the changes in my contract and will toss the phone in the garbage. Then I will go with a provider who wouldn't pull that on me.
If I were paying for a phone subsidized over 2 years, ads are not welcome here either. If my phone gets an OTA update to become an ad vomiter, that is a change in my contract that I do not have to accept, and I will trash the phone and change providers.
So, where would the ad-supported device model come to play? I see only one place, and that is the low end market, such as the prepaid phones one sees for sale for $15-$30, or the "free" phones that come with a 1-2 year contract. Maybe this market is what Google might be aiming for, where people would tolerate ads in return for a smartphone that costs $20.
Problem is, is the mostly compatible nature. If someone is familar with Pozidriv heads and uses the right tool, it works out. However, someone not familar with it and not noticing the four marks that show the differences might just reach for a Phillips screwdriver and likely cam it out.
This is why I like Torx or Robertson (square heads), because to cam it out, it takes more than reaching for something that "mostly fits" to trash things, although having the wrong sized screwdriver might do some damage.
Blecch, the Phillips screwdriver is one of the most brain damaged things ever invented, much less standardized. Torx is far better, spline drive and Bristol set can handle serious torque without rounding out, and even the old square (Robertson) head at least doesn't strip a screw after a few cycles of opening and tightening down. The only reason why that type of screw head became prominent is because it would cam out and strip the screw as opposed to snapping off the screw head, which was important in factories with workers new to the technology, and the fact torque measurements back then were "tighten until it strips then back off a quarter turn".
I'd like to see a standard in batteries, but it would also have to be expandable. As batteries get embedded controllers to help fine tune the power output from individual cells, what might be a good, standard connector last year may not support the micromanagement needed for optimal power tuning in years to come.
That right there is why I like T-Mobile. After a while in a contract, their CS will most likely be kind enough to give one an unlock code, especially if one is traveling abroad. This is a courtesy that I don't often see with other providers, and this is one reason I have stayed with them for so long. T-Mobile is the best provider in the US to get if you have an unlocked GSM phone, want to plunk down $20 for a SIM card, and start rolling with a plan.
I REALLY hope T-Mobile gets the Milestone (GSM version of the Droid) if they don't get the Nexus One. In the US, T-Mobile's biggest weakness is that their phones tend to be a half generation to a generation behind everyone else's. Right now, Verizon has the Droid, Sprint has the Moment, AT&T has the iPhone, and there is no real front running star of the show in T-Mobile's lineup if one is shopping for a phone first, network second. T-Mobile needs a kick butt phone desperately.
Exactly. I have been a long (7 years) T-Mobile customer, and have been OOC since '07. I'm debating myself between three things, either buying a subsdized phone and a two year contract (paying a bit more monthly to amortize the phone's subsidy), buying a phone at retail price and staying OOC (out of contract), or just hitting Google up for an ADP2, dropping a SIM card in and going that route. Since the retail price of the MyTouch 3G, and Google's ADP2 are very close, I may just buy the ADP2 (both are rebranded HTC Magics.)
What makes me wonder if Google would offer the Nexus One phone as an ADP3, unlocked and allowing root access so I can put a custom OS build on it. Except for the fact that this phone doesn't have a slide out keyboard (which does make a difference when you have a ssh client up), it would be an ideal thing to have all around.
How about instead of a title, they either send an unlock code/OTA unlock the phone when the contract ends, or the ETF is paid? That would be only fair.
For CDMA phones, this isn't an issue as much, but for GSM phones, it would be nice to pick up a SIM card in Elbonia when travelling there and use that provider's network rather than hoping for coverage from a US place.
Maybe a compromise would be to have multiple repositories in tiers:
A tier 1 repository would be packages that come with the OS, of known good quality stuff. gcc, the kernel, GNOME/KDE libraries, Open Office, etc. In RedHat, this would be stuff signed with the distribution key.
A tier 2 repository would be packages that have been vetted by an independant person, where the package had the source code examined and was built from source by a third party. Problem is that this takes time and lots of eyeballs, and time is money. Volunteers might help, but it might take an actual revenue stream to make this doable, most likely by donations and ad revenue. These packages would be signed by the independant distributor.
A tier 3 repository would be a free for all, have a disclaimer that you have zero clue what you are getting, so examine the source code. Signing would either be missing altogether, or done by the author.
The problem is that Linux historically has had clean repositories since its inception. It is very rare for someone to drop malware into the "food supply" of distros. People write a utility, post it on freshmeat, people toy with it, and if the program is good, the author may get some help, or it may become a distinct project in its own right. Its just not heard of for someone to write a Trojan in this fashion, even though its something that isn't a complete surprise.
Of course, we can go to a third party dedicated to vetting software, but then it becomes an arms race of who can write the most obfuscated code to get tricks and traps past the people viewing who might not be dedicated security experts and who might miss a pointer arithmetic error that later on down the line might give an intruder a backdoor.
It is a cool excercise in geekdom to have that though. Plus, another advantage of having the WPA2 password change every so often is that you can give your LAB party guests the WPA password for that interval of time and know that as soon as the cronjob fires to change the router's key, their access automatically gets pulled. Without the cryptographic nonce, they have no way of figuring out what the n+1 phrase is.
If I read TFA right, he is implying that "don't put anything on the Internet you don't want personally associated with you, even by your worst enemies", a good slogan to think about before clicking "send" on a Web page, a Slashdot post, a Facebook entry, etc.
If this is correct, then its understandable. Companies can be coerced to not just hand over information, but to actively be a partner in a civil/criminal case with a gag order put on them.
That could be a decently secure system if done right. Have a program running on each of the boxes that takes the year, date, day of week, and hour (perhaps having a value for quarter hour, but you don't want to granular because machines may not be that tightly timesynced). Then add a secret key value. 128 bits would be minimum, best would be something 512 bits of cryptographically strong unpredictable data.
SHA-512 the date info + the random secret key, and convert the info to a WPA2 key format by getting 63 usable characters and dropping the rest, and you have a decent key that changes with time, but in a way that no attacker could duplicate or know what a future change would be. Since they don't have the nonce value that is appended, they have no way of knowing what the result will be, even if they know your date format.
Of course, your weakest link will then become one of your hosts because if an attacker roots one, they can grab the secret key.
I personally don't change my WPA2 key that often (every six months or when I reinstall a laptop), mainly because there are not any feasible attacks, even in theory, that can break a key over time that there are with WEP, or perhaps WPA. I could be wrong though. Maybe its time to move to WPA2 Enterprise sooner or later so the weak link isn't the shared secret.
If an attacker can get at my machine's clipboard, then I have far bigger problems to worry about other than how sturdy my WPA2 key is. That's akin to worrying if someone is fretting about using Medeco M3, Abloy PROTEC, or Evva MKS on the front door when a robber just smashed into the living room with a pickup truck.
The weakest point of the WPA2 implementation is that every machine on the SSID has to know that key. So if one laptop gets compromised and the attacker is able to extract the key, they have a ticket to entry as long as the MAC address is changable to mimic ones in use. If you want better security, there is always WPA2-Enterprise (EAP-TLS or PEAP) and running your own RADIUS server. The best security is running WPA2-Enterprise, EAP-TLS, and having the client key be on a smart card. This way, even if an attacker steals the laptop, smart card, and smart card PIN, it can be booted off the network access list without affecting any other hosts. Instead of a separate smart card, an on board TPM also works well, allowing transparent network use, but preventing someone from spoofing unless a laptop is compromised [1]. Another way to mitigate loss of a WPA2 key is to use multiple wireless networks, and to put each machine on its own SSID. Of course, on home equipment, this requires an AP per SSID, and on business class routers, you might be limited to only 16 SSIDs.
Oh, one last thing... turning off SSID broadcasting does almost nothing for security. Focus on making the WPA2 key secure instead.
[1]: Wireless security can't help if a laptop is compromised, similar to an ignition lock doesn't help protect a house window (obligatory car analogy). There are other technologies to use to prevent that, disk encryption, antivirus software, two factor authentication, and running a separate user on machines for administrative work versus everyday use on a machine [2].
[2]: Some people say that a standard is "username" for the general use user and "aausername" for the user with admin rights.
Believe it or not, there are some embedded devices which don't have the CPU juice for WPA2, so they were given a BIOS update so they can run something better than WEP as some form of security. WPA has its issues, but it sure beats WEP.
The best wireless setup is to have two wireless SSIDs. Your internal one that runs off of WPA2-Enterprise, RADIUS server, and smart cards. Then an external one that has a stern packet filter and throttling mechanism. This way, people can log on your open wireless to check E-mail, but Limewire and other P2P apps will be stopped. Of course, someone can jump that, but if they do that, its not your problem anymore.
I do see one use for MAC address security, and its more of a legal thing than computer protection. If a security breach criminal case winds up in court, and you can prove a potential intruder was bypassing your MAC security, it might land a conviction. Otherwise, someone can make up a story of you allowing people to have your WPA2 passwords, etc.
Even better, use a utility that gets random data without going through the Internet. Here, I use KeePass, tell it to make a 63 character random string, wiggle the mouse and type in some keys.
Then I paste the string into my router, put a copy of the string on a file in a TC protected container. That I copy to a USB flash drive and manually copy and paste that into the rest of my boxes' WPA2 config.
If I forget the WPA2 password, who cares. I log on the router via a hardwired connection, repeat the above process. I also repeat the above every so often (about once or twice yearly).
If someone can brute force a cryptographically secure 63 digit password to get on my WPA2 subnet, they must be very desperate.
The trick is: You do not have to remember the 63 digit string. This means you can use a phrase without worry about trying to keep it in your head. You just need to have it stored in a secure place so you can cut and paste it to all your machines.
RAIT? There are some larger tape units that support striping across multiple drives similar to RAID 1 and 5. There is even RAID across multiple libraries (RAIL) where you have multiple libraries. However, RAIT and RAIL are extremely rare these days, and tend to not to be used.
As for backup programs supporting this, Amanda has been known to have this functionality to my knowledge. I'm sure TSM, Networker, and others do as well.
Fortunately, newer versions of TC have two headers, so if the main one is scrozzled, you can check the "use backup header embedded in the volume if available" under Mount Options and have a second chance of mounting the volume.
With modern compression and encryption algorithms, a single bit flipped can mean a *lot* of downstream corruption, especially in video that uses deltas, or encryption algorithms that are stream based, so all bits upstream have some effect as the file gets encrypted. A single bit flipped will render an encrypted file completely unusable.
Having ECC in metadata is fine, but in a perfect world, applications shouldn't ignore ECC. Especially when a file is being used and modified. Instead, either the app should update the ECC records when any writes are performed, or at least when the file is being closed.
I agree with you about ZFS. Getting Sun to dual license it under the GPL would mean it becoming a de facto standard everywhere but Macs and Windows. However, we should have ECC in the file format, so regardless of what type of machine a file is stored on, there is a good chance of repairs for a file.
On an ISO basis, one can use a utility like DVDDisaster to append ECC info to the end of an ISO file before burning to CD or DVD. Since this is transparent to user action, the use of the added ECC only really comes into play if a MD5 hash check fails.
The problem we face is that ECC file formats are rare that store the error correction in the same file, unless one breaks up a file and uses .PAR files. You have winRAR, StuffIt, and WinACE which all have user selectable levels of ECC [2], but all the three formats are proprietary. What is needed is an open specification like gzip, 7zip, or bzip2 to have not just build in ECC, but user selectable. Reason? Some cases, just 1% of ECC is more than enough. Other cases, having the file almost 2-3 times its original size [1] may not be enough, especially for long term archiving of large files onto WORM media for long term storage (50 years if a business is under FCC laws, 7 years in most cases.)
The solution: A format that is licensed under either the Creative Commons and is not subject to patents where it allows the user to select where the ECC coding is added (just appended versus interspersed through the file), how much ECC is added, and perhaps various HMACs (SHA-256) so the decoding part can immediately check for damage. Then have both a dedicated utility that is dual licensed under GPL/BSD, and have the functionaly available as an option in bzip2, tar, gzip, 7zip, and other compression methods, just like encryption is available. Even the OpenPGP format should have ECC as an option after signing and encrypting the packet.
The key to this is standardization, both across platforms, and throughout time. We don't need differing ECC utility standards. We need -ONE- ECC standard for a file format and no others. This ensures that if I encode a file on a Mac today, 20 years from now, I decode it using a ringtop display projecting into the air, it will decode with no problems or incompatibilities.
[1]: Sometimes it is better to have one file with twice the space of ECC than it is to have two files. The reason for this is that two files would have to be constantly diffed, and one wouldn't know which was corrupted. Plus, file manipulation is easier with just one.
[2]: Sometimes it helps for a user to select how the ECC is distributed. Some media might have large bursts of errors such as a uncorrectable scratch in a CD. Other media might have a lot of random noise that is scattered. Having methods to be able to deal with both conditions in general, but yet optimize for one of them might be a good thing, especially for a long term format.
Five releases for clients, with general features added (IIRC):
Windows 2000 Workstation -- came out early and was the successor for NT. Had decent DirectX support while NT had rudimentary at best. First plug and play OS, allowing for removable drive support. Supported AD and GPOs. Came with EFS. Built in Web server. Dynamic volumes. A mechanism for getting updates via the Web.
Windows ME -- From Windows 98, a few UI changes, a DRM stack (Protected Audio Path) ensuring that non trusted sound card drivers would not be able to decode songs, and a OS rollback mechanism.
Windows XP -- Fundamentally Windows 2000, except with a decorative UI change, the same Protected Audio Path as ME, activation (unless a VL copy), incoming firewall (it was in since the OS release, but SP3 made the XP firewall a lot more prominent), volume snapshots (for being able to back up open files), another version of DirectX, ability to roll back drivers, and the ability to work well with USB flash media. Better EFS implementation (allowing multiple users access to encrypted files, as well as allowing for no data recovery agent by default.)
Windows Vista -- Previous version functionality, better separated user/admin roles, a lot of security behind the scenes (ASLR), incoming/outgoing firewall, better concurrent user functionality, and BitLocker. Image based installs. Better functionality with SATA and RAID units, so one doesn't need to provide a floppy during install time. A move away from using the Web browser for getting product updates.
Windows 7 -- BitLocker To Go, AppLocker, much less resource use, more behind the scenes security, ability to combine the EFS Data Recovery agent with BitLocker's recovery needs, innate OS virtualization, and a recovery partition installed by default.
Server operating systems since 2000 are similar:
Windows Server 2000 -- same codebase as Windows 2000 Workstation, first iteration of Active Directory, IPSEC, built in Web server. Built in mechanism for updating manually via the Web (then later on automatically.)
Windows Server 2003 -- Previous Versions functionality, upgraded group policies, activation in non VL editions, Secure Audio Path, VSS (volume snapshots), dynamic volumes with RAID 5 support.
Windows Server 2008 -- Image based incremental backups, BitLocker, better support for SATA and RAID installs, a lot of behind the scenes security (ASLR, etc), NAC, clustering of virtualization with Hyper-V, read-only domain controllers, ability to turn off Active Directory services, better UPS support, and self-healing NTFS.
Windows Server 2008 R2 -- Better use of resources, more behind the scenes security, BitLocker To Go added, native support of VHD volumes, better caching functionality, enhanced Hyper-V support, better power management, and the Active Directory recycle bin.
The LapLink mover (especially the Enterprise version) is a good idea for this case.
Call me an old coot, but I just do not like, in any fashion, an OS upgrade between versions (especially for production critical machines.) Installing on a bare metal machine means that there is no cruft, half-configured files, broken Registry/ODM/NetInfo entries, or anything else on the OS partitions that might cause problems. Plus, if there is an application issue, it is easier to find conflicts.
Of course, the nice by-product of a complete bare metal install is the ability to re-partition the OS drives, so if a machine should have the OS drive mirrored, this is a good time to find another disk to drop in, change the OS drives to RAID candidates on a RAID card, and install.
There are of course exceptions. On non-production systems (read, systems I don't need to have an auditable documentation trail), I used to be able to upgrade RedHat versions by a simple manual RPM install of the core "redhat-release" RPM, then run yum -y upgrade from a repository on the LAN and let it run. In a few hours, most likely I'd end up with either the latest version of the OS. The cases it didn't work, I'd end up with some RPM dependency that would need to be cleared up, and then it would finish the upgrade cycle.