The IRS has a capital gains exemption for ordinary people selling their main / residential home (as opposed to investors in the business of flipping houses).

http://www.irs.gov/taxtopics/tc701.html

Basically, if you've lived in your home for at least two of the five years prior to the sale, you can claim a $250,000 capital gains exemption ($500,000 if you are married and file a joint return). In your example, the $100K capital gains would be tax free.

I remember there was a thick coax variant of ethernet too (I think called 10 base 5).

I've never used it, but I remember there were AUIs (attachment unit interface) with a vampire tap that would connect your station to the ethernet cable at specific points (where the standing wave from the carrier would be strongest). The points were marked with dots, and you had to be careful to cut the cable in the right places. The vampire tap would drill into the cable until it reached the inner conductor. Your workstation connected to the AUI tap by a DB-15 cable.

Kids these days have no idea what they're missing!

To be honest, I'm not sure how the LTE side works, or how closely it's integrated with the legacy CDMA2000 network (if at all)... if this means the carriers are implementing an EIR as part of their LTE rollouts, then yes, the newer LTE devices would be covered.

Older CDMA2000 subscribers wouldn't be covered (and right now, there are still millions of those, especially in areas where LTE is not yet available).

As long as the carrier knows the ESN / MEID of the CDMA phone is blacklisted, I assume they'd refuse to activate it.

The tricky part is sharing that blacklist across all carriers in some standard (so if a Verizon handset is marked as stolen, Sprint or another CDMA carrier would know not to activate it). With GSM, that shared database is already defined as a standard and widely implemented (though I'm not sure all GSM carriers actually use it).

WCDMA, and iDEN are basically variations of GSM. Traditional GSM phones run on a TDMA air interface... WCDMA is the use of a CDMA air interface to provide GSM service. It is *not* the same thing as CDMA2000, which is traditionally called "CDMA" here.

http://en.wikipedia.org/wiki/WCDMA#Deployment

The GSM standards define a database called the Equipment Identity Register (EIR), which is what carriers would use to blacklist stolen equipment. GSM network elements already know how to query an EIR to see if a handset is marked as stolen / etc.

CDMA2000 phones have something similar to an IMEI, called a MEID. Unfortunately, the standards used in CDMA2000 networks have no concept of an EIR, let alone any way of querying one. I have no idea how much is involved to retrofit CDMA2000 networks to support an EIR or what components need to be upgraded, but it would definitely include updates to standards, software changes across all equipment manufacturers, and then coordinated deployments across all carriers. It's technically feasible, but I don't see that happening quickly. Remember how long it took operators to adopt number portability in North America?

I was thinking about this the other day as a technical challenge.

Assuming their SMS system handles tens of thousands of texts per second, each of which needs to be tested against this user-definable dictionary of 1600 words, is it even possible for the platform to keep up? Are there sophisticated search / pattern matching algorithms for testing a message against 1600 substrings? I can think of a very naive way to do this, but I'm sure it would not scale.

How would one implement this kind of high-speed pattern matching??

If you have an older unit that needs service, Sony won't railroad you into a newer unit.

I recently sent in a 60GB backward compatible PS3 for repair (wouldn't power on). They gave me the option of a $129 repair, or for $99 I could swap it for one of the newer models instead. The Sony rep left the choice up to me but she definitely understood why I wanted to stick with the older model, in fact almost encouraged me to go that route (I would have anyway).

I paid the $129... they ended up swapping mine for another 60GB backward compatible console. I got my replacement a week after I shipped my old one. The unit I received looked brand new. It was shiny... clean... still had the vinyl cling film. It was a different serial number... but the same model number (CECHA01). It may have been a refurbed unit, but regardless, Sony definitely took care of me.

In what ways is it more complex to administer an email server vs. an SMSC? Have you ever operated an SMSC?

One big difference between email and SMS is the way that messages are delivered to the recipient.

With email, it is up to the client to pull messages from the server periodically. The server doesn't need to worry about the client being unreachable -- if the client is logged in, the POP3 / IMAP transfer is likely to succeed. Thus, the server doesn't need to do anything special to handle retries to millions of clients -- that is all handled client side.

Unlike Email, SMS uses a push model for delivery. The push model minimizes the use of the phone's transmitter, which helps preserve handset battery life. Also, server push allows for immediate delivery of messages (rather than waiting around for the client to log in a few minutes later).

The problem with server push is that it is difficult to scale it to handle thousands of messages per second / millions of oustanding messages, especially when the recipients are often unavailable to receive messages. Sure, a large percentage of SMS messages go through on the first attempt, but definitely not all. There are a number of reasons why SMS delivery might fail (handset powered off, poor signal, overloaded cell site or network, etc).

It is up to the SMSC to implement the retry mechanism. It must handle a large number of queued messages, destined for possibly millions of recipients. The retry mechanism must be effective, minimizing messaging delays. At the same time, it must not be wasteful (SS7 and control channel bandwidth are a finite resource). The carrier may incur SS7 network charges for every delivery attempt, successful or not. In other words, scheduling retries to maximize success, minimize bandwidth demands, and minimize delay is a difficult thing to get right. Blindly retrying everything in the queue every couple of minutes will not fly.

The server push architecture of SMS is one of the main things that makes SMS so much more complex than you seem to think it is. I don't deny that email can be surprisingly complex too, but SMS is far from the simple packet pipe that many people seem to confuse it with.