ਪ੍ਰੋਗਰਾਮਰਾਂ ਅਤੇ ਇੰਜੀਨੀਅਰਾਂ ਦੀ ਲੋਕਧਾਰਾ (ਭਾਗ 1)

ਇਹ ਇੰਟਰਨੈਟ ਤੋਂ ਕਹਾਣੀਆਂ ਦੀ ਇੱਕ ਚੋਣ ਹੈ ਕਿ ਕਿਵੇਂ ਬੱਗ ਕਈ ਵਾਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸ਼ਾਨਦਾਰ ਪ੍ਰਗਟਾਵੇ ਕਰਦੇ ਹਨ। ਸ਼ਾਇਦ ਤੁਹਾਡੇ ਕੋਲ ਵੀ ਦੱਸਣ ਲਈ ਕੁਝ ਹੈ।

ਵਨੀਲਾ ਆਈਸ ਕਰੀਮ ਲਈ ਕਾਰ ਐਲਰਜੀ

ਇੰਜੀਨੀਅਰਾਂ ਲਈ ਇੱਕ ਕਹਾਣੀ ਜੋ ਸਮਝਦੇ ਹਨ ਕਿ ਸਪੱਸ਼ਟ ਹਮੇਸ਼ਾ ਜਵਾਬ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਇਹ ਕਿ ਤੱਥ ਭਾਵੇਂ ਕਿੰਨੇ ਵੀ ਦੂਰ-ਦੁਰਾਡੇ ਲੱਗੇ ਹੋਣ, ਉਹ ਅਜੇ ਵੀ ਤੱਥ ਹਨ। ਜਨਰਲ ਮੋਟਰਜ਼ ਕਾਰਪੋਰੇਸ਼ਨ ਦੇ ਪੋਂਟੀਏਕ ਡਿਵੀਜ਼ਨ ਨੂੰ ਇੱਕ ਸ਼ਿਕਾਇਤ ਮਿਲੀ:

ਇਹ ਦੂਜੀ ਵਾਰ ਹੈ ਜਦੋਂ ਮੈਂ ਤੁਹਾਨੂੰ ਲਿਖ ਰਿਹਾ ਹਾਂ, ਅਤੇ ਜਵਾਬ ਨਾ ਦੇਣ ਲਈ ਮੈਂ ਤੁਹਾਨੂੰ ਦੋਸ਼ੀ ਨਹੀਂ ਠਹਿਰਾਉਂਦਾ, ਕਿਉਂਕਿ ਇਹ ਪਾਗਲ ਲੱਗਦਾ ਹੈ। ਸਾਡੇ ਪਰਿਵਾਰ ਵਿੱਚ ਰਾਤ ਦੇ ਖਾਣੇ ਤੋਂ ਬਾਅਦ ਹਰ ਰਾਤ ਆਈਸਕ੍ਰੀਮ ਖਾਣ ਦੀ ਪਰੰਪਰਾ ਹੈ। ਆਈਸਕ੍ਰੀਮ ਦੀਆਂ ਕਿਸਮਾਂ ਹਰ ਵਾਰ ਬਦਲਦੀਆਂ ਹਨ, ਅਤੇ ਰਾਤ ਦੇ ਖਾਣੇ ਤੋਂ ਬਾਅਦ, ਪੂਰਾ ਪਰਿਵਾਰ ਚੁਣਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਆਈਸਕ੍ਰੀਮ ਖਰੀਦਣੀ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਮੈਂ ਸਟੋਰ 'ਤੇ ਜਾਂਦਾ ਹਾਂ। ਮੈਂ ਹਾਲ ਹੀ ਵਿੱਚ ਇੱਕ ਨਵਾਂ Pontiac ਖਰੀਦਿਆ ਹੈ ਅਤੇ ਉਦੋਂ ਤੋਂ ਆਈਸਕ੍ਰੀਮ ਲੈਣ ਲਈ ਮੇਰੀਆਂ ਯਾਤਰਾਵਾਂ ਇੱਕ ਸਮੱਸਿਆ ਬਣ ਗਈਆਂ ਹਨ। ਤੁਸੀਂ ਦੇਖੋਗੇ, ਹਰ ਵਾਰ ਜਦੋਂ ਮੈਂ ਵਨੀਲਾ ਆਈਸਕ੍ਰੀਮ ਖਰੀਦਦਾ ਹਾਂ ਅਤੇ ਸਟੋਰ ਤੋਂ ਵਾਪਸ ਆਉਂਦਾ ਹਾਂ, ਤਾਂ ਕਾਰ ਸਟਾਰਟ ਨਹੀਂ ਹੋਵੇਗੀ। ਜੇ ਮੈਂ ਕੋਈ ਹੋਰ ਆਈਸਕ੍ਰੀਮ ਲਿਆਉਂਦਾ ਹਾਂ, ਤਾਂ ਕਾਰ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਸਟਾਰਟ ਹੋ ਜਾਂਦੀ ਹੈ. ਮੈਂ ਇੱਕ ਗੰਭੀਰ ਸਵਾਲ ਪੁੱਛਣਾ ਚਾਹੁੰਦਾ ਹਾਂ, ਭਾਵੇਂ ਇਹ ਕਿੰਨਾ ਵੀ ਬੇਵਕੂਫ਼ ਲੱਗਦਾ ਹੈ: "ਪੋਂਟੀਆਕ ਬਾਰੇ ਅਜਿਹਾ ਕੀ ਹੈ ਜੋ ਇਹ ਉਦੋਂ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ ਜਦੋਂ ਮੈਂ ਵਨੀਲਾ ਆਈਸਕ੍ਰੀਮ ਲਿਆਉਂਦਾ ਹਾਂ, ਪਰ ਜਦੋਂ ਮੈਂ ਆਈਸਕ੍ਰੀਮ ਦਾ ਕੋਈ ਹੋਰ ਸੁਆਦ ਲਿਆਉਂਦਾ ਹਾਂ ਤਾਂ ਆਸਾਨੀ ਨਾਲ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ?"

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਕਲਪਨਾ ਕਰ ਸਕਦੇ ਹੋ, ਡਿਵੀਜ਼ਨ ਪ੍ਰਧਾਨ ਪੱਤਰ ਬਾਰੇ ਸ਼ੱਕੀ ਸੀ. ਹਾਲਾਂਕਿ, ਹੁਣੇ ਹੀ, ਮੈਂ ਇੱਕ ਇੰਜੀਨੀਅਰ ਨੂੰ ਜਾਂਚ ਕਰਨ ਲਈ ਭੇਜਿਆ ਹੈ। ਉਹ ਹੈਰਾਨ ਸੀ ਕਿ ਉਸ ਦੀ ਮੁਲਾਕਾਤ ਇਕ ਸੋਹਣੇ ਇਲਾਕੇ ਵਿਚ ਰਹਿਣ ਵਾਲੇ ਇਕ ਅਮੀਰ, ਪੜ੍ਹੇ-ਲਿਖੇ ਆਦਮੀ ਨਾਲ ਹੋਈ। ਉਹ ਰਾਤ ਦੇ ਖਾਣੇ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਮਿਲਣ ਲਈ ਰਾਜ਼ੀ ਹੋ ਗਏ ਤਾਂ ਜੋ ਉਹ ਦੋਵੇਂ ਆਈਸਕ੍ਰੀਮ ਲਈ ਸਟੋਰ 'ਤੇ ਜਾ ਸਕਣ। ਉਸ ਸ਼ਾਮ ਇਹ ਵਨੀਲਾ ਸੀ, ਅਤੇ ਜਦੋਂ ਉਹ ਕਾਰ 'ਤੇ ਵਾਪਸ ਆਏ, ਤਾਂ ਇਹ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਵੇਗੀ।

ਇੰਜਨੀਅਰ ਸ਼ਾਮ ਨੂੰ ਤਿੰਨ ਹੋਰ ਆਇਆ। ਪਹਿਲੀ ਵਾਰ ਆਈਸਕ੍ਰੀਮ ਚਾਕਲੇਟ ਸੀ। ਕਾਰ ਸਟਾਰਟ ਹੋ ਗਈ। ਦੂਜੀ ਵਾਰ ਸਟ੍ਰਾਬੇਰੀ ਆਈਸਕ੍ਰੀਮ ਸੀ. ਕਾਰ ਸਟਾਰਟ ਹੋ ਗਈ। ਤੀਜੀ ਸ਼ਾਮ ਨੂੰ ਉਸਨੇ ਵਨੀਲਾ ਲੈਣ ਲਈ ਕਿਹਾ। ਕਾਰ ਸਟਾਰਟ ਨਹੀਂ ਹੋਈ।

ਤਰਕਸ਼ੀਲ ਤਰਕ ਕਰਦਿਆਂ, ਇੰਜੀਨੀਅਰ ਨੇ ਇਹ ਮੰਨਣ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੱਤਾ ਕਿ ਕਾਰ ਨੂੰ ਵਨੀਲਾ ਆਈਸਕ੍ਰੀਮ ਤੋਂ ਐਲਰਜੀ ਸੀ। ਇਸ ਲਈ, ਮੈਂ ਕਾਰ ਦੇ ਮਾਲਕ ਨਾਲ ਸਹਿਮਤ ਹੋ ਗਿਆ ਕਿ ਉਹ ਉਦੋਂ ਤੱਕ ਆਪਣੀਆਂ ਮੁਲਾਕਾਤਾਂ ਜਾਰੀ ਰੱਖੇਗਾ ਜਦੋਂ ਤੱਕ ਉਸਨੂੰ ਸਮੱਸਿਆ ਦਾ ਕੋਈ ਹੱਲ ਨਹੀਂ ਮਿਲ ਜਾਂਦਾ। ਅਤੇ ਰਸਤੇ ਵਿੱਚ, ਉਸਨੇ ਨੋਟਸ ਲੈਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ: ਉਸਨੇ ਸਾਰੀ ਜਾਣਕਾਰੀ, ਦਿਨ ਦਾ ਸਮਾਂ, ਗੈਸੋਲੀਨ ਦੀ ਕਿਸਮ, ਸਟੋਰ ਤੋਂ ਆਉਣ ਅਤੇ ਵਾਪਸੀ ਦਾ ਸਮਾਂ, ਆਦਿ ਲਿਖ ਲਿਆ।

ਇੰਜੀਨੀਅਰ ਨੂੰ ਜਲਦੀ ਹੀ ਅਹਿਸਾਸ ਹੋ ਗਿਆ ਕਿ ਕਾਰ ਦੇ ਮਾਲਕ ਨੇ ਵਨੀਲਾ ਆਈਸਕ੍ਰੀਮ ਖਰੀਦਣ ਵਿੱਚ ਘੱਟ ਸਮਾਂ ਬਿਤਾਇਆ ਹੈ। ਇਸ ਦਾ ਕਾਰਨ ਸਟੋਰ ਵਿੱਚ ਸਾਮਾਨ ਦਾ ਖਾਕਾ ਸੀ। ਵਨੀਲਾ ਆਈਸ ਕਰੀਮ ਸਭ ਤੋਂ ਵੱਧ ਪ੍ਰਸਿੱਧ ਸੀ ਅਤੇ ਇਸਨੂੰ ਲੱਭਣਾ ਆਸਾਨ ਬਣਾਉਣ ਲਈ ਸਟੋਰ ਦੇ ਸਾਹਮਣੇ ਇੱਕ ਵੱਖਰੇ ਫਰੀਜ਼ਰ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ ਸੀ। ਅਤੇ ਹੋਰ ਸਾਰੀਆਂ ਕਿਸਮਾਂ ਸਟੋਰ ਦੇ ਪਿਛਲੇ ਹਿੱਸੇ ਵਿੱਚ ਸਨ, ਅਤੇ ਸਹੀ ਕਿਸਮ ਲੱਭਣ ਅਤੇ ਭੁਗਤਾਨ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗਿਆ।

ਹੁਣ ਸਵਾਲ ਇੰਜਨੀਅਰ ਲਈ ਸੀ: ਜੇ ਇੰਜਣ ਬੰਦ ਹੋਣ ਤੋਂ ਘੱਟ ਸਮਾਂ ਬੀਤ ਗਿਆ ਸੀ ਤਾਂ ਕਾਰ ਸਟਾਰਟ ਕਿਉਂ ਨਹੀਂ ਹੋਈ? ਕਿਉਂਕਿ ਸਮੱਸਿਆ ਸਮਾਂ ਸੀ ਨਾ ਕਿ ਵਨੀਲਾ ਆਈਸਕ੍ਰੀਮ ਦੀ, ਇੰਜਨੀਅਰ ਨੇ ਜਲਦੀ ਜਵਾਬ ਲੱਭ ਲਿਆ: ਇਹ ਇੱਕ ਗੈਸ ਲਾਕ ਸੀ। ਇਹ ਹਰ ਸ਼ਾਮ ਵਾਪਰਦਾ ਸੀ, ਪਰ ਜਦੋਂ ਕਾਰ ਮਾਲਕ ਨੇ ਆਈਸਕ੍ਰੀਮ ਦੀ ਭਾਲ ਵਿੱਚ ਵਧੇਰੇ ਸਮਾਂ ਬਿਤਾਇਆ, ਤਾਂ ਇੰਜਣ ਕਾਫ਼ੀ ਠੰਡਾ ਹੋਣ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋ ਗਿਆ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਚਾਲੂ ਹੋ ਗਿਆ। ਅਤੇ ਜਦੋਂ ਆਦਮੀ ਨੇ ਵਨੀਲਾ ਆਈਸ ਕਰੀਮ ਖਰੀਦੀ, ਤਾਂ ਇੰਜਣ ਅਜੇ ਵੀ ਬਹੁਤ ਗਰਮ ਸੀ ਅਤੇ ਗੈਸ ਲਾਕ ਨੂੰ ਘੁਲਣ ਦਾ ਸਮਾਂ ਨਹੀਂ ਸੀ.

ਨੈਤਿਕ: ਇੱਥੋਂ ਤੱਕ ਕਿ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪਾਗਲ ਸਮੱਸਿਆਵਾਂ ਵੀ ਕਈ ਵਾਰ ਅਸਲੀ ਹੁੰਦੀਆਂ ਹਨ.

ਕਰੈਸ਼ Bandicoot

ਇਹ ਅਨੁਭਵ ਕਰਨਾ ਦੁਖਦਾਈ ਹੈ। ਇੱਕ ਪ੍ਰੋਗਰਾਮਰ ਹੋਣ ਦੇ ਨਾਤੇ, ਤੁਸੀਂ ਆਪਣੇ ਕੋਡ ਨੂੰ ਪਹਿਲਾਂ, ਦੂਜੇ, ਤੀਜੇ ... ਅਤੇ ਕਿਤੇ ਵੀ ਦਸ ਹਜ਼ਾਰਵੇਂ ਸਥਾਨ ਵਿੱਚ ਕੰਪਾਈਲਰ ਨੂੰ ਦੋਸ਼ੀ ਠਹਿਰਾਉਣ ਦੀ ਆਦਤ ਪਾਉਂਦੇ ਹੋ। ਅਤੇ ਸੂਚੀ ਦੇ ਹੇਠਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਸਾਜ਼-ਸਾਮਾਨ ਨੂੰ ਦੋਸ਼ੀ ਠਹਿਰਾਉਂਦੇ ਹੋ.

ਇਹ ਹਾਰਡਵੇਅਰ ਬੱਗ ਬਾਰੇ ਮੇਰੀ ਕਹਾਣੀ ਹੈ.

ਕ੍ਰੈਸ਼ ਬੈਂਡੀਕੂਟ ਗੇਮ ਲਈ, ਮੈਂ ਮੈਮਰੀ ਕਾਰਡ ਨੂੰ ਲੋਡ ਕਰਨ ਅਤੇ ਸੇਵ ਕਰਨ ਲਈ ਕੋਡ ਲਿਖਿਆ ਹੈ। ਅਜਿਹੇ ਸਮਗ ਗੇਮ ਡਿਵੈਲਪਰ ਲਈ, ਇਹ ਪਾਰਕ ਵਿੱਚ ਸੈਰ ਕਰਨ ਵਰਗਾ ਸੀ: ਮੈਂ ਸੋਚਿਆ ਕਿ ਕੰਮ ਨੂੰ ਕਈ ਦਿਨ ਲੱਗ ਜਾਣਗੇ. ਹਾਲਾਂਕਿ, ਮੈਂ ਛੇ ਹਫ਼ਤਿਆਂ ਲਈ ਕੋਡ ਨੂੰ ਡੀਬੱਗ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ. ਰਸਤੇ ਵਿੱਚ, ਮੈਂ ਹੋਰ ਸਮੱਸਿਆਵਾਂ ਦਾ ਹੱਲ ਕੀਤਾ, ਪਰ ਹਰ ਕੁਝ ਦਿਨਾਂ ਵਿੱਚ ਮੈਂ ਕੁਝ ਘੰਟਿਆਂ ਲਈ ਇਸ ਕੋਡ ਵਿੱਚ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹਾਂ। ਇਹ ਦੁੱਖ ਸੀ।

ਲੱਛਣ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੇ ਸਨ: ਜਦੋਂ ਤੁਸੀਂ ਗੇਮ ਦੇ ਮੌਜੂਦਾ ਪਲੇਥਰੂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦੇ ਹੋ ਅਤੇ ਮੈਮਰੀ ਕਾਰਡ ਤੱਕ ਪਹੁੰਚ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਭ ਕੁਝ ਲਗਭਗ ਹਮੇਸ਼ਾ ਠੀਕ ਹੋ ਜਾਂਦਾ ਹੈ... ਪਰ ਕਈ ਵਾਰ ਬਿਨਾਂ ਕਿਸੇ ਸਪੱਸ਼ਟ ਕਾਰਨ ਦੇ ਪੜ੍ਹਨ ਜਾਂ ਲਿਖਣ ਦਾ ਸਮਾਂ ਸਮਾਪਤ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਛੋਟੀ ਰਿਕਾਰਡਿੰਗ ਅਕਸਰ ਮੈਮਰੀ ਕਾਰਡ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੀ ਹੈ। ਜਦੋਂ ਕੋਈ ਖਿਡਾਰੀ ਬਚਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹ ਨਾ ਸਿਰਫ਼ ਬਚਾਉਣ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦਾ ਹੈ, ਸਗੋਂ ਨਕਸ਼ੇ ਨੂੰ ਵੀ ਨਸ਼ਟ ਕਰ ਦਿੰਦਾ ਹੈ। ਬਕਵਾਸ.

ਥੋੜੀ ਦੇਰ ਬਾਅਦ, ਸੋਨੀ ਵਿਖੇ ਸਾਡੇ ਨਿਰਮਾਤਾ, ਕੋਨੀ ਬੱਸ, ਘਬਰਾਉਣ ਲੱਗ ਪਏ। ਅਸੀਂ ਇਸ ਬੱਗ ਨਾਲ ਗੇਮ ਨੂੰ ਨਹੀਂ ਭੇਜ ਸਕੇ, ਅਤੇ ਛੇ ਹਫ਼ਤਿਆਂ ਬਾਅਦ ਮੈਨੂੰ ਸਮਝ ਨਹੀਂ ਆਈ ਕਿ ਸਮੱਸਿਆ ਦਾ ਕਾਰਨ ਕੀ ਸੀ। ਕੋਨੀ ਦੁਆਰਾ, ਅਸੀਂ ਹੋਰ PS1 ਡਿਵੈਲਪਰਾਂ ਨਾਲ ਸੰਪਰਕ ਕੀਤਾ: ਕੀ ਕਿਸੇ ਨੂੰ ਵੀ ਅਜਿਹਾ ਕੁਝ ਮਿਲਿਆ ਹੈ? ਨੰ. ਕਿਸੇ ਨੂੰ ਵੀ ਮੈਮਰੀ ਕਾਰਡ ਨਾਲ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ।

ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ ਡੀਬੱਗਿੰਗ ਲਈ ਕੋਈ ਵਿਚਾਰ ਨਹੀਂ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਸਿਰਫ "ਵੰਡੋ ਅਤੇ ਜਿੱਤੋ" ਦੀ ਪਹੁੰਚ ਬਚੀ ਹੈ: ਨੁਕਸਦਾਰ ਪ੍ਰੋਗਰਾਮ ਤੋਂ ਵੱਧ ਤੋਂ ਵੱਧ ਕੋਡ ਨੂੰ ਹਟਾਓ ਜਦੋਂ ਤੱਕ ਕੋਈ ਮੁਕਾਬਲਤਨ ਛੋਟਾ ਟੁਕੜਾ ਬਾਕੀ ਨਹੀਂ ਰਹਿੰਦਾ ਜੋ ਅਜੇ ਵੀ ਸਮੱਸਿਆ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ। ਭਾਵ, ਤੁਸੀਂ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਟੁਕੜੇ-ਟੁਕੜੇ ਤੋਂ ਕੱਟ ਦਿੰਦੇ ਹੋ ਜਦੋਂ ਤੱਕ ਉਹ ਹਿੱਸਾ ਨਹੀਂ ਰਹਿੰਦਾ ਜਿਸ ਵਿੱਚ ਬੱਗ ਹੁੰਦਾ ਹੈ।

ਪਰ ਗੱਲ ਇਹ ਹੈ ਕਿ, ਵੀਡੀਓ ਗੇਮ ਦੇ ਹਿੱਸੇ ਨੂੰ ਕੱਟਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ. ਜੇਕਰ ਤੁਸੀਂ ਗੰਭੀਰਤਾ ਦੀ ਨਕਲ ਕਰਨ ਵਾਲੇ ਕੋਡ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਹੈ ਤਾਂ ਇਸਨੂੰ ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ? ਜਾਂ ਡਰਾਇੰਗ ਅੱਖਰ?

ਇਸ ਲਈ, ਸਾਨੂੰ ਪੂਰੇ ਮੋਡੀਊਲ ਨੂੰ ਸਟੱਬਾਂ ਨਾਲ ਬਦਲਣਾ ਪਵੇਗਾ ਜੋ ਕੁਝ ਲਾਭਦਾਇਕ ਕਰਨ ਦਾ ਦਿਖਾਵਾ ਕਰਦੇ ਹਨ, ਪਰ ਅਸਲ ਵਿੱਚ ਅਜਿਹਾ ਕੁਝ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਕਰਦੇ ਹਨ ਜਿਸ ਵਿੱਚ ਗਲਤੀਆਂ ਨਹੀਂ ਹੋ ਸਕਦੀਆਂ। ਸਾਨੂੰ ਘੱਟੋ-ਘੱਟ ਕੰਮ ਕਰਨ ਲਈ ਖੇਡ ਲਈ ਅਜਿਹੀਆਂ ਬੈਸਾਖੀਆਂ ਲਿਖਣੀਆਂ ਪੈਣਗੀਆਂ। ਇਹ ਇੱਕ ਹੌਲੀ ਅਤੇ ਦਰਦਨਾਕ ਪ੍ਰਕਿਰਿਆ ਹੈ.

ਸੰਖੇਪ ਵਿੱਚ, ਮੈਂ ਇਹ ਕੀਤਾ. ਮੈਂ ਕੋਡ ਦੇ ਵੱਧ ਤੋਂ ਵੱਧ ਟੁਕੜਿਆਂ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਜਦੋਂ ਤੱਕ ਮੇਰੇ ਕੋਲ ਸ਼ੁਰੂਆਤੀ ਕੋਡ ਨਹੀਂ ਬਚਿਆ ਸੀ ਜੋ ਗੇਮ ਨੂੰ ਚਲਾਉਣ ਲਈ ਸਿਸਟਮ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਦਾ ਹੈ, ਰੈਂਡਰਿੰਗ ਹਾਰਡਵੇਅਰ ਨੂੰ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਆਦਿ। ਬੇਸ਼ੱਕ, ਇਸ ਪੜਾਅ 'ਤੇ ਮੈਂ ਸੇਵ ਅਤੇ ਲੋਡ ਮੀਨੂ ਨਹੀਂ ਬਣਾ ਸਕਿਆ, ਕਿਉਂਕਿ ਮੈਨੂੰ ਸਾਰੇ ਗ੍ਰਾਫਿਕਸ ਕੋਡ ਲਈ ਇੱਕ ਸਟੱਬ ਬਣਾਉਣਾ ਹੋਵੇਗਾ। ਪਰ ਮੈਂ (ਅਦਿੱਖ) ਸੇਵ ਅਤੇ ਲੋਡ ਸਕ੍ਰੀਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਉਪਭੋਗਤਾ ਹੋਣ ਦਾ ਦਿਖਾਵਾ ਕਰ ਸਕਦਾ ਹਾਂ ਅਤੇ ਸੇਵ ਕਰਨ ਲਈ ਕਹਿ ਸਕਦਾ ਹਾਂ ਅਤੇ ਫਿਰ ਮੈਮਰੀ ਕਾਰਡ 'ਤੇ ਲਿਖ ਸਕਦਾ ਹਾਂ।

ਇਸਨੇ ਮੈਨੂੰ ਕੋਡ ਦਾ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਟੁਕੜਾ ਛੱਡ ਦਿੱਤਾ ਜਿਸ ਵਿੱਚ ਅਜੇ ਵੀ ਉਪਰੋਕਤ ਸਮੱਸਿਆ ਸੀ - ਪਰ ਇਹ ਅਜੇ ਵੀ ਬੇਤਰਤੀਬੇ ਹੋ ਰਿਹਾ ਸੀ! ਜ਼ਿਆਦਾਤਰ ਅਕਸਰ ਸਭ ਕੁਝ ਠੀਕ ਕੰਮ ਕਰਦਾ ਸੀ, ਪਰ ਕਦੇ-ਕਦਾਈਂ ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਸਨ. ਮੈਂ ਲਗਭਗ ਸਾਰੇ ਗੇਮ ਕੋਡ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਹੈ, ਪਰ ਬੱਗ ਅਜੇ ਵੀ ਜ਼ਿੰਦਾ ਸੀ। ਇਹ ਉਲਝਣ ਵਾਲਾ ਸੀ: ਬਾਕੀ ਕੋਡ ਨੇ ਅਸਲ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਕੀਤਾ.

ਕਿਸੇ ਸਮੇਂ, ਸ਼ਾਇਦ ਸਵੇਰੇ ਤਿੰਨ ਵਜੇ, ਮੇਰੇ ਮਨ ਵਿੱਚ ਇੱਕ ਵਿਚਾਰ ਆਇਆ। ਪੜ੍ਹੋ ਅਤੇ ਲਿਖੋ (ਇਨਪੁਟ/ਆਊਟਪੁੱਟ) ਓਪਰੇਸ਼ਨਾਂ ਵਿੱਚ ਸਟੀਕ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮਾਂ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਹਾਰਡ ਡਰਾਈਵ, ਮੈਮਰੀ ਕਾਰਡ ਜਾਂ ਬਲੂਟੁੱਥ ਮੋਡੀਊਲ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹੋ, ਤਾਂ ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਨੀਵੇਂ-ਪੱਧਰ ਦਾ ਕੋਡ ਅਜਿਹਾ ਘੜੀ ਦੀਆਂ ਦਾਲਾਂ ਦੇ ਅਨੁਸਾਰ ਕਰਦਾ ਹੈ।

ਇੱਕ ਘੜੀ ਦੀ ਮਦਦ ਨਾਲ, ਇੱਕ ਡਿਵਾਈਸ ਜੋ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਪ੍ਰੋਸੈਸਰ ਨਾਲ ਨਹੀਂ ਜੁੜੀ ਹੁੰਦੀ ਹੈ, ਨੂੰ ਪ੍ਰੋਸੈਸਰ 'ਤੇ ਚੱਲਣ ਵਾਲੇ ਕੋਡ ਨਾਲ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਘੜੀ ਬੌਡ ਦਰ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ - ਉਹ ਗਤੀ ਜਿਸ ਨਾਲ ਡੇਟਾ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਸਮੇਂ ਨਾਲ ਉਲਝਣ ਹੈ, ਤਾਂ ਜਾਂ ਤਾਂ ਹਾਰਡਵੇਅਰ ਜਾਂ ਸੌਫਟਵੇਅਰ, ਜਾਂ ਦੋਵੇਂ, ਵੀ ਉਲਝਣ ਵਿੱਚ ਹਨ. ਅਤੇ ਇਹ ਬਹੁਤ ਮਾੜਾ ਹੈ, ਕਿਉਂਕਿ ਡੇਟਾ ਖਰਾਬ ਹੋ ਸਕਦਾ ਹੈ.

ਉਦੋਂ ਕੀ ਜੇ ਸਾਡੇ ਕੋਡ ਵਿੱਚ ਕੋਈ ਚੀਜ਼ ਸਮੇਂ ਨੂੰ ਉਲਝਾਉਂਦੀ ਹੈ? ਮੈਂ ਟੈਸਟ ਪ੍ਰੋਗਰਾਮ ਕੋਡ ਵਿੱਚ ਇਸ ਨਾਲ ਸਬੰਧਤ ਹਰ ਚੀਜ਼ ਦੀ ਜਾਂਚ ਕੀਤੀ ਅਤੇ ਦੇਖਿਆ ਕਿ ਅਸੀਂ PS1 ਵਿੱਚ ਪ੍ਰੋਗਰਾਮੇਬਲ ਟਾਈਮਰ ਨੂੰ 1 kHz (1000 ਟਿੱਕ ਪ੍ਰਤੀ ਸਕਿੰਟ) ਵਿੱਚ ਸੈੱਟ ਕੀਤਾ ਹੈ। ਇਹ ਕਾਫ਼ੀ ਹੈ; ਮੂਲ ਰੂਪ ਵਿੱਚ, ਜਦੋਂ ਕੰਸੋਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਇਹ 100 Hz 'ਤੇ ਚੱਲਦਾ ਹੈ। ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਗੇਮਾਂ ਇਸ ਬਾਰੰਬਾਰਤਾ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ.

ਐਂਡੀ, ਗੇਮ ਡਿਵੈਲਪਰ, ਟਾਈਮਰ ਨੂੰ 1 kHz 'ਤੇ ਸੈੱਟ ਕਰਦਾ ਹੈ ਤਾਂ ਕਿ ਹਰਕਤਾਂ ਦੀ ਗਣਨਾ ਵਧੇਰੇ ਸਹੀ ਢੰਗ ਨਾਲ ਕੀਤੀ ਜਾ ਸਕੇ। ਐਂਡੀ ਓਵਰਬੋਰਡ ਜਾਣ ਦਾ ਰੁਝਾਨ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਜੇਕਰ ਅਸੀਂ ਗੰਭੀਰਤਾ ਦੀ ਨਕਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਇਸਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਸਹੀ ਕਰਦੇ ਹਾਂ!

ਪਰ ਉਦੋਂ ਕੀ ਜੇ ਟਾਈਮਰ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਨਾਲ ਪ੍ਰੋਗਰਾਮ ਦੇ ਸਮੁੱਚੇ ਸਮੇਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸਲਈ ਘੜੀ ਜੋ ਮੈਮੋਰੀ ਕਾਰਡ ਲਈ ਬੌਡ ਰੇਟ ਨੂੰ ਨਿਯੰਤ੍ਰਿਤ ਕਰਦੀ ਹੈ?

ਮੈਂ ਟਾਈਮਰ ਕੋਡ ਦੀ ਟਿੱਪਣੀ ਕੀਤੀ. ਗਲਤੀ ਦੁਬਾਰਾ ਨਹੀਂ ਹੋਈ। ਪਰ ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਅਸੀਂ ਇਸਨੂੰ ਠੀਕ ਕਰ ਦਿੱਤਾ ਹੈ, ਕਿਉਂਕਿ ਅਸਫਲਤਾ ਬੇਤਰਤੀਬ ਨਾਲ ਆਈ ਹੈ। ਕੀ ਹੋਇਆ ਜੇ ਮੈਂ ਖੁਸ਼ਕਿਸਮਤ ਸੀ?

ਕੁਝ ਦਿਨਾਂ ਬਾਅਦ ਮੈਂ ਟੈਸਟ ਪ੍ਰੋਗਰਾਮ ਨਾਲ ਦੁਬਾਰਾ ਪ੍ਰਯੋਗ ਕੀਤਾ। ਬੱਗ ਮੁੜ ਨਹੀਂ ਆਇਆ। ਮੈਂ ਪੂਰੇ ਗੇਮ ਕੋਡਬੇਸ 'ਤੇ ਵਾਪਸ ਚਲਾ ਗਿਆ ਅਤੇ ਸੇਵ ਅਤੇ ਲੋਡ ਕੋਡ ਨੂੰ ਸੋਧਿਆ ਤਾਂ ਕਿ ਪ੍ਰੋਗਰਾਮੇਬਲ ਟਾਈਮਰ ਮੈਮਰੀ ਕਾਰਡ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸਦੇ ਅਸਲ ਮੁੱਲ (100Hz) 'ਤੇ ਰੀਸੈਟ ਹੋ ਜਾਵੇ, ਅਤੇ ਫਿਰ 1kHz 'ਤੇ ਰੀਸੈਟ ਹੋ ਜਾਵੇ। ਕੋਈ ਹੋਰ ਕਰੈਸ਼ ਨਹੀਂ ਸਨ।

ਪਰ ਅਜਿਹਾ ਕਿਉਂ ਹੋਇਆ?

ਮੈਂ ਦੁਬਾਰਾ ਟੈਸਟ ਪ੍ਰੋਗਰਾਮ 'ਤੇ ਵਾਪਸ ਆ ਗਿਆ। ਮੈਂ ਇੱਕ 1 kHz ਟਾਈਮਰ ਨਾਲ ਇੱਕ ਗਲਤੀ ਦੀ ਮੌਜੂਦਗੀ ਵਿੱਚ ਕੁਝ ਪੈਟਰਨ ਲੱਭਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ। ਆਖਰਕਾਰ ਮੈਂ ਦੇਖਿਆ ਕਿ ਗਲਤੀ ਉਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕੋਈ PS1 ਕੰਟਰੋਲਰ ਨਾਲ ਖੇਡਦਾ ਹੈ. ਕਿਉਂਕਿ ਮੈਂ ਖੁਦ ਅਜਿਹਾ ਕਦੇ-ਕਦਾਈਂ ਹੀ ਕਰਾਂਗਾ - ਸੇਵ ਅਤੇ ਲੋਡ ਕੋਡ ਦੀ ਜਾਂਚ ਕਰਦੇ ਸਮੇਂ ਮੈਨੂੰ ਇੱਕ ਕੰਟਰੋਲਰ ਦੀ ਲੋੜ ਕਿਉਂ ਪਵੇਗੀ? - ਮੈਂ ਇਸ ਨਿਰਭਰਤਾ ਵੱਲ ਧਿਆਨ ਵੀ ਨਹੀਂ ਦਿੱਤਾ. ਪਰ ਇੱਕ ਦਿਨ ਸਾਡੇ ਕਲਾਕਾਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਮੇਰੇ ਟੈਸਟਿੰਗ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਸੀ - ਮੈਂ ਸ਼ਾਇਦ ਉਸ ਪਲ ਨੂੰ ਗਾਲਾਂ ਕੱਢ ਰਿਹਾ ਸੀ - ਅਤੇ ਘਬਰਾ ਕੇ ਆਪਣੇ ਹੱਥਾਂ ਵਿੱਚ ਕੰਟਰੋਲਰ ਨੂੰ ਘੁਮਾ ਦਿੱਤਾ। ਇੱਕ ਤਰੁੱਟੀ ਆਈ ਹੈ। "ਕੀ ਉਡੀਕ ਕਰੋ?!" ਖੈਰ, ਇਸ ਨੂੰ ਦੁਬਾਰਾ ਕਰੋ! ”

ਜਦੋਂ ਮੈਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਇਹ ਦੋ ਘਟਨਾਵਾਂ ਆਪਸ ਵਿੱਚ ਜੁੜੀਆਂ ਹੋਈਆਂ ਸਨ, ਮੈਂ ਆਸਾਨੀ ਨਾਲ ਗਲਤੀ ਨੂੰ ਦੁਬਾਰਾ ਪੇਸ਼ ਕਰਨ ਦੇ ਯੋਗ ਸੀ: ਮੈਂ ਮੈਮਰੀ ਕਾਰਡ ਵਿੱਚ ਰਿਕਾਰਡ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਕੰਟਰੋਲਰ ਨੂੰ ਹਿਲਾਇਆ, ਅਤੇ ਮੈਮਰੀ ਕਾਰਡ ਨੂੰ ਬਰਬਾਦ ਕਰ ਦਿੱਤਾ। ਮੇਰੇ ਲਈ ਇਹ ਇੱਕ ਹਾਰਡਵੇਅਰ ਬੱਗ ਵਾਂਗ ਲੱਗ ਰਿਹਾ ਸੀ।

ਮੈਂ ਕੌਨੀ ਕੋਲ ਆਇਆ ਅਤੇ ਉਸ ਨੂੰ ਆਪਣੀ ਖੋਜ ਬਾਰੇ ਦੱਸਿਆ। ਉਸਨੇ PS1 ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਵਾਲੇ ਇੰਜੀਨੀਅਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਜਾਣਕਾਰੀ ਰੀਲੇਅ ਕੀਤੀ। “ਅਸੰਭਵ,” ਉਸਨੇ ਜਵਾਬ ਦਿੱਤਾ, “ਇਹ ਹਾਰਡਵੇਅਰ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੋ ਸਕਦੀ।” ਮੈਂ ਕੌਨੀ ਨੂੰ ਸਾਡੇ ਲਈ ਗੱਲਬਾਤ ਦਾ ਪ੍ਰਬੰਧ ਕਰਨ ਲਈ ਕਿਹਾ।

ਇੰਜੀਨੀਅਰ ਨੇ ਮੈਨੂੰ ਬੁਲਾਇਆ ਅਤੇ ਅਸੀਂ ਉਸਦੀ ਟੁੱਟੀ ਹੋਈ ਅੰਗਰੇਜ਼ੀ ਅਤੇ ਮੇਰੀ (ਅਤਿਅੰਤ) ਟੁੱਟੀ ਜਾਪਾਨੀ ਵਿੱਚ ਬਹਿਸ ਕੀਤੀ। ਅੰਤ ਵਿੱਚ ਮੈਂ ਕਿਹਾ, "ਮੈਨੂੰ ਆਪਣਾ 30 ਲਾਈਨ ਟੈਸਟ ਪ੍ਰੋਗਰਾਮ ਭੇਜਣ ਦਿਓ ਜਿੱਥੇ ਕੰਟਰੋਲਰ ਨੂੰ ਹਿਲਾਉਣ ਨਾਲ ਇੱਕ ਬੱਗ ਪੈਦਾ ਹੁੰਦਾ ਹੈ।" ਉਹ ਮੰਨ ਗਿਆ। ਨੇ ਕਿਹਾ ਕਿ ਇਹ ਸਮੇਂ ਦੀ ਬਰਬਾਦੀ ਸੀ ਅਤੇ ਉਹ ਇੱਕ ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਕੰਮ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਰੁੱਝਿਆ ਹੋਇਆ ਸੀ, ਪਰ ਅਸੀਂ ਇਸ ਲਈ ਛੱਡ ਦੇਵਾਂਗੇ ਕਿਉਂਕਿ ਅਸੀਂ ਸੋਨੀ ਲਈ ਇੱਕ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਡਿਵੈਲਪਰ ਸੀ। ਮੈਂ ਆਪਣੇ ਟੈਸਟ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਸਾਫ਼ ਕੀਤਾ ਅਤੇ ਉਸਨੂੰ ਭੇਜਿਆ।

ਅਗਲੀ ਸ਼ਾਮ (ਅਸੀਂ ਲਾਸ ਏਂਜਲਸ ਵਿੱਚ ਸੀ ਅਤੇ ਉਹ ਟੋਕੀਓ ਵਿੱਚ ਸੀ) ਉਸਨੇ ਮੈਨੂੰ ਬੁਲਾਇਆ ਅਤੇ ਭੇਡਚਾਲ ਨਾਲ ਮੁਆਫੀ ਮੰਗੀ। ਇਹ ਇੱਕ ਹਾਰਡਵੇਅਰ ਸਮੱਸਿਆ ਸੀ।

ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਇਹ ਬੱਗ ਕੀ ਸੀ, ਪਰ ਜੋ ਮੈਂ ਸੋਨੀ ਹੈੱਡਕੁਆਰਟਰ 'ਤੇ ਸੁਣਿਆ, ਜੇਕਰ ਤੁਸੀਂ ਟਾਈਮਰ ਨੂੰ ਉੱਚੇ ਮੁੱਲ 'ਤੇ ਸੈੱਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਟਾਈਮਰ ਕ੍ਰਿਸਟਲ ਦੇ ਆਸ-ਪਾਸ ਮਦਰਬੋਰਡ 'ਤੇ ਕੰਪੋਨੈਂਟਾਂ ਨਾਲ ਦਖਲ ਦਿੰਦਾ ਹੈ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਮੈਮੋਰੀ ਕਾਰਡ ਲਈ ਇੱਕ ਬੌਡ ਰੇਟ ਕੰਟਰੋਲਰ ਸੀ, ਜੋ ਕੰਟਰੋਲਰਾਂ ਲਈ ਬੌਡ ਰੇਟ ਵੀ ਨਿਰਧਾਰਤ ਕਰਦਾ ਸੀ। ਮੈਂ ਇੰਜੀਨੀਅਰ ਨਹੀਂ ਹਾਂ, ਇਸ ਲਈ ਮੈਂ ਕੁਝ ਗੜਬੜ ਕਰ ਸਕਦਾ ਹਾਂ।

ਪਰ ਤਲ ਲਾਈਨ ਇਹ ਹੈ ਕਿ ਮਦਰਬੋਰਡ ਦੇ ਭਾਗਾਂ ਵਿੱਚ ਦਖਲਅੰਦਾਜ਼ੀ ਸੀ. ਅਤੇ ਜਦੋਂ ਕੰਟਰੋਲਰ ਪੋਰਟ ਅਤੇ 1 kHz 'ਤੇ ਚੱਲ ਰਹੇ ਟਾਈਮਰ ਦੇ ਨਾਲ ਮੈਮਰੀ ਕਾਰਡ ਪੋਰਟ ਰਾਹੀਂ ਇੱਕੋ ਸਮੇਂ ਡਾਟਾ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਬਿੱਟ ਖਤਮ ਹੋ ਗਏ ਸਨ, ਡਾਟਾ ਖਤਮ ਹੋ ਗਿਆ ਸੀ, ਅਤੇ ਕਾਰਡ ਖਰਾਬ ਹੋ ਗਿਆ ਸੀ।

ਮਾੜੀਆਂ ਗਾਵਾਂ

1980 ਦੇ ਦਹਾਕੇ ਵਿੱਚ, ਮੇਰੇ ਸਲਾਹਕਾਰ ਸਰਗੇਈ ਨੇ SM-1800 ਲਈ ਸਾਫਟਵੇਅਰ ਲਿਖਿਆ, ਜੋ PDP-11 ਦਾ ਇੱਕ ਸੋਵੀਅਤ ਕਲੋਨ ਸੀ। ਇਹ ਮਾਈਕ੍ਰੋਕੰਪਿਊਟਰ ਹੁਣੇ ਹੀ Sverdlovsk ਨੇੜੇ ਇੱਕ ਰੇਲਵੇ ਸਟੇਸ਼ਨ 'ਤੇ ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਕਿ USSR ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਟ੍ਰਾਂਸਪੋਰਟ ਹੱਬ ਹੈ। ਨਵੀਂ ਪ੍ਰਣਾਲੀ ਵੈਗਨਾਂ ਅਤੇ ਮਾਲ ਆਵਾਜਾਈ ਨੂੰ ਰੂਟ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤੀ ਗਈ ਸੀ। ਪਰ ਇਸ ਵਿੱਚ ਇੱਕ ਤੰਗ ਕਰਨ ਵਾਲਾ ਬੱਗ ਸੀ ਜੋ ਬੇਤਰਤੀਬੇ ਕਰੈਸ਼ਾਂ ਅਤੇ ਕਰੈਸ਼ਾਂ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਸ਼ਾਮ ਨੂੰ ਘਰ ਜਾਂਦਾ ਹੈ ਤਾਂ ਡਿੱਗਣਾ ਹਮੇਸ਼ਾ ਹੁੰਦਾ ਹੈ। ਪਰ ਅਗਲੇ ਦਿਨ ਪੂਰੀ ਜਾਂਚ ਦੇ ਬਾਵਜੂਦ, ਕੰਪਿਊਟਰ ਨੇ ਸਾਰੇ ਦਸਤੀ ਅਤੇ ਆਟੋਮੈਟਿਕ ਟੈਸਟਾਂ ਵਿੱਚ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕੀਤਾ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਦੌੜ ਦੀ ਸਥਿਤੀ ਜਾਂ ਕੁਝ ਹੋਰ ਪ੍ਰਤੀਯੋਗੀ ਬੱਗ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ ਕੁਝ ਖਾਸ ਸ਼ਰਤਾਂ ਅਧੀਨ ਹੁੰਦਾ ਹੈ। ਦੇਰ ਰਾਤ ਨੂੰ ਕਾਲਾਂ ਤੋਂ ਥੱਕੇ ਹੋਏ, ਸਰਗੇਈ ਨੇ ਇਸ ਦੀ ਤਹਿ ਤੱਕ ਜਾਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਅਤੇ ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਸਮਝੋ ਕਿ ਮਾਰਸ਼ਲਿੰਗ ਯਾਰਡ ਦੀਆਂ ਕਿਹੜੀਆਂ ਸਥਿਤੀਆਂ ਨੇ ਕੰਪਿਊਟਰ ਨੂੰ ਖਰਾਬ ਕੀਤਾ.

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਉਸਨੇ ਸਾਰੀਆਂ ਅਣਪਛਾਤੀਆਂ ਡਿੱਗੀਆਂ ਦੇ ਅੰਕੜੇ ਇਕੱਠੇ ਕੀਤੇ ਅਤੇ ਮਿਤੀ ਅਤੇ ਸਮੇਂ ਦੁਆਰਾ ਇੱਕ ਗ੍ਰਾਫ ਬਣਾਇਆ। ਪੈਟਰਨ ਸਪੱਸ਼ਟ ਸੀ. ਕੁਝ ਹੋਰ ਦਿਨਾਂ ਲਈ ਨਿਰੀਖਣ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਸਰਗੇਈ ਨੇ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਉਹ ਭਵਿੱਖ ਦੇ ਸਿਸਟਮ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਦੇ ਸਮੇਂ ਦੀ ਭਵਿੱਖਬਾਣੀ ਆਸਾਨੀ ਨਾਲ ਕਰ ਸਕਦਾ ਹੈ.

ਉਸਨੂੰ ਜਲਦੀ ਹੀ ਪਤਾ ਲੱਗਾ ਕਿ ਰੁਕਾਵਟਾਂ ਉਦੋਂ ਹੀ ਆਈਆਂ ਜਦੋਂ ਸਟੇਸ਼ਨ ਉੱਤਰੀ ਯੂਕਰੇਨ ਅਤੇ ਪੱਛਮੀ ਰੂਸ ਤੋਂ ਪਸ਼ੂਆਂ ਦੇ ਰੇਲਗੱਡੀ ਨੂੰ ਛਾਂਟ ਰਿਹਾ ਸੀ ਅਤੇ ਨੇੜਲੇ ਬੁੱਚੜਖਾਨੇ ਵੱਲ ਜਾ ਰਿਹਾ ਸੀ। ਇਹ ਆਪਣੇ ਆਪ ਵਿੱਚ ਅਜੀਬ ਸੀ, ਕਿਉਂਕਿ ਬੁੱਚੜਖਾਨੇ ਨੂੰ ਕਜ਼ਾਕਿਸਤਾਨ ਵਿੱਚ ਬਹੁਤ ਨੇੜੇ ਸਥਿਤ ਫਾਰਮਾਂ ਦੁਆਰਾ ਸਪਲਾਈ ਕੀਤਾ ਗਿਆ ਸੀ।

ਚਰਨੋਬਲ ਪਰਮਾਣੂ ਪਾਵਰ ਪਲਾਂਟ 1986 ਵਿੱਚ ਵਿਸਫੋਟ ਹੋਇਆ ਸੀ, ਅਤੇ ਰੇਡੀਓਐਕਟਿਵ ਫਾਲੋਆਉਟ ਨੇ ਆਲੇ ਦੁਆਲੇ ਦੇ ਖੇਤਰਾਂ ਨੂੰ ਰਹਿਣਯੋਗ ਬਣਾ ਦਿੱਤਾ ਸੀ। ਉੱਤਰੀ ਯੂਕਰੇਨ, ਬੇਲਾਰੂਸ ਅਤੇ ਪੱਛਮੀ ਰੂਸ ਦੇ ਵਿਸ਼ਾਲ ਖੇਤਰ ਦੂਸ਼ਿਤ ਸਨ। ਪਹੁੰਚਣ ਵਾਲੀਆਂ ਗੱਡੀਆਂ ਵਿੱਚ ਰੇਡੀਏਸ਼ਨ ਦੇ ਉੱਚ ਪੱਧਰ ਦਾ ਸ਼ੱਕ ਕਰਦੇ ਹੋਏ, ਸਰਗੇਈ ਨੇ ਇਸ ਥਿਊਰੀ ਨੂੰ ਪਰਖਣ ਲਈ ਇੱਕ ਢੰਗ ਵਿਕਸਿਤ ਕੀਤਾ। ਆਬਾਦੀ ਨੂੰ ਡੋਸੀਮੀਟਰ ਰੱਖਣ ਦੀ ਮਨਾਹੀ ਸੀ, ਇਸ ਲਈ ਸਰਗੇਈ ਨੇ ਰੇਲਵੇ ਸਟੇਸ਼ਨ 'ਤੇ ਕਈ ਫੌਜੀ ਬੰਦਿਆਂ ਨਾਲ ਆਪਣੇ ਆਪ ਨੂੰ ਰਜਿਸਟਰ ਕੀਤਾ। ਵੋਡਕਾ ਦੇ ਕਈ ਪੀਣ ਤੋਂ ਬਾਅਦ, ਉਹ ਇੱਕ ਸਿਪਾਹੀ ਨੂੰ ਸ਼ੱਕੀ ਗੱਡੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਰੇਡੀਏਸ਼ਨ ਦੇ ਪੱਧਰ ਨੂੰ ਮਾਪਣ ਲਈ ਮਨਾਉਣ ਵਿੱਚ ਕਾਮਯਾਬ ਰਿਹਾ। ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਪੱਧਰ ਆਮ ਮੁੱਲਾਂ ਨਾਲੋਂ ਕਈ ਗੁਣਾ ਵੱਧ ਸੀ।

ਪਸ਼ੂਆਂ ਨੇ ਨਾ ਸਿਰਫ ਬਹੁਤ ਜ਼ਿਆਦਾ ਰੇਡੀਏਸ਼ਨ ਛੱਡੀ, ਇਸਦਾ ਪੱਧਰ ਇੰਨਾ ਉੱਚਾ ਸੀ ਕਿ ਇਸ ਨਾਲ SM-1800 ਦੀ ਯਾਦ ਵਿੱਚ ਬਿੱਟਾਂ ਦਾ ਬੇਤਰਤੀਬ ਨੁਕਸਾਨ ਹੋਇਆ, ਜੋ ਕਿ ਸਟੇਸ਼ਨ ਦੇ ਕੋਲ ਇੱਕ ਇਮਾਰਤ ਵਿੱਚ ਸਥਿਤ ਸੀ।

ਯੂਐਸਐਸਆਰ ਵਿੱਚ ਭੋਜਨ ਦੀ ਘਾਟ ਸੀ, ਅਤੇ ਅਧਿਕਾਰੀਆਂ ਨੇ ਦੇਸ਼ ਦੇ ਦੂਜੇ ਖੇਤਰਾਂ ਦੇ ਮੀਟ ਨਾਲ ਚਰਨੋਬਲ ਮੀਟ ਨੂੰ ਮਿਲਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। ਇਸ ਨੇ ਕੀਮਤੀ ਸਰੋਤਾਂ ਨੂੰ ਗੁਆਏ ਬਿਨਾਂ ਰੇਡੀਓਐਕਟੀਵਿਟੀ ਦੇ ਸਮੁੱਚੇ ਪੱਧਰ ਨੂੰ ਘਟਾਉਣਾ ਸੰਭਵ ਬਣਾਇਆ। ਇਸ ਬਾਰੇ ਪਤਾ ਲੱਗਣ ਤੋਂ ਬਾਅਦ, ਸਰਗੇਈ ਨੇ ਤੁਰੰਤ ਪਰਵਾਸ ਲਈ ਦਸਤਾਵੇਜ਼ ਭਰ ਦਿੱਤੇ. ਅਤੇ ਕੰਪਿਊਟਰ ਕਰੈਸ਼ ਆਪਣੇ ਆਪ ਬੰਦ ਹੋ ਗਏ ਜਦੋਂ ਸਮੇਂ ਦੇ ਨਾਲ ਰੇਡੀਏਸ਼ਨ ਦਾ ਪੱਧਰ ਘੱਟ ਗਿਆ.

ਪਾਈਪਾਂ ਰਾਹੀਂ

ਇੱਕ ਸਮੇਂ ਦੀ ਗੱਲ ਹੈ, ਮੂਵੀਟੈਕ ਸਲਿਊਸ਼ਨਜ਼ ਨੇ ਸਿਨੇਮਾਘਰਾਂ ਲਈ ਸਾੱਫਟਵੇਅਰ ਬਣਾਇਆ, ਜੋ ਲੇਖਾਕਾਰੀ, ਟਿਕਟਾਂ ਦੀ ਵਿਕਰੀ ਅਤੇ ਆਮ ਪ੍ਰਬੰਧਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ। ਫਲੈਗਸ਼ਿਪ ਐਪ ਦਾ DOS ਸੰਸਕਰਣ ਉੱਤਰੀ ਅਮਰੀਕਾ ਵਿੱਚ ਛੋਟੇ ਅਤੇ ਮੱਧ-ਆਕਾਰ ਦੇ ਮੂਵੀ ਥੀਏਟਰ ਚੇਨਾਂ ਵਿੱਚ ਕਾਫ਼ੀ ਮਸ਼ਹੂਰ ਸੀ। ਇਸ ਲਈ ਇਹ ਕੋਈ ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ ਕਿ ਜਦੋਂ ਇੱਕ ਵਿੰਡੋਜ਼ 95 ਸੰਸਕਰਣ ਦੀ ਘੋਸ਼ਣਾ ਕੀਤੀ ਗਈ ਸੀ, ਨਵੀਨਤਮ ਟੱਚ ਸਕਰੀਨਾਂ ਅਤੇ ਸਵੈ-ਸੇਵਾ ਕਿਓਸਕਾਂ ਨਾਲ ਏਕੀਕ੍ਰਿਤ, ਅਤੇ ਸਾਰੇ ਤਰ੍ਹਾਂ ਦੇ ਰਿਪੋਰਟਿੰਗ ਟੂਲਸ ਨਾਲ ਲੈਸ, ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਸਿੱਧ ਹੋ ਗਿਆ। ਅਕਸਰ ਅੱਪਡੇਟ ਸਮੱਸਿਆ ਦੇ ਬਿਨਾ ਚਲਾ ਗਿਆ. ਸਥਾਨਕ IT ਸਟਾਫ ਨੇ ਨਵੇਂ ਸਾਜ਼ੋ-ਸਾਮਾਨ ਸਥਾਪਿਤ ਕੀਤੇ, ਮਾਈਗਰੇਟ ਕੀਤੇ ਡੇਟਾ, ਅਤੇ ਕਾਰੋਬਾਰ ਜਾਰੀ ਰੱਖਿਆ। ਸਿਵਾਏ ਜਦੋਂ ਇਹ ਨਹੀਂ ਚੱਲਿਆ। ਜਦੋਂ ਇਹ ਹੋਇਆ, ਤਾਂ ਕੰਪਨੀ ਜੇਮਸ ਨੂੰ ਭੇਜੇਗੀ, ਜਿਸਨੂੰ "ਦ ਕਲੀਨਰ" ਦਾ ਉਪਨਾਮ ਦਿੱਤਾ ਗਿਆ ਹੈ।

ਹਾਲਾਂਕਿ ਉਪਨਾਮ ਇੱਕ ਨਾਪਾਕ ਕਿਸਮ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ, ਕਲੀਨਰ ਸਿਰਫ਼ ਇੰਸਟ੍ਰਕਟਰ, ਇੰਸਟਾਲਰ ਅਤੇ ਜੈਕ-ਆਫ-ਆਲ-ਟ੍ਰੇਡ ਦਾ ਸੁਮੇਲ ਹੈ। ਜੇਮਸ ਕਲਾਇੰਟ ਦੀ ਸਾਈਟ 'ਤੇ ਸਾਰੇ ਭਾਗਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਲਈ ਕੁਝ ਦਿਨ ਬਿਤਾਏਗਾ, ਅਤੇ ਫਿਰ ਸਟਾਫ ਨੂੰ ਨਵੇਂ ਸਿਸਟਮ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਨੀ ਹੈ, ਕਿਸੇ ਵੀ ਹਾਰਡਵੇਅਰ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਅਤੇ ਇਸ ਦੇ ਬਚਪਨ ਦੇ ਦੌਰਾਨ ਸਾਫਟਵੇਅਰ ਦੀ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਮਦਦ ਕਰਨ ਲਈ ਕੁਝ ਦਿਨ ਬਿਤਾਏਗਾ।

ਇਸ ਲਈ, ਇਹ ਕੋਈ ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ ਕਿ ਇਹਨਾਂ ਰੁਝੇਵੇਂ ਭਰੇ ਸਮਿਆਂ ਦੌਰਾਨ, ਜੇਮਜ਼ ਸਵੇਰੇ ਦਫਤਰ ਪਹੁੰਚਿਆ, ਅਤੇ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਉਹ ਆਪਣੇ ਡੈਸਕ ਤੇ ਪਹੁੰਚਦਾ, ਮੈਨੇਜਰ ਦੁਆਰਾ ਉਸਦਾ ਸਵਾਗਤ ਕੀਤਾ ਗਿਆ, ਆਮ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਕੈਫੀਨ ਨਾਲ ਭਰਿਆ ਹੋਇਆ ਸੀ।

"ਮੈਨੂੰ ਡਰ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਐਨਾਪੋਲਿਸ, ਨੋਵਾ ਸਕੋਸ਼ੀਆ ਜਾਣ ਦੀ ਲੋੜ ਹੈ।" ਉਹਨਾਂ ਦਾ ਸਾਰਾ ਸਿਸਟਮ ਖਰਾਬ ਹੋ ਗਿਆ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਇੰਜੀਨੀਅਰਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਇੱਕ ਰਾਤ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਇਹ ਨਹੀਂ ਸਮਝ ਸਕਦੇ ਕਿ ਕੀ ਹੋਇਆ। ਇੰਝ ਜਾਪਦਾ ਹੈ ਕਿ ਸਰਵਰ 'ਤੇ ਨੈੱਟਵਰਕ ਅਸਫਲ ਹੋ ਗਿਆ ਹੈ। ਪਰ ਇਸ ਤੋਂ ਬਾਅਦ ਹੀ ਸਿਸਟਮ ਕਈ ਮਿੰਟ ਚੱਲਦਾ ਰਿਹਾ।

- ਉਹ ਪੁਰਾਣੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਵਾਪਸ ਨਹੀਂ ਆਏ? - ਜੇਮਜ਼ ਨੇ ਪੂਰੀ ਗੰਭੀਰਤਾ ਨਾਲ ਜਵਾਬ ਦਿੱਤਾ, ਹਾਲਾਂਕਿ ਮਾਨਸਿਕ ਤੌਰ 'ਤੇ ਉਸਨੇ ਹੈਰਾਨੀ ਨਾਲ ਆਪਣੀਆਂ ਅੱਖਾਂ ਚੌੜੀਆਂ ਕੀਤੀਆਂ।

- ਬਿਲਕੁਲ: ਉਨ੍ਹਾਂ ਦੇ ਆਈਟੀ ਮਾਹਰ ਨੇ "ਪਹਿਲਾਂ ਬਦਲੀਆਂ" ਅਤੇ ਆਪਣੇ ਪੁਰਾਣੇ ਸਰਵਰ ਨੂੰ ਛੱਡਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। ਜੇਮਜ਼, ਉਨ੍ਹਾਂ ਨੇ ਸਿਸਟਮ ਨੂੰ ਛੇ ਸਾਈਟਾਂ 'ਤੇ ਸਥਾਪਿਤ ਕੀਤਾ ਅਤੇ ਸਿਰਫ ਪ੍ਰੀਮੀਅਮ ਸਹਾਇਤਾ ਲਈ ਭੁਗਤਾਨ ਕੀਤਾ, ਅਤੇ ਉਨ੍ਹਾਂ ਦਾ ਕਾਰੋਬਾਰ ਹੁਣ ਉਸੇ ਤਰ੍ਹਾਂ ਚੱਲ ਰਿਹਾ ਹੈ ਜਿਵੇਂ ਇਹ 1950 ਦੇ ਦਹਾਕੇ ਵਿੱਚ ਸੀ।

ਜੇਮਜ਼ ਥੋੜ੍ਹਾ ਜਿਹਾ ਸਿੱਧਾ ਹੋਇਆ।

- ਇਹ ਹੋਰ ਗੱਲ ਹੈ। ਠੀਕ ਹੈ, ਆਓ ਸ਼ੁਰੂ ਕਰੀਏ।

ਜਦੋਂ ਉਹ ਅੰਨਾਪੋਲਿਸ ਪਹੁੰਚਿਆ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਉਸਨੇ ਗਾਹਕ ਦਾ ਪਹਿਲਾ ਥੀਏਟਰ ਲੱਭਿਆ ਜਿਸ ਵਿੱਚ ਸਮੱਸਿਆ ਸੀ। ਹਵਾਈ ਅੱਡੇ 'ਤੇ ਲਏ ਗਏ ਨਕਸ਼ੇ 'ਤੇ, ਸਭ ਕੁਝ ਵਧੀਆ ਲੱਗ ਰਿਹਾ ਸੀ, ਪਰ ਲੋੜੀਂਦੇ ਪਤੇ ਦੇ ਆਲੇ ਦੁਆਲੇ ਦਾ ਖੇਤਰ ਸ਼ੱਕੀ ਲੱਗ ਰਿਹਾ ਸੀ. ਜੈਟੋ ਨਹੀਂ, ਪਰ ਫਿਲਮ ਨੋਇਰ ਦੀ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹੈ। ਜਿਵੇਂ ਹੀ ਜੇਮਜ਼ ਕਰਬ ਡਾਊਨਟਾਊਨ 'ਤੇ ਖੜ੍ਹਾ ਸੀ, ਇਕ ਵੇਸਵਾ ਉਸ ਕੋਲ ਆਈ। ਅੰਨਾਪੋਲਿਸ ਦੇ ਆਕਾਰ ਦੇ ਮੱਦੇਨਜ਼ਰ, ਇਹ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਪੂਰੇ ਸ਼ਹਿਰ ਵਿਚ ਇਕੋ ਇਕ ਸੀ। ਉਸ ਦੀ ਦਿੱਖ ਨੇ ਤੁਰੰਤ ਮਸ਼ਹੂਰ ਪਾਤਰ ਨੂੰ ਧਿਆਨ ਵਿਚ ਲਿਆਂਦਾ ਜਿਸ ਨੇ ਵੱਡੇ ਪਰਦੇ 'ਤੇ ਪੈਸੇ ਲਈ ਸੈਕਸ ਦੀ ਪੇਸ਼ਕਸ਼ ਕੀਤੀ ਸੀ। ਨਹੀਂ, ਜੂਲੀਆ ਰੌਬਰਟਸ ਬਾਰੇ ਨਹੀਂ, ਜੋਨ ਵੋਇਟ ਬਾਰੇ [ਫਿਲਮ "ਮਿਡਨਾਈਟ ਕਾਉਬੌਏ" ਦਾ ਸੰਕੇਤ - ਲਗਭਗ। ਲੇਨ].

ਵੇਸਵਾ ਨੂੰ ਆਪਣੇ ਰਾਹ 'ਤੇ ਭੇਜ ਕੇ, ਜੇਮਜ਼ ਸਿਨੇਮਾ ਚਲਾ ਗਿਆ। ਆਲੇ ਦੁਆਲੇ ਦਾ ਇਲਾਕਾ ਬਿਹਤਰ ਹੋ ਗਿਆ ਸੀ, ਪਰ ਇਸ ਨੇ ਅਜੇ ਵੀ ਹੇਠਾਂ ਭੱਜਣ ਦਾ ਪ੍ਰਭਾਵ ਦਿੱਤਾ. ਇਹ ਨਹੀਂ ਕਿ ਜੇਮਜ਼ ਬਹੁਤ ਚਿੰਤਤ ਸੀ। ਉਹ ਪਹਿਲਾਂ ਵੀ ਖਰਾਬ ਥਾਵਾਂ 'ਤੇ ਜਾ ਚੁੱਕਾ ਹੈ। ਅਤੇ ਇਹ ਕੈਨੇਡਾ ਸੀ, ਜਿੱਥੇ ਲੁਟੇਰੇ ਵੀ ਤੁਹਾਡਾ ਬਟੂਆ ਲੈਣ ਤੋਂ ਬਾਅਦ "ਧੰਨਵਾਦ" ਕਹਿਣ ਲਈ ਕਾਫੀ ਨਰਮ ਹੁੰਦੇ ਹਨ।

ਸਿਨੇਮਾ ਦੇ ਪਾਸੇ ਦਾ ਪ੍ਰਵੇਸ਼ ਦੁਆਰ ਇੱਕ ਸੁੰਨੀ ਗਲੀ ਵਿੱਚ ਸੀ। ਜੇਮਸ ਨੇ ਦਰਵਾਜ਼ਾ ਖੜਕਾਇਆ ਅਤੇ ਦਰਵਾਜ਼ਾ ਖੜਕਾਇਆ। ਜਲਦੀ ਹੀ ਇਹ ਚੀਕਿਆ ਅਤੇ ਥੋੜ੍ਹਾ ਜਿਹਾ ਖੁੱਲ੍ਹ ਗਿਆ।

-ਕੀ ਤੁਸੀਂ ਕਲੀਨਰ ਹੋ? - ਅੰਦਰੋਂ ਇੱਕ ਖੂੰਖਾਰ ਆਵਾਜ਼ ਆਈ।

- ਹਾਂ, ਇਹ ਮੈਂ ਹਾਂ... ਮੈਂ ਸਭ ਕੁਝ ਠੀਕ ਕਰਨ ਆਇਆ ਹਾਂ।

ਜੇਮਸ ਸਿਨੇਮਾ ਦੀ ਲਾਬੀ ਵਿੱਚ ਚਲਾ ਗਿਆ। ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਕੋਈ ਹੋਰ ਵਿਕਲਪ ਨਹੀਂ ਸੀ, ਸਟਾਫ ਨੇ ਸੈਲਾਨੀਆਂ ਨੂੰ ਕਾਗਜ਼ੀ ਟਿਕਟਾਂ ਦੇਣੀਆਂ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀਆਂ। ਇਸ ਨੇ ਵਿੱਤੀ ਰਿਪੋਰਟਿੰਗ ਨੂੰ ਮੁਸ਼ਕਲ ਬਣਾ ਦਿੱਤਾ, ਹੋਰ ਦਿਲਚਸਪ ਵੇਰਵਿਆਂ ਨੂੰ ਛੱਡ ਦਿਓ। ਪਰ ਸਟਾਫ ਨੇ ਜੇਮਸ ਨੂੰ ਰਾਹਤ ਦੇ ਨਾਲ ਸਵਾਗਤ ਕੀਤਾ ਅਤੇ ਤੁਰੰਤ ਉਸਨੂੰ ਸਰਵਰ ਰੂਮ ਵਿੱਚ ਲੈ ਗਏ।

ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ, ਸਭ ਕੁਝ ਠੀਕ ਸੀ. ਜੇਮਸ ਨੇ ਸਰਵਰ ਵਿੱਚ ਲੌਗਇਨ ਕੀਤਾ ਅਤੇ ਆਮ ਸ਼ੱਕੀ ਥਾਵਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ। ਕੋਈ ਸਮੱਸਿਆ ਨਹੀ. ਹਾਲਾਂਕਿ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਾਵਧਾਨੀ ਦੇ ਕਾਰਨ, ਜੇਮਜ਼ ਨੇ ਸਰਵਰ ਨੂੰ ਬੰਦ ਕਰ ਦਿੱਤਾ, ਨੈੱਟਵਰਕ ਕਾਰਡ ਨੂੰ ਬਦਲ ਦਿੱਤਾ, ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਵਾਪਸ ਮੋੜ ਦਿੱਤਾ। ਉਸ ਨੇ ਤੁਰੰਤ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਸਟਾਫ ਨੇ ਫਿਰ ਟਿਕਟਾਂ ਵੇਚਣੀਆਂ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀਆਂ।

ਜੇਮਜ਼ ਨੇ ਮਾਰਕ ਨੂੰ ਬੁਲਾਇਆ ਅਤੇ ਉਸ ਨੂੰ ਸਥਿਤੀ ਤੋਂ ਜਾਣੂ ਕਰਵਾਇਆ। ਇਹ ਕਲਪਨਾ ਕਰਨਾ ਔਖਾ ਨਹੀਂ ਹੈ ਕਿ ਜੇਮਜ਼ ਆਲੇ-ਦੁਆਲੇ ਰਹਿਣਾ ਚਾਹ ਸਕਦਾ ਹੈ ਅਤੇ ਇਹ ਦੇਖਣਾ ਚਾਹੁੰਦਾ ਹੈ ਕਿ ਕੀ ਕੁਝ ਅਚਾਨਕ ਵਾਪਰਦਾ ਹੈ. ਉਹ ਪੌੜੀਆਂ ਉਤਰ ਗਿਆ ਅਤੇ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਪੁੱਛਣ ਲੱਗਾ ਕਿ ਕੀ ਹੋਇਆ। ਜ਼ਾਹਿਰ ਹੈ ਕਿ ਸਿਸਟਮ ਨੇ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ ਹੈ। ਉਹਨਾਂ ਨੇ ਇਸਨੂੰ ਬੰਦ ਅਤੇ ਚਾਲੂ ਕਰ ਦਿੱਤਾ, ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ। ਪਰ 10 ਮਿੰਟ ਬਾਅਦ ਸਿਸਟਮ ਬੰਦ ਹੋ ਗਿਆ।

ਇਸ ਸਮੇਂ ਕੁਝ ਅਜਿਹਾ ਹੀ ਹੋਇਆ। ਅਚਾਨਕ, ਟਿਕਟਿੰਗ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਤਰੁੱਟੀਆਂ ਆਉਣੀਆਂ ਸ਼ੁਰੂ ਹੋ ਗਈਆਂ। ਸਟਾਫ ਨੇ ਸਾਹ ਭਰਿਆ ਅਤੇ ਕਾਗਜ਼ ਦੀਆਂ ਟਿਕਟਾਂ ਫੜ ਲਈਆਂ, ਅਤੇ ਜੇਮਜ਼ ਜਲਦੀ ਨਾਲ ਸਰਵਰ ਰੂਮ ਵੱਲ ਚਲਾ ਗਿਆ। ਸਰਵਰ ਨਾਲ ਸਭ ਕੁਝ ਵਧੀਆ ਲੱਗ ਰਿਹਾ ਸੀ।

ਫਿਰ ਇੱਕ ਕਰਮਚਾਰੀ ਅੰਦਰ ਦਾਖਲ ਹੋਇਆ।

- ਸਿਸਟਮ ਦੁਬਾਰਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।

ਜੇਮਜ਼ ਹੈਰਾਨ ਸੀ ਕਿਉਂਕਿ ਉਸਨੇ ਕੁਝ ਨਹੀਂ ਕੀਤਾ ਸੀ। ਵਧੇਰੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ, ਅਜਿਹਾ ਕੁਝ ਵੀ ਨਹੀਂ ਜੋ ਸਿਸਟਮ ਨੂੰ ਕੰਮ ਕਰੇਗਾ। ਉਸਨੇ ਲੌਗ ਆਊਟ ਕੀਤਾ, ਆਪਣਾ ਫ਼ੋਨ ਚੁੱਕਿਆ, ਅਤੇ ਆਪਣੀ ਕੰਪਨੀ ਦੀ ਸਹਾਇਤਾ ਲਾਈਨ 'ਤੇ ਕਾਲ ਕੀਤੀ। ਜਲਦੀ ਹੀ ਉਹੀ ਕਰਮਚਾਰੀ ਸਰਵਰ ਰੂਮ ਵਿੱਚ ਦਾਖਲ ਹੋਇਆ।

- ਸਿਸਟਮ ਡਾਊਨ ਹੈ।

ਜੇਮਜ਼ ਨੇ ਸਰਵਰ ਵੱਲ ਨਿਗ੍ਹਾ ਮਾਰੀ। ਬਹੁ-ਰੰਗੀ ਆਕਾਰਾਂ ਦਾ ਇੱਕ ਦਿਲਚਸਪ ਅਤੇ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਪੈਟਰਨ ਸਕ੍ਰੀਨ 'ਤੇ ਨੱਚਦਾ ਹੈ - ਅਰਾਜਕਤਾ ਨਾਲ ਰਾਈਥਿੰਗ ਅਤੇ ਇੰਟਰਵਿਨਿੰਗ ਪਾਈਪਾਂ। ਅਸੀਂ ਸਾਰਿਆਂ ਨੇ ਕਿਸੇ ਸਮੇਂ ਇਸ ਸਕ੍ਰੀਨਸੇਵਰ ਨੂੰ ਦੇਖਿਆ ਹੈ। ਇਹ ਸੁੰਦਰਤਾ ਨਾਲ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ hypnotizing ਸੀ.

ਜੇਮਜ਼ ਨੇ ਇੱਕ ਬਟਨ ਦਬਾਇਆ ਅਤੇ ਪੈਟਰਨ ਗਾਇਬ ਹੋ ਗਿਆ। ਉਹ ਜਲਦੀ ਨਾਲ ਟਿਕਟ ਦਫਤਰ ਪਹੁੰਚਿਆ ਅਤੇ ਰਸਤੇ ਵਿਚ ਉਸ ਨੂੰ ਵਾਪਸ ਆ ਰਹੇ ਇਕ ਕਰਮਚਾਰੀ ਨੂੰ ਮਿਲਿਆ।

- ਸਿਸਟਮ ਦੁਬਾਰਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਮਾਨਸਿਕ ਫੇਸਪੈਮ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜੋ ਜੇਮਜ਼ ਨੇ ਕੀਤਾ ਸੀ। ਸਕਰੀਨ ਸੇਵਰ. ਇਹ OpenGL ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਅਤੇ ਇਸ ਲਈ, ਓਪਰੇਸ਼ਨ ਦੌਰਾਨ, ਇਹ ਸਰਵਰ ਪ੍ਰੋਸੈਸਰ ਦੇ ਸਾਰੇ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ. ਨਤੀਜੇ ਵਜੋਂ, ਸਰਵਰ ਲਈ ਹਰੇਕ ਕਾਲ ਇੱਕ ਸਮਾਂ ਸਮਾਪਤੀ ਨਾਲ ਖਤਮ ਹੁੰਦੀ ਹੈ।

ਜੇਮਜ਼ ਸਰਵਰ ਰੂਮ ਵਿੱਚ ਵਾਪਸ ਆਇਆ, ਲੌਗਇਨ ਕੀਤਾ, ਅਤੇ ਇੱਕ ਖਾਲੀ ਸਕਰੀਨ ਨਾਲ ਸੁੰਦਰ ਪਾਈਪਾਂ ਨਾਲ ਸਕਰੀਨਸੇਵਰ ਨੂੰ ਬਦਲ ਦਿੱਤਾ। ਭਾਵ, ਇੱਕ ਸਕ੍ਰੀਨਸੇਵਰ ਦੀ ਬਜਾਏ ਜੋ 100% ਪ੍ਰੋਸੈਸਰ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ, ਮੈਂ ਇੱਕ ਹੋਰ ਸਥਾਪਤ ਕੀਤਾ ਜੋ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਨਹੀਂ ਕਰਦਾ. ਫਿਰ ਮੈਂ ਆਪਣੇ ਅੰਦਾਜ਼ੇ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ 10 ਮਿੰਟ ਉਡੀਕ ਕੀਤੀ।

ਜਦੋਂ ਜੇਮਸ ਅਗਲੇ ਸਿਨੇਮਾ ਵਿੱਚ ਪਹੁੰਚਿਆ, ਤਾਂ ਉਹ ਸੋਚ ਰਿਹਾ ਸੀ ਕਿ ਆਪਣੇ ਮੈਨੇਜਰ ਨੂੰ ਕਿਵੇਂ ਸਮਝਾਇਆ ਜਾਵੇ ਕਿ ਉਸਨੇ ਸਕ੍ਰੀਨ ਸੇਵਰ ਨੂੰ ਬੰਦ ਕਰਨ ਲਈ ਸਿਰਫ 800 ਕਿਲੋਮੀਟਰ ਦੀ ਉਡਾਣ ਭਰੀ ਸੀ।

ਚੰਦਰਮਾ ਦੇ ਇੱਕ ਖਾਸ ਪੜਾਅ ਦੌਰਾਨ ਕਰੈਸ਼

ਸੱਚੀ ਕਹਾਣੀ. ਇੱਕ ਦਿਨ ਇੱਕ ਸੌਫਟਵੇਅਰ ਬੱਗ ਪੈਦਾ ਹੋਇਆ ਜੋ ਚੰਦਰਮਾ ਦੇ ਪੜਾਅ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਸੀ। ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਰੁਟੀਨ ਸੀ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਚੰਦਰਮਾ ਦੇ ਅਸਲ ਪੜਾਅ ਦੇ ਅਨੁਮਾਨ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਵੱਖ-ਵੱਖ MIT ਪ੍ਰੋਗਰਾਮਾਂ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਸੀ। GLS ਨੇ ਇਸ ਰੁਟੀਨ ਨੂੰ ਇੱਕ LISP ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਬਣਾਇਆ ਜੋ, ਇੱਕ ਫਾਈਲ ਲਿਖਣ ਵੇਲੇ, ਲਗਭਗ 80 ਅੱਖਰਾਂ ਦੀ ਲੰਮੀ ਟਾਈਮਸਟੈਂਪ ਵਾਲੀ ਇੱਕ ਲਾਈਨ ਆਉਟਪੁੱਟ ਕਰੇਗਾ। ਇਹ ਬਹੁਤ ਘੱਟ ਹੁੰਦਾ ਸੀ ਕਿ ਇੱਕ ਸੰਦੇਸ਼ ਦੀ ਪਹਿਲੀ ਲਾਈਨ ਬਹੁਤ ਲੰਬੀ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਅਗਲੀ ਲਾਈਨ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ। ਅਤੇ ਜਦੋਂ ਪ੍ਰੋਗਰਾਮ ਨੇ ਬਾਅਦ ਵਿੱਚ ਇਸ ਫਾਈਲ ਨੂੰ ਪੜ੍ਹਿਆ, ਤਾਂ ਇਸਨੇ ਸਰਾਪ ਦਿੱਤਾ. ਪਹਿਲੀ ਲਾਈਨ ਦੀ ਲੰਬਾਈ ਸਹੀ ਮਿਤੀ ਅਤੇ ਸਮੇਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਨਾਲ ਹੀ ਟਾਈਮਸਟੈਂਪ ਦੇ ਛਾਪੇ ਜਾਣ ਦੇ ਸਮੇਂ ਦੇ ਪੜਾਅ ਨਿਰਧਾਰਨ ਦੀ ਲੰਬਾਈ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। ਭਾਵ, ਬੱਗ ਅਸਲ ਵਿੱਚ ਚੰਦਰਮਾ ਦੇ ਪੜਾਅ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ!

ਪਹਿਲਾ ਪੇਪਰ ਐਡੀਸ਼ਨ ਜਾਰਗਨ ਫਾਈਲ (ਸਟੀਲ-1983) ਵਿੱਚ ਅਜਿਹੀ ਇੱਕ ਲਾਈਨ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਸ਼ਾਮਲ ਹੈ ਜੋ ਵਰਣਨ ਕੀਤੇ ਗਏ ਬੱਗ ਵੱਲ ਲੈ ਗਈ, ਪਰ ਟਾਈਪਸੈਟਰ ਨੇ ਇਸਨੂੰ "ਸਥਿਰ" ਕੀਤਾ। ਇਸ ਨੂੰ ਉਦੋਂ ਤੋਂ "ਚੰਨ ਪੜਾਅ ਬੱਗ" ਵਜੋਂ ਦਰਸਾਇਆ ਗਿਆ ਹੈ।

ਹਾਲਾਂਕਿ, ਧਾਰਨਾਵਾਂ ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ. ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ, CERN (ਯੂਰੋਪੀਅਨ ਸੈਂਟਰ ਫਾਰ ਨਿਊਕਲੀਅਰ ਰਿਸਰਚ) ਦੇ ਇੰਜੀਨੀਅਰਾਂ ਨੂੰ ਵੱਡੇ ਇਲੈਕਟ੍ਰੋਨ-ਪੋਜ਼ੀਟ੍ਰੋਨ ਕੋਲਾਈਡਰ 'ਤੇ ਕੀਤੇ ਗਏ ਪ੍ਰਯੋਗਾਂ ਵਿੱਚ ਗਲਤੀਆਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਸੀ। ਕਿਉਂਕਿ ਕੰਪਿਊਟਰ ਵਿਗਿਆਨੀਆਂ ਨੂੰ ਨਤੀਜਾ ਦਿਖਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਡਿਵਾਈਸ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਗਏ ਬਹੁਤ ਸਾਰੇ ਡੇਟਾ ਦੀ ਸਰਗਰਮੀ ਨਾਲ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਹਨ, ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਨੇ ਅੰਦਾਜ਼ਾ ਲਗਾਇਆ ਕਿ ਸੌਫਟਵੇਅਰ ਚੰਦਰਮਾ ਦੇ ਪੜਾਅ ਲਈ ਕਿਸੇ ਤਰ੍ਹਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਸੀ। ਕਈ ਹਤਾਸ਼ ਇੰਜੀਨੀਅਰ ਸੱਚ ਦੀ ਤਹਿ ਤੱਕ ਪਹੁੰਚ ਗਏ। ਚੰਦਰਮਾ ਦੇ ਲੰਘਣ ਦੌਰਾਨ ਧਰਤੀ ਦੇ ਵਿਗਾੜ ਕਾਰਨ 27 ਕਿਲੋਮੀਟਰ ਲੰਬੇ ਰਿੰਗ ਦੀ ਜਿਓਮੈਟਰੀ ਵਿੱਚ ਮਾਮੂਲੀ ਤਬਦੀਲੀ ਕਾਰਨ ਇਹ ਗਲਤੀ ਪੈਦਾ ਹੋਈ! ਇਹ ਕਹਾਣੀ ਭੌਤਿਕ ਵਿਗਿਆਨ ਦੇ ਲੋਕਧਾਰਾ ਵਿੱਚ "ਕਣ ਭੌਤਿਕ ਵਿਗਿਆਨ ਉੱਤੇ ਨਿਊਟਨ ਦਾ ਬਦਲਾ" ਅਤੇ ਭੌਤਿਕ ਵਿਗਿਆਨ ਦੇ ਸਭ ਤੋਂ ਸਰਲ ਅਤੇ ਸਭ ਤੋਂ ਪੁਰਾਣੇ ਨਿਯਮਾਂ ਅਤੇ ਸਭ ਤੋਂ ਉੱਨਤ ਵਿਗਿਆਨਕ ਸੰਕਲਪਾਂ ਵਿਚਕਾਰ ਸਬੰਧ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ ਦਾਖਲ ਹੋਈ ਹੈ।

ਟਾਇਲਟ ਨੂੰ ਫਲੱਸ਼ ਕਰਨ ਨਾਲ ਟਰੇਨ ਰੁਕ ਜਾਂਦੀ ਹੈ

ਸਭ ਤੋਂ ਵਧੀਆ ਹਾਰਡਵੇਅਰ ਬੱਗ ਜਿਸ ਬਾਰੇ ਮੈਂ ਕਦੇ ਸੁਣਿਆ ਹੈ ਉਹ ਫਰਾਂਸ ਵਿੱਚ ਇੱਕ ਹਾਈ ਸਪੀਡ ਟ੍ਰੇਨ ਵਿੱਚ ਸੀ। ਇਸ ਬੱਗ ਕਾਰਨ ਰੇਲਗੱਡੀ ਦੀ ਐਮਰਜੈਂਸੀ ਬ੍ਰੇਕ ਲੱਗ ਗਈ, ਪਰ ਉਦੋਂ ਹੀ ਜਦੋਂ ਸਵਾਰੀ ਸਵਾਰ ਸਨ। ਅਜਿਹੇ ਹਰ ਮਾਮਲੇ ਵਿੱਚ, ਰੇਲ ਗੱਡੀ ਨੂੰ ਸੇਵਾ ਤੋਂ ਹਟਾਇਆ ਗਿਆ, ਜਾਂਚ ਕੀਤੀ ਗਈ, ਪਰ ਕੁਝ ਨਹੀਂ ਮਿਲਿਆ। ਫਿਰ ਉਸਨੂੰ ਲਾਈਨ 'ਤੇ ਵਾਪਸ ਭੇਜਿਆ ਗਿਆ, ਅਤੇ ਉਹ ਤੁਰੰਤ ਇੱਕ ਸਟਾਪ 'ਤੇ ਕਰੈਸ਼ ਹੋ ਗਿਆ।

ਇਕ ਚੈਕਿੰਗ ਦੌਰਾਨ ਟਰੇਨ 'ਚ ਸਫਰ ਕਰ ਰਿਹਾ ਇਕ ਇੰਜੀਨੀਅਰ ਟਾਇਲਟ 'ਚ ਚਲਾ ਗਿਆ। ਉਹ ਜਲਦੀ ਹੀ ਧੋਤਾ ਗਿਆ, ਬੂਮ! ਐਮਰਜੈਂਸੀ ਸਟਾਪ।

ਇੰਜੀਨੀਅਰ ਨੇ ਡਰਾਈਵਰ ਨਾਲ ਸੰਪਰਕ ਕੀਤਾ ਅਤੇ ਪੁੱਛਿਆ:

- ਤੁਸੀਂ ਬ੍ਰੇਕ ਲਗਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਕਰ ਰਹੇ ਸੀ?

- ਖੈਰ, ਮੈਂ ਉਤਰਨ 'ਤੇ ਹੌਲੀ ਹੋ ਗਿਆ ...

ਇਹ ਅਜੀਬ ਸੀ, ਕਿਉਂਕਿ ਆਮ ਕਾਰਵਾਈ ਦੌਰਾਨ ਰੇਲਗੱਡੀ ਦਰਜਨਾਂ ਵਾਰ ਉਤਰਨ 'ਤੇ ਹੌਲੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਰੇਲਗੱਡੀ ਅੱਗੇ ਵਧੀ, ਅਤੇ ਅਗਲੀ ਉਤਰਾਈ 'ਤੇ ਡਰਾਈਵਰ ਨੇ ਚੇਤਾਵਨੀ ਦਿੱਤੀ:

- ਮੈਂ ਹੌਲੀ ਕਰਨ ਜਾ ਰਿਹਾ ਹਾਂ।

ਕੁਝ ਨਹੀਂ ਹੋਇਆ।

- ਤੁਸੀਂ ਆਖਰੀ ਬ੍ਰੇਕਿੰਗ ਦੌਰਾਨ ਕੀ ਕੀਤਾ? - ਡਰਾਈਵਰ ਨੂੰ ਪੁੱਛਿਆ.

- ਖੈਰ... ਮੈਂ ਟਾਇਲਟ ਵਿੱਚ ਸੀ...

- ਠੀਕ ਹੈ, ਫਿਰ ਟਾਇਲਟ ਜਾਓ ਅਤੇ ਤੁਸੀਂ ਉਹੀ ਕਰੋ ਜਦੋਂ ਅਸੀਂ ਦੁਬਾਰਾ ਹੇਠਾਂ ਜਾਂਦੇ ਹਾਂ!

ਇੰਜਨੀਅਰ ਟਾਇਲਟ ਗਿਆ, ਅਤੇ ਜਦੋਂ ਡਰਾਈਵਰ ਨੇ ਚੇਤਾਵਨੀ ਦਿੱਤੀ: "ਮੈਂ ਹੌਲੀ ਹੋ ਰਿਹਾ ਹਾਂ," ਉਸਨੇ ਪਾਣੀ ਵਹਾਇਆ। ਬੇਸ਼ੱਕ ਟਰੇਨ ਤੁਰੰਤ ਰੁਕ ਗਈ।

ਹੁਣ ਉਹ ਸਮੱਸਿਆ ਨੂੰ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਕਾਰਨ ਲੱਭਣ ਦੀ ਲੋੜ ਹੈ।

ਦੋ ਮਿੰਟਾਂ ਬਾਅਦ, ਉਨ੍ਹਾਂ ਨੇ ਦੇਖਿਆ ਕਿ ਇੰਜਣ ਦੀ ਬ੍ਰੇਕ ਰਿਮੋਟ ਕੰਟਰੋਲ ਕੇਬਲ (ਟਰੇਨ ਦੇ ਹਰ ਸਿਰੇ 'ਤੇ ਇਕ ਇੰਜਣ ਸੀ) ਇਲੈਕਟ੍ਰੀਕਲ ਕੈਬਿਨੇਟ ਦੀ ਕੰਧ ਤੋਂ ਡਿਸਕਨੈਕਟ ਹੋ ਗਿਆ ਸੀ ਅਤੇ ਰੀਲੇਅ 'ਤੇ ਪਿਆ ਸੀ ਜੋ ਟਾਇਲਟ ਪਲੱਗ ਸੋਲਨੋਇਡ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦਾ ਸੀ... ਜਦੋਂ ਰੀਲੇਅ ਚਾਲੂ ਕੀਤਾ ਗਿਆ ਸੀ, ਇਸਨੇ ਬ੍ਰੇਕ ਕੇਬਲ ਵਿੱਚ ਦਖਲਅੰਦਾਜ਼ੀ ਕੀਤੀ, ਅਤੇ ਅਸਫਲਤਾਵਾਂ ਦੇ ਵਿਰੁੱਧ ਸਿਸਟਮ ਸੁਰੱਖਿਆ ਵਿੱਚ ਐਮਰਜੈਂਸੀ ਬ੍ਰੇਕਿੰਗ ਸ਼ਾਮਲ ਹੈ।

ਗੇਟਵੇ ਜੋ ਫੋਰਟਰਨ ਨੂੰ ਨਫ਼ਰਤ ਕਰਦਾ ਸੀ

ਕੁਝ ਮਹੀਨੇ ਪਹਿਲਾਂ ਅਸੀਂ ਦੇਖਿਆ ਸੀ ਕਿ ਮੇਨਲੈਂਡ [ਇਹ ਹਵਾਈ ਵਿੱਚ ਸੀ] ਉੱਤੇ ਨੈੱਟਵਰਕ ਕਨੈਕਸ਼ਨ ਬਹੁਤ, ਬਹੁਤ ਹੌਲੀ ਹੋ ਰਹੇ ਸਨ। ਇਹ 10-15 ਮਿੰਟਾਂ ਤੱਕ ਰਹਿ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਅਚਾਨਕ ਦੁਬਾਰਾ ਹੋ ਸਕਦਾ ਹੈ। ਕੁਝ ਸਮੇਂ ਬਾਅਦ, ਮੇਰੇ ਸਾਥੀ ਨੇ ਮੈਨੂੰ ਸ਼ਿਕਾਇਤ ਕੀਤੀ ਕਿ ਮੇਨਲੈਂਡ 'ਤੇ ਨੈਟਵਰਕ ਕਨੈਕਸ਼ਨ вообще ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਉਸ ਕੋਲ ਕੁਝ FORTRAN ਕੋਡ ਸੀ ਜਿਸ ਨੂੰ ਮੁੱਖ ਭੂਮੀ 'ਤੇ ਇੱਕ ਮਸ਼ੀਨ ਵਿੱਚ ਨਕਲ ਕਰਨ ਦੀ ਲੋੜ ਸੀ, ਪਰ ਅਜਿਹਾ ਨਹੀਂ ਹੋ ਸਕਿਆ ਕਿਉਂਕਿ "ਨੈੱਟਵਰਕ ਨੇ FTP ਅੱਪਲੋਡ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਸਮਾਂ ਨਹੀਂ ਰੱਖਿਆ ਸੀ।"

ਹਾਂ, ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਨੈਟਵਰਕ ਅਸਫਲਤਾਵਾਂ ਉਦੋਂ ਆਈਆਂ ਜਦੋਂ ਇੱਕ ਸਹਿਕਰਮੀ ਨੇ ਮੇਨਲੈਂਡ 'ਤੇ ਇੱਕ ਮਸ਼ੀਨ ਨੂੰ ਫੋਰਟਰਨ ਵਿੱਚ ਸਰੋਤ ਕੋਡ ਵਾਲੀ ਇੱਕ ਫਾਈਲ ਨੂੰ FTP ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ। ਅਸੀਂ ਫਾਈਲ ਨੂੰ ਆਰਕਾਈਵ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ: ਫਿਰ ਇਸਨੂੰ ਆਸਾਨੀ ਨਾਲ ਕਾਪੀ ਕੀਤਾ ਗਿਆ (ਪਰ ਟਾਰਗਿਟ ਮਸ਼ੀਨ ਵਿੱਚ ਅਨਪੈਕਰ ਨਹੀਂ ਸੀ, ਇਸਲਈ ਸਮੱਸਿਆ ਹੱਲ ਨਹੀਂ ਹੋਈ)। ਅੰਤ ਵਿੱਚ ਅਸੀਂ FORTRAN ਕੋਡ ਨੂੰ ਬਹੁਤ ਛੋਟੇ ਟੁਕੜਿਆਂ ਵਿੱਚ "ਵੰਡਿਆ" ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਭੇਜਿਆ। ਬਹੁਤੇ ਟੁਕੜੇ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਕਾਪੀ ਕੀਤੇ ਗਏ ਸਨ, ਪਰ ਕੁਝ ਟੁਕੜੇ ਪਾਸ ਨਹੀਂ ਹੋਏ, ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਪਾਸ ਨਹੀਂ ਹੋਏ ਕਈ ਕੋਸ਼ਿਸ਼ਾਂ

ਜਦੋਂ ਅਸੀਂ ਸਮੱਸਿਆ ਵਾਲੇ ਅੰਸ਼ਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ, ਤਾਂ ਸਾਨੂੰ ਪਤਾ ਲੱਗਾ ਕਿ ਉਹਨਾਂ ਵਿੱਚ ਕੁਝ ਸਾਂਝਾ ਸੀ: ਉਹਨਾਂ ਸਾਰਿਆਂ ਵਿੱਚ ਟਿੱਪਣੀ ਬਲਾਕ ਸਨ ਜੋ ਕੈਪੀਟਲ C ਵਾਲੀਆਂ ਲਾਈਨਾਂ ਨਾਲ ਸ਼ੁਰੂ ਅਤੇ ਖਤਮ ਹੁੰਦੇ ਸਨ (ਇੱਕ ਸਹਿਯੋਗੀ ਵਜੋਂ FORTRAN ਵਿੱਚ ਟਿੱਪਣੀ ਕਰਨ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਸੀ)। ਅਸੀਂ ਮੇਨਲੈਂਡ 'ਤੇ ਨੈੱਟਵਰਕ ਮਾਹਰਾਂ ਨੂੰ ਈਮੇਲ ਕੀਤੀ ਅਤੇ ਮਦਦ ਲਈ ਕਿਹਾ। ਬੇਸ਼ੱਕ, ਉਹ ਸਾਡੀਆਂ ਫਾਈਲਾਂ ਦੇ ਨਮੂਨੇ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਸਨ ਜੋ FTP ਰਾਹੀਂ ਟ੍ਰਾਂਸਫਰ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਸਨ... ਪਰ ਸਾਡੇ ਪੱਤਰ ਉਨ੍ਹਾਂ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚੇ। ਅੰਤ ਵਿੱਚ ਅਸੀਂ ਇੱਕ ਸਧਾਰਨ ਨਾਲ ਆਏ ਵਿਆਖਿਆਗੈਰ-ਤਬਾਦਲਾਯੋਗ ਫ਼ਾਈਲਾਂ ਕਿਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ। ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ :) [ਮੈਂ ਇੱਥੇ ਸਮੱਸਿਆ ਵਾਲੇ ਫੋਰਟਰਨ ਟਿੱਪਣੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਜੋੜਨ ਦੀ ਹਿੰਮਤ ਕਰਦਾ ਹਾਂ? ਸ਼ਾਇਦ ਇਸਦੀ ਕੀਮਤ ਨਹੀਂ ਹੈ!]

ਅੰਤ ਵਿੱਚ ਅਸੀਂ ਇਸਦਾ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋ ਗਏ। ਸਾਡੇ ਕੈਂਪਸ ਦੇ ਹਿੱਸੇ ਅਤੇ ਮੇਨਲੈਂਡ ਨੈਟਵਰਕ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਨਵਾਂ ਗੇਟਵੇ ਹਾਲ ਹੀ ਵਿੱਚ ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਸ ਵਿੱਚ ਉਹਨਾਂ ਪੈਕੇਟਾਂ ਨੂੰ ਸੰਚਾਰਿਤ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਮੁਸ਼ਕਲ ਸੀ ਜਿਸ ਵਿੱਚ ਵੱਡੇ ਅੱਖਰ C ਦੇ ਵਾਰ-ਵਾਰ ਬਿੱਟ ਹੁੰਦੇ ਸਨ! ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਪੈਕਟ ਸਾਰੇ ਗੇਟਵੇ ਸਰੋਤਾਂ ਨੂੰ ਲੈ ਸਕਦੇ ਹਨ ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਹੋਰ ਪੈਕੇਟਾਂ ਨੂੰ ਲੰਘਣ ਤੋਂ ਰੋਕ ਸਕਦੇ ਹਨ। ਅਸੀਂ ਗੇਟਵੇ ਨਿਰਮਾਤਾ ਨੂੰ ਸ਼ਿਕਾਇਤ ਕੀਤੀ... ਅਤੇ ਉਨ੍ਹਾਂ ਨੇ ਜਵਾਬ ਦਿੱਤਾ: “ਓ, ਹਾਂ, ਤੁਹਾਨੂੰ ਵਾਰ-ਵਾਰ C ਦੇ ਇੱਕ ਬੱਗ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਰਿਹਾ ਹੈ! ਅਸੀਂ ਉਸ ਬਾਰੇ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੇ ਹਾਂ।” ਅਸੀਂ ਅੰਤ ਵਿੱਚ ਕਿਸੇ ਹੋਰ ਨਿਰਮਾਤਾ ਤੋਂ ਇੱਕ ਨਵਾਂ ਗੇਟਵੇ ਖਰੀਦ ਕੇ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕੀਤਾ (ਪੂਰਵ ਦੇ ਬਚਾਅ ਵਿੱਚ, FORTRAN ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥਾ ਕੁਝ ਲਈ ਇੱਕ ਫਾਇਦਾ ਹੋ ਸਕਦਾ ਹੈ!)

ਮੁਸ਼ਕਲ ਸਮੇਂ

ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ, ਪੜਾਅ 40 ਕਲੀਨਿਕਲ ਅਜ਼ਮਾਇਸ਼ਾਂ ਦੇ ਖਰਚਿਆਂ ਨੂੰ ਘਟਾਉਣ ਲਈ ਪਰਲ ਵਿੱਚ ਇੱਕ ETL ਸਿਸਟਮ ਬਣਾਉਣ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹੋਏ, ਮੈਨੂੰ ਲਗਭਗ 000 ਤਾਰੀਖਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਦੀ ਲੋੜ ਸੀ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਦੋ ਟੈਸਟ ਪਾਸ ਨਹੀਂ ਕਰ ਸਕੇ। ਇਸ ਨੇ ਮੈਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪਰੇਸ਼ਾਨ ਨਹੀਂ ਕੀਤਾ ਕਿਉਂਕਿ ਇਹ ਤਾਰੀਖਾਂ ਕਲਾਇੰਟ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਡੇਟਾ ਤੋਂ ਲਈਆਂ ਗਈਆਂ ਸਨ ਜੋ ਅਕਸਰ, ਕੀ ਅਸੀਂ ਕਹੀਏ, ਹੈਰਾਨੀਜਨਕ ਸੀ. ਪਰ ਜਦੋਂ ਮੈਂ ਅਸਲ ਡੇਟਾ ਦੀ ਜਾਂਚ ਕੀਤੀ, ਤਾਂ ਪਤਾ ਲੱਗਿਆ ਕਿ ਇਹ ਮਿਤੀਆਂ 1 ਜਨਵਰੀ, 2011 ਅਤੇ 1 ਜਨਵਰੀ, 2007 ਸਨ। ਮੈਂ ਸੋਚਿਆ ਕਿ ਮੇਰੇ ਦੁਆਰਾ ਹੁਣੇ ਲਿਖੇ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਬੱਗ ਸ਼ਾਮਲ ਸੀ, ਪਰ ਇਹ ਪਤਾ ਲੱਗਿਆ ਕਿ ਇਹ ਪਹਿਲਾਂ ਹੀ 30 ਸਾਲ ਹੋ ਚੁੱਕਾ ਹੈ। ਪੁਰਾਣਾ ਇਹ ਸਾਫਟਵੇਅਰ ਈਕੋਸਿਸਟਮ ਤੋਂ ਅਣਜਾਣ ਲੋਕਾਂ ਲਈ ਰਹੱਸਮਈ ਲੱਗ ਸਕਦਾ ਹੈ। ਪੈਸੇ ਕਮਾਉਣ ਦੇ ਕਿਸੇ ਹੋਰ ਕੰਪਨੀ ਦੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਚੱਲ ਰਹੇ ਫੈਸਲੇ ਦੇ ਕਾਰਨ, ਮੇਰੇ ਕਲਾਇੰਟ ਨੇ ਮੈਨੂੰ ਇੱਕ ਬੱਗ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਭੁਗਤਾਨ ਕੀਤਾ ਜੋ ਇੱਕ ਕੰਪਨੀ ਨੇ ਦੁਰਘਟਨਾ ਦੁਆਰਾ ਅਤੇ ਦੂਜੀ ਨੇ ਜਾਣਬੁੱਝ ਕੇ ਪੇਸ਼ ਕੀਤਾ ਸੀ। ਤੁਹਾਡੇ ਲਈ ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਮੈਂ ਕਿਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਿਹਾ ਹਾਂ, ਮੈਨੂੰ ਉਸ ਕੰਪਨੀ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਜਿਸ ਨੇ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਜੋੜਿਆ ਜੋ ਬੱਗ ਬਣ ਗਈ, ਨਾਲ ਹੀ ਕੁਝ ਹੋਰ ਦਿਲਚਸਪ ਘਟਨਾਵਾਂ ਜਿਨ੍ਹਾਂ ਨੇ ਮੇਰੇ ਦੁਆਰਾ ਫਿਕਸ ਕੀਤੇ ਰਹੱਸਮਈ ਬੱਗ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਇਆ।

ਚੰਗੇ ਪੁਰਾਣੇ ਦਿਨਾਂ ਵਿੱਚ, ਐਪਲ ਕੰਪਿਊਟਰ ਕਦੇ-ਕਦਾਈਂ ਸਵੈ-ਇੱਛਾ ਨਾਲ ਆਪਣੀ ਮਿਤੀ 1 ਜਨਵਰੀ, 1904 ਨੂੰ ਰੀਸੈਟ ਕਰ ਦਿੰਦੇ ਸਨ। ਕਾਰਨ ਸਧਾਰਨ ਸੀ: ਇਸ ਨੇ ਤਾਰੀਖ ਅਤੇ ਸਮੇਂ ਦਾ ਧਿਆਨ ਰੱਖਣ ਲਈ ਬੈਟਰੀ ਦੁਆਰਾ ਸੰਚਾਲਿਤ "ਸਿਸਟਮ ਕਲਾਕ" ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਜਦੋਂ ਬੈਟਰੀ ਮਰ ਗਈ ਤਾਂ ਕੀ ਹੋਇਆ? ਕੰਪਿਊਟਰਾਂ ਨੇ ਇੱਕ ਯੁੱਗ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਹੀ ਸਕਿੰਟਾਂ ਦੀ ਗਿਣਤੀ ਦੁਆਰਾ ਤਾਰੀਖ ਨੂੰ ਟਰੈਕ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਯੁਗ ਦੁਆਰਾ ਸਾਡਾ ਮਤਲਬ ਅਸਲ ਤਾਰੀਖ ਦਾ ਹਵਾਲਾ ਸੀ, ਅਤੇ ਮੈਕਿੰਟੋਸ਼ਜ਼ ਲਈ ਇਹ 1 ਜਨਵਰੀ, 1904 ਸੀ। ਅਤੇ ਬੈਟਰੀ ਦੇ ਮਰਨ ਤੋਂ ਬਾਅਦ, ਮੌਜੂਦਾ ਮਿਤੀ ਨੂੰ ਨਿਰਧਾਰਤ ਮਿਤੀ 'ਤੇ ਰੀਸੈਟ ਕੀਤਾ ਗਿਆ ਸੀ। ਪਰ ਅਜਿਹਾ ਕਿਉਂ ਹੋਇਆ?

ਪਹਿਲਾਂ, ਐਪਲ ਅਸਲ ਤਾਰੀਖ ਤੋਂ ਸਕਿੰਟਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ 32 ਬਿਟਸ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਸੀ। ਇੱਕ ਬਿੱਟ ਦੋ ਮੁੱਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਸਟੋਰ ਕਰ ਸਕਦਾ ਹੈ - 1 ਜਾਂ 0. ਦੋ ਬਿੱਟ ਚਾਰ ਮੁੱਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਸਟੋਰ ਕਰ ਸਕਦੇ ਹਨ: 00, 01, 10, 11. ਤਿੰਨ ਬਿੱਟ - ਅੱਠ ਵਿੱਚੋਂ ਇੱਕ ਮੁੱਲ: 000, 001, 010, 011, 100 , 101, 110, 111, ਆਦਿ। ਅਤੇ 32 232 ਮੁੱਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਸਟੋਰ ਕਰ ਸਕਦਾ ਹੈ, ਯਾਨੀ 4 ਸਕਿੰਟ। ਐਪਲ ਦੀਆਂ ਤਾਰੀਖਾਂ ਲਈ, ਇਹ ਲਗਭਗ 294 ਸਾਲਾਂ ਦੇ ਬਰਾਬਰ ਹੈ, ਇਸਲਈ ਪੁਰਾਣੇ ਮੈਕ 967 ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਤਾਰੀਖਾਂ ਨੂੰ ਸੰਭਾਲ ਨਹੀਂ ਸਕਦੇ। ਅਤੇ ਜੇਕਰ ਸਿਸਟਮ ਦੀ ਬੈਟਰੀ ਮਰ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਯੁੱਗ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਮਿਤੀ 296 ਸਕਿੰਟਾਂ 'ਤੇ ਰੀਸੈਟ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ ਹਰ ਵਾਰ ਕੰਪਿਊਟਰ ਨੂੰ ਚਾਲੂ ਕਰਨ 'ਤੇ (ਜਾਂ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਨਵੀਂ ਬੈਟਰੀ ਨਹੀਂ ਖਰੀਦਦੇ) ਤਾਰੀਖ ਨੂੰ ਹੱਥੀਂ ਸੈੱਟ ਕਰਨਾ ਹੁੰਦਾ ਹੈ।

ਹਾਲਾਂਕਿ, ਐਪਲ ਦੇ ਯੁੱਗ ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਤਾਰੀਖਾਂ ਨੂੰ ਸਕਿੰਟਾਂ ਵਜੋਂ ਸਟੋਰ ਕਰਨ ਦੇ ਫੈਸਲੇ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਯੁੱਗ ਤੋਂ ਪਹਿਲਾਂ ਤਾਰੀਖਾਂ ਨੂੰ ਸੰਭਾਲ ਨਹੀਂ ਸਕਦੇ, ਜਿਸ ਦੇ ਦੂਰਗਾਮੀ ਨਤੀਜੇ ਸਨ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਦੇਖਾਂਗੇ। ਐਪਲ ਨੇ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਪੇਸ਼ ਕੀਤੀ, ਇੱਕ ਬੱਗ ਨਹੀਂ. ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ, ਇਸਦਾ ਮਤਲਬ ਇਹ ਸੀ ਕਿ ਮੈਕਿਨਟੋਸ਼ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ "ਮਲੇਨਿਅਮ ਬੱਗ" (ਜੋ ਕਿ ਬਹੁਤ ਸਾਰੀਆਂ ਮੈਕ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਾਰੇ ਨਹੀਂ ਕਿਹਾ ਜਾ ਸਕਦਾ ਸੀ ਜਿਨ੍ਹਾਂ ਦੀਆਂ ਪਾਬੰਦੀਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਆਪਣੇ ਖੁਦ ਦੇ ਡੇਟ ਸਿਸਟਮ ਸਨ) ਤੋਂ ਬਚਾਅ ਸੀ।

ਲੰਗ ਜਾਓ. ਅਸੀਂ ਲੋਟਸ 1-2-3, IBM ਦੀ "ਕਾਤਲ ਐਪਲੀਕੇਸ਼ਨ" ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਿਸ ਨੇ PC ਕ੍ਰਾਂਤੀ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕੀਤੀ, ਹਾਲਾਂਕਿ ਐਪਲ ਕੰਪਿਊਟਰਾਂ ਵਿੱਚ VisiCalc ਸੀ, ਜਿਸ ਨੇ ਨਿੱਜੀ ਕੰਪਿਊਟਰ ਨੂੰ ਸਫ਼ਲ ਬਣਾਇਆ। ਨਿਰਪੱਖਤਾ ਵਿੱਚ, ਜੇਕਰ 1-2-3 ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦਾ, ਤਾਂ PC ਸ਼ਾਇਦ ਹੀ ਬੰਦ ਹੋ ਜਾਂਦੇ, ਅਤੇ ਨਿੱਜੀ ਕੰਪਿਊਟਰਾਂ ਦਾ ਇਤਿਹਾਸ ਬਹੁਤ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਵਿਕਸਤ ਹੋ ਸਕਦਾ ਸੀ। ਲੋਟਸ 1-2-3 ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ 1900 ਨੂੰ ਲੀਪ ਸਾਲ ਮੰਨਿਆ ਗਿਆ। ਜਦੋਂ ਮਾਈਕ੍ਰੋਸਾੱਫਟ ਨੇ ਆਪਣੀ ਪਹਿਲੀ ਸਪ੍ਰੈਡਸ਼ੀਟ, ਮਲਟੀਪਲੈਨ ਜਾਰੀ ਕੀਤੀ, ਤਾਂ ਇਸਨੇ ਮਾਰਕੀਟ ਦਾ ਇੱਕ ਛੋਟਾ ਹਿੱਸਾ ਹਾਸਲ ਕੀਤਾ। ਅਤੇ ਜਦੋਂ ਉਹਨਾਂ ਨੇ ਐਕਸਲ ਪ੍ਰੋਜੈਕਟ ਲਾਂਚ ਕੀਤਾ, ਤਾਂ ਉਹਨਾਂ ਨੇ ਨਾ ਸਿਰਫ ਲੋਟਸ 1-2-3 ਤੋਂ ਕਤਾਰ ਅਤੇ ਕਾਲਮ ਨਾਮਕਰਨ ਸਕੀਮ ਦੀ ਨਕਲ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਸਗੋਂ 1900 ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਇੱਕ ਲੀਪ ਸਾਲ ਵਜੋਂ ਮੰਨ ਕੇ ਬੱਗ ਅਨੁਕੂਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। ਇਹ ਸਮੱਸਿਆ ਅੱਜ ਵੀ ਮੌਜੂਦ ਹੈ। ਭਾਵ, 1-2-3 ਵਿੱਚ ਇਹ ਇੱਕ ਬੱਗ ਸੀ, ਪਰ ਐਕਸਲ ਵਿੱਚ ਇਹ ਇੱਕ ਸੁਚੇਤ ਫੈਸਲਾ ਸੀ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਸੀ ਕਿ ਸਾਰੇ 1-2-3 ਉਪਭੋਗਤਾ ਡੇਟਾ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਆਪਣੀਆਂ ਟੇਬਲਾਂ ਨੂੰ ਐਕਸਲ ਵਿੱਚ ਆਯਾਤ ਕਰ ਸਕਦੇ ਹਨ, ਭਾਵੇਂ ਇਹ ਗਲਤ ਸੀ।

ਪਰ ਇੱਕ ਹੋਰ ਸਮੱਸਿਆ ਸੀ. ਪਹਿਲਾਂ, ਮਾਈਕਰੋਸਾਫਟ ਨੇ ਮੈਕਿਨਟੋਸ਼ ਲਈ ਐਕਸਲ ਜਾਰੀ ਕੀਤਾ, ਜੋ ਕਿ 1 ਜਨਵਰੀ, 1904 ਤੋਂ ਪਹਿਲਾਂ ਦੀਆਂ ਤਾਰੀਖਾਂ ਨੂੰ ਨਹੀਂ ਪਛਾਣਦਾ ਸੀ। ਅਤੇ ਐਕਸਲ ਵਿੱਚ, 1 ਜਨਵਰੀ, 1900 ਨੂੰ ਯੁੱਗ ਦੀ ਸ਼ੁਰੂਆਤ ਮੰਨਿਆ ਜਾਂਦਾ ਸੀ। ਇਸ ਲਈ, ਡਿਵੈਲਪਰਾਂ ਨੇ ਇੱਕ ਤਬਦੀਲੀ ਕੀਤੀ ਤਾਂ ਜੋ ਉਹਨਾਂ ਦੇ ਪ੍ਰੋਗਰਾਮ ਨੇ ਯੁੱਗ ਦੀ ਕਿਸਮ ਨੂੰ ਪਛਾਣਿਆ ਅਤੇ ਲੋੜੀਂਦੇ ਯੁੱਗ ਦੇ ਅਨੁਸਾਰ ਆਪਣੇ ਅੰਦਰ ਡਾਟਾ ਸਟੋਰ ਕੀਤਾ। ਮਾਈਕ੍ਰੋਸਾੱਫਟ ਨੇ ਇਸ ਬਾਰੇ ਇੱਕ ਵਿਆਖਿਆਤਮਕ ਲੇਖ ਵੀ ਲਿਖਿਆ। ਅਤੇ ਇਸ ਫੈਸਲੇ ਨੇ ਮੇਰੇ ਬੱਗ ਦੀ ਅਗਵਾਈ ਕੀਤੀ.

ਮੇਰੇ ETL ਸਿਸਟਮ ਨੇ ਉਹਨਾਂ ਗਾਹਕਾਂ ਤੋਂ ਐਕਸਲ ਸਪ੍ਰੈਡਸ਼ੀਟਾਂ ਪ੍ਰਾਪਤ ਕੀਤੀਆਂ ਜੋ ਵਿੰਡੋਜ਼ 'ਤੇ ਬਣਾਈਆਂ ਗਈਆਂ ਸਨ, ਪਰ ਮੈਕ 'ਤੇ ਵੀ ਬਣਾਈਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਇਸ ਲਈ, ਸਾਰਣੀ ਵਿੱਚ ਯੁੱਗ ਦੀ ਸ਼ੁਰੂਆਤ ਜਾਂ ਤਾਂ 1 ਜਨਵਰੀ, 1900, ਜਾਂ 1 ਜਨਵਰੀ, 1904 ਹੋ ਸਕਦੀ ਹੈ। ਕਿਵੇਂ ਪਤਾ ਕਰਨਾ ਹੈ? ਐਕਸਲ ਫਾਈਲ ਫੌਰਮੈਟ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਦਿਖਾਉਂਦਾ ਹੈ, ਪਰ ਜੋ ਪਾਰਸਰ ਮੈਂ ਵਰਤਿਆ ਸੀ, ਉਸ ਨੇ ਇਹ ਨਹੀਂ ਦਿਖਾਇਆ (ਹੁਣ ਇਹ ਕਰਦਾ ਹੈ), ਅਤੇ ਇਹ ਮੰਨ ਲਿਆ ਕਿ ਤੁਸੀਂ ਇੱਕ ਖਾਸ ਸਾਰਣੀ ਲਈ ਯੁੱਗ ਨੂੰ ਜਾਣਦੇ ਹੋ। ਮੈਂ ਸ਼ਾਇਦ ਐਕਸਲ ਬਾਈਨਰੀ ਫਾਰਮੈਟ ਨੂੰ ਸਮਝਣ ਅਤੇ ਪਾਰਸਰ ਲੇਖਕ ਨੂੰ ਇੱਕ ਪੈਚ ਭੇਜਣ ਵਿੱਚ ਵਧੇਰੇ ਸਮਾਂ ਬਿਤਾ ਸਕਦਾ ਸੀ, ਪਰ ਮੇਰੇ ਕੋਲ ਕਲਾਇੰਟ ਲਈ ਹੋਰ ਬਹੁਤ ਕੁਝ ਸੀ, ਇਸਲਈ ਮੈਂ ਯੁੱਗ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਜਲਦੀ ਹੀ ਇੱਕ ਖੋਜੀ ਲਿਖਿਆ। ਉਹ ਸਧਾਰਨ ਸੀ.

ਐਕਸਲ ਵਿੱਚ, ਮਿਤੀ 5 ਜੁਲਾਈ, 1998 ਨੂੰ "07-05-98" (ਬੇਕਾਰ ਅਮਰੀਕੀ ਪ੍ਰਣਾਲੀ), "ਜੁਲਾਈ 5, 98", "5 ਜੁਲਾਈ, 1998", "5-ਜੁਲਾਈ-98" ਜਾਂ ਫਾਰਮੈਟ ਵਿੱਚ ਦਰਸਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਕੁਝ ਹੋਰ ਫਾਰਮੈਟ। ਇੱਕ ਹੋਰ ਬੇਕਾਰ ਫਾਰਮੈਟ (ਵਿਅੰਗਾਤਮਕ ਤੌਰ 'ਤੇ, ਮੇਰੇ ਐਕਸਲ ਦੇ ਸੰਸਕਰਣ ਦੁਆਰਾ ਪੇਸ਼ ਕੀਤੇ ਗਏ ਫਾਰਮੈਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ISO 8601 ਸੀ)। ਹਾਲਾਂਕਿ, ਸਾਰਣੀ ਦੇ ਅੰਦਰ, ਗੈਰ-ਫਾਰਮੈਟ ਕੀਤੀ ਮਿਤੀ ਨੂੰ ਜਾਂ ਤਾਂ epoch-35981 ਲਈ "1900" ਜਾਂ epoch-34519 ਲਈ "1904" ਵਜੋਂ ਸਟੋਰ ਕੀਤਾ ਗਿਆ ਸੀ (ਸੰਖਿਆ ਯੁੱਗ ਤੋਂ ਬਾਅਦ ਦੇ ਦਿਨਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ)। ਮੈਂ ਫਾਰਮੈਟ ਕੀਤੀ ਮਿਤੀ ਤੋਂ ਸਾਲ ਨੂੰ ਐਕਸਟਰੈਕਟ ਕਰਨ ਲਈ ਇੱਕ ਸਧਾਰਨ ਪਾਰਸਰ ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਅਤੇ ਫਿਰ ਗੈਰ-ਫਾਰਮੈਟ ਕੀਤੀ ਮਿਤੀ ਤੋਂ ਸਾਲ ਕੱਢਣ ਲਈ ਐਕਸਲ ਪਾਰਸਰ ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਜੇਕਰ ਦੋਵੇਂ ਮੁੱਲ 4 ਸਾਲਾਂ ਤੋਂ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਮੈਨੂੰ ਪਤਾ ਸੀ ਕਿ ਮੈਂ epoch-1904 ਦੇ ਨਾਲ ਇੱਕ ਸਿਸਟਮ ਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਸੀ।

ਮੈਂ ਸਿਰਫ਼ ਫਾਰਮੈਟ ਕੀਤੀਆਂ ਤਾਰੀਖਾਂ ਦੀ ਵਰਤੋਂ ਕਿਉਂ ਨਹੀਂ ਕੀਤੀ? ਕਿਉਂਕਿ 5 ਜੁਲਾਈ, 1998 ਨੂੰ "ਜੁਲਾਈ, 98" ਦੇ ਤੌਰ 'ਤੇ ਫਾਰਮੈਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਮਹੀਨੇ ਦੇ ਗੁੰਮ ਹੋਏ ਦਿਨ ਹਨ। ਸਾਨੂੰ ਬਹੁਤ ਸਾਰੀਆਂ ਕੰਪਨੀਆਂ ਤੋਂ ਟੇਬਲ ਪ੍ਰਾਪਤ ਹੋਏ ਜਿਨ੍ਹਾਂ ਨੇ ਉਹਨਾਂ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਬਣਾਇਆ ਹੈ ਕਿ ਤਾਰੀਖਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣਾ ਸਾਡੇ (ਇਸ ਕੇਸ ਵਿੱਚ, ਮੇਰੇ) ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜੇਕਰ ਐਕਸਲ ਇਸ ਨੂੰ ਸਹੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਸਾਨੂੰ ਵੀ ਅਜਿਹਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ!

ਉਸੇ ਸਮੇਂ ਮੈਨੂੰ 39082 ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ। ਮੈਂ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਣਾ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਲੋਟਸ 1-2-3 ਨੇ 1900 ਨੂੰ ਲੀਪ ਸਾਲ ਮੰਨਿਆ, ਅਤੇ ਇਸਨੂੰ Excel ਵਿੱਚ ਵਫ਼ਾਦਾਰੀ ਨਾਲ ਦੁਹਰਾਇਆ ਗਿਆ। ਅਤੇ ਕਿਉਂਕਿ ਇਸਨੇ ਸਾਲ 1900 ਵਿੱਚ ਇੱਕ ਦਿਨ ਜੋੜਿਆ ਹੈ, ਉਸੇ ਦਿਨ ਲਈ ਕਈ ਤਾਰੀਖ ਗਣਨਾ ਫੰਕਸ਼ਨ ਗਲਤ ਹੋ ਸਕਦੇ ਹਨ। ਯਾਨੀ, 39082 1 ਜਨਵਰੀ, 2011 (Macs ਉੱਤੇ) ਜਾਂ 31 ਦਸੰਬਰ, 2006 (ਵਿੰਡੋਜ਼ ਉੱਤੇ) ਹੋ ਸਕਦਾ ਹੈ। ਜੇ ਮੇਰੇ "ਸਾਲ ਪਾਰਸਰ" ਨੇ ਫਾਰਮੈਟ ਕੀਤੇ ਮੁੱਲ ਤੋਂ ਸਾਲ 2011 ਕੱਢਿਆ, ਤਾਂ ਸਭ ਕੁਝ ਠੀਕ ਹੈ। ਪਰ ਕਿਉਂਕਿ ਐਕਸਲ ਪਾਰਸਰ ਇਹ ਨਹੀਂ ਜਾਣਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਯੁੱਗ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ, ਇਹ ਡਿਫਾਲਟ ਈਪੋਕ-1900, ਸਾਲ 2006 ਨੂੰ ਵਾਪਸ ਕਰ ਰਿਹਾ ਹੈ। ਮੇਰੀ ਅਰਜ਼ੀ ਨੇ ਦੇਖਿਆ ਕਿ ਅੰਤਰ 5 ਸਾਲ ਸੀ, ਇਸਨੂੰ ਇੱਕ ਗਲਤੀ ਮੰਨਿਆ, ਇਸਨੂੰ ਲੌਗ ਕੀਤਾ, ਅਤੇ ਇੱਕ ਗੈਰ-ਫਾਰਮੈਟਿਡ ਮੁੱਲ ਵਾਪਸ ਕੀਤਾ।

ਇਸਦੇ ਆਲੇ ਦੁਆਲੇ ਜਾਣ ਲਈ, ਮੈਂ ਇਹ ਲਿਖਿਆ (ਸੂਡੋਕੋਡ):

diff = formatted_year - parsed_year
if 0 == diff
    assume 1900 date system
if 4 == diff
    assume 1904 date system
if 5 == diff and month is December and day is 31
    assume 1904 date system

ਅਤੇ ਫਿਰ ਸਾਰੀਆਂ 40 ਤਾਰੀਖਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਪਾਰਸ ਕੀਤਾ ਗਿਆ ਸੀ।

ਵੱਡੇ ਪ੍ਰਿੰਟ ਨੌਕਰੀਆਂ ਦੇ ਮੱਧ ਵਿੱਚ

1980 ਦੇ ਦਹਾਕੇ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ, ਮੇਰੇ ਪਿਤਾ ਨੇ ਸਟੋਰੇਜ਼ ਟੈਕਨਾਲੋਜੀ ਵਿੱਚ ਕੰਮ ਕੀਤਾ, ਜੋ ਹੁਣ ਬੰਦ ਹੋ ਚੁੱਕੀ ਡਿਵੀਜ਼ਨ ਹੈ ਜਿਸ ਨੇ ਹਾਈ-ਸਪੀਡ ਟੇਪ ਫੀਡਿੰਗ ਲਈ ਟੇਪ ਡਰਾਈਵਾਂ ਅਤੇ ਨਿਊਮੈਟਿਕ ਸਿਸਟਮ ਬਣਾਏ।

ਉਹਨਾਂ ਨੇ ਡਰਾਈਵਾਂ ਨੂੰ ਮੁੜ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਤਾਂ ਕਿ ਉਹਨਾਂ ਕੋਲ ਇੱਕ ਕੇਂਦਰੀ "A" ਡਰਾਈਵ ਸੱਤ "B" ਡਰਾਈਵਾਂ ਨਾਲ ਜੁੜੀ ਹੋਵੇ, ਅਤੇ "A" ਡਰਾਈਵ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਵਾਲੀ RAM ਵਿੱਚ ਛੋਟੀ OS ਸਾਰੀਆਂ "B" ਡਰਾਈਵਾਂ ਨੂੰ ਰੀਡ ਅਤੇ ਰਾਈਟ ਓਪਰੇਸ਼ਨ ਸੌਂਪ ਸਕੇ।

ਹਰ ਵਾਰ ਜਦੋਂ ਡਰਾਈਵ “A” ਸ਼ੁਰੂ ਕੀਤੀ ਜਾਂਦੀ ਸੀ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਇਸਦੀ ਮੈਮੋਰੀ ਵਿੱਚ ਲੋਡ ਕਰਨ ਲਈ “A” ਨਾਲ ਜੁੜੀ ਪੈਰੀਫਿਰਲ ਡਰਾਈਵ ਵਿੱਚ ਇੱਕ ਫਲਾਪੀ ਡਿਸਕ ਪਾਉਣੀ ਜ਼ਰੂਰੀ ਸੀ। ਇਹ ਬਹੁਤ ਹੀ ਮੁੱਢਲਾ ਸੀ: ਕੰਪਿਊਟਿੰਗ ਪਾਵਰ ਇੱਕ 8-ਬਿੱਟ ਮਾਈਕ੍ਰੋਕੰਟਰੋਲਰ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਗਈ ਸੀ।

ਅਜਿਹੇ ਸਾਜ਼ੋ-ਸਾਮਾਨ ਲਈ ਟੀਚਾ ਦਰਸ਼ਕ ਬਹੁਤ ਵੱਡੇ ਡੇਟਾ ਵੇਅਰਹਾਊਸਾਂ ਵਾਲੀਆਂ ਕੰਪਨੀਆਂ ਸਨ - ਬੈਂਕਾਂ, ਪ੍ਰਚੂਨ ਚੇਨਾਂ, ਆਦਿ - ਜਿਨ੍ਹਾਂ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਐਡਰੈੱਸ ਲੇਬਲ ਜਾਂ ਬੈਂਕ ਸਟੇਟਮੈਂਟਾਂ ਨੂੰ ਛਾਪਣ ਦੀ ਲੋੜ ਸੀ।

ਇੱਕ ਗਾਹਕ ਨੂੰ ਇੱਕ ਸਮੱਸਿਆ ਸੀ. ਇੱਕ ਪ੍ਰਿੰਟ ਜੌਬ ਦੇ ਮੱਧ ਵਿੱਚ, ਇੱਕ ਖਾਸ ਡਰਾਈਵ "A" ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਸਕਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਪੂਰਾ ਕੰਮ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਡਰਾਈਵ ਦੀ ਕਾਰਵਾਈ ਨੂੰ ਬਹਾਲ ਕਰਨ ਲਈ, ਸਟਾਫ ਨੂੰ ਸਭ ਕੁਝ ਰੀਬੂਟ ਕਰਨਾ ਪਿਆ। ਅਤੇ ਜੇ ਇਹ ਛੇ ਘੰਟਿਆਂ ਦੇ ਕੰਮ ਦੇ ਮੱਧ ਵਿੱਚ ਵਾਪਰਿਆ, ਤਾਂ ਕੰਪਿਊਟਰ ਦਾ ਬਹੁਤ ਮਹਿੰਗਾ ਸਮਾਂ ਗੁਆ ਦਿੱਤਾ ਗਿਆ ਅਤੇ ਪੂਰੇ ਓਪਰੇਸ਼ਨ ਦੀ ਸਮਾਂ-ਸਾਰਣੀ ਵਿੱਚ ਵਿਘਨ ਪੈ ਗਿਆ।

ਸਟੋਰੇਜ ਟੈਕਨੋਲੋਜੀਜ਼ ਤੋਂ ਟੈਕਨੀਸ਼ੀਅਨ ਭੇਜੇ ਗਏ ਸਨ। ਪਰ ਉਹਨਾਂ ਦੀਆਂ ਸਭ ਤੋਂ ਵਧੀਆ ਕੋਸ਼ਿਸ਼ਾਂ ਦੇ ਬਾਵਜੂਦ, ਉਹ ਟੈਸਟ ਦੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਬੱਗ ਨੂੰ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥ ਸਨ: ਇਹ ਵੱਡੇ ਪ੍ਰਿੰਟ ਜੌਬਾਂ ਦੇ ਮੱਧ ਵਿੱਚ ਵਾਪਰਦਾ ਜਾਪਦਾ ਸੀ। ਸਮੱਸਿਆ ਹਾਰਡਵੇਅਰ ਦੀ ਨਹੀਂ ਸੀ, ਉਹਨਾਂ ਨੇ ਉਹ ਸਭ ਕੁਝ ਬਦਲ ਦਿੱਤਾ ਜੋ ਉਹ ਕਰ ਸਕਦੇ ਸਨ: RAM, ਮਾਈਕਰੋਕੰਟਰੋਲਰ, ਫਲਾਪੀ ਡਰਾਈਵ, ਟੇਪ ਡਰਾਈਵ ਦਾ ਹਰ ਸਮਝਿਆ ਜਾਣ ਵਾਲਾ ਹਿੱਸਾ - ਸਮੱਸਿਆ ਬਣੀ ਰਹੀ।

ਫਿਰ ਤਕਨੀਸ਼ੀਅਨਾਂ ਨੇ ਹੈੱਡਕੁਆਰਟਰ ਬੁਲਾਇਆ ਅਤੇ ਐਕਸਪਰਟ ਨੂੰ ਬੁਲਾਇਆ।

ਮਾਹਰ ਨੇ ਕੁਰਸੀ ਅਤੇ ਕੌਫੀ ਦਾ ਕੱਪ ਫੜਿਆ, ਕੰਪਿਊਟਰ ਰੂਮ ਵਿਚ ਬੈਠ ਗਿਆ—ਉਨ੍ਹਾਂ ਦਿਨਾਂ ਵਿਚ ਕੰਪਿਊਟਰਾਂ ਨੂੰ ਸਮਰਪਿਤ ਕਮਰੇ ਸਨ—ਅਤੇ ਦੇਖਿਆ ਗਿਆ ਜਦੋਂ ਸਟਾਫ ਇਕ ਵੱਡੀ ਪ੍ਰਿੰਟ ਜੌਬ ਦੀ ਕਤਾਰ ਵਿਚ ਖੜ੍ਹਾ ਸੀ। ਮਾਹਰ ਇੱਕ ਅਸਫਲਤਾ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਸੀ - ਅਤੇ ਇਹ ਹੋਇਆ. ਹਰ ਕਿਸੇ ਨੇ ਐਕਸਪਰਟ ਵੱਲ ਦੇਖਿਆ, ਪਰ ਉਸ ਨੂੰ ਕੁਝ ਪਤਾ ਨਹੀਂ ਸੀ ਕਿ ਅਜਿਹਾ ਕਿਉਂ ਹੋਇਆ। ਇਸ ਲਈ ਉਸਨੇ ਕੰਮ ਨੂੰ ਦੁਬਾਰਾ ਕਤਾਰ ਵਿੱਚ ਲਗਾਉਣ ਦਾ ਆਦੇਸ਼ ਦਿੱਤਾ, ਅਤੇ ਸਾਰਾ ਸਟਾਫ ਅਤੇ ਟੈਕਨੀਸ਼ੀਅਨ ਕੰਮ 'ਤੇ ਵਾਪਸ ਆ ਗਏ।

ਮਾਹਰ ਫਿਰ ਕੁਰਸੀ 'ਤੇ ਬੈਠ ਗਿਆ ਅਤੇ ਅਸਫਲਤਾ ਦਾ ਇੰਤਜ਼ਾਰ ਕਰਨ ਲੱਗਾ। ਲਗਭਗ ਛੇ ਘੰਟੇ ਬੀਤ ਗਏ ਅਤੇ ਅਸਫਲਤਾ ਆਈ. ਮਾਹਰ ਨੂੰ ਫਿਰ ਕੋਈ ਵਿਚਾਰ ਨਹੀਂ ਸੀ, ਸਿਵਾਏ ਇਸ ਦੇ ਕਿ ਸਭ ਕੁਝ ਲੋਕਾਂ ਨਾਲ ਭਰੇ ਕਮਰੇ ਵਿੱਚ ਵਾਪਰਿਆ। ਉਸਨੇ ਮਿਸ਼ਨ ਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਦਾ ਆਦੇਸ਼ ਦਿੱਤਾ, ਵਾਪਸ ਬੈਠ ਗਿਆ ਅਤੇ ਉਡੀਕ ਕੀਤੀ।

ਤੀਜੀ ਅਸਫਲਤਾ ਦੁਆਰਾ, ਮਾਹਰ ਨੇ ਕੁਝ ਦੇਖਿਆ. ਅਸਫਲਤਾ ਉਦੋਂ ਵਾਪਰੀ ਜਦੋਂ ਕਰਮਚਾਰੀਆਂ ਨੇ ਵਿਦੇਸ਼ੀ ਡਰਾਈਵ ਵਿੱਚ ਟੇਪਾਂ ਨੂੰ ਬਦਲਿਆ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸਫਲਤਾ ਉਦੋਂ ਵਾਪਰੀ ਜਦੋਂ ਇੱਕ ਕਰਮਚਾਰੀ ਫਰਸ਼ 'ਤੇ ਇੱਕ ਖਾਸ ਟਾਈਲ ਵਿੱਚੋਂ ਲੰਘਿਆ।

ਉੱਚਾ ਫਰਸ਼ 6 ਤੋਂ 8 ਇੰਚ ਦੀ ਉਚਾਈ 'ਤੇ ਵਿਛਾਈਆਂ ਗਈਆਂ ਐਲੂਮੀਨੀਅਮ ਟਾਈਲਾਂ ਦਾ ਬਣਿਆ ਹੋਇਆ ਸੀ। ਕੰਪਿਊਟਰਾਂ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਤਾਰਾਂ ਉੱਚੀ ਮੰਜ਼ਿਲ ਦੇ ਹੇਠਾਂ ਦੌੜਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਕਿਸੇ ਨੂੰ ਗਲਤੀ ਨਾਲ ਮਹੱਤਵਪੂਰਨ ਕੇਬਲ 'ਤੇ ਪੈਰ ਰੱਖਣ ਤੋਂ ਰੋਕਿਆ ਜਾ ਸਕੇ। ਮਲਬੇ ਨੂੰ ਉੱਚੇ ਫਰਸ਼ ਦੇ ਹੇਠਾਂ ਜਾਣ ਤੋਂ ਰੋਕਣ ਲਈ ਟਾਈਲਾਂ ਨੂੰ ਬਹੁਤ ਕੱਸ ਕੇ ਰੱਖਿਆ ਗਿਆ ਸੀ।

ਮਾਹਰ ਨੇ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਟਾਇਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿਗੜ ਗਈ ਸੀ। ਜਦੋਂ ਇੱਕ ਕਰਮਚਾਰੀ ਨੇ ਇਸਦੇ ਕੋਨੇ 'ਤੇ ਕਦਮ ਰੱਖਿਆ, ਤਾਂ ਟਾਇਲ ਦੇ ਕਿਨਾਰੇ ਨਾਲ ਲੱਗੀਆਂ ਟਾਈਲਾਂ ਦੇ ਵਿਰੁੱਧ ਰਗੜ ਗਏ। ਟਾਈਲਾਂ ਨੂੰ ਜੋੜਨ ਵਾਲੇ ਪਲਾਸਟਿਕ ਦੇ ਹਿੱਸੇ ਵੀ ਉਹਨਾਂ ਦੇ ਨਾਲ ਰਗੜ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਸਥਿਰ ਮਾਈਕ੍ਰੋਡਿਸਚਾਰਜ ਹੁੰਦੇ ਹਨ ਜੋ ਰੇਡੀਓ ਫ੍ਰੀਕੁਐਂਸੀ ਦਖਲਅੰਦਾਜ਼ੀ ਕਰਦੇ ਹਨ।

ਅੱਜ, RAM ਰੇਡੀਓ ਫ੍ਰੀਕੁਐਂਸੀ ਦਖਲ ਤੋਂ ਬਹੁਤ ਬਿਹਤਰ ਸੁਰੱਖਿਅਤ ਹੈ। ਪਰ ਉਨ੍ਹਾਂ ਸਾਲਾਂ ਵਿੱਚ ਅਜਿਹਾ ਨਹੀਂ ਸੀ। ਮਾਹਰ ਨੇ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਇਸ ਦਖਲਅੰਦਾਜ਼ੀ ਨੇ ਮੈਮੋਰੀ ਨੂੰ ਵਿਗਾੜ ਦਿੱਤਾ ਹੈ, ਅਤੇ ਇਸਦੇ ਨਾਲ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦਾ ਕੰਮ. ਉਸਨੇ ਸਹਾਇਤਾ ਸੇਵਾ ਨੂੰ ਬੁਲਾਇਆ, ਨਵੀਆਂ ਟਾਈਲਾਂ ਦਾ ਆਦੇਸ਼ ਦਿੱਤਾ, ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਸਥਾਪਿਤ ਕੀਤਾ, ਅਤੇ ਸਮੱਸਿਆ ਗਾਇਬ ਹੋ ਗਈ।

ਇਹ ਉੱਚੀ ਲਹਿਰ ਹੈ!

ਕਹਾਣੀ ਇੱਕ ਸਰਵਰ ਰੂਮ ਵਿੱਚ ਹੋਈ, ਪੋਰਟਸਮਾਊਥ (ਮੇਰੇ ਖਿਆਲ ਵਿੱਚ), ਡੌਕਸ ਖੇਤਰ ਵਿੱਚ ਇੱਕ ਦਫਤਰ ਦੀ ਚੌਥੀ ਜਾਂ ਪੰਜਵੀਂ ਮੰਜ਼ਿਲ 'ਤੇ.

ਇੱਕ ਦਿਨ ਮੁੱਖ ਡੇਟਾਬੇਸ ਵਾਲਾ ਯੂਨਿਕਸ ਸਰਵਰ ਕਰੈਸ਼ ਹੋ ਗਿਆ। ਉਨ੍ਹਾਂ ਨੇ ਉਸਨੂੰ ਮੁੜ ਚਾਲੂ ਕੀਤਾ, ਪਰ ਉਹ ਖੁਸ਼ੀ ਨਾਲ ਵਾਰ-ਵਾਰ ਡਿੱਗਦਾ ਰਿਹਾ। ਅਸੀਂ ਸਹਾਇਤਾ ਸੇਵਾ ਤੋਂ ਕਿਸੇ ਨੂੰ ਕਾਲ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।

ਸਹਿਯੋਗੀ ਵਿਅਕਤੀ... ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਉਸਦਾ ਨਾਮ ਮਾਰਕ ਸੀ, ਪਰ ਇਸ ਨਾਲ ਕੋਈ ਫ਼ਰਕ ਨਹੀਂ ਪੈਂਦਾ... ਮੈਨੂੰ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਮੈਂ ਉਸਨੂੰ ਜਾਣਦਾ ਹਾਂ। ਇਸ ਨਾਲ ਕੋਈ ਫ਼ਰਕ ਨਹੀਂ ਪੈਂਦਾ, ਅਸਲ ਵਿੱਚ। ਚਲੋ ਮਾਰਕ ਨਾਲ ਜੁੜੇ ਰਹੀਏ, ਠੀਕ ਹੈ? ਮਹਾਨ।

ਇਸ ਲਈ, ਕੁਝ ਘੰਟਿਆਂ ਬਾਅਦ ਮਾਰਕ ਆ ਗਿਆ (ਇਹ ਲੀਡਜ਼ ਤੋਂ ਪੋਰਟਸਮਾਊਥ ਤੱਕ ਲੰਬਾ ਰਸਤਾ ਨਹੀਂ ਹੈ, ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ), ਸਰਵਰ ਚਾਲੂ ਕੀਤਾ ਅਤੇ ਸਭ ਕੁਝ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਕੰਮ ਕੀਤਾ। ਆਮ ਡੈਨ ਸਪੋਰਟ, ਗਾਹਕ ਇਸ ਬਾਰੇ ਬਹੁਤ ਪਰੇਸ਼ਾਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਮਾਰਕ ਲੌਗ ਫਾਈਲਾਂ ਨੂੰ ਦੇਖਦਾ ਹੈ ਅਤੇ ਕੁਝ ਵੀ ਅਣਸੁਖਾਵਾਂ ਨਹੀਂ ਲੱਭਦਾ। ਇਸ ਲਈ ਮਾਰਕ ਰੇਲਗੱਡੀ 'ਤੇ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ (ਜਾਂ ਉਹ ਜਿਸ ਵੀ ਆਵਾਜਾਈ ਦੇ ਢੰਗ 'ਤੇ ਪਹੁੰਚਿਆ ਸੀ, ਉਹ ਸਭ ਲਈ ਇੱਕ ਲੰਗੜੀ ਗਾਂ ਹੋ ਸਕਦੀ ਸੀ ਜੋ ਮੈਂ ਜਾਣਦਾ ਹਾਂ... ਵੈਸੇ ਵੀ, ਇਸ ਨਾਲ ਕੋਈ ਫ਼ਰਕ ਨਹੀਂ ਪੈਂਦਾ, ਠੀਕ ਹੈ?) ਅਤੇ ਬਰਬਾਦ ਹੋ ਕੇ ਵਾਪਸ ਲੀਡਜ਼ ਵੱਲ ਜਾਂਦਾ ਹੈ। ਦਿਨ.

ਉਸੇ ਸ਼ਾਮ ਨੂੰ ਸਰਵਰ ਦੁਬਾਰਾ ਕਰੈਸ਼ ਹੋ ਗਿਆ। ਕਹਾਣੀ ਉਹੀ ਹੈ ... ਸਰਵਰ ਨਹੀਂ ਉੱਠਦਾ. ਮਾਰਕ ਰਿਮੋਟਲੀ ਮਦਦ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਪਰ ਕਲਾਇੰਟ ਸਰਵਰ ਨੂੰ ਚਾਲੂ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ।

ਇੱਕ ਹੋਰ ਰੇਲਗੱਡੀ, ਬੱਸ, ਨਿੰਬੂ ਮੇਰਿੰਗੂ ਜਾਂ ਕੋਈ ਹੋਰ ਬਕਵਾਸ, ਅਤੇ ਮਾਰਕ ਪੋਰਟਸਮਾਉਥ ਵਿੱਚ ਵਾਪਸ ਆ ਗਿਆ ਹੈ. ਦੇਖੋ, ਸਰਵਰ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਬੂਟ ਹੁੰਦਾ ਹੈ! ਚਮਤਕਾਰ। ਮਾਰਕ ਇਹ ਜਾਂਚ ਕਰਨ ਵਿੱਚ ਕਈ ਘੰਟੇ ਬਿਤਾਉਂਦਾ ਹੈ ਕਿ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਜਾਂ ਸੌਫਟਵੇਅਰ ਨਾਲ ਸਭ ਕੁਝ ਠੀਕ ਹੈ ਅਤੇ ਲੀਡਜ਼ ਲਈ ਰਵਾਨਾ ਹੁੰਦਾ ਹੈ।

ਦਿਨ ਦੇ ਅੱਧ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸਰਵਰ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ (ਇਸ ਨੂੰ ਆਸਾਨ ਬਣਾਓ!) ਇਸ ਵਾਰ ਸਰਵਰ ਨੂੰ ਬਦਲਣ ਲਈ ਹਾਰਡਵੇਅਰ ਸਹਿਯੋਗੀ ਲੋਕਾਂ ਨੂੰ ਲਿਆਉਣਾ ਜਾਇਜ਼ ਜਾਪਦਾ ਹੈ। ਪਰ ਨਹੀਂ, ਲਗਭਗ 10 ਘੰਟਿਆਂ ਬਾਅਦ ਇਹ ਵੀ ਡਿੱਗਦਾ ਹੈ.

ਕਈ ਦਿਨਾਂ ਤੱਕ ਸਥਿਤੀ ਆਪਣੇ ਆਪ ਨੂੰ ਦੁਹਰਾਉਂਦੀ ਰਹੀ। ਸਰਵਰ ਕੰਮ ਕਰਦਾ ਹੈ, ਲਗਭਗ 10 ਘੰਟਿਆਂ ਬਾਅਦ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅਗਲੇ 2 ਘੰਟਿਆਂ ਲਈ ਚਾਲੂ ਨਹੀਂ ਹੁੰਦਾ। ਉਨ੍ਹਾਂ ਨੇ ਕੂਲਿੰਗ, ਮੈਮੋਰੀ ਲੀਕ ਦੀ ਜਾਂਚ ਕੀਤੀ, ਉਨ੍ਹਾਂ ਨੇ ਸਭ ਕੁਝ ਚੈੱਕ ਕੀਤਾ, ਪਰ ਕੁਝ ਨਹੀਂ ਮਿਲਿਆ. ਫਿਰ ਕਰੈਸ਼ ਬੰਦ ਹੋ ਗਏ।

ਹਫ਼ਤਾ ਬੇਪਰਵਾਹ ਬੀਤਿਆ... ਹਰ ਕੋਈ ਖੁਸ਼ ਸੀ। ਖੁਸ਼ ਹੈ ਜਦੋਂ ਤੱਕ ਇਹ ਸਭ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ. ਤਸਵੀਰ ਉਹੀ ਹੈ। ਕੰਮ ਦੇ 10 ਘੰਟੇ, ਡਾਊਨਟਾਈਮ ਦੇ 2-3 ਘੰਟੇ...

ਅਤੇ ਫਿਰ ਕਿਸੇ ਨੇ (ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਨੇ ਮੈਨੂੰ ਦੱਸਿਆ ਕਿ ਇਸ ਵਿਅਕਤੀ ਦਾ ਆਈਟੀ ਨਾਲ ਕੋਈ ਲੈਣਾ-ਦੇਣਾ ਨਹੀਂ ਸੀ) ਨੇ ਕਿਹਾ:

"ਇਹ ਲਹਿਰ ਹੈ!"

ਵਿਸਮਿਕਤਾ ਖਾਲੀ ਨਜ਼ਰਾਂ ਨਾਲ ਮਿਲ ਗਈ ਸੀ, ਅਤੇ ਕਿਸੇ ਦਾ ਹੱਥ ਸ਼ਾਇਦ ਸੁਰੱਖਿਆ ਕਾਲ ਬਟਨ 'ਤੇ ਝਿਜਕਿਆ ਸੀ.

"ਇਹ ਲਹਿਰਾਂ ਨਾਲ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ।"

ਇਹ IT ਸਹਾਇਤਾ ਕਰਮਚਾਰੀਆਂ ਲਈ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਿਦੇਸ਼ੀ ਸੰਕਲਪ ਜਾਪਦਾ ਹੈ, ਜੋ ਕੌਫੀ ਲਈ ਬੈਠਣ ਵੇਲੇ ਟਾਇਡ ਈਅਰਬੁੱਕ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਸੰਭਾਵਨਾ ਨਹੀਂ ਰੱਖਦੇ. ਉਨ੍ਹਾਂ ਨੇ ਸਮਝਾਇਆ ਕਿ ਇਹ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਨਾਲ ਲਹਿਰ ਨਾਲ ਸਬੰਧਤ ਨਹੀਂ ਹੋ ਸਕਦਾ, ਕਿਉਂਕਿ ਸਰਵਰ ਇੱਕ ਹਫ਼ਤੇ ਤੋਂ ਬਿਨਾਂ ਅਸਫਲਤਾ ਦੇ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ।

"ਪਿਛਲੇ ਹਫ਼ਤੇ ਲਹਿਰਾਂ ਘੱਟ ਸਨ, ਪਰ ਇਸ ਹਫ਼ਤੇ ਇਹ ਵੱਧ ਹੈ।"

ਉਹਨਾਂ ਲਈ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਸ਼ਬਦਾਵਲੀ ਜਿਨ੍ਹਾਂ ਕੋਲ ਯਾਟ ਲਾਇਸੈਂਸ ਨਹੀਂ ਹੈ। ਲਹਿਰਾਂ ਚੰਦਰ ਚੱਕਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ। ਅਤੇ ਜਿਵੇਂ ਕਿ ਧਰਤੀ ਘੁੰਮਦੀ ਹੈ, ਹਰ 12,5 ਘੰਟਿਆਂ ਵਿੱਚ ਸੂਰਜ ਅਤੇ ਚੰਦਰਮਾ ਦੀ ਗਰੈਵੀਟੇਸ਼ਨਲ ਖਿੱਚ ਇੱਕ ਸਮੁੰਦਰੀ ਲਹਿਰ ਪੈਦਾ ਕਰਦੀ ਹੈ। 12,5-ਘੰਟੇ ਦੇ ਚੱਕਰ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਇੱਕ ਉੱਚੀ ਲਹਿਰ ਹੈ, ਚੱਕਰ ਦੇ ਮੱਧ ਵਿੱਚ ਇੱਕ ਐਬ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਇੱਕ ਉੱਚੀ ਲਹਿਰ ਹੈ। ਪਰ ਜਿਵੇਂ-ਜਿਵੇਂ ਚੰਦਰਮਾ ਦਾ ਚੱਕਰ ਬਦਲਦਾ ਹੈ, ਉਸੇ ਤਰ੍ਹਾਂ ਨੀਵੇਂ ਅਤੇ ਉੱਚੇ ਲਹਿਰਾਂ ਵਿੱਚ ਅੰਤਰ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਚੰਦਰਮਾ ਸੂਰਜ ਅਤੇ ਧਰਤੀ ਦੇ ਵਿਚਕਾਰ ਜਾਂ ਧਰਤੀ ਦੇ ਉਲਟ ਪਾਸੇ (ਪੂਰਾ ਚੰਦ ਜਾਂ ਕੋਈ ਚੰਦਰਮਾ ਨਹੀਂ) ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸਾਨੂੰ ਸਿਜ਼ੀਜਿਨ ਟਾਈਡਜ਼ ਮਿਲਦੀਆਂ ਹਨ - ਸਭ ਤੋਂ ਉੱਚੀਆਂ ਲਹਿਰਾਂ ਅਤੇ ਸਭ ਤੋਂ ਘੱਟ ਨੀਵੀਆਂ ਲਹਿਰਾਂ। ਅੱਧੇ ਚੰਦਰਮਾ 'ਤੇ ਸਾਨੂੰ ਚਤੁਰਭੁਜ ਲਹਿਰਾਂ ਮਿਲਦੀਆਂ ਹਨ - ਸਭ ਤੋਂ ਹੇਠਲੀਆਂ ਲਹਿਰਾਂ। ਦੋ ਅਤਿਅੰਤ ਵਿਚਕਾਰ ਅੰਤਰ ਬਹੁਤ ਘੱਟ ਜਾਂਦਾ ਹੈ. ਚੰਦਰ ਚੱਕਰ 28 ਦਿਨ ਰਹਿੰਦਾ ਹੈ: ਸਿਜ਼ੀਜੀਅਨ - ਚਤੁਰਭੁਜ - ਸਿਜ਼ੀਜੀਅਨ - ਚਤੁਰਭੁਜ।

ਜਦੋਂ ਤਕਨੀਸ਼ੀਅਨਾਂ ਨੂੰ ਸਮੁੰਦਰੀ ਜ਼ਹਾਜ਼ਾਂ ਦੇ ਤੱਤ ਬਾਰੇ ਦੱਸਿਆ ਗਿਆ ਸੀ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੇ ਤੁਰੰਤ ਸੋਚਿਆ ਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਪੁਲਿਸ ਨੂੰ ਬੁਲਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਅਤੇ ਕਾਫ਼ੀ ਲਾਜ਼ੀਕਲ. ਪਰ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਯਾਰ ਸਹੀ ਸੀ. ਦੋ ਹਫ਼ਤੇ ਪਹਿਲਾਂ, ਇੱਕ ਵਿਨਾਸ਼ਕਾਰੀ ਦਫਤਰ ਤੋਂ ਬਹੁਤ ਦੂਰ ਨਹੀਂ ਸੀ. ਹਰ ਵਾਰ ਜਦੋਂ ਲਹਿਰਾਂ ਨੇ ਇਸ ਨੂੰ ਇੱਕ ਨਿਸ਼ਚਿਤ ਉਚਾਈ ਤੱਕ ਵਧਾਇਆ, ਤਾਂ ਜਹਾਜ਼ ਦੀ ਰਾਡਾਰ ਪੋਸਟ ਸਰਵਰ ਰੂਮ ਫਲੋਰ ਦੇ ਪੱਧਰ 'ਤੇ ਖਤਮ ਹੋ ਗਈ। ਅਤੇ ਰਾਡਾਰ (ਜਾਂ ਇਲੈਕਟ੍ਰਾਨਿਕ ਯੁੱਧ ਸਾਜ਼ੋ-ਸਾਮਾਨ, ਜਾਂ ਕੁਝ ਹੋਰ ਫੌਜੀ ਖਿਡੌਣੇ) ਨੇ ਕੰਪਿਊਟਰਾਂ ਵਿੱਚ ਹਫੜਾ-ਦਫੜੀ ਮਚਾ ਦਿੱਤੀ।

ਰਾਕੇਟ ਲਈ ਫਲਾਈਟ ਮਿਸ਼ਨ

ਮੈਨੂੰ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ, ਕੰਪਾਈਲਰ ਅਤੇ ਭਾਸ਼ਾ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣਾਂ ਲਈ ਇੱਕ ਵਿਸ਼ਾਲ (ਲਗਭਗ 400 ਹਜ਼ਾਰ ਲਾਈਨਾਂ) ਰਾਕੇਟ ਲਾਂਚ ਕੰਟਰੋਲ ਅਤੇ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਪੋਰਟ ਕਰਨ ਦਾ ਕੰਮ ਸੌਂਪਿਆ ਗਿਆ ਸੀ। ਹੋਰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ, ਸੋਲਾਰਿਸ 2.5.1 ਤੋਂ ਸੋਲਾਰਿਸ 7 ਤੱਕ, ਅਤੇ ਐਡਾ 83 ਵਿੱਚ ਲਿਖੇ ਗਏ ਵਰਡਿਕਸ ਐਡਾ ਡਿਵੈਲਪਮੈਂਟ ਸਿਸਟਮ (VADS) ਤੋਂ, Ada 95 ਵਿੱਚ ਲਿਖੇ ਗਏ Rational Apex Ada ਸਿਸਟਮ ਤੱਕ। VADS ਨੂੰ ਤਰਕਸ਼ੀਲ ਦੁਆਰਾ ਖਰੀਦਿਆ ਗਿਆ ਸੀ, ਅਤੇ ਇਸਦਾ ਉਤਪਾਦ ਸੀ. ਅਪ੍ਰਚਲਿਤ, ਹਾਲਾਂਕਿ ਤਰਕਸ਼ੀਲ ਨੇ Apex ਕੰਪਾਈਲਰ ਵਿੱਚ ਤਬਦੀਲੀ ਨੂੰ ਸੌਖਾ ਬਣਾਉਣ ਲਈ VADS-ਵਿਸ਼ੇਸ਼ ਪੈਕੇਜਾਂ ਦੇ ਅਨੁਕੂਲ ਸੰਸਕਰਣਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ।

ਤਿੰਨ ਲੋਕਾਂ ਨੇ ਕੋਡ ਨੂੰ ਸਾਫ਼-ਸੁਥਰਾ ਕੰਪਾਇਲ ਕਰਨ ਵਿੱਚ ਮੇਰੀ ਮਦਦ ਕੀਤੀ। ਦੋ ਹਫ਼ਤੇ ਲੱਗ ਗਏ। ਅਤੇ ਫਿਰ ਮੈਂ ਸਿਸਟਮ ਨੂੰ ਕੰਮ ਕਰਨ ਲਈ ਆਪਣੇ ਆਪ ਕੰਮ ਕੀਤਾ. ਸੰਖੇਪ ਵਿੱਚ, ਇਹ ਇੱਕ ਸਾਫਟਵੇਅਰ ਸਿਸਟਮ ਦਾ ਸਭ ਤੋਂ ਭੈੜਾ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਲਾਗੂ ਕਰਨਾ ਸੀ ਜਿਸਦਾ ਮੈਂ ਸਾਹਮਣਾ ਕੀਤਾ ਸੀ, ਇਸਲਈ ਪੋਰਟ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਹੋਰ ਦੋ ਮਹੀਨੇ ਲੱਗ ਗਏ। ਸਿਸਟਮ ਨੂੰ ਫਿਰ ਟੈਸਟਿੰਗ ਲਈ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਿਸ ਵਿੱਚ ਕਈ ਹੋਰ ਮਹੀਨੇ ਲੱਗ ਗਏ। ਮੈਂ ਜਾਂਚ ਦੇ ਦੌਰਾਨ ਪਾਏ ਗਏ ਬੱਗਾਂ ਨੂੰ ਤੁਰੰਤ ਠੀਕ ਕੀਤਾ, ਪਰ ਉਹਨਾਂ ਦੀ ਗਿਣਤੀ ਤੇਜ਼ੀ ਨਾਲ ਘਟ ਗਈ (ਸਰੋਤ ਕੋਡ ਇੱਕ ਉਤਪਾਦਨ ਪ੍ਰਣਾਲੀ ਸੀ, ਇਸਲਈ ਇਸਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਕਾਫ਼ੀ ਭਰੋਸੇਮੰਦ ਸੀ, ਮੈਨੂੰ ਨਵੇਂ ਕੰਪਾਈਲਰ ਦੇ ਅਨੁਕੂਲਣ ਦੌਰਾਨ ਪੈਦਾ ਹੋਏ ਬੱਗਾਂ ਨੂੰ ਹਟਾਉਣਾ ਪਿਆ)। ਆਖਰਕਾਰ, ਜਦੋਂ ਸਭ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ ਜਿਵੇਂ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ, ਮੈਨੂੰ ਕਿਸੇ ਹੋਰ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੱਤਾ ਗਿਆ ਸੀ.

ਅਤੇ ਥੈਂਕਸਗਿਵਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਸ਼ੁੱਕਰਵਾਰ ਨੂੰ, ਫ਼ੋਨ ਦੀ ਘੰਟੀ ਵੱਜੀ.

ਰਾਕੇਟ ਲਾਂਚ ਲਗਭਗ ਤਿੰਨ ਹਫ਼ਤਿਆਂ ਵਿੱਚ ਟੈਸਟ ਕੀਤਾ ਜਾਣਾ ਸੀ, ਅਤੇ ਕਾਉਂਟਡਾਊਨ ਦੇ ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਟੈਸਟਾਂ ਦੌਰਾਨ, ਕਮਾਂਡਾਂ ਦੀ ਲੜੀ ਨੂੰ ਬਲੌਕ ਕੀਤਾ ਗਿਆ ਸੀ। ਅਸਲ ਜੀਵਨ ਵਿੱਚ, ਇਹ ਟੈਸਟ ਨੂੰ ਅਧੂਰਾ ਬਣਾ ਦੇਵੇਗਾ, ਅਤੇ ਜੇਕਰ ਇੰਜਣ ਸ਼ੁਰੂ ਹੋਣ ਦੇ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਰੁਕਾਵਟ ਆ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਸਹਾਇਕ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਕਈ ਅਟੱਲ ਕਾਰਵਾਈਆਂ ਹੋਣਗੀਆਂ, ਜਿਸ ਲਈ ਰਾਕੇਟ ਦੀ ਲੰਮੀ - ਅਤੇ ਮਹਿੰਗੀ - ਤਿਆਰੀ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਇਹ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਇਆ ਹੁੰਦਾ, ਪਰ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਸਮੇਂ ਅਤੇ ਬਹੁਤ ਸਾਰੇ, ਬਹੁਤ ਸਾਰੇ ਪੈਸੇ ਦੇ ਨੁਕਸਾਨ ਤੋਂ ਬਹੁਤ ਪਰੇਸ਼ਾਨ ਹੋਏ ਹੋਣਗੇ। ਕਿਸੇ ਨੂੰ ਤੁਹਾਨੂੰ ਇਹ ਨਾ ਦੱਸਣ ਦਿਓ ਕਿ ਡਿਪਾਰਟਮੈਂਟ ਆਫ਼ ਡਿਫੈਂਸ ਲਾਪਰਵਾਹੀ ਨਾਲ ਪੈਸਾ ਖਰਚ ਕਰਦਾ ਹੈ—ਮੈਂ ਕਦੇ ਵੀ ਕਿਸੇ ਕੰਟਰੈਕਟਿੰਗ ਮੈਨੇਜਰ ਨੂੰ ਨਹੀਂ ਮਿਲਿਆ ਜਿਸ ਨੇ ਸਮਾਂ-ਸਾਰਣੀ ਦੇ ਬਾਅਦ ਬਜਟ ਨੂੰ ਪਹਿਲਾਂ ਜਾਂ ਦੂਜਾ ਨਹੀਂ ਰੱਖਿਆ।

ਪਿਛਲੇ ਮਹੀਨਿਆਂ ਵਿੱਚ, ਇਹ ਕਾਉਂਟਡਾਊਨ ਚੁਣੌਤੀ ਸੈਂਕੜੇ ਵਾਰ ਕਈ ਰੂਪਾਂ ਵਿੱਚ ਚਲਾਈ ਗਈ ਸੀ, ਸਿਰਫ਼ ਕੁਝ ਮਾਮੂਲੀ ਹਿਚਕੀ ਦੇ ਨਾਲ। ਇਸ ਲਈ ਅਜਿਹਾ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਬਹੁਤ ਘੱਟ ਸੀ, ਪਰ ਇਸਦੇ ਨਤੀਜੇ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਸਨ। ਇਹਨਾਂ ਦੋਵਾਂ ਕਾਰਕਾਂ ਨੂੰ ਗੁਣਾ ਕਰੋ, ਅਤੇ ਤੁਸੀਂ ਸਮਝੋਗੇ ਕਿ ਖ਼ਬਰਾਂ ਨੇ ਮੇਰੇ ਅਤੇ ਦਰਜਨਾਂ ਇੰਜੀਨੀਅਰਾਂ ਅਤੇ ਪ੍ਰਬੰਧਕਾਂ ਲਈ ਇੱਕ ਬਰਬਾਦ ਛੁੱਟੀ ਵਾਲੇ ਹਫ਼ਤੇ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕੀਤੀ ਹੈ।

ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਪੋਰਟ ਕਰਨ ਵਾਲੇ ਵਿਅਕਤੀ ਵਜੋਂ ਮੇਰੇ ਵੱਲ ਧਿਆਨ ਦਿੱਤਾ ਗਿਆ ਸੀ.

ਜਿਵੇਂ ਕਿ ਜ਼ਿਆਦਾਤਰ ਸੁਰੱਖਿਆ-ਨਾਜ਼ੁਕ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਨਾਲ, ਬਹੁਤ ਸਾਰੇ ਮਾਪਦੰਡ ਲੌਗ ਕੀਤੇ ਗਏ ਸਨ, ਇਸਲਈ ਸਿਸਟਮ ਦੇ ਕਰੈਸ਼ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਲਾਗੂ ਕੀਤੇ ਗਏ ਕੋਡ ਦੀਆਂ ਕੁਝ ਲਾਈਨਾਂ ਦੀ ਪਛਾਣ ਕਰਨਾ ਕਾਫ਼ੀ ਆਸਾਨ ਸੀ। ਅਤੇ ਬੇਸ਼ੱਕ, ਉਹਨਾਂ ਬਾਰੇ ਕੁਝ ਵੀ ਅਸਾਧਾਰਨ ਨਹੀਂ ਸੀ; ਉਹੀ ਸਮੀਕਰਨ ਉਸੇ ਦੌੜ ਦੌਰਾਨ ਹਜ਼ਾਰਾਂ ਵਾਰ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਸਫਲਤਾਪੂਰਵਕ ਲਾਗੂ ਕੀਤੇ ਗਏ ਸਨ.

ਅਸੀਂ ਲੋਕਾਂ ਨੂੰ Apex ਤੋਂ ਤਰਕਸ਼ੀਲ ਵਿੱਚ ਬੁਲਾਇਆ ਕਿਉਂਕਿ ਉਹ ਉਹ ਸਨ ਜਿਨ੍ਹਾਂ ਨੇ ਕੰਪਾਈਲਰ ਵਿਕਸਤ ਕੀਤਾ ਸੀ ਅਤੇ ਉਹਨਾਂ ਦੁਆਰਾ ਵਿਕਸਤ ਕੀਤੇ ਗਏ ਕੁਝ ਰੂਟੀਨ ਨੂੰ ਸ਼ੱਕੀ ਕੋਡ ਵਿੱਚ ਬੁਲਾਇਆ ਗਿਆ ਸੀ। ਉਹ (ਅਤੇ ਬਾਕੀ ਸਾਰੇ) ਇਸ ਗੱਲ ਤੋਂ ਪ੍ਰਭਾਵਿਤ ਹੋਏ ਕਿ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਰਾਸ਼ਟਰੀ ਮਹੱਤਵ ਵਾਲੀ ਸਮੱਸਿਆ ਦੀ ਜੜ੍ਹ ਤੱਕ ਜਾਣ ਦੀ ਲੋੜ ਸੀ।

ਕਿਉਂਕਿ ਰਸਾਲਿਆਂ ਵਿੱਚ ਕੁਝ ਵੀ ਦਿਲਚਸਪ ਨਹੀਂ ਸੀ, ਅਸੀਂ ਇੱਕ ਸਥਾਨਕ ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਵਿੱਚ ਸਮੱਸਿਆ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। ਇਹ ਕੋਈ ਆਸਾਨ ਕੰਮ ਨਹੀਂ ਸੀ ਕਿਉਂਕਿ ਇਵੈਂਟ ਪ੍ਰਤੀ 1000 ਦੌੜਾਂ 'ਤੇ ਲਗਭਗ ਇਕ ਵਾਰ ਹੋਇਆ ਸੀ। ਇੱਕ ਸ਼ੱਕੀ ਕਾਰਨ ਇਹ ਸੀ ਕਿ ਇੱਕ ਵਿਕਰੇਤਾ ਦੁਆਰਾ ਵਿਕਸਤ ਮਿਊਟੇਕਸ ਫੰਕਸ਼ਨ (VADS ਮਾਈਗ੍ਰੇਸ਼ਨ ਪੈਕੇਜ ਦਾ ਹਿੱਸਾ) ਲਈ ਇੱਕ ਕਾਲ Unlock ਤਾਲਾ ਖੋਲ੍ਹਣ ਦੀ ਅਗਵਾਈ ਨਹੀਂ ਕੀਤੀ। ਪ੍ਰੋਸੈਸਿੰਗ ਥ੍ਰੈੱਡ ਜਿਸਨੂੰ ਫੰਕਸ਼ਨ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਦਿਲ ਦੀ ਧੜਕਣ ਦੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਸੰਸਾਧਿਤ ਕਰਦਾ ਹੈ, ਜੋ ਹਰ ਸਕਿੰਟ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਆਉਂਦੇ ਹਨ। ਅਸੀਂ ਬਾਰੰਬਾਰਤਾ ਨੂੰ 10 Hz ਤੱਕ ਵਧਾ ਦਿੱਤਾ, ਯਾਨੀ 10 ਵਾਰ ਪ੍ਰਤੀ ਸਕਿੰਟ, ਅਤੇ ਚੱਲਣਾ ਸ਼ੁਰੂ ਕੀਤਾ। ਲਗਭਗ ਇੱਕ ਘੰਟੇ ਬਾਅਦ ਸਿਸਟਮ ਨੇ ਆਪਣੇ ਆਪ ਨੂੰ ਲਾਕ ਕਰ ਦਿੱਤਾ. ਲੌਗ ਵਿੱਚ, ਅਸੀਂ ਦੇਖਿਆ ਕਿ ਰਿਕਾਰਡ ਕੀਤੇ ਸੁਨੇਹਿਆਂ ਦਾ ਕ੍ਰਮ ਫੇਲ੍ਹ ਹੋਏ ਟੈਸਟ ਦੌਰਾਨ ਉਹੀ ਸੀ। ਅਸੀਂ ਕਈ ਹੋਰ ਦੌੜਾਂ ਬਣਾਈਆਂ, ਸਿਸਟਮ ਨੂੰ ਸ਼ੁਰੂਆਤ ਤੋਂ 45-90 ਮਿੰਟਾਂ ਬਾਅਦ ਲਗਾਤਾਰ ਬਲੌਕ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਹਰ ਵਾਰ ਲੌਗ ਵਿੱਚ ਉਹੀ ਰੂਟ ਹੁੰਦਾ ਸੀ। ਭਾਵੇਂ ਅਸੀਂ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਵੱਖਰੇ ਕੋਡ ਚਲਾ ਰਹੇ ਸੀ - ਸੰਦੇਸ਼ ਦੀ ਬਾਰੰਬਾਰਤਾ ਵੱਖਰੀ ਸੀ - ਸਿਸਟਮ ਦਾ ਵਿਵਹਾਰ ਇੱਕੋ ਜਿਹਾ ਸੀ, ਇਸਲਈ ਸਾਨੂੰ ਭਰੋਸਾ ਸੀ ਕਿ ਇਹ ਲੋਡ ਦ੍ਰਿਸ਼ ਉਸੇ ਸਮੱਸਿਆ ਦਾ ਕਾਰਨ ਬਣ ਰਿਹਾ ਸੀ।

ਹੁਣ ਸਾਨੂੰ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਸਮੀਕਰਨਾਂ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਬਲੌਕਿੰਗ ਕਿੱਥੇ ਹੋਈ ਸੀ।

ਸਿਸਟਮ ਦੇ ਇਸ ਲਾਗੂਕਰਨ ਨੇ Ada ਟਾਸਕ ਸਿਸਟਮ ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਅਤੇ ਇਸਦੀ ਅਵਿਸ਼ਵਾਸ਼ਯੋਗ ਮਾੜੀ ਵਰਤੋਂ ਕੀਤੀ। Ada ਵਿੱਚ ਟਾਸਕ ਇੱਕ ਉੱਚ-ਪੱਧਰੀ ਸਮਕਾਲੀ ਤੌਰ 'ਤੇ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਕੰਸਟਰੱਕਟ ਹਨ, ਜੋ ਕਿ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੇ ਥਰਿੱਡਸ ਵਰਗਾ ਹੈ, ਸਿਰਫ ਭਾਸ਼ਾ ਵਿੱਚ ਹੀ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਜਦੋਂ ਦੋ ਕਾਰਜਾਂ ਨੂੰ ਸੰਚਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਉਹ "ਇੱਕ ਮੁਲਾਕਾਤ ਸੈਟ ਕਰਦੇ ਹਨ", ਲੋੜੀਂਦੇ ਡੇਟਾ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਅਤੇ ਫਿਰ ਮੁਲਾਕਾਤ ਨੂੰ ਰੋਕਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਦੇ ਸੁਤੰਤਰ ਕਾਰਜਾਂ 'ਤੇ ਵਾਪਸ ਆਉਂਦੇ ਹਨ। ਹਾਲਾਂਕਿ, ਸਿਸਟਮ ਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਸੀ. ਇੱਕ ਟਾਰਗੇਟ ਟਾਸਕ ਦੇ ਮਿਲਣ ਤੋਂ ਬਾਅਦ, ਉਹ ਟਾਰਗੇਟ ਟਾਸਕ ਇੱਕ ਹੋਰ ਟਾਸਕ ਦੇ ਨਾਲ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਜੋ ਫਿਰ ਇੱਕ ਤੀਜੇ ਟਾਸਕ ਨਾਲ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਉਦੋਂ ਤੱਕ ਜਦੋਂ ਤੱਕ ਕੁਝ ਪ੍ਰਕਿਰਿਆ ਪੂਰੀ ਨਹੀਂ ਹੋ ਜਾਂਦੀ। ਇਸ ਤੋਂ ਬਾਅਦ, ਇਹ ਸਾਰੀਆਂ ਮੁਲਾਕਾਤਾਂ ਪੂਰੀਆਂ ਹੋ ਗਈਆਂ ਅਤੇ ਹਰ ਕੰਮ ਨੂੰ ਆਪਣੇ ਅਮਲ ਵਿਚ ਵਾਪਸ ਆਉਣਾ ਪਿਆ। ਭਾਵ, ਅਸੀਂ ਦੁਨੀਆ ਦੇ ਸਭ ਤੋਂ ਮਹਿੰਗੇ ਫੰਕਸ਼ਨ ਕਾਲ ਸਿਸਟਮ ਨਾਲ ਨਜਿੱਠ ਰਹੇ ਸੀ, ਜਿਸ ਨੇ ਪੂਰੀ "ਮਲਟੀਟਾਸਕਿੰਗ" ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਰੋਕ ਦਿੱਤਾ ਜਦੋਂ ਇਹ ਇਨਪੁਟ ਡੇਟਾ ਦੇ ਕੁਝ ਹਿੱਸੇ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਸੀ। ਅਤੇ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਸਿਰਫ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਨਹੀਂ ਹੋਈਆਂ ਕਿਉਂਕਿ ਥ੍ਰਰੂਪੁਟ ਬਹੁਤ ਘੱਟ ਸੀ।

ਮੈਂ ਇਸ ਕਾਰਜ ਵਿਧੀ ਦਾ ਵਰਣਨ ਕੀਤਾ ਹੈ ਕਿਉਂਕਿ ਜਦੋਂ ਇੱਕ ਮੁਲਾਕਾਤ ਦੀ ਬੇਨਤੀ ਕੀਤੀ ਗਈ ਸੀ ਜਾਂ ਪੂਰਾ ਹੋਣ ਦੀ ਉਮੀਦ ਕੀਤੀ ਗਈ ਸੀ, ਤਾਂ ਇੱਕ "ਟਾਸਕ ਸਵਿੱਚ" ਹੋ ਸਕਦਾ ਹੈ। ਭਾਵ, ਪ੍ਰੋਸੈਸਰ ਕਿਸੇ ਹੋਰ ਕੰਮ ਦੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਚਲਾਉਣ ਲਈ ਤਿਆਰ ਹੈ। ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਜਦੋਂ ਇੱਕ ਕੰਮ ਦੂਜੇ ਕੰਮ ਨਾਲ ਮਿਲਣ ਲਈ ਤਿਆਰ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰਾ ਕੰਮ ਚਲਾਉਣਾ ਸ਼ੁਰੂ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਨਿਯੰਤਰਣ ਪਹਿਲੀ ਮੁਲਾਕਾਤ ਵਿੱਚ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਹੋਰ ਘਟਨਾਵਾਂ ਵਾਪਰ ਸਕਦੀਆਂ ਹਨ ਜੋ ਕੰਮ ਨੂੰ ਬਦਲਣ ਦਾ ਕਾਰਨ ਬਣਦੀਆਂ ਹਨ; ਅਜਿਹੀ ਇੱਕ ਘਟਨਾ ਇੱਕ ਸਿਸਟਮ ਫੰਕਸ਼ਨ ਲਈ ਇੱਕ ਕਾਲ ਹੈ, ਜਿਵੇਂ ਕਿ ਇੱਕ mutex ਨੂੰ ਛਾਪਣਾ ਜਾਂ ਚਲਾਉਣਾ।

ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਕੋਡ ਦੀ ਕਿਹੜੀ ਲਾਈਨ ਸਮੱਸਿਆ ਦਾ ਕਾਰਨ ਬਣ ਰਹੀ ਸੀ, ਮੈਨੂੰ ਇੱਕ ਟਾਸਕ ਸਵਿੱਚ ਨੂੰ ਟਰਿੱਗਰ ਕੀਤੇ ਬਿਨਾਂ ਸਟੇਟਮੈਂਟਾਂ ਦੇ ਕ੍ਰਮ ਦੁਆਰਾ ਪ੍ਰਗਤੀ ਨੂੰ ਰਿਕਾਰਡ ਕਰਨ ਦਾ ਇੱਕ ਤਰੀਕਾ ਲੱਭਣ ਦੀ ਲੋੜ ਸੀ, ਜੋ ਇੱਕ ਕਰੈਸ਼ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਸੀ। ਇਸ ਲਈ ਮੈਂ ਫਾਇਦਾ ਨਹੀਂ ਉਠਾ ਸਕਿਆ Put_Line()I/O ਕਾਰਵਾਈਆਂ ਕਰਨ ਤੋਂ ਬਚਣ ਲਈ। ਮੈਂ ਇੱਕ ਕਾਊਂਟਰ ਵੇਰੀਏਬਲ ਜਾਂ ਕੁਝ ਸਮਾਨ ਸੈੱਟ ਕਰ ਸਕਦਾ ਹਾਂ, ਪਰ ਜੇਕਰ ਮੈਂ ਇਸਨੂੰ ਸਕ੍ਰੀਨ 'ਤੇ ਪ੍ਰਦਰਸ਼ਿਤ ਨਹੀਂ ਕਰ ਸਕਦਾ ਤਾਂ ਮੈਂ ਇਸਦਾ ਮੁੱਲ ਕਿਵੇਂ ਦੇਖ ਸਕਦਾ ਹਾਂ?

ਨਾਲ ਹੀ, ਲੌਗ ਦੀ ਜਾਂਚ ਕਰਦੇ ਸਮੇਂ, ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ, ਦਿਲ ਦੀ ਧੜਕਣ ਦੇ ਸੁਨੇਹਿਆਂ ਦੀ ਪ੍ਰੋਸੈਸਿੰਗ ਵਿੱਚ ਫ੍ਰੀਜ਼ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਜਿਸ ਨੇ ਪ੍ਰਕਿਰਿਆ ਦੇ ਸਾਰੇ I/O ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਬਲੌਕ ਕੀਤਾ ਅਤੇ ਹੋਰ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਕੀਤੇ ਜਾਣ ਤੋਂ ਰੋਕਿਆ, ਹੋਰ ਸੁਤੰਤਰ ਕਾਰਜਾਂ ਨੂੰ ਚਲਾਇਆ ਜਾਣਾ ਜਾਰੀ ਰਿਹਾ। ਭਾਵ, ਕੰਮ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਲੌਕ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ, ਸਿਰਫ ਕਾਰਜਾਂ ਦੀ ਇੱਕ (ਨਾਜ਼ੁਕ) ਲੜੀ.

ਇਹ ਬਲਾਕਿੰਗ ਸਮੀਕਰਨ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਲਈ ਲੋੜੀਂਦਾ ਸੁਰਾਗ ਸੀ।

ਮੈਂ ਇੱਕ Ada ਪੈਕੇਜ ਬਣਾਇਆ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਟਾਸਕ, ਇੱਕ ਗਿਣਿਆ ਗਿਆ ਕਿਸਮ, ਅਤੇ ਉਸ ਕਿਸਮ ਦਾ ਇੱਕ ਗਲੋਬਲ ਵੇਰੀਏਬਲ ਹੈ। ਅਣਗਿਣਤ ਸ਼ਬਦਾਵਲੀ ਸਮੱਸਿਆ ਵਾਲੇ ਕ੍ਰਮ ਦੇ ਖਾਸ ਸਮੀਕਰਨਾਂ ਨਾਲ ਬੰਨ੍ਹੇ ਹੋਏ ਸਨ (ਉਦਾਹਰਨ ਲਈ. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), ਅਤੇ ਫਿਰ ਇਸ ਵਿੱਚ ਅਸਾਈਨਮੈਂਟ ਸਮੀਕਰਨ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਹਨ ਜੋ ਇੱਕ ਗਲੋਬਲ ਵੇਰੀਏਬਲ ਲਈ ਅਨੁਸਾਰੀ ਗਣਨਾ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ। ਕਿਉਂਕਿ ਇਸ ਸਭ ਦੇ ਆਬਜੈਕਟ ਕੋਡ ਨੇ ਮੈਮੋਰੀ ਵਿੱਚ ਇੱਕ ਸਥਿਰਤਾ ਨੂੰ ਸਟੋਰ ਕੀਤਾ ਹੈ, ਇਸ ਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਟਾਸਕ ਸਵਿਚਿੰਗ ਬਹੁਤ ਅਸੰਭਵ ਸੀ। ਅਸੀਂ ਮੁੱਖ ਤੌਰ 'ਤੇ ਸਮੀਕਰਨਾਂ ਬਾਰੇ ਸ਼ੱਕੀ ਸੀ ਜੋ ਕਾਰਜ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹਨ, ਕਿਉਂਕਿ ਬਲਾਕਿੰਗ ਕਾਰਜ ਨੂੰ ਵਾਪਸ ਬਦਲਣ ਵੇਲੇ ਵਾਪਸ ਜਾਣ ਦੀ ਬਜਾਏ ਐਗਜ਼ੀਕਿਊਸ਼ਨ 'ਤੇ ਆਈ ਹੈ (ਕਈ ਕਾਰਨਾਂ ਕਰਕੇ)।

ਟਰੈਕਿੰਗ ਟਾਸਕ ਸਿਰਫ਼ ਇੱਕ ਲੂਪ ਵਿੱਚ ਚੱਲਦਾ ਹੈ ਅਤੇ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਇਹ ਦੇਖਣ ਲਈ ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਗਲੋਬਲ ਵੇਰੀਏਬਲ ਦਾ ਮੁੱਲ ਬਦਲ ਗਿਆ ਹੈ। ਹਰੇਕ ਤਬਦੀਲੀ ਦੇ ਨਾਲ, ਮੁੱਲ ਨੂੰ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਫਿਰ ਇੱਕ ਛੋਟਾ ਇੰਤਜ਼ਾਰ ਅਤੇ ਇੱਕ ਨਵਾਂ ਚੈੱਕ। ਮੈਂ ਫਾਈਲ ਵਿੱਚ ਵੇਰੀਏਬਲ ਲਿਖਿਆ ਹੈ ਕਿਉਂਕਿ ਟਾਸਕ ਨੂੰ ਉਦੋਂ ਹੀ ਚਲਾਇਆ ਗਿਆ ਸੀ ਜਦੋਂ ਸਿਸਟਮ ਨੇ ਇਸ ਨੂੰ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਲਈ ਚੁਣਿਆ ਸੀ ਜਦੋਂ ਸਮੱਸਿਆ ਵਾਲੇ ਖੇਤਰ ਵਿੱਚ ਟਾਸਕ ਨੂੰ ਬਦਲਦੇ ਹੋਏ. ਇਸ ਟਾਸਕ ਵਿੱਚ ਜੋ ਵੀ ਹੋਇਆ ਉਹ ਹੋਰ, ਗੈਰ-ਸੰਬੰਧਿਤ ਬਲੌਕ ਕੀਤੇ ਕੰਮਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰੇਗਾ।

ਇਹ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਸੀ ਕਿ ਜਦੋਂ ਸਿਸਟਮ ਸਮੱਸਿਆ ਵਾਲੇ ਕੋਡ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਬਿੰਦੂ 'ਤੇ ਪਹੁੰਚ ਗਿਆ ਸੀ, ਤਾਂ ਗਲੋਬਲ ਵੇਰੀਏਬਲ ਨੂੰ ਰੀਸੈਟ ਕੀਤਾ ਜਾਵੇਗਾ ਜਦੋਂ ਹਰੇਕ ਅਗਲੇ ਸਮੀਕਰਨ 'ਤੇ ਜਾਣਾ ਹੋਵੇਗਾ। ਫਿਰ ਕੁਝ ਅਜਿਹਾ ਹੋਵੇਗਾ ਜੋ ਟਾਸਕ ਨੂੰ ਸਵਿਚ ਕਰਨ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ, ਅਤੇ ਕਿਉਂਕਿ ਇਸਦੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਫ੍ਰੀਕੁਐਂਸੀ (10 Hz) ਮਾਨੀਟਰਿੰਗ ਟਾਸਕ ਨਾਲੋਂ ਘੱਟ ਹੈ, ਮਾਨੀਟਰ ਗਲੋਬਲ ਵੇਰੀਏਬਲ ਦੇ ਮੁੱਲ ਨੂੰ ਕੈਪਚਰ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਲਿਖ ਸਕਦਾ ਹੈ। ਇੱਕ ਆਮ ਸਥਿਤੀ ਵਿੱਚ, ਮੈਂ ਗਿਣਤੀਆਂ ਦੇ ਇੱਕ ਸਬਸੈੱਟ ਦਾ ਦੁਹਰਾਇਆ ਜਾਣ ਵਾਲਾ ਕ੍ਰਮ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹਾਂ: ਟਾਸਕ ਸਵਿੱਚ ਦੇ ਸਮੇਂ ਵੇਰੀਏਬਲ ਦੇ ਆਖਰੀ ਮੁੱਲ। ਲਟਕਣ 'ਤੇ, ਗਲੋਬਲ ਵੇਰੀਏਬਲ ਨੂੰ ਹੁਣ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਲਿਖਿਆ ਗਿਆ ਆਖਰੀ ਮੁੱਲ ਇਹ ਦਰਸਾਏਗਾ ਕਿ ਕਿਹੜਾ ਸਮੀਕਰਨ ਪੂਰਾ ਨਹੀਂ ਹੋਇਆ।

ਮੈਂ ਟਰੈਕਿੰਗ ਨਾਲ ਕੋਡ ਚਲਾਇਆ. ਉਹ ਜੰਮ ਗਿਆ। ਅਤੇ ਨਿਗਰਾਨੀ ਨੇ ਘੜੀ ਦੇ ਕੰਮ ਵਾਂਗ ਕੰਮ ਕੀਤਾ.

ਲੌਗ ਵਿੱਚ ਸੰਭਾਵਿਤ ਕ੍ਰਮ ਸ਼ਾਮਲ ਹੈ, ਜਿਸਨੂੰ ਇੱਕ ਮੁੱਲ ਦੁਆਰਾ ਰੋਕਿਆ ਗਿਆ ਸੀ ਜੋ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਇੱਕ ਮਿਊਟੈਕਸ ਨੂੰ ਕਾਲ ਕੀਤਾ ਗਿਆ ਸੀ Unlock, ਅਤੇ ਕੰਮ ਪੂਰਾ ਨਹੀਂ ਹੋਇਆ ਹੈ - ਜਿਵੇਂ ਕਿ ਹਜ਼ਾਰਾਂ ਪਿਛਲੀਆਂ ਕਾਲਾਂ ਨਾਲ ਹੁੰਦਾ ਹੈ।

ਸਿਖਰ ਇੰਜੀਨੀਅਰ ਇਸ ਸਮੇਂ ਆਪਣੇ ਕੋਡ ਦਾ ਬੁਖ਼ਾਰ ਨਾਲ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰ ਰਹੇ ਸਨ ਅਤੇ ਉਨ੍ਹਾਂ ਨੇ ਮਿਊਟੇਕਸ ਵਿੱਚ ਇੱਕ ਜਗ੍ਹਾ ਲੱਭੀ ਜਿੱਥੇ ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਇੱਕ ਲਾਕ ਹੋ ਸਕਦਾ ਹੈ। ਪਰ ਇਸਦੀ ਸੰਭਾਵਨਾ ਬਹੁਤ ਘੱਟ ਸੀ, ਕਿਉਂਕਿ ਇੱਕ ਨਿਸ਼ਚਤ ਸਮੇਂ 'ਤੇ ਵਾਪਰਨ ਵਾਲੀਆਂ ਘਟਨਾਵਾਂ ਦਾ ਸਿਰਫ ਇੱਕ ਨਿਸ਼ਚਤ ਕ੍ਰਮ ਬਲਾਕਿੰਗ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ। ਮਰਫੀ ਦਾ ਕਾਨੂੰਨ, ਦੋਸਤੋ, ਇਹ ਮਰਫੀ ਦਾ ਕਾਨੂੰਨ ਹੈ।

ਮੈਨੂੰ ਲੋੜੀਂਦੇ ਕੋਡ ਦੇ ਟੁਕੜੇ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ, ਮੈਂ ਉਸ ਟੁਕੜੇ ਤੱਕ ਮਿਊਟੈਕਸ ਐਕਸੈਸ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਲਈ ਇੱਕ ਛੋਟੇ ਮੂਲ Ada mutex ਪੈਕੇਜ ਨਾਲ mutex ਫੰਕਸ਼ਨ ਕਾਲਾਂ (OS mutex ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੇ ਸਿਖਰ 'ਤੇ ਬਣਾਇਆ) ਨੂੰ ਬਦਲ ਦਿੱਤਾ।

ਮੈਂ ਇਸਨੂੰ ਕੋਡ ਵਿੱਚ ਪਾ ਦਿੱਤਾ ਅਤੇ ਟੈਸਟ ਚਲਾਇਆ। ਸੱਤ ਘੰਟੇ ਬਾਅਦ ਵੀ ਕੋਡ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ।

ਮੇਰਾ ਕੋਡ ਰੈਸ਼ਨਲ ਨੂੰ ਜਮ੍ਹਾ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਿੱਥੇ ਉਹਨਾਂ ਨੇ ਇਸਨੂੰ ਕੰਪਾਇਲ ਕੀਤਾ, ਇਸਨੂੰ ਵੱਖ ਕੀਤਾ, ਅਤੇ ਜਾਂਚ ਕੀਤੀ ਕਿ ਇਹ ਉਹੀ ਪਹੁੰਚ ਨਹੀਂ ਵਰਤਦਾ ਜੋ ਸਮੱਸਿਆ ਵਾਲੇ ਮਿਊਟੇਕਸ ਫੰਕਸ਼ਨਾਂ ਵਿੱਚ ਵਰਤਿਆ ਗਿਆ ਸੀ।

ਇਹ ਮੇਰੇ ਕਰੀਅਰ ਦੀ ਸਭ ਤੋਂ ਭੀੜ ਵਾਲੀ ਕੋਡ ਸਮੀਖਿਆ ਸੀ 🙂 ਮੇਰੇ ਨਾਲ ਕਮਰੇ ਵਿੱਚ ਲਗਭਗ ਦਸ ਇੰਜੀਨੀਅਰ ਅਤੇ ਪ੍ਰਬੰਧਕ ਸਨ, ਹੋਰ ਦਸ ਲੋਕ ਇੱਕ ਕਾਨਫਰੰਸ ਕਾਲ 'ਤੇ ਸਨ - ਅਤੇ ਉਨ੍ਹਾਂ ਸਾਰਿਆਂ ਨੇ ਕੋਡ ਦੀਆਂ ਲਗਭਗ 20 ਲਾਈਨਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ।

ਕੋਡ ਦੀ ਸਮੀਖਿਆ ਕੀਤੀ ਗਈ ਸੀ, ਨਵੀਆਂ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫਾਈਲਾਂ ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਰਸਮੀ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟਿੰਗ ਲਈ ਜਮ੍ਹਾ ਕੀਤਾ ਗਿਆ ਸੀ। ਕੁਝ ਹਫ਼ਤਿਆਂ ਬਾਅਦ, ਕਾਉਂਟਡਾਊਨ ਟੈਸਟ ਸਫਲ ਰਿਹਾ ਅਤੇ ਰਾਕੇਟ ਨੇ ਉਡਾਣ ਭਰੀ।

ਠੀਕ ਹੈ, ਇਹ ਸਭ ਠੀਕ ਅਤੇ ਵਧੀਆ ਹੈ, ਪਰ ਕਹਾਣੀ ਦਾ ਕੀ ਮਤਲਬ ਹੈ?

ਇਹ ਇੱਕ ਬਿਲਕੁਲ ਘਿਣਾਉਣੀ ਸਮੱਸਿਆ ਸੀ। ਕੋਡ ਦੀਆਂ ਸੈਂਕੜੇ ਹਜ਼ਾਰਾਂ ਲਾਈਨਾਂ, ਸਮਾਨਾਂਤਰ ਐਗਜ਼ੀਕਿਊਸ਼ਨ, ਇੱਕ ਦਰਜਨ ਤੋਂ ਵੱਧ ਇੰਟਰੈਕਟਿੰਗ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਖਰਾਬ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਮਾੜਾ ਲਾਗੂਕਰਨ, ਏਮਬੈਡਡ ਸਿਸਟਮਾਂ ਲਈ ਇੰਟਰਫੇਸ ਅਤੇ ਲੱਖਾਂ ਡਾਲਰ ਖਰਚ ਕੀਤੇ ਗਏ ਹਨ। ਕੋਈ ਦਬਾਅ ਨਹੀਂ, ਸਹੀ।

ਇਸ ਸਮੱਸਿਆ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ ਮੈਂ ਇਕੱਲਾ ਨਹੀਂ ਸੀ, ਹਾਲਾਂਕਿ ਜਦੋਂ ਮੈਂ ਪੋਰਟਿੰਗ ਕਰ ਰਿਹਾ ਸੀ ਤਾਂ ਮੈਂ ਸੁਰਖੀਆਂ ਵਿੱਚ ਸੀ। ਪਰ ਭਾਵੇਂ ਮੈਂ ਇਹ ਕੀਤਾ ਹੈ, ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਮੈਂ ਕੋਡ ਦੀਆਂ ਸਾਰੀਆਂ ਸੈਂਕੜੇ-ਹਜ਼ਾਰਾਂ ਲਾਈਨਾਂ ਨੂੰ ਸਮਝ ਲਿਆ ਹੈ, ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਹੈ। ਸਾਰੇ ਦੇਸ਼ ਦੇ ਇੰਜੀਨੀਅਰਾਂ ਦੁਆਰਾ ਕੋਡ ਅਤੇ ਲੌਗਸ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ ਜਦੋਂ ਉਹਨਾਂ ਨੇ ਮੈਨੂੰ ਅਸਫਲਤਾ ਦੇ ਕਾਰਨਾਂ ਬਾਰੇ ਉਹਨਾਂ ਦੀਆਂ ਧਾਰਨਾਵਾਂ ਬਾਰੇ ਦੱਸਿਆ, ਤਾਂ ਉਹਨਾਂ ਦਾ ਖੰਡਨ ਕਰਨ ਵਿੱਚ ਮੈਨੂੰ ਸਿਰਫ ਅੱਧਾ ਮਿੰਟ ਲੱਗਿਆ। ਅਤੇ ਜਦੋਂ ਮੈਨੂੰ ਸਿਧਾਂਤਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਕਿਹਾ ਗਿਆ ਸੀ, ਤਾਂ ਮੈਂ ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ ਨੂੰ ਦੇਵਾਂਗਾ, ਕਿਉਂਕਿ ਇਹ ਮੇਰੇ ਲਈ ਸਪੱਸ਼ਟ ਸੀ ਕਿ ਇਹ ਇੰਜੀਨੀਅਰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਜਾ ਰਹੇ ਸਨ। ਹੰਕਾਰੀ ਆਵਾਜ਼? ਹਾਂ, ਇਹ ਸੱਚ ਹੈ, ਪਰ ਮੈਂ ਕਿਸੇ ਹੋਰ ਕਾਰਨ ਕਰਕੇ ਅਨੁਮਾਨਾਂ ਅਤੇ ਬੇਨਤੀਆਂ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ।

ਮੈਂ ਸਮੱਸਿਆ ਦੀ ਪ੍ਰਕਿਰਤੀ ਨੂੰ ਸਮਝ ਗਿਆ. ਮੈਨੂੰ ਬਿਲਕੁਲ ਨਹੀਂ ਪਤਾ ਸੀ ਕਿ ਇਹ ਕਿੱਥੇ ਹੋ ਰਿਹਾ ਸੀ ਜਾਂ ਕਿਉਂ, ਪਰ ਮੈਨੂੰ ਪਤਾ ਸੀ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਸੀ।

ਸਾਲਾਂ ਦੌਰਾਨ, ਮੈਂ ਬਹੁਤ ਸਾਰਾ ਗਿਆਨ ਅਤੇ ਅਨੁਭਵ ਇਕੱਠਾ ਕੀਤਾ ਹੈ। ਮੈਂ ਅਡਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਪਾਇਨੀਅਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸੀ ਅਤੇ ਇਸਦੇ ਫਾਇਦਿਆਂ ਅਤੇ ਨੁਕਸਾਨਾਂ ਨੂੰ ਸਮਝਦਾ ਸੀ। ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਕਿ ਐਡਾ ਰਨਟਾਈਮ ਲਾਇਬ੍ਰੇਰੀਆਂ ਕੰਮਾਂ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦੀਆਂ ਹਨ ਅਤੇ ਸਮਾਨਾਂਤਰ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਨਾਲ ਨਜਿੱਠਦੀਆਂ ਹਨ। ਅਤੇ ਮੈਂ ਮੈਮੋਰੀ, ਰਜਿਸਟਰਾਂ ਅਤੇ ਅਸੈਂਬਲਰ ਦੇ ਪੱਧਰ 'ਤੇ ਘੱਟ-ਪੱਧਰੀ ਪ੍ਰੋਗਰਾਮਿੰਗ ਨੂੰ ਸਮਝਦਾ ਹਾਂ. ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਮੈਨੂੰ ਆਪਣੇ ਖੇਤਰ ਵਿੱਚ ਡੂੰਘਾ ਗਿਆਨ ਹੈ। ਅਤੇ ਮੈਂ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਸਮੱਸਿਆ ਦਾ ਕਾਰਨ ਲੱਭਣ ਲਈ ਕੀਤੀ। ਮੈਂ ਸਿਰਫ ਬੱਗ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਕੰਮ ਨਹੀਂ ਕੀਤਾ, ਮੈਂ ਸਮਝ ਗਿਆ ਕਿ ਇਸਨੂੰ ਇੱਕ ਬਹੁਤ ਹੀ ਸੰਵੇਦਨਸ਼ੀਲ ਰਨਟਾਈਮ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕਿਵੇਂ ਲੱਭਿਆ ਜਾਵੇ।

ਜ਼ਾਬਤੇ ਨਾਲ ਸੰਘਰਸ਼ ਦੀਆਂ ਅਜਿਹੀਆਂ ਕਹਾਣੀਆਂ ਉਨ੍ਹਾਂ ਲਈ ਬਹੁਤ ਦਿਲਚਸਪ ਨਹੀਂ ਹਨ ਜੋ ਅਜਿਹੇ ਸੰਘਰਸ਼ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਹਾਲਤਾਂ ਤੋਂ ਜਾਣੂ ਨਹੀਂ ਹਨ। ਪਰ ਇਹ ਕਹਾਣੀਆਂ ਸਾਨੂੰ ਇਹ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ ਕਿ ਅਸਲ ਵਿੱਚ ਮੁਸ਼ਕਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਇਹ ਕੀ ਕਰਦਾ ਹੈ।

ਸੱਚਮੁੱਚ ਸਖ਼ਤ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਪ੍ਰੋਗਰਾਮਰ ਤੋਂ ਵੱਧ ਹੋਣ ਦੀ ਲੋੜ ਹੈ। ਤੁਹਾਨੂੰ ਕੋਡ ਦੀ "ਕਿਸਮਤ" ਨੂੰ ਸਮਝਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਇਹ ਇਸਦੇ ਵਾਤਾਵਰਣ ਨਾਲ ਕਿਵੇਂ ਅੰਤਰਕਿਰਿਆ ਕਰਦਾ ਹੈ, ਅਤੇ ਵਾਤਾਵਰਣ ਖੁਦ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਅਤੇ ਫਿਰ ਤੁਹਾਡੇ ਕੋਲ ਆਪਣਾ ਬਰਬਾਦ ਛੁੱਟੀ ਵਾਲਾ ਹਫ਼ਤਾ ਹੋਵੇਗਾ।

ਜਾਰੀ ਰੱਖਣ ਲਈ

ਸਰੋਤ: www.habr.com