This morning I woke up to find some articles posted online (here and here) more or less asking Apple to add some functionality to the iPhone. The first article was written by someone looking to ditch their Nokia N95 for the iPhone, but with the snag being that they require it has a better camera. While that is technically the only request, he went out of his way to include a mockup of the phone, which also includes 60GB of storage, a slide out keyboard, a front-facing camera for video chatting, and a camera with optical zoom. The folks over at Gizmodo took the idea and tweaked it some to end up with this.
As I read over these things I can help but wonder, have they not completely missed the boat here? The decision by Apple to not include a physical keyboard, but only a virtual one was without a doubt a huge, nay epic, decision. While the folks over at RIM were scratching their head on how they could possibly make QWERTY keyboard keys smaller, and even resorting to putting two letters on a single key, Apple saw the issue and sidestepped it like the plague. Of course, this decision was very much a gamble, are people ready for this? Are they willing to give up a physical keyboard? The answer is yes. While I can hear the hardcore Blackberry users yelling, I believe this is a case where they need to be ignored (end users don't like to hear this, but there are occasions when its true).
Want proof? Take a gander at the Blackberry Storm and the Android G1.
Like the iPhone, the Storm chose to skip over the physical keyboard and in its place put a virtual one with "haptic-feedback" (the much discussed 'clicking'). I had the chance to play with a Storm briefly this past week and found it to be a nice phone, and while it did take me some time to get used to the keyboard I could see myself becoming quite good with it after a few days of use. Oddly enough, one of the common questions/complaints with the Storm is whether or not the 'click' can be turned off and the keyboard can just be used as a touchscreen (the answer is no). While were on this tour d'phone, it makes sense to discuss the Android G1 which did choose to include a physical keyboard in its design. What feature are the Android developers feverishly working on? That's right, a virtual keyboard. While I have not heard many complaints about the G1's keyboard (granted I don't know anyone with one) people still have a desire for a virtual keyboard, and how convenient it is to be able to immediately type away without having to flip up a screen.
The transition to a virtual keyboard can no doubt be a unpleasant one, but realistically a keyboard the size of a business card (virtual or not) is going take some getting used to. Before you start pondering how you are going to text while driving on a virtual keyboard, you wont have the problem soon, it becomes illegal in California in two days. Problem solved.
After having used the iPhone keyboard for a while now, I can say that the only real issue with it is the lack of landscape typing in crucial applications like Mail and SMS. While I do fine with the vertical keyboard, I think the addition of sideways typing could really make it easier to type away on a long email. I am in no way the only person who feels this way, and I know Apple has received may-a-request for this.
Getting back to the original point of the article, the decision to omit a physical keyboard was no doubt a large one, but it is not something I see being reversed. Virtual keyboards are going to continue to improve to the point that we will look back and laugh at the Blackberries with rice-grain sized keys. So those of you holding out for an iPhone with a full QWERTY, don't hold your breath, or better yet keep dreaming.
Just a few quick note on the other additional features added to the phone:
60GB of space - Sure, who doesn't want more space? That's just a matter of price, SSDs aren't getting cheaper as fast as anyone would like
Front-facing camera - Word is the G2 is going to have this, well see. The type of video you would see (and transmit) on a 3G network in real-time seems pretty awful. While there are physical limitations which constrain this, I think the network is another big consideration.
Optical-zoom camera - No doubt the iPhone camera is beyond pathetic. The lack of even primitive video capture abilities is quite perplexing considering that every cheapish cell today can do this. I think the full zoom is a bit much. Realistically I see improvements to the camera in the future, but its still going to be second-class in the camera department, as are all cellphone cameras.
A Physical Keyboard? Your Insane
Posted by
Jonathan Kupferman
on Monday, December 29, 2008
Labels:
Andriod,
apple,
Blackberry,
Blackberry Storm,
Camera,
G1,
Google Andriod,
iPhone,
N95,
Nokia,
Physical Keyboard,
Virtual Keyboard
Comments: (0)
Blackout
Posted by
Jonathan Kupferman
on Wednesday, December 17, 2008
So I finally had some time and decided to update the styling on my blog. The old one was nice, but I definitely prefer this one much more. Its somewhat different from what I originally had in mind, but I think it's for the better.
Bittorrent using UDP
Posted by
Jonathan Kupferman
on Monday, December 1, 2008
BitTorrent the creators of the very popular uTorrent client have stated that in the next version (currently alpha) they are going to make a proprietary UDP-based protocol called uTP the default protocol used by uTorrent (see announcement). This prompted a fellow over at The Register to predict that this move will cause the internet to meltdown. Of course such a drastic prediction will bring about all sorts of discussion of the issue, see Slashdot posts.
The first thing to understand about BitTorrent and TCP (what it currently uses/defaults to) is that the two are a poor fit. If you think about the way BitTorrent works, it generally creates lots of connections for short lived high throughput transfers. Unlike previous P2P applications (e.g. Kazaa/Napster), files on BitTorrent are split into small chunks, this way the chunks can be downloaded from different hosts simultaneously and likley signficantly faster. Chunks themselves are generally quite small (1MB by default), furthermore, most people tend to have high (broadband) speed connections, thus the duration of the connections to individual hosts is short. These factors make TCP a terrible fit for use in BitTorrent. Basically, when TCP starts a connection it begins sending very slowly (1 in-flight packet) and (exponentially) builds up until it a packet is lost which signals the sender that they may be going too fast. While the exponential increase should lead the sender to reach the maximum send rate quickly it is not quick enough. With the high speed broadband connections available today, it actually takes a reasonable number of round-trips for TCP to reach its maximum send rate. Based on some back of the napkin calculations a 1Mbps link requires 93 in-flight packets to be sent (assuming 1500 byte packet size and 100ms RTT, Throughput=.75*(window size/RTT)). Starting at 1 packet, it will take slow-start 7 round trips (2^7=128) to get up to that rate, and 1Mbps isnt even that fast.... Since the connections made are generally short-lived they will likley spend most of their time in slow start sending much slower then it can actually be.
With all of these factors it comes as no surprise that the folks over at BitTorrent want to make their own protocol which they can optimize for torrenting. Especially since torrent traffic is completely different from the types of traffic TCP was designed for and performs well with. The protocol and the client itself is proprietary which is going to be a point of contention with quite a few people I am sure.
The reason why some have predicted the meltdown of the internet is because UDP does not employ any congestion-control or congestion-avoidance schemes like TCP does, it instead continues to blast away packets as fast as it can. This is the basic version of UDP, the nice thing about UDP is that one add to it the services that they require, and omit those that they dont. TCP already has so many things built it (reliability, etc) that result in poor performance that they simply chose to build it on their own, only including those things that they need while not having to navigate around those things which TCP has already included.
As for now, the UDP based protocol will likley avoid many of the throttling mechanisms put into place by ISPs (e.g. Comcast) to help curb downloading. I dont believe that this is an attempt to avoid these mechanisms since making the traffic UDP allows it to be much easier to distinguish between torrent traffic and other traffic whereas with TCP it is a somewhat more convoluted process. I suspect that this will make it easier for ISPs to classify torrent traffic, the question is what will they do with it.
Update:
I just read this article over at networkperformancedaily.com where the author actually talks to the VP over at BitTorrent Inc. about why they chose to make a protocol, based on what they said it does in fact seem like they are doing the responsible thing, even stating that the protocol needs to be "MORE sensitive to latency then TCP." He also says that it is a "scavenger protocol. It scavanges and uses bandwidth that is not being used by other applications at all.." I think this is the absolutely correct approach to be taking. Just as a kicker to the above article, the first comment posted was by Richard Bennet, the author of the Register's "The Internet is going to meltdown" article.
The first thing to understand about BitTorrent and TCP (what it currently uses/defaults to) is that the two are a poor fit. If you think about the way BitTorrent works, it generally creates lots of connections for short lived high throughput transfers. Unlike previous P2P applications (e.g. Kazaa/Napster), files on BitTorrent are split into small chunks, this way the chunks can be downloaded from different hosts simultaneously and likley signficantly faster. Chunks themselves are generally quite small (1MB by default), furthermore, most people tend to have high (broadband) speed connections, thus the duration of the connections to individual hosts is short. These factors make TCP a terrible fit for use in BitTorrent. Basically, when TCP starts a connection it begins sending very slowly (1 in-flight packet) and (exponentially) builds up until it a packet is lost which signals the sender that they may be going too fast. While the exponential increase should lead the sender to reach the maximum send rate quickly it is not quick enough. With the high speed broadband connections available today, it actually takes a reasonable number of round-trips for TCP to reach its maximum send rate. Based on some back of the napkin calculations a 1Mbps link requires 93 in-flight packets to be sent (assuming 1500 byte packet size and 100ms RTT, Throughput=.75*(window size/RTT)). Starting at 1 packet, it will take slow-start 7 round trips (2^7=128) to get up to that rate, and 1Mbps isnt even that fast.... Since the connections made are generally short-lived they will likley spend most of their time in slow start sending much slower then it can actually be.
With all of these factors it comes as no surprise that the folks over at BitTorrent want to make their own protocol which they can optimize for torrenting. Especially since torrent traffic is completely different from the types of traffic TCP was designed for and performs well with. The protocol and the client itself is proprietary which is going to be a point of contention with quite a few people I am sure.
The reason why some have predicted the meltdown of the internet is because UDP does not employ any congestion-control or congestion-avoidance schemes like TCP does, it instead continues to blast away packets as fast as it can. This is the basic version of UDP, the nice thing about UDP is that one add to it the services that they require, and omit those that they dont. TCP already has so many things built it (reliability, etc) that result in poor performance that they simply chose to build it on their own, only including those things that they need while not having to navigate around those things which TCP has already included.
As for now, the UDP based protocol will likley avoid many of the throttling mechanisms put into place by ISPs (e.g. Comcast) to help curb downloading. I dont believe that this is an attempt to avoid these mechanisms since making the traffic UDP allows it to be much easier to distinguish between torrent traffic and other traffic whereas with TCP it is a somewhat more convoluted process. I suspect that this will make it easier for ISPs to classify torrent traffic, the question is what will they do with it.
Update:
I just read this article over at networkperformancedaily.com where the author actually talks to the VP over at BitTorrent Inc. about why they chose to make a protocol, based on what they said it does in fact seem like they are doing the responsible thing, even stating that the protocol needs to be "MORE sensitive to latency then TCP." He also says that it is a "scavenger protocol. It scavanges and uses bandwidth that is not being used by other applications at all.." I think this is the absolutely correct approach to be taking. Just as a kicker to the above article, the first comment posted was by Richard Bennet, the author of the Register's "The Internet is going to meltdown" article.
Search
Labels
- (14) microsoft
- (11) Google
- (9) Amazon
- (9) cloud computing
- (8) windows
- (6) apple
- (5) amazon ec2
- (5) linux
- (4) Rails
- (4) Ruby on Rails
- (4) advertising
- (4) design
- (4) laptop
- (4) python
- (4) web performance
- (3) Blog
- (3) Caching
- (3) Facebook
- (3) Gmail
- (3) Internet Explorer
- (3) Kindle
- (3) Performance
- (3) Platform-as-a-Service
- (3) RSS
- (3) RSS Readers
- (3) Rackspace
- (3) Ruby
- (3) Seinfeld
- (3) Yahoo
- (3) web design
- (2) Andriod
- (2) Azure
- (2) Bloggers
- (2) CSS
- (2) Chrome
- (2) College
- (2) Downtime
- (2) Firefox
- (2) G1
- (2) Gates
- (2) Google Andriod
- (2) Google Chrome
- (2) HTML
- (2) Jeff Bezos
- (2) Memcached
- (2) MySQL
- (2) Relational Database
- (2) Slashdot
- (2) Software
- (2) Twitter
- (2) Website Performance
- (2) bing
- (2) data storage
- (2) dell
- (2) google app
- (2) iPhone
- (2) interview questions
- (2) ipod
- (2) programming
- (2) search engine
- (2) torrent
- (2) usability
- (2) vista
- (2) web applications