As told before, I have the ICS as provided by Samsung (to it is not the stock ICS, it is the Samsung-version of ICS) on the Galaxy Tab 10.1. Now that it is nearly two months of using it, I want to share a little bit of my experience.
Basically it just works. If you know ICS already, you more or less know how it is on the Galaxy Tab 10.1.
The calendar app is different, it is the Samsung app, not the native ICS one. I have a problem to sync it with the exchange-connector as it is in Horde 4, but I did not take the time to investigate the issue. My Nexus S connects just fine, so it must be some modification by Samsung which is causing the issue.
Sometimes the tablet hangs, and I have to shutdown by pressing the power button for some seconds. This only happens when connected via WLAN. When I start the tablet again, it will hang again if I am not fast enough to enter the PIN of the SIM, unlock the screen and to deactivate the WLAN. But even then it will hang after the deactivation of the WLAN. After rebooting the second time (with WLAN already deactivated), everything works again.
The email app is also stuttering sometimes. This happens when I open a folder with a lot of emails and the email app is trying to determine if there are attachments or not. Either the app is not multi-threaded, or it is not well done.
Apart from that it just works.
Today I have read an interesting investigation and problem analysis from Jim Gettys.
It is a set of articles he wrote over several months and is not finished writing as of this writing (if you are deeply interested in it go and read them, the most interesting ones are from December and January and the comments to the articles are also contributing to the big picture). Basically he is telling that a lot of network problems users at home (with ADSL/cable or WLAN) experience are because buffers in the network hardware or in operating systems are too big. He also proposes workarounds until this problem is attacked by OS vendors and equipment manufacturers.
Basically he is telling the network congestion algorithms can not do their work good, because the network buffers which are too big come into the way of their work (not reporting packet loss timely enough respectively try to not lose packets in situations where packet loss would be better because it would trigger action in the congestion algorithms).
He investigated the behavior of Linux, OS X and Windows (the system he had available). I wanted to have a quick look at the situation in FreeBSD regarding this, but it seems at least with my network card I am not able to see/find the corresponding size of the buffers in drivers in 30 seconds.
I think it would be very good if this issue is investigated in FreeBSD, and apart from maybe taking some action in the source also write some section for the handbook which explains the issue (one problem here is, that there are situations where you want/need to have such big buffers and as such we can not just downsize them) and how to benchmark and tune this.
Unfortunately I even have too much on my plate to even further look into this. 🙁 I hope one of the network people in FreeBSD is picking up the ball and starts playing.
The nice thing about WLAN is, that you can follow the instructions of your Doctor (“go to bed, sweat a lot, that is the only thing you can do to heal”), and at the same time you can do something if you get bored and have the power to do some not so difficoult reading (if you do not accept a TV in the bedroom like me).