Single Setup (SS)

Problem: Modern applications used by 99% of population (M$ Office) are very powerful, mature and very configurable. Every such application has a local setup.

Totally encapsulated inside the single machine (aka PC) configuration, and then again inside second layer of partial encapsulation inside a single user environment (aka login, or desktop). Consequently user, utilizing the same application (eg. any Office app) on several desktops will have a task of setting them up all over again and will have several different setups with either big and obvious differences, or ever growing set of annoying little differences between setups of the same application, configured inside different environments on different machines (most often: home PC and office laptop). In case of some extremely pervasive and often used app’s (Outlook) setups are not trivial (passwords, etc) , but are very important for proper functioning. In 99% of cases users are unable and unwilling to synchronize the setups. This is one of the annoyances people "learn to live with".

Ghosting: In case of OS setups there is concept of Ghosting (make and save the binary image of the HD and thus preserve OS installed on it). It is very low level and requires non-trivial specialized knowledge because of OS sensitivity to different hardware. It is also in a legal gray zone, due to the single CPU licensing issue.

VM: Virtual Machine concept makes containment of the whole Os single installation and configuration possible. Again this is very similar to ghosting: a binary single file representing "everything". No real practical use to 99% of users who have no resources and knowledge to manipulate and use VM environment binaries. Also currently real VM capable hardware is out of reach of 99% of users.

Transparent and scalable solution for single setup management is needed.

SS Solution


For each application, store its setup in a single on-line location. Have a single setup used by many application instances configured to run either on-line or locally.

Detached App (DAPP) : I predict transformation of on-line app’s to detached app’s. AJAX+browser is OK, but local application provides more comfortable and secure computing, and utilizes local resources better. on-line services are transparently used when available (reachable).
For a DAPP , SS is essential concept. Actually :

DBJ: "Every App should be DAPP!"

Cloud Computing (CC) : SS service is an natural extension to the set of CC services.

(Marketing: DCGM-C aka DCGM-Cloud. DCGM implementation of the CC for the benefit of DCGM customers)

App agnostic: SS can be made to be independent of the particular App. This has to be investigated. Sharing SS ‘particles’ (pieces of setup data) may be useful. Like common password, or common SS for the host where several app’s are running. Similar to the concept of the WIN Registry  but on-line.

(Marketing: On-line Registry. Is this the SS actually? )

OS-SS: SS for the OS. Passwords, complete hardware and software setup of a single machine (OS installation) can be stored on-line and re-used between machines to achieve exactly the same OS configuration. This would be invaluable productivity booster for Data Center Management! Problem: this is hard to do (impossible?) without changing the OS itself.
(Red Hat Linux core, had to be changed to achieve paravirtualization with it, same as WS2008 Hyper-V release)

OS agnostic: ideally SS may be independent of the underlying OS. Although this has no value for single OS app’s, like MS Office. It would be a very clever feature (expensive to develop and test) used by a tiny minority of users. A careful and consistent statistical research of the market representative sample should give an answer about the commercial feasibility of such a solution.

SS Implementation

On-Line Registry: easy to implement. Very tricky to use safely. Only for WIN platforms. Might be useful for Data Center administrators if supported with good management software with lot of inbuilt WIN registry knowledge and safeguards.

SSML : SS XML schema. Key concept for implementing SS as a CC service.

Legacy App: Adapters to use SS are necessary for legacy app’s. Third party SS adapters are possible. Example: SS UK Ltd (hypothetical co.) makes and sells SS adapters for M$ Office. SS*OL (SS adapter for Outlook 2007) periodically sends the local OL setup to SS service (perhaps owned by SS UK Ltd) for this user and for this machine. On users request SS*OL UI pops-up to make use of the online SS possible and thus to setup the Outlook (fully or partially) on her office laptop, to be exactly the same as her Outlook on her home PC. Or just to transfer her personal e-mail account setup from her home PC and Outlook to her office laptop PC and outlook.

DAPP : new DAPPS will/should use SS with very little development effort to achieve very big advantage vs. non SS enabled Apps.

Commercial Viability

Window of opportunity, defined the maximal time to market, before competition appears and delivers:

MOSS 2007: has no SS concept. But, allows users to store at least 50% of previous local configuration on the MOSS side. Relies on the local Office installation.

SaaS : Software as a Service: makes some kind of DAPP from e.g. M$ Office. With setup stored on the "server side". Requires extremely sophisticated infrastructure, maintenance and support. Out of reach of 90% M$ Office users.

Google Docs:

Open Office (OO): if OO developers "figure it out", they can relatively easily implement the SS concept and transform OO in to the DAPP. They can offer free SS on-line storage.

M$ Office: same goes for M$. Although in the personal computing (vs corporate computing) arena they have no obvious "new way ahead", for the moment.

One thought on “Single Setup (SS)”

Comments are closed.