Archive for the ‘Software Astrology’ Category

Software Astrology update (February, 2009)

Sunday, March 1st, 2009

Here is the monthly summary of my Software Astrology blog:

Build Date: December 13

Build Date: December 14

Horoscope on Software: March 2009

- Dmitry Vostokov @ -

Software Astrology Blog (Week 2)

Sunday, January 18th, 2009

Here is the weekly summary of my Software Astrology blog:

Build Date: December 11

Software Meaning of First Names

Build Date: December 12

Winter Computations 

- Dmitry Vostokov @ -

What’s in your name? A Debugging Perspective

Wednesday, January 14th, 2009

An idea came from one of co-authors of a memory visualization book to interpret my name as Debug monitor interrupt __try (Dmitry) to remember correct spelling. As usual I generalize too much and propose to interpret other names from software and debugging perspective to unearth their hidden meaning:

Jeff (Jump exceptionally from fault) 

Serhat (Structured exception redirection handler trap) 

Sasha (Segment aligned structured handler)

Jamie (Jump across memory if exception)

More name interpretations are coming. Please don’t hesitate to send me yours. :-)

- Dmitry Vostokov @ -

Software Astrology Blog (Week 1)

Monday, January 12th, 2009

Week 0 was skipped due to New Year holidays. Here is weekly summary of my Software Astrology blog:

Build Date: December 9

On the Moon and Software

Build Date: December 10

- Dmitry Vostokov @ -

Software Astrology Blog (Week -1)

Sunday, December 28th, 2008

Weekly summary of my Software Astrology blog:

Build Date: December 7

More on Sun and Software

Horoscope on Software: January 2009

Introducing Opcodology

Build Date: December 8

- Dmitry Vostokov @ -

Software Astrology Blog (Week -2)

Monday, December 22nd, 2008

Weekly summary of my Software Astrology blog:

Astrology of Computation

Build Date: December 6

Sun and Software

- Dmitry Vostokov @ -

Software Astrology Blog (Week -3)

Sunday, December 14th, 2008

Weekly summary of my Software Astrology blog:

Build Date: December 3

Build Date: December 4

Software Astrology Depicted

Astrology of Software

Build Date: December 5

- Dmitry Vostokov @ -

Breaking Technical Barrier

Sunday, December 7th, 2008

A short note: sometimes there are difficulties to explain the nature of software faults to not so technically oriented customers or casual inquirers. Here the language of software astrology can greatly help in assembling the right phrases and provide easily understandable analogies.

- Dmitry Vostokov @ -

Software Astrology Blog

Sunday, December 7th, 2008

I’ve decided to decouple software astrology posts from this software science-oriented blog and founded:

Currently it hosts a blog called:

Software Astrology: The Dark Side of Software Science

There you can find all build date astrology posts and more are coming. In a welcome note to the blog I wrote down motivations behind it:

Welcome to Software Astrology!

To maintain the link between two blogs I’m going to post weekly summaries.

- Dmitry Vostokov @ -

Build Date: December 2

Friday, December 5th, 2008

Warning!: This post belongs to Build Date Astrology category. Do not take it seriously.

The Day of Larger Than Computation

Modules, products or systems built on December 2 have tremendous execution power. No matter how small their code they will exert an influence on their surrounding execution environment. Less evolved components built on that day can do great amount of damage to themselves and other modules. Computation is their God. When provoked by testing or debugging they are confrontational but not very aggressive. Often December 2 modules, products or systems see computation as a struggle where they must emerge as a victor. They are fighting not for their resources but for the certain basic computational values they were programmed for. Integrity is very important for them. The great challenge for December 2 components is to reconcile their computational individualism and their built-in computational paths. Often they stray from the latter. They constantly learn throughout their complex computational life what is true and what is false. Although December 2 modules, products or systems health is built-in they need regular yearly checkups with a software maintenance engineer otherwise small problems go too long without being found and fixed. Idle periods of activity are very important to their computational health. If they have a sibling component built on the same date they behave like subordinated to it.

DLL, SYS and EXE born on this date:

MSVCR80.dll Sat Dec 02 17:50:32 2006
rdbss.sys   Thu Dec 02 20:37:11 2004
Mup.sys     Thu Dec 02 20:37:23 2004
ftdisk.sys  Thu Dec 02 22:29:58 2004 
hal.dll     Thu Dec 02 22:29:15 2004

Weaknesses: Manipulative computation.

Strengths: Dynamic computation, lucid code, human orientation.

Advice: Watch your debugging temper. Regardless of what customers say, fixing bugs is not everything. Be self-assure, less judgemental and condemning to software. Acknowledge your debugging weaknesses and past mistakes.

- Dmitry Vostokov @ -

Build Date: December 1

Tuesday, December 2nd, 2008

Warning!: This post belongs to Build Date Astrology category. Do not take it seriously.

The Day of Debugging License

Modules, products or systems built on December 1 win customers over despite denying the rules of protocol. They can provide impression of simplicity but this is not the case. Their internals can be very complex and their perceived simplicity is the direct consequence of their user interface. Modules are not fully aware of what they are doing and seen as being driven by external components. Modules, products or systems built on this day are very busy with computation and have little time to care about users despite their built-in human-computer interaction. However they strive to calculate the impossible in all domains. They love to interact with other components with opposite behaviour. December 1 components are free modules and exert the full computation capabilities on the right data arrived at the right time. Working too many hours can seriously damage their internals and they may loose touch with their built-in goals. Sometimes December 1 modules, products or systems outrageous behaviour need to be amended to become more tolerable and not to hang. They need to be idle from time to time to avoid burn-out.

DLL, SYS and EXE born on this date:

VERSION.dll    Wed Dec 01 01:37:27 1999
nvcoaft51.sys  Wed Dec 01 11:55:40 2004
dump_m5289.sys Wed Dec 01 02:49:17 2004
CFGMGR32.DLL   Wed Dec 01 15:37:31 1999
MPRAPI.DLL     Wed Dec 01 15:37:29 1999
ICMP.DLL       Wed Dec 01 15:37:29 1999
RTUTILS.DLL    Wed Dec 01 15:37:27 1999

Weaknesses: Misdirected computation, unawareness of environment.

Strengths: Energetic computation, UI extroverts.

Advice: Keep a handle on your desire to debug. Beware of damaging other processes and alienating users with a overly direct debugging approach.

- Dmitry Vostokov @ -

The Deep Meaning of Astrology

Monday, December 1st, 2008

A bit of digression on the first winter day in Ireland. What does it mean to be meanigful as astrology? It is meaningful as Tr O(Log y):

AsTrOLogy ↔ As Tr O(Log y) As O(Log y) ↔ bound (or dominated in case of small-o notation) by Log y after some y >= y0 or bound (or dominated in case of small-o notation) by -logy. So Astrology is bounded and dominated by Y (Why?) lowered in magnitude by Log. Bounded and dominated by the this ultimate question…

Tr is trace operation in linear algebra. Tr (a number) = a number by definition of a 1×1 matrix
O is Big O notation

- Dmitry Vostokov @ -

Build Date: November 30

Sunday, November 30th, 2008

Warning!: This post belongs to Build Date Astrology category. Do not take it seriously.

The Day of Measured Testing

Modules built on November 30 have a built-in capacity for  overcoming challenges of hostile environments. They are capable of bringing surprises to security attacks, for example. One can learn a lot about them by studying their traces or doing reverse engineering. November 30 components do their work to the utmost degree of quality with a little waste of CPU and memory. Message boxes they pop up have a subtle sense of thought-provoking humour but it can also be a full blown thigh-slapping. November 30 systems are very defensive when attacked. They are stubbornly resistant to reverse engineering but at the same time very open to honest debugging. 

DLL, SYS and EXE born on this date: 

tifsfilt.sys Tue Nov 30 07:16:27 2004
alrsvc.dll   Tue Nov 30 17:31:14 1999
ntkrpamp.exe Fri Nov 30 14:54:49 2007
Tppwrif.sys  Tue Nov 30 02:38:22 2004

Weaknesses: Over-reactive to code and data injection, funny behaviour.

Strengths: Thorough developed, dynamic responsiveness.

Advice: Improvise during troubleshooting and debugging. Admire control vs. spontaneity balance. Laugh at your failures.

- Dmitry Vostokov @ -

Introducing Build Date Astrology

Sunday, November 30th, 2008

I often hear about cosmic mysteries or influences when problems happen in computer environments. Passing by an astrology section in a local book shop yesterday a revelation came to me that a compile / link time (build time) might influence a component (DLL, EXE, SYS files), product or system behaviour. From now on I’m going to blog about every build date with examples. And as usual, I’m also going to publish a book for this iterative and incremental activity called:

Title: The Secret Language of Build Dates: Unique Astrology Profiles for Every Build of the Year with Advice on Testing, Troubleshooting and Debugging
ISBN: 978-1906717407

Knowing build dates will help you to test, troubleshoot and even debug software in hopeless cases where you don’t know where to start. Astrology will help you to choose a random direction! Finally the output of WinDbg lmv command has more sense to me :-)

- Dmitry Vostokov @ -