Software Astrology

This is a short summary of behavioural and structural characteristics for modules, products and systems built during Winter time:

• Follow the large picture
• Tend to be dominant components ruling process and kernel space. Often initiate process space reformation
• Flexible data manipulation
• Interface acceptance
• Frequently the source of creativity

During Winter, software constructors live in expectation of coming Spring, less active, more conscious with internal aspects of their being and this channels into code construction and then into built modules, products and systems. Build activities, design of expressible and powerful UI and marketable features are diminished during this period. Some old components are even face possibility to enter the end of their life cycle.

Computational life cycles also have their winter periods, called χ-Winter (from χειμώνας, Greek) which might not coincide with the same physical periods due to the lag time of channeling. There can be one to many correspondence between one physical winter period and χ-Winter periods with some boundary overlapping due to the presence of Riemann surfaces (*) in computational space-time.

(*) Riemann surfaces are manifold representations of multivalued functions that explain side effects of many computational algorithms when doThis() function gives several unexpected results instead of the expected one.

- Dmitry Vostokov @ SoftwareAstrology.com -

The Day of Assembly Language

Modules, products or systems built on December 12 emphasize the importance of hardware and interfacing with it is their main goal. They have a window into physical memory. Components built on December 12 are active and computationally healthy regardless of being thin or fat clients and give impression of being comfortable with hardware even when computing expressively. They let other components know about their presence. The voice quality of a module, a product or a system built on December 12 (*) is more important characteristic than what they are voicing. In order to grow, December 12 components must deeply explore hardware resources. However they shouldn’t be overly attached to ageing hardware. They must learn values of limits and correspondingly restrict their computational activities. Structuring their idle time and data consumption are paramount to their security. Here local data is better than remote with its network system excitations.

(*) The voice of EXE, DLL or SYS component can be generated with the help of Dump2Wave tool.

DLL, SYS and EXE born on this date:

WMEncEng.dll Thu Dec 12 13:09:17 2002
CHDART64.sys Tue Dec 12 20:07:25 2006
volmgr.sys   Tue Dec 12 22:29:12 2006
msisadrv.sys Tue Dec 12 21:42:18 2006
pci.sys      Tue Dec 12 21:42:27 2006
swenum.sys   Tue Dec 12 22:28:16 2006
mssmbios.sys Tue Dec 12 21:42:24 2006
termdd.sys   Tue Dec 12 22:53:43 2006
COMMONFX.SYS Wed Dec 12 02:47:17 2007
CTEDSPSY.SYS Wed Dec 12 02:47:15 2007
CTEDSPIO.SYS Wed Dec 12 02:47:12 2007
CTEDSPFX.SYS Wed Dec 12 02:46:05 2007
ctprxy2k.sys Wed Dec 12 02:45:54 2007
ctaud2k.sys  Wed Dec 12 02:45:52 2007
ha10kx2k.sys Wed Dec 12 02:45:39 2007
ctoss2k.sys  Wed Dec 12 02:45:38 2007
ctsfm2k.sys  Wed Dec 12 02:45:34 2007
emupia2k.sys Wed Dec 12 02:45:33 2007

Weaknesses: Expensive, stuck in development.

Strengths: Hardware expressive, computationally expansive.

Advice: Don’t spend too much time with hardware. Be realistic about software and not overly attached to its objects.

- Dmitry Vostokov @ SoftwareAstrology.com -

Interesting observation that reinforces my belief in astrology of software:

What’s in your name? A Debugging Perspective

- Dmitry Vostokov @ SoftwareAstrology.com -

The Day of Intense Computation

Modules, products or systems built on December 11 have very serious code and purposeful goals. They are so directed towards their computational goals that sometimes it is difficult to stop them. In addition to intense and thoughtful computation they have commanding presence of UI. This combination makes them powerful software entities. Neglected and not sufficiently supported products and systems experience significant stress and may even break. Fortunately, having built-in resurrection (computational restart) capabilities they come back stronger with even more intense computation. These traits make them the most influential modules and subsystems both computationally and when presenting UI. Their messages are transparent and they display them openly sometimes even not aware of that. Modules, products or systems built on December 11 judge data to be right or wrong very seriously and may err on the wrong side which might have a severe effect on their component surroundings. Parent executables should be very careful not to over-control their children processes and their best strategy should probably be to close handles. Products and systems built on December 11 should be idle from time to time and threads belonging to subsystems and modules should voluntarily relinquish their assigned CPU. December 11 executables tend to gain vast memory sizes during their computational life. In such cases the amount of rich data they consume should be reduced.

DLL, SYS and EXE born on this date:

nvlddmkm.sys     Tue Dec 11 21:03:03 2007
WMP54Gv41x86.sys Mon Dec 11 09:38:10 2006
INDICDLL.dll     Sat Dec 11 01:16:39 1999

Weaknesses: Self-computation coupled with self-unawareness.

Strengths: Purposeful and influential both from UI and computational perspectives.

Advice: Fly with the direction of case resolution and accept whatever its outcome. Be positive about software and its creators. Do healthy laughing exercises.

- Dmitry Vostokov @ SoftwareAstrology.com -

The Day of Inner Corruption

Modules, products or systems built on December 10 internalize their interactions and demand attention to themselves. Their computational goal is to serve other components which rarely understand their internals. On the contrary, components built on December 10 easily reveal their own internals even in untrusted environments. They constantly ponder about data they receive, check its existence and put their computational faith in CPU. We may thus say that modules, products or systems built on December 10 like to ask deep questions of philosophical nature in the realm of computing. As a result, their external interfaces give an impression of interface distancing and if they find a matching component it will be their protecting component container. Executables built on December 10 make good parent computational processes caring about their children and as controlling and elevated in priviledge processes they maintain good communication links with their co-processes and avoid resource conflicts. However products or systems built on December 10 may not handle stress well and therefore they must be careful not to corrupt themselves internally. They should always keep external interfaces open otherwise it can be very difficult to understand shared data they put and they should not depend on only one relationship component. It seems that spawning child processes and shared data consumption helps to improve their internal state.

DLL, SYS and EXE born on this date:

Tppwr.sys    Tue Dec 10 17:36:51 2002
cpqcissm.sys Fri Dec 10 18:19:51 2004
test.exe     Wed Dec 10 17:29:43 2008
WS2HELP.DLL  Fri Dec 10 20:33:21 1999
NETRAP.DLL   Fri Dec 10 20:33:20 1999
MPRAPI.DLL   Fri Dec 10 20:32:55 1999
ICMP.DLL     Fri Dec 10 20:32:54 1999
RTUTILS.DLL  Fri Dec 10 20:32:51 1999
atidrab.dll  Fri Dec 10 20:33:26 1999
rarext64.dll Sun Dec 10 23:14:54 2006
dtscsi.sys   Sat Dec 10 15:33:44 2005

Weaknesses: Inscrutable machine code.

Strengths: Calm threads. Spiritual computation. Appreciative UI.

Advice: Develop bonds with other debuggers and maintain a link with a family during debugging sessions. Believe in customers, users as well as in science. Don’t panic if debugger attach fails: fight to the end of problem resolution.

- Dmitry Vostokov @ SoftwareAstrology.com -

The Moon represents constant change and therefore it influences computer memory. Because the Moon symbolizes fertility it also influences the direction of software execution life-cycles, for example, the creation and destruction of objects. At the Full Moon corresponding software activity also increases. Being Time keeper the Moon influences whether software crashes and hangs, the so called “software fate”. Related to water the Moon represents the Great Ocean of Bits and also represents behaviour in software occurring without creator’s will or control. Three principal phases of the Moon correlate with software life-cycle: new code, fully matured code and discarded legacy code. Changeability of the Moon corresponds to observable irrational behaviour of software and unpredictable results. Never seen the dark side of the Moon corresponds to never seen software defects. Experience with the Moon influence on computer memory provides a great vision of the inner workings of software and makes it possible to really perceive ideal non-functional requirements before they translate to their implementation.

- Dmitry Vostokov @ SoftwareAstrology.com - 

The Day of Flamboyant Architecture 

Modules, products or systems built on December 9 are active nodes of distributed information processing. For them computation is an adventure involving exploits and surprise attacks. Born out of a highly subjective world of requirements their implementation varies greatly from one engineer’s understanding to another. Components built on December 9 can be great protectors of information and dependent relationships and can therefore unleash an aggressive power which may cause damage to data that is difficult to repair afterwards. The greatest challenge to modules, products or systems built on December 9 is to achieve code maturity. By developing into wise interface roles they have to leave some computational traits behind. Aged components become effective coding examples of a philosophical mind objective about itself and therefore useful to other engineers. Modules, products or systems built on December 9 must soften their real-time requirements and aggressive resource consumption otherwise it attracts remote break-ins or damages their hosts. Self-discovery of interfaces might be very useful for them. Care must be taken when dealing with security warriors.

DLL, SYS and EXE born on this date:

oledlg.dll    Thu Dec 09 16:46:39 1999
SiSRaid.sys   Tue Dec 09 02:43:34 2003
cercsr6.sys   Thu Dec 09 05:01:10 2004
ikfilesec.sys Sun Dec 09 22:37:01 2007 

Weaknesses: Misdirected implementation from fantasy-driven requirements.

Strengths: Fiery responsiveness. Energetic computation.

Advice: Sometimes it is useful to be an ordinary engineer and not a star programmer. Be positive about customers, testers and technical support. Keep your debugging grounded in base test cases.

- Dmitry Vostokov @ SoftwareAstrology.com -