Monday, May 23, 2005

The compiled .NET code is stored as an assembly.
The assembly stores:

IL code.

Assembly metadata (manifest).
Identity: Name, version and culture info.
Names of files within the assembly.
Types access data: private or otherwise.
Security permissions.

Type metadata.
Details of types, methods and properties within the assembly.

Resources: an assembly is therefore self-describing. It does not depend on external things like registry entries or type library files for reuse. ILDASM tool shipped with .NET gives an insight into the manifest and type metadata.

Sunday, May 15, 2005

Future Imperfect:Deficit Economics


I was at the IMAX for watching XXX-2, Seeing the spending, the mental graph started plotting and I recalled the gerantocratic explosion,soon to be realized, on THIS planet we live. By 2k24,The gray would dominate the Planet. As the youger generations of the present are lesser frugal, I wonder what would happen to the Economies of Various Nations. As the Savings Capital Index goes down with the ageing population, The baby boomers when they hit their 60's , their savings rate would go down and so would the Capitals of various nations..... This is rolling up to take a Snow Ball effect...The solutions I can think of are,

1. National Gov's should encourage by giving more % as interest
2. Tax exemptions for people who save money
3. Gov should introduce a Social Security program that would enforce a fraction of salary to be regular mandatory savings towards the pension schemes.

Thursday, May 12, 2005

The top 10 questions would-be entrepreneurs should ask themselves before pursuing an idea for a business:

1. What is new and different about your innovation?
2. What other things like this are out there? Why is yours better?
3. How big is the market? How many people have this problem?
4. How much would it cost to make this product? And what do you think the market will pay?
5. How defensible is the concept? Is there good intellectual property?
6. How is this innovation strategic to my business?
7. How easy is it to communicate the innovation?
8. How could the product evolve? Is there an opportunity to build it out into a product line? Can it be updated/augmented in future versions?
9. Where would someone expect to purchase this product?
10. What will be tricky or difficult in developing this product?

Friday, May 06, 2005

Fault management is about finding things that go wrong such as failed or damaged components, broken cables etc. This is about things that 'should' be working correctly but aren't. It is not about misconfiguration or user error.

Therefore the best way to tackle fault management is by Monitoring.

Once any piece of hardware, cable or network process is running properly it will normally only stop due to failure (of a part etc.) as long as none of its environmental factors change.


When a problem occurs, the task of fault management is to detect, isolate, and repair malfunctions in the network and its associated systems.

The first step, detection, can be thought of as an online process that gives indication of malfunctioning. Real-time detection mechanisms are usually implemented within the network protocols and devices. These can raise alarms either directly or via monitoring software.

The second step, consists of fault localization and identification. Fault localization is typically achieved through algorithms (procedures) that compute a possible set of faults while fault identification is done by testing and comparing the hypothetical faulty component(s) with known working equipment.

The last step, repair is achieved by taking corrective actions. This step may need equipment replacement, change of system configuration, or software removal of bugs.

Example: AppleTalk
On an AppleTalk network you can watch the Sockets of your major network applications such as AppleShare. If one of these applications crashed your monitoring software would register the fault. It could then inform you by beeping, paging you or even emailing other staff.

Fault Management SystemsAre used to monitor and record information about software and hardware on your network. Each time a fault occurs it should be logged so that the "fault history" of each component of the system/network can be recorded.

Typical information that should be recorded is:


Time/Date fault occured.
How was the fault detected?
What was the duration of the fault? = How long until service restored?
How was service restored? = repair, replace, etc.
What was the cost (time/labour/other) of restoring service?
Time/Date service restored.

By keeping a record of at least the information mentioned above you can easily determine how often a particular item breaks down, when an item is no longer worth repairing, which components are most reliable or otherwise.


--------------------------------------------------------------------------------