So the Army was working on a IED defuser to help our boys in the IRAQ. They came up with something that looks like this. Full Wired article is here http://www.wired.com/dangerroom/2011/03/pentagon-still-hearts-its-bogus-bomb-zapper/. Wow.
Tuesday, March 29, 2011
Everyone knows that the truck nuts are supposed to hang from the trailer hitch
So the Army was working on a IED defuser to help our boys in the IRAQ. They came up with something that looks like this. Full Wired article is here http://www.wired.com/dangerroom/2011/03/pentagon-still-hearts-its-bogus-bomb-zapper/. Wow.
Monday, March 28, 2011
ATT handicaps my wifes new smartphone
My wife finally decided to make the jump from the iPhone to a 'NICE' HTC Inspire. Great hardware, to bad it is hobbled by ATT's stupid Android 2.2 build. No SWYPE. Wow... SWYPE was a major reason for convincing my wife to switch. I purchased a Samsung Captivate with 'droid 2.1 and SWYPE is included in the build. So I think no problem, I'll just got to the app store and load it. IT'S NOT IN THE APP STORE. So off I go to the SWYPE site. They have the download available there but I have to violate my phones TOS to load it.
Look ATT, you have totally taken a nice 4G capable (ATT's network != 4G) phone and made it less usable than my Black berry curve from 5 years ago. Shame on you. The phone has a 30 day return policy and I am seriously thinking of taking it back.
Look ATT, you have totally taken a nice 4G capable (ATT's network != 4G) phone and made it less usable than my Black berry curve from 5 years ago. Shame on you. The phone has a 30 day return policy and I am seriously thinking of taking it back.
Friday, March 11, 2011
Wednesday, March 2, 2011
Benchmarking Java IO on Solaris.
So my boss has informed me that our application is due for a large volume increase. To that end he is wanting some testing done to determine if the application can handle the increase. The application performs full text searches on file ranging from 1k to 900 MB uncompressed. With the volume increase the 900 MB may go to 4 GB. Right now all the files are gzipped and they are searched real time when the user submits the query. To bench mark the capabilities for uncompressing and searching a file, I need to come up with an average case and a worst case scenario. My worst case scenario is when the file is on the file system but not in file cache, however, once I read the file then all subsequent tests are invalid because the file-cache will be delivering the file instead of the disk.
I pinged my SA about this and did some research. I tried touching the file, and deleting the file and copying in new version, anything to get the file cache to invalidate the file. Nothing worked. Then in my research I found two techniques to achieve this. The first is loading up the file cache with enough files that the only room left is smaller than the target file. This seemed to be problematic, so I have not gone down this path. I did find a jewel in the mount_ufs man page which leads me to believe that I can mount a dir and tell Solaris to keep these files out of file cache. It is called forcedirectio. I hope it works.
I pinged my SA about this and did some research. I tried touching the file, and deleting the file and copying in new version, anything to get the file cache to invalidate the file. Nothing worked. Then in my research I found two techniques to achieve this. The first is loading up the file cache with enough files that the only room left is smaller than the target file. This seemed to be problematic, so I have not gone down this path. I did find a jewel in the mount_ufs man page which leads me to believe that I can mount a dir and tell Solaris to keep these files out of file cache. It is called forcedirectio. I hope it works.
Subscribe to:
Posts (Atom)
