On and off I have been looking at getting a storage device, notably the Netgear ReadyNAS NV+ and the Drobo. The price held me back on the former and and the USB interface held me back on the latter. Drobo does have a product called DroboShare but it is still USB only.
Now Drobo has released a FireWire 800/USB device and it now look very attractive as a storage device.
With the price of 1TB hard drives hovering around $200, this is hard to argue with.
I have resisted posting anything about the current issues at Twitter, though I have complained about their service in the past, but this time it seems that people are starting to walk.
Two weeks ago TechCrunch carried a story about this with the following comment:
So why aren’t people screaming about the feature being gone? Because this time, they’re just heading over to Friendfeed to have those very same conversations. Friendfeed for most users was just a place to bookmarks all their activities on other social networks. Now, more and more, it’s a place that people start conversations. The early adopters got that a while ago. Now, the not so early adopters are using it as a Twitter replacement, too.
My feeling is that Twitter still has “critical mass”, but my gut tells me that there is a shift going on. I am hearing more and more stories about people tiring of the service outages and while there is a lot of understanding and patience over growing pains and the fact that it is a free service, the lack of reliability and constancy seems to be wearing people down. Migrations always start slowly and happen very quickly when “critical mass” has been achieved, some also call that an “inflection point.”
But I found this story about the perk that Google gives its employees somewhat funny:
Working at Google was once almost an extension of living with your parents, but now it seems dad is starting to charge rent.
I have been looking at the new 3G iPhone and have decided not to upgrade to it from my current iPhone. This for three reasons. First I don’t have 3G where I live. Second I don’t need GPS (yet). Finally the pricing is a gasper. Indeed while the phone is cheaper, the monthly price is higher across the board than the current plan I have. Parenthetically I would note that while ATT calls this an upgrade, it really isn’t since I would still be paying the regular price for the phone and be locking myself into a two year contract, which is no different than what you would get as a new customer.
I think I will wait until the next model.
This post by Dan Pritchett on ACM Queue about “An ACID Alternative” is worth reading if you are into scaling databases.
Nothing really new if you read his “Adding Simplicity” weblog, but a good recap nonetheless.
The sea is full of interesting relationships, some symbiotic, some parasitic, some for convenience, and some we have yet to understand.
This one is interesting, the little red fish are probably using the sea urchin’s spines for protection, but another possible explanation is that they were playing in the eddie currents caused by the water washing over the spines. Indeed there was a lot of current (and surge) on this dive, off Dirty Rock in the Cocos Island, and eddie currents would have formed around the spines of this sea urchin. I am not sure the sea urchin was deriving anything from this (apart from a cleaning of its spines), but the fish seemed to be enjoying it. Most of the sea urchins there had the same thing going on, and there were a lot of them there! The scale is a little deceiving, the spines are actually about 8-12 inches across, definitely a hazard for the unweary diver.
This dive in Dirty Rock was one of the more challenging dives we went on, there was a current and lot of surge. While this was a minor problem at 80 feet, you still had to use your (gloved) hands to maneuver along the bottom, the surge was a pretty major problem for the safety stop at 20 feet and you were bobbed around like a cork in a storm. It was a blast!
I came across this interesting little rumor about the next versions of iTunes and the iPhone/iTouch software. It seems that you will be able to use the iPhone/iTouch as a remote control for iTunes to control playback.
Also use the new Remote application for iPhone or iPod touch to control iTunes playback from anywhere in your home — a free download from the App Store.
I think this is a great idea as I have my music all stored on my desktop computer but I like to play back music through my AppleTV located in my living room (away from my desktop computer). Currently I have to control that either by streaming from my laptop, not ideal, or by using the remote desktop feature to access my desktop computer from my laptop. In either case I need to use my laptop. It would be really nice to use my iPhone to do that instead.
Yes, I could copy my music to my AppleTV, or allow my AppleTV to access my music library remotely but I have good reasons not to want to do that. Mainly because the syncing controls on iTunes are pretty basic.
What I would really like to see is a better way to enter text on my AppleTV, using a bluetooth keyboard for example, using the remote to spell out movie titles really sucks, especially since I can’t rent HD movies from my computer.
Apparently Apple left some superfluous designable.nib files in their apps in Mac OS X 10.5:
While Apple may likely be expanding the use of background file compression to save space in Snow Leopard, today’s Mac OS X Leopard is unnecessarily overweight due to an error Apple made when packaging the system, according to a developer who asked to remain anonymous. Leopard apps all contain superfluous designable.nib files that should have been removed in the Golden Master. “Mail alone has around 1400 of these files, taking up almost 200 MB of disk space,” he noted.
I have to wonder why those files were left there, surely they would have been omitted from the target as part of a production build, but it may be easy to overlook that. I also wonder if they were left in Mac OS x 10.4.x? And I also wonder why Apple has not deleted in any of the 10.5 updates we have had to date.
If it is Apple’s intention to create a single code base for Mac OS X for all their devices (I recall that this was announced at WWDC ‘08) then it would make sense to slim things down as much as possible so that they can target devices with a little as 4GB on them (such as one of the original iPhones.)
Actually I went into a secondary Mac OS X 10.5 installation I have and removed all the designable.nib files from the Application folder with no ill effects. Of course the Application folder is ~40GB so losing ~500MB did not really slim things that much.
I was very interested to read this post by Kristian Nielsen on BIT-aligned storage.
He is comparing the time it takes to get numbers from memory, actually from memory and summing them, with the numbers in their native format, packed to a fixed number of bits and packed to a variable number of bits. Interestingly there was little difference between native format and packed to a fixed number of bits, which really makes sense to me, I have found that bit-shifting is a very cheap operation for modern CPUs.
This was also interesting to me because you usually need to store lots of numbers when you are doing full text indexing. While I have not found the need to pack numbers in memory, I always do so when storing them to disk and transmitting them over the network.
This has two benefits:
The first is that packed numbers are much quicker to read from disk (and write but that is less important) than unpacked numbers, especially if you have small numbers (which you will have if you use deltas as much as possible). This is really not new, I did my first tests on a Centris 610 running A/UX.
The second benefit is that you store the numbers in an architecture neutral format because you don’t have to deal with big-endian vs. little-endian differences. While this is less of an issue today because the i386/AMD64/EMT64 platform is pretty much ubiquitous, it was much more of an issue a decade ago.
The storage mechanism is pretty simple, you grab the lower 7 bits, store those and set the high bit if there are more bits to read, in code:
/* Masks for compressed numbers storage */
#define UTL_NUM_COMPRESSED_CONTINUE_BIT (0x80)
#define UTL_NUM_COMPRESSED_DATA_MASK (0x7F)
#define UTL_NUM_COMPRESSED_DATA_BITS (7)
/* Macro to get the number of bytes occupied by a compressed 32 bit integer.
** The integer to evaluate should be set in uiMacroValue and the number of
** bytes is placed in uiMacroByteCount
*/
#define UTL_NUM_GET_COMPRESSED_UINT_SIZE(uiMacroValue, uiMacroByteCount) \
{ \
if ( uiMacroValue < (1UL << 7) ) \
uiMacroByteCount = 1; \
else if ( uiMacroValue < (1UL << 14) ) \
uiMacroByteCount = 2; \
else if ( uiMacroValue < (1UL << 21) ) \
uiMacroByteCount = 3; \
else if ( uiMacroValue < (1UL << 28) ) \
uiMacroByteCount = 4; \
else \
uiMacroByteCount = 5; \
}
/* Macro for reading a compressed integer from memory. The integer is
** read starting at pucMacroPtr and is stored in uiMacroValue
*/
#define UTL_NUM_READ_COMPRESSED_UINT(uiMacroValue, pucMacroPtr) \
{ unsigned char ucMacroByte = ''; \
ASSERT(pucMacroPtr != NULL); \
uiMacroValue = 0; \
do { \
uiMacroValue = uiMacroValue << UTL_NUM_COMPRESSED_DATA_BITS; \
ucMacroByte = *(pucMacroPtr++); \
uiMacroValue += (ucMacroByte & UTL_NUM_COMPRESSED_DATA_MASK); \
} \
while ( ucMacroByte & UTL_NUM_COMPRESSED_CONTINUE_BIT ); \
}
/* Macro for compressing an unsigned integer and writing it to memory */
#define UTL_NUM_READ_COMPRESSED_UINT(uiMacroValue, pucMacroPtr) \
{ \
ASSERT(pucMacroPtr != NULL); \
for ( uiMacroValue = 0; uiMacroValue <= 0); \
ASSERT(pucMacroPtr != NULL); \
UTL_NUM_GET_COMPRESSED_UINT_SIZE(uiMacroLocalValue, uiMacroByteCount); \
for ( uiMacroBytesLeft = uiMacroByteCount; uiMacroBytesLeft > 0; uiMacroBytesLeft-- ) { \
ucMacroByte = (unsigned char)(uiMacroLocalValue & UTL_NUM_COMPRESSED_DATA_MASK); \
if ( uiMacroBytesLeft != uiMacroByteCount ) { \
ucMacroByte |= UTL_NUM_COMPRESSED_CONTINUE_BIT; \
} \
pucMacroPtr[uiMacroBytesLeft - 1] = ucMacroByte; \
uiMacroLocalValue >>= UTL_NUM_COMPRESSED_DATA_BITS; \
} \
pucMacroPtr += uiMacroByteCount; \
ASSERT(uiMacroLocalValue == 0); \
}
I use macros here because they get called a *lot* and so are faster than functions (even inline ones I think.)
I came across a neat little tool for Mac OS X called Platypus which turns scripts into applications.
From the web site:
Platypus is a developer tool for the Mac OS X operating system. It can be used to create native, flawlessly integrated Mac OS X applications from interpreted scripts such as shell scripts or Perl and Python programs. This is done by wrapping the script in an application bundle directory structure along with an executable binary that runs the script. Platypus thus makes it possible for you to share your scripts and programs with those unfamiliar with the command line interface, without any knowledge of the Mac OS X APIs — a few clicks and you will have your own Mac OS X graphical program. Creating installers, maintenance applications, login items, launchers, automations and droplets is very easy using Platypus.
A nice alternative to running scripts off the command line.
Subscribe in a reader
|
