The analogy of God in one's home and its equivalent in those unexplainable immeasurable unfathomable cosmos out there.....
Let me take a simple example from the software world, to make it more meaningful to the modern technical world too...
For those of you who have had a chance to work with an enterprise level J2EE product and its various extensions / 3rd party integrations that together scale up the product to a much higher level of customer centric deployment model which would typically be a clustered set up across several severs that together constitute the customer's in-house software suite implementation which would be always a huge one compared to the typical Dev and Qa deployment models that are followed in an R&D organization's SDLC.
In such a scenario, there would be a few issues, that result out of a version difference between the bundled JRE / and the in-house JVM.
An enterprise level J2EE product offering typically includes a bundled JRE which is essentially a customized one compared to the universal JRE/JVM present on the server.
In a scenario during 2009, an enterprise level J2EE product named "Application Performance Management" essentially an offering customized with Java Probes / Tracers to get infused in to the targeted customer application's code during the run time in order to derive certain metrics to arrive at the latter's monitoring statistics...
So, the bundled JRE and the customer's in-house JVM when not in sync (up until to the exact version number as per the Prod Docs' updated specifications) it results in certain incompatibility issues....
Neither the software provider can roll back the bundled JRE to an older version to be in-sync with what its customer wants for whatsoever reasons,
nor the costumer prefers to update their in-house JVM for a certain period of time citing some global customer requirements to stay at a particular version for whatsoever reasons...
In such a scenario, the software provider must handle the situation stating...
" Unless the JVM gets an upgrade to the specified version, the software consumer must be prudent enough to live with a malfunctioned feature dependant on a particular fix / patch upgrade or a certain customization must be allowed by the field folks' implementations to their in-house JVM so that a trade off gets achieved to mitigate the incompatibility issues being observed w.r.t certain functionality.. "
In this way neither the run time environment, ( held by the customer's environments' rt.jar ) gets disturbed as per the consumer's preference nor the successful patch/upgrade feature implementation is kept on hold to solve a bothering issue....
[ With the improvised "Docker Image based software provisioning", it might be no more an issue (if the legacy customers too have updated their environments accordingly as appropriate to get handled via Docker Image Provisioning System) because of the imposed auto handling of the "Docker Image Dependency Sequence" which will automatically take care of the JVM upgrades as well by pulling in the requisite JDK required to be present on the software consumer's in-house environs / implementations.....]
Quite similarly, our understanding of God from a few typical images / pictures / moorthys kept in our respective homes would have to be in sync with whatever is the established actual cosmic version rendered by genuine sathgurus and other spiritual stalwarts.....
Else, with the various misunderstandings caused by the frequency mismatch,
when a typical spiritualist's generic devotional life is misunderstood and is deliberately abused, it will only bring in a malfunctioned perspective disturbing everyone's peace of mind...
Hence, opinions of whatsoever are supposed to be kept to us and our dear ones and statements of refined altruistic expressions are supposed to be considered for judgements and decisions so that peace prevails for everyone in every given aspect....
No comments:
Post a Comment