A digital flood is upon us. Content inundates us. It begins as bits of content swirling everywhere—a document, an image, a written corporate procedure, a web page, or an email. The binary mist mixes, combines, and rains down on us. It pools in laptops, on desktops, and in server farms. Creeks and streams meander to corporate reservoirs. Modern civilizations prosper and thrive as continents surrounded by oceans of content.

But content is a resource that must be actively managed in order to safeguard its freshness.  Left unmanaged, it seeps away, picks up funny odors, or simply becomes stale. It is no longer adequate to store content in odd-sized barrels and ladle out more to anyone who needs some.

Shoppers leaving the trolleys in the carpark after shopping

Trolley pushers pushing the trolley back to its original location

Was just reminded of my earlier article at:

http://james.com.sg/2011/04/22/getting-our-trolleys-to-line-upalignment-of-incentives/

Well I was pondering over the trolley issue I kind of blogged about yesterday and came to the realization that such situations are very common in our daily lives.

Basically, we humans are much like flowing water and mindless sheeps when we make our daily decisions in life.  As a result, we tend to make choices based on minimising the marginal costs or maximising the marginal benefits.

To shape human’s behaviour, we try to introduce new incentives/disincentives.  This has the effect of changing the costs structure so that it becomes cheaper for humans to adopt the new behaviour.

MC refers to Marginal Costs and as it is cheaper for more people to perform the undesired behaviour, we need to introduce an incentive, i.e. getting your dollar coin back if you return the cart to its rightful location, to create a new incenticized system.

That is… till the innovation of the chain contraption whereby a person needs to slot in a dollar coin before the trolley could be removed from the trolley chain.  To retrieve back the dollar coin, the shopper will need to chain back the trolley.  The dollar coin was used as some sort of a deposit to incentivize shoppers to return the trolley back to its original holding location.

Some might feel that a civil conscious Singaporean would have returned the trolley to its rightful position without the need of such contraption.  But, maybe instead of overly relying on the innate good naturedness of human beings, it is time for us to start thinking about creating systems with the incentives aligned towards our objectives.

Apparently, since the system is working:

Benefits of a shopper using the trolley > Inconvenience of the shopper in returning it to the trolley queue

Morale of the Story:  By aligning the incentives of the system to the desired outcome/objectives, we can more easily achieve our goals.

But seriously, why not just hire another staff (let’s call him the trolley man) to help return trolleys back to the queue.  It might increase costs slightly.. but the increase in costs might be insignificant if we divide the wages of the trolley man by the number of purchases (as in the case of our endless queues at the checkout counters in NTUC).  Hmmm… besides.. it helps with unemployment… 

Seriously, a trolley man might be the best alternative.  Some people will see the chain contraption as a cost savings to the organisation.  But simply looking at the problem that way would have ignored the fact that the trolley man provides a service far superior to a mechanical chain, i.e.  what if the shopper did not have a dollar coin to spare?  what if the shopper needs to rush off somewhere else and that 2 minutes of fumbling for coins and returning the trolley to its rightful location is just… too costly?

Basically, if

Inconvenience of the shopping using and returning the trolley > Wages of Trolley man / no of trolleys returned per month

Then an optimal system will be to hire a dedicated trolley man to take charge of the returning the trolleys….

Morale of the Story:  Success of a system should always be based on the actual benefit and cost analysis across many different stakeholders.

Hmmm… which makes me wonder… as companies replace phone receptionist with automated answering machines that tells you to….

Press 1 if you would like to speak to sales…. Press 2 if you……

Are they really running their Customer Management System in an optimal way?  If you ask me, I think I would prefer to pay a couple of dollars more for some better service over the phone…

Marcin Jakubowski

Project: Global Village Construction Set

http://www.ted.com/talks/marcin_jakubowski.html

Nice Quote: Our goal is a repository of published designs so clear, so complete, that a single burned DVD is effectively a civilization starter kit

Next Mission:  Set up an OpenSolaris system to function much like my Nexenta SAN with an ISCSI interface!

Installation of Open Solaris

My Redundant Array of Hard Drives

http://docs.huihoo.com/opensolaris/

http://virtualgeek.typepad.com/virtual_geek/2009/01/a-multivendor-post-to-help-our-mutual-iscsi-customers-using-vmware.html

http://virtualgeek.typepad.com/virtual_geek/2009/09/a-multivendor-post-on-using-iscsi-with-vmware-vsphere.html

Nice Instructions on Setting up ISCI and VMWare

http://www.vmadmin.co.uk/vmware/35-esxserver/231-esxvmkernelrrmpiodvs

ISCI

I think I finally got the concept.  Link Aggregation is not for ISCI.  It seems like we got to have dedicated NICs for Link Aggregation for ISCI.

• Step 1: We need to tie these dedicated NICs to VMKernals and then
• Step 2: Get the ISCSI to use these VMKernals to route their traffic.

ISCI Part 2

Pretty interesting read.. on how this guy got it working with his Thecus N7700PRO which is .. a NAS with a  10Gbe interface.  

http://www.gavinadams.org/blog/2010/07/19/esxi-41-and-the-9000-byte-mtu-on-vmk0

Interesting Terms

Interesting new terms I would like to know.

• Jumbo Frames
• Spanning Tree Protocol

Interesting Quotes

If performance is important, have you thought about how many workloads (guests) are you running? Both individually and in aggregate are they typically random, or streaming? Random I/O workloads put very little throughput stress on the SAN network. Conversely, sequential, large block I/O workloads place a heavier load.

https://rcbi.rochester.edu/users/vanooste/weblog/86d4d/What_I_learned_from_ZFS_wNexenta_and_OpenSolaris.html

I like the concept of:

Compression however has been in the system for a bit and works well. The idea is that because you have to read/write less to the IO subsystem you get better response times. The decompression is done in CPU and we’re all happy with much better throughput at the cost of a bit more CPU (which seems ubiquitous in this day and age). The default compression algorithm LZJB is unnoticeable on most systems and gets a decent amount of compression (~40% on my system).

Yes… my CPU is always like grinding at 20%.  Will like to make it just a little harder… if it can give me better performance…

http://www.nexenta.com/corp/nexentastor-overview/nexentastor-versions

Hmm.. the community version is a total of 576MB.  Definitely a much bigger download than FreeNAS.  Going for version 3.0.4.  Hope it goes well…