پروگرامرز ۽ انجنيئرن جا لوڪ داستان (حصو 1)

هي انٽرنيٽ تان ڪهاڻين جو هڪ انتخاب آهي ته ڪيئن ڪيڏا ڪڏهن ڪڏهن مڪمل طور تي ناقابل بيان ظاهر ٿيندا آهن. شايد توهان وٽ پڻ ٻڌائڻ لاء ڪجهه آهي.

وينلا آئس ڪريم کي ڪار جي الرجي

انجنيئرن لاءِ هڪ ڪهاڻي جيڪي سمجهن ٿا ته واضع هميشه جواب نه هوندو آهي، ۽ اهو معاملو ڪيترو به پري حقيقتون نظر اچن ٿيون، اهي اڃا تائين حقيقتون آهن. جنرل موٽر ڪارپوريشن جي Pontiac ڊويزن کي هڪ شڪايت ملي ٿي:

هي ٻيو ڀيرو آهي جو مان توهان ڏانهن لکي رهيو آهيان، ۽ مان توهان کي جواب نه ڏيڻ جو الزام نه ٿو ڏيان، ڇاڪاڻ ته اهو چريو لڳي ٿو. اسان جي خاندان ۾ هر رات رات جي ماني کانپوءِ آئس ڪريم کائڻ جو رواج آهي. آئس ڪريم جا قسم هر وقت تبديل ٿيندا رهن ٿا ۽ رات جي ماني کان پوءِ سڄو خاندان چونڊيندو آهي ته ڪهڙي آئس ڪريم خريد ڪري، جنهن کان پوءِ مان دڪان تي وڃان ٿو. مون تازو هڪ نئون Pontiac خريد ڪيو آهي ۽ ان وقت کان وٺي منهنجي آئس ڪريم حاصل ڪرڻ جو سفر هڪ مسئلو بڻجي ويو آهي. توهان ڏسندا، هر ڀيري آئون وينلا آئس ڪريم خريد ڪريان ٿو ۽ دڪان تان واپس اچان ٿو، ڪار شروع نه ٿيندي. جيڪڏهن مان ڪا ٻي آئس ڪريم آڻيان ته ڪار بغير ڪنهن پريشاني جي شروع ٿي. مان هڪ سنجيده سوال پڇڻ چاهيان ٿو، چاهي اهو ڪيترو به بيوقوف هجي: ”پونٽياڪ جي باري ۾ اها ڪهڙي ڳالهه آهي جو اها شروع نه ٿي ٿئي جڏهن مان وينلا آئس ڪريم آڻيان ٿو، پر آساني سان شروع ٿي وڃي ٿي جڏهن مان آئس ڪريم جو ٻيو ذائقو آڻيان ٿو؟

جئين توهان تصور ڪري سگهو ٿا، ڊويزن صدر خط بابت شڪي هو. بهرحال، صرف صورت ۾، مون هڪ انجنيئر کي چيڪ ڪرڻ لاء موڪليو. هن کي حيرت ٿي ته هن جي ملاقات هڪ خوبصورت علائقي ۾ رهندڙ هڪ امير، پڙهيل لکيل ماڻهوءَ سان ٿي. رات جي ماني کان پوءِ فوراً ملڻ لاءِ راضي ٿيا ته جيئن ٻئي آئس ڪريم لاءِ دڪان تي وڃي سگهن. شام جو اها وينلا هئي، ۽ جڏهن اهي واپس ڪار ڏانهن ويا، اهو شروع نه ٿيندو.

انجنيئر شام جو ٽي وڳي آيو. پهريون ڀيرو آئس ڪريم چاکليٽ هئي. گاڏي شروع ٿي. ٻيو ڀيرو اتي اسٽرابيري آئس ڪريم هئي. گاڏي شروع ٿي. ٽئين شام جو هن وينلا وٺڻ لاءِ چيو. ڪار شروع نه ٿي.

عقلي طور تي، انجنيئر اهو مڃڻ کان انڪار ڪيو ته ڪار کي وينلا آئس ڪريم کان الرجي هئي. تنهن ڪري، مون ڪار جي مالڪ سان اتفاق ڪيو ته هو هن جا دورا جاري رکندو جيستائين هن مسئلي جو حل ڳولي. ۽ رستي ۾، هن نوٽس وٺڻ شروع ڪيو: هن سڄي معلومات لکي، ڏينهن جو وقت، پيٽرول جو قسم، اچڻ جو وقت ۽ دڪان مان واپسي وغيره.

انجنيئر جلد ئي محسوس ڪيو ته ڪار جي مالڪ وينلا آئس ڪريم خريد ڪرڻ ۾ گهٽ وقت گذاريو. ان جو سبب اسٽور ۾ سامان جي ترتيب هئي. وينلا آئس ڪريم تمام مشهور هئي ۽ اسٽور جي سامهون هڪ الڳ فريزر ۾ رکيل هئي ته جيئن ان کي ڳولڻ آسان بڻائي سگهجي. ۽ ٻيون سڀئي قسمون اسٽور جي پٺيءَ ۾ هيون، ۽ صحيح قسم ڳولڻ ۽ ادا ڪرڻ ۾ گهڻو وقت لڳي ويو.

هاڻي سوال انجنيئر لاءِ هو ته: جيڪڏهن انجڻ بند ٿيڻ کان گهٽ وقت گذري چڪو هو ته ڪار شروع ڇو نه ٿي؟ جيئن ته مسئلو وقت هو، وينلا آئس ڪريم نه، انجنيئر جلدي جواب مليو: اهو هڪ گيس تالا هو. اهو هر شام ٿيندو هو، پر جڏهن ڪار مالڪ وڌيڪ وقت آئس ڪريم ڳولڻ ۾ گذاريو، انجڻ ڪافي ٿڌي ۽ آساني سان شروع ٿي وئي. ۽ جڏهن انسان وينلا آئس ڪريم خريد ڪيو، انجڻ اڃا به گرم هئي ۽ گئس جي تالا کي ڦهلائڻ جو وقت نه هو.

اخلاقي: جيتوڻيڪ مڪمل طور تي چريو مسئلا ڪڏهن ڪڏهن حقيقي آهن.

حادثي Bandicoot

اهو تجربو ڪرڻ دردناڪ آهي. هڪ پروگرامر جي حيثيت ۾، توهان پنهنجي ڪوڊ کي پهريون، ٻيو، ٽيون ... ۽ ڪٿي ڏهه هزار هين جاء تي توهان ڪمپيلر کي الزام ڏيڻ جي عادت حاصل ڪندا آهيو. ۽ وڌيڪ ھيٺ ڏنل فهرست توھان اڳ ۾ ئي سامان تي الزام لڳايو.

هتي هارڊويئر بگ بابت منهنجي ڪهاڻي آهي.

راند Crash Bandicoot لاءِ، مون ميموري ڪارڊ تي لوڊ ۽ محفوظ ڪرڻ لاءِ ڪوڊ لکيو. اهڙي سمگ گيم ڊولپر لاءِ، اها پارڪ ۾ هلڻ وانگر هئي: مون سوچيو ته ڪم ۾ ڪيترائي ڏينهن لڳندا. بهرحال، مون ڇهن هفتن تائين ڪوڊ ڊيبگنگ ختم ڪيو. رستي ۾، مون ٻين مسئلن کي حل ڪيو، پر هر ڪجهه ڏينهن ۾ آئون ڪجهه ڪلاڪن لاء هن ڪوڊ ڏانهن موٽيو. اها اذيت هئي.

علامت هن طرح نظر آئي: جڏهن توهان راند جي موجوده راند کي بچايو ۽ ميموري ڪارڊ تائين رسائي ڪريو، هر شيء تقريبا هميشه ٺيڪ ٿي ويندي آهي ... پر ڪڏهن ڪڏهن پڙهڻ يا لکڻ جي آپريشن جو وقت بغير ڪنهن واضح سبب جي ڪري ٿو. هڪ مختصر رڪارڊنگ اڪثر ڪري ميموري ڪارڊ کي نقصان پهچائيندو آهي. جڏهن هڪ رانديگر بچائڻ جي ڪوشش ڪري ٿو، هو نه رڳو بچائڻ ۾ ناڪام ٿئي ٿو، پر نقشو پڻ تباهه ڪري ٿو. گندو.

ٿوري دير کان پوءِ، سوني ۾ اسان جو پروڊيوسر، ڪني بس، خوفزده ٿيڻ لڳو. اسان هن بگ سان راند نه موڪلي سگهياسين، ۽ ڇهن هفتن کان پوءِ مون کي سمجهه ۾ نه آيو ته مسئلو ڇا هو. ڪوني جي ذريعي، اسان ٻين PS1 ڊولپرز سان رابطو ڪيو: ڇا ڪنهن کي به ساڳيو ڪجهه مليو آهي؟ نه. ميموري ڪارڊ سان ڪو به مسئلو نه هو.

جڏهن توهان وٽ ڊيبگنگ لاءِ ڪو به خيال نه آهي، صرف هڪ طريقو ڇڏي ويو آهي "ورهايو ۽ فتح ڪريو": ناقص پروگرام مان وڌيڪ ۽ وڌيڪ ڪوڊ هٽايو جيستائين هڪ نسبتا ننڍڙو ٽڪرا باقي رهي ٿو جيڪو اڃا تائين مسئلو پيدا ڪري ٿو. اهو آهي، توهان پروگرام کي ٽڪرا ٽڪرا ٽڪرا ڪٽيو جيستائين اهو حصو جنهن ۾ بگ شامل آهي باقي رهي.

پر شيء اها آهي ته، وڊيو گيم مان ٽڪر ڪڍڻ تمام ڏکيو آهي. ان کي ڪيئن هلايو جيڪڏهن توهان ڪوڊ هٽائي ڇڏيو جيڪو ڪشش ثقل کي متحرڪ ڪري ٿو؟ يا ڊرائنگ ڪردار؟

تنهن ڪري، اسان کي مڪمل ماڊلز کي اسٽب سان تبديل ڪرڻو پوندو جيڪي ڪجهه ڪارائتو ڪم ڪرڻ جو ارادو ڪن ٿا، پر حقيقت ۾ ڪجهه بلڪل آسان آهي جنهن ۾ غلطيون نه هجن. گهٽ ۾ گهٽ ڪم ڪرڻ لاءِ اسان کي راند لاءِ اهڙيون ڪچيون لکڻيون پونديون. اهو هڪ سست ۽ دردناڪ عمل آهي.

مختصر ۾، مون ڪيو. مون ڪوڊ جا وڌيڪ ۽ وڌيڪ ٽڪرا هٽائي ڇڏيا جيستائين مون کي ابتدائي ڪوڊ سان ڇڏي ڏنو ويو جيڪو سسٽم کي ترتيب ڏئي ٿو راند کي هلائڻ لاءِ، رينجرنگ هارڊويئر کي شروع ڪري ٿو، وغيره. يقينن، هن مرحلي تي مان محفوظ ۽ لوڊ مينيو ٺاهي نه سگهيو آهيان، ڇاڪاڻ ته مون کي سڀني گرافڪس ڪوڊ لاء هڪ اسٽب ٺاهڻو پوندو. پر مان ظاهر ڪري سگهان ٿو ته هڪ صارف هجڻ جو استعمال ڪندي (پوشيده) محفوظ ۽ لوڊ اسڪرين ۽ محفوظ ڪرڻ لاءِ پڇان ۽ پوءِ ميموري ڪارڊ تي لکان.

اهو مون کي ڪوڊ جو هڪ ننڍڙو ٽڪرو ڇڏي ويو جيڪو اڃا تائين مٿيان مسئلو هو - پر اهو اڃا تائين بي ترتيب سان ٿي رهيو هو! اڪثر گهڻو ڪري سڀڪنھن شيء کي ٺيڪ ڪم ڪيو، پر ڪڏهن ڪڏهن اتي glitches هئا. مون تقريبن سڀني راند جو ڪوڊ هٽايو، پر بگ اڃا تائين جيئرو هو. هي حيران ڪندڙ هو: باقي ڪوڊ اصل ۾ ڪجھ به نه ڪيو.

ڪنهن موقعي تي، غالباً صبح جو ٽي وڳي، مون کي هڪ خيال آيو. پڙهو ۽ لکو (ان پٽ/آئوٽ پُٽ) عملن ۾ درست عمل جي وقت شامل آهن. جڏهن توهان هارڊ ڊرائيو، ميموري ڪارڊ يا بلوٽوٿ ماڊل سان ڪم ڪريو ٿا، ته پڙهڻ ۽ لکڻ لاءِ ذميدار گهٽ-سطح جو ڪوڊ ڪلاڪ پلس جي مطابق ڪندو آهي.

هڪ ڪلاڪ جي مدد سان، هڪ ڊوائيس جيڪو سڌو سنئون پروسيسر سان ڳنڍيل ناهي، پروسيسر تي عمل ڪندڙ ڪوڊ سان هم وقت سازي ڪئي وئي آهي. گھڙي بيڊ جي شرح کي طئي ڪري ٿي- رفتار جنهن تي ڊيٽا منتقل ڪئي وئي آهي. جيڪڏهن وقت سان مونجهارو آهي، ته پوءِ هارڊويئر يا سافٽ ويئر، يا ٻئي، پڻ مونجهارو آهن. ۽ اهو تمام خراب آهي، ڇاڪاڻ ته ڊيٽا خراب ٿي سگهي ٿي.

ڇا جيڪڏهن اسان جي ڪوڊ ۾ ڪا شيءِ وقتن کي پريشان ڪري ٿي؟ مون ٽيسٽ پروگرام ڪوڊ ۾ ان سان لاڳاپيل هر شي کي چيڪ ڪيو ۽ محسوس ڪيو ته اسان PS1 کان 1 kHz (1000 ٽڪر في سيڪنڊ) ۾ پروگرام قابل ٽائيم مقرر ڪيو. اهو ڪافي آهي؛ ڊفالٽ طور، جڏهن ڪنسول شروع ٿئي ٿو، اهو 100 هز تي هلندو آهي. ۽ اڪثر رانديون هن تعدد کي استعمال ڪندا آهن.

اينڊي، گيم ڊولپر، ٽائمر کي 1 kHz تي سيٽ ڪيو ته جيئن تحريڪن کي وڌيڪ صحيح طور تي ڳڻيو وڃي. اينڊي کي اوور بورڊ وڃڻ جو شوق آهي، ۽ جيڪڏهن اسان ڪشش ثقل جي تقليد ڪريون ٿا، ته اسان ان کي جيترو ٿي سگهي صحيح ڪريون ٿا!

پر ڇا جيڪڏهن ٽائمر کي تيز ڪرڻ سان ڪنهن به طرح پروگرام جي مجموعي وقت تي اثر انداز ٿئي ٿي، ۽ تنهن ڪري اهو ڪلاڪ جيڪو ميموري ڪارڊ لاء بيڊ جي شرح کي منظم ڪري ٿو؟

مون تبصرو ڪيو ٽائمر ڪوڊ. غلطي ٻيهر نه ٿي. پر هن جو مطلب اهو ناهي ته اسان ان کي درست ڪيو، ڇاڪاڻ ته ناڪامي بي ترتيب ٿي وئي آهي. ڇا جيڪڏهن مان صرف خوش قسمت هئس؟

ڪجهه ڏينهن کان پوءِ مون وري ٽيسٽ پروگرام سان تجربو ڪيو. بگ ٻيهر نه آيو. مان مڪمل گيم ڪوڊ بيس ڏانھن واپس ويس ۽ سيو ۽ لوڊ ڪوڊ کي تبديل ڪيو ته جيئن پروگراميبل ٽائمر ميموري ڪارڊ تائين پھچڻ کان اڳ پنھنجي اصل قدر (100Hz) تي ري سيٽ ڪري، ۽ پوءِ 1kHz تي واپس سيٽ ڪري. وڌيڪ حادثا نه هئا.

پر ائين ڇو ٿيو؟

مان ٻيهر ٽيسٽ پروگرام ڏانهن موٽي آيو آهيان. مون هڪ 1 kHz ٽائمر سان غلطي جي واقعن ۾ ڪجهه نموني ڳولڻ جي ڪوشش ڪئي. آخرڪار مون محسوس ڪيو ته غلطي ٿيندي آهي جڏهن ڪو ماڻهو PS1 ڪنٽرولر سان راند ڪندو آهي. جيئن ته مان پاڻ اهو ڪم گهٽ ئي ڪندس - ڇو ته مون کي هڪ ڪنٽرولر جي ضرورت پوندي جڏهن سيو ۽ لوڊ ڪوڊ جي جانچ ڪندي؟ - مون هن انحصار کي به نوٽيس نه ڪيو. پر هڪ ڏينهن اسان جو هڪ فنڪار منهنجو انتظار ڪري رهيو هو ته جاچ ختم ڪريان - مان شايد ان وقت لعنت ڪري رهيو هوس - ۽ اعصابي طور تي ڪنٽرولر کي پنهنجي هٿن ۾ ڦيرايو. هڪ غلطي ٿي وئي آهي. "انتظار، ڇا؟!" چڱو، ٻيهر ڪر!”

جڏهن مون محسوس ڪيو ته اهي ٻئي واقعا هڪ ٻئي سان ڳنڍيل هئا، مون کي آساني سان غلطي ٻيهر پيدا ڪرڻ جي قابل ٿي ويو: مون ميموري ڪارڊ تي رڪارڊ ڪرڻ شروع ڪيو، ڪنٽرولر کي منتقل ڪيو، ۽ ميموري ڪارڊ کي برباد ڪيو. مون کي اهو هڪ هارڊويئر بگ وانگر نظر آيو.

مان ڪني وٽ آيس ۽ کيس پنهنجي دريافت بابت ٻڌايو. هن معلومات کي انجڻين مان هڪ ڏانهن پهچايو جنهن PS1 کي ڊزائين ڪيو. "ناممڪن،" هن جواب ڏنو، "اهو هارڊويئر مسئلو نه ٿي سگهي." مون ڪوني کي اسان لاءِ گفتگو جو بندوبست ڪرڻ لاءِ چيو.

انجنيئر مون کي سڏيو ۽ اسان هن جي ٽوٽل انگريزي ۽ منهنجي (انتهائي) ٽوٽل جاپاني ۾ بحث ڪيو. آخرڪار مون چيو، "مون کي صرف منهنجو 30 لائن ٽيسٽ پروگرام موڪلڻ ڏيو جتي ڪنٽرولر کي منتقل ڪرڻ سان بگ پيدا ٿئي ٿو." هن اتفاق ڪيو. چيو ته اهو وقت جو ضايع آهي ۽ هو هڪ نئين منصوبي تي ڪم ڪرڻ ۾ تمام گهڻو مصروف هو، پر ان کي ڏيندو ڇو ته اسان سوني لاء هڪ اهم ڊولپر هئاسين. مون پنهنجي ٽيسٽ پروگرام کي صاف ڪيو ۽ ان کي موڪليو.

ٻئي شام (اسان لاس اينجلس ۾ هئاسين ۽ هو ٽوڪيو ۾ هو) هن مون کي فون ڪيو ۽ بيحد معذرت ڪئي. اهو هڪ هارڊويئر مسئلو هو.

مون کي خبر ناهي ته اصل ۾ بگ ڇا هو، پر سوني هيڊ ڪوارٽرز مان جيڪو ٻڌو اٿم، جيڪڏهن توهان ٽائمر کي ڪافي قدر تي مقرر ڪيو، اهو ٽائمر ڪرسٽل جي ڀرسان مدر بورڊ تي اجزاء سان مداخلت ڪندو. انهن مان هڪ ميموري ڪارڊ لاءِ بڊ ريٽ ڪنٽرولر هو، جيڪو پڻ ڪنٽرولرز لاءِ بيڊ ريٽ مقرر ڪندو هو. مان انجنيئر نه آهيان، تنهنڪري مون کي شايد ڪجهه خراب ڪيو آهي.

پر هيٺئين لائن اها آهي ته ماء بورڊ تي اجزاء جي وچ ۾ مداخلت هئي. ۽ جڏهن هڪ ئي وقت ڪنٽرولر پورٽ ۽ ميموري ڪارڊ پورٽ ذريعي 1 ڪلو هرٽز تي هلندڙ ٽائمر ذريعي ڊيٽا کي منتقل ڪيو ويو، بٽ گم ٿي ويا، ڊيٽا گم ٿي وئي، ۽ ڪارڊ خراب ٿي ويو.

خراب ڳئون

1980 جي ڏهاڪي ۾، منهنجي مرشد سرگئي SM-1800 لاءِ سافٽ ويئر لکيو، جيڪو PDP-11 جو سوويت ڪلون هو. هي مائڪرو ڪمپيوٽر صرف Sverdlovsk جي ويجهو ريلوي اسٽيشن تي نصب ڪيو ويو آهي، يو ايس ايس آر ۾ هڪ اهم ٽرانسپورٽ مرڪز. نئون نظام ويگنن ۽ مال بردار ٽريفڪ کي روٽ ڪرڻ لاءِ ٺاهيو ويو هو. پر ان ۾ هڪ پريشان ڪندڙ بگ شامل هو جنهن جي ڪري بي ترتيب حادثا ۽ حادثا ٿيا. زوال هميشه ٿيندو هو جڏهن ڪو ماڻهو شام جو گهر ويندو هو. پر ٻئي ڏينهن مڪمل تحقيق جي باوجود، ڪمپيوٽر سڀني دستي ۽ خودڪار ٽيسٽ ۾ صحيح ڪم ڪيو. اهو عام طور تي هڪ نسل جي حالت يا ڪجهه ٻين مقابلي واري بگ کي ظاهر ڪري ٿو جيڪو ڪجهه حالتن هيٺ ٿئي ٿو. رات جو دير سان ڪالن کان ٿڪل، سرگئي ان جي تري ۾ وڃڻ جو فيصلو ڪيو، ۽ سڀ کان پهريان، سمجھيو ته مارشلنگ يارڊ ۾ ڪهڙيون حالتون ڪمپيوٽر جي خراب ٿيڻ جو سبب بڻيا.

پهريون، هن سڀني اڻڄاتل ڦڙن جا انگ اکر گڏ ڪيا ۽ تاريخ ۽ وقت جي حساب سان هڪ گراف ٺاهيو. نموني پڌرو هو. ڪجهه ڏينهن جي مشاهدي کان پوء، سرجي محسوس ڪيو ته هو آساني سان مستقبل جي سسٽم جي ناڪامي جي وقت جو اندازو لڳائي سگهي ٿو.

هن کي جلد ئي معلوم ٿيو ته رڪاوٽون صرف تڏهن پيدا ٿيون جڏهن اسٽيشن اتر يوڪرين ۽ اولهه روس کان ڍورن جي ٽرينن کي ترتيب ڏئي رهي هئي ويجهي ذبح خاني ڏانهن. اهو پاڻ ۾ عجيب هو، ڇاڪاڻ ته ذبح خانو قزاقستان ۾ تمام گهڻو ويجهو واقع فارمن طرفان فراهم ڪيو ويو هو.

چرنوبل ايٽمي پاور پلانٽ 1986 ۾ ڌماڪو ٿيو، ۽ تابڪاري جي نتيجي ۾ ڀرپاسي وارن علائقن کي غير آباد بڻائي ڇڏيو. اتر يوڪرين، بيلاروس ۽ مغربي روس ۾ وسيع علائقا آلوده هئا. اچڻ واري گاڏين ۾ تابڪاري جي اعلي سطح تي شڪ ڪندي، سرگئي هن نظريي کي جانچڻ لاء هڪ طريقو ٺاهيو. آبادي کي dosimeters ڪرڻ کان منع ڪئي وئي هئي، تنهن ڪري سرگيءَ پاڻ کي ريلوي اسٽيشن تي ڪيترن ئي فوجي جوانن سان رجسٽر ڪرايو. ووڊڪا جي ڪيترن ئي پيئڻ کان پوء، هن هڪ سپاهي کي قائل ڪرڻ ۾ ڪامياب ٿي ويو ته مشڪوڪ گاڏين مان تابڪاري جي سطح کي ماپ ڪري. اهو ظاهر ٿيو ته سطح عام قدرن کان ڪيترائي ڀيرا وڌيڪ هئي.

نه رڳو ڍور تابڪاري جو تمام گهڻو اخراج ڪندا هئا، پر ان جي سطح ايتري بلند هئي جو ان جي نتيجي ۾ SM-1800 جي يادگيري ۾ بِٽس جو بي ترتيب نقصان ٿيو، جيڪو اسٽيشن جي ڀرسان هڪ عمارت ۾ واقع هو.

اتي يو ايس ايس آر ۾ کاڌي جي کوٽ هئي، ۽ اختيارين فيصلو ڪيو ته چرنوبيل گوشت کي ملڪ جي ٻين علائقن مان گوشت سان ملايو. اهو ممڪن آهي ته قيمتي وسيلن کي وڃائڻ کان سواء ريڊيو ايڪٽيويٽ جي مجموعي سطح کي گهٽائڻ. هن جي باري ۾ سکيو، سرگيء فوري طور تي لڏپلاڻ لاء دستاويز ڀريو. ۽ ڪمپيوٽر جا حادثا پنهنجو پاڻ تي بند ٿي ويا جڏهن تابڪاري جي سطح وقت سان گهٽجي وئي.

پائپ ذريعي

هڪ دفعي، موويٽيڪ سولوشن سئنيما لاءِ سافٽ ويئر ٺاهي، اڪائونٽنگ، ٽڪيٽ وڪرو ۽ عام انتظام لاءِ ٺهيل. فليگ شپ ايپ جو DOS ورجن اتر آمريڪا ۾ ننڍي ۽ وچولي سائيز جي مووي ٿيٽر زنجيرن ۾ ڪافي مشهور هو. تنهن ڪري اها تعجب جي ڳالهه ناهي ته جڏهن ونڊوز 95 ورزن جو اعلان ڪيو ويو، جديد ٽچ اسڪرينز ۽ سيلف سروس ڪوسڪ سان ضم ٿي، ۽ هر قسم جي رپورٽنگ اوزارن سان ليس، اهو تمام جلدي مشهور ٿيو، پڻ. اڪثر ڪري تازه ڪاري بغير ڪنهن پريشاني جي ٿي وئي. مقامي آئي ٽي اسٽاف نئون سامان نصب ڪيو، منتقل ٿيل ڊيٽا، ۽ ڪاروبار جاري رهيو. سواءِ جڏهن اهو آخري نه ٿيو. جڏهن اهو ٿيو، ڪمپني موڪلي ها جيمس، جنهن جو نالو "دي ڪلينر" آهي.

جيتوڻيڪ nickname هڪ غير معمولي قسم جو مشورو ڏئي ٿو، صاف ڪندڙ صرف استاد، انسٽالر ۽ جيڪ-آف-آل-ٽريڊ جو هڪ مجموعو آهي. جيمس ڪلائنٽ جي سائيٽ تي ڪجهه ڏينهن گذاريندو سڀني حصن کي گڏ ڪري، ۽ پوءِ ڪجهه ڏينهن گذاريندو اسٽاف کي سيکاريندو ته نئين سسٽم کي ڪيئن استعمال ڪجي، ڪنهن به هارڊويئر جي مسئلن کي حل ڪيو جيڪو پيدا ٿئي ٿو ۽ بنيادي طور تي سافٽ ويئر کي ان جي ننڍپڻ ۾ مدد ڪندي.

تنهن ڪري، اها حيرت جي ڳالهه ناهي ته انهن مصروف وقتن ۾، جيمس صبح جو آفيس پهتو، ۽ ان کان اڳ جو هو پنهنجي ميز تي پهچندو، هن کي مينيجر طرفان سلام ڪيو ويو، معمول کان وڌيڪ ڪافين سان ڀريل هو.

”مون کي ڊپ آهي ته توهان کي جلد کان جلد اناپولس، نووا اسڪوٽيا وڃڻو پوندو. انهن جو سمورو نظام تباهه ٿي ويو، ۽ انهن جي انجنيئرن سان گڏ ڪم ڪرڻ جي هڪ رات کان پوء، اسان کي خبر ناهي ته ڇا ٿيو. لڳي ٿو سرور تي نيٽ ورڪ ناڪام ٿي ويو آهي. پر پوءِ ئي سسٽم ڪيترن ئي منٽن تائين هليو ويو.

- اهي پراڻي نظام ڏانهن واپس نه آيا؟ - جيمس مڪمل طور تي سنجيدگي سان جواب ڏنو، جيتوڻيڪ ذهني طور تي هن پنهنجي اکين کي حيران ڪيو.

- بلڪل: سندن آئي ٽي ماهر ”ترجيحون بدلائي ڇڏيون“ ۽ فيصلو ڪيو پنھنجي پراڻي سرور سان ڇڏڻ. جيمس، انهن ڇهن سائيٽن تي سسٽم نصب ڪيو ۽ صرف پريميم سپورٽ لاء ادا ڪيو، ۽ انهن جو ڪاروبار هاڻي هليو ويو آهي جيئن اهو 1950s ۾ هو.

جيمس ٿورو سڌو ٿي ويو.

- اها ٻي ڳالهه آهي. ٺيڪ آهي، اچو ته شروع ڪريون.

جڏهن هو اناپولس ۾ پهتو، هن پهريون ڪم ڪيو جيڪو هن ڪسٽمر جو پهريون ٿيٽر ڳوليو جنهن ۾ ڪو مسئلو هو. ايئرپورٽ تي ورتل نقشي تي، هر شيءِ مهذب نظر اچي رهي هئي، پر گهربل ايڊريس جي آس پاس وارو علائقو مشڪوڪ نظر آيو. گيٽو نه، پر فلم نير جي ياد ڏياري. جيئن ئي جيمس ڪرب شهر ۾ بيٺو، هڪ طوائف هن جي ويجهو آئي. اناپولس جي سائيز جي لحاظ کان، اهو ئي ممڪن آهي ته سڄي شهر ۾ صرف هڪ ئي هو. هن جي ظاهر کي فوري طور تي مشهور ڪردار ذهن ۾ آندو، جيڪو وڏي اسڪرين تي پئسا لاء جنسي پيش ڪيو. نه، جوليا رابرٽس بابت نه، پر جون ووائيٽ بابت [فلم "Midnight Cowboy" ڏانهن اشارو - تقريبن. لين].

طوائف کي پنهنجي رستي تي موڪلڻ بعد، جيمس سئنيما ڏانهن ويو. آس پاس جو علائقو بهتر ٿي چڪو هو، پر اهو اڃا تائين هلندي وڃڻ جو تاثر ڏئي رهيو هو. نه ته جيمس ڏاڍو پريشان هو. هو اڳي به خراب هنڌن تي ويو آهي. ۽ هي ڪئناڊا هو، جتي مگگر به توهان جي پرس وٺڻ کان پوءِ ”مهرباني“ چوڻ لاءِ ڪافي شائسته آهن.

سئنيما جو پاسو دروازو هڪ گندي گهٽي ۾ هو. جيمس دروازي ڏانهن وڌيو ۽ کڙڪيو. جلد ئي اهو creaked ۽ ٿورو کوليو.

- ڇا توهان صاف ڪندڙ آهيو؟ - اندر مان هڪ ٻرندڙ آواز آيو.

- ها، اهو مان آهيان ... مان سڀ ڪجهه ٺيڪ ڪرڻ آيو آهيان.

جيمس سئنيما جي لابي ۾ هليو ويو. بظاهر ٻيو ڪو به آپشن نه هئڻ ڪري، عملي سياحن کي ڪاغذن جي ٽڪيٽون ڏيڻ شروع ڪيون. هن مالي رپورٽنگ کي ڏکيو بڻائي ڇڏيو، اڪيلو ڇڏي ڏيو وڌيڪ دلچسپ تفصيل. پر عملي جيمس کي سلام ڪيو ۽ فوري طور تي سرور روم ۾ وٺي ويا.

پهرين نظر ۾، سڀ ڪجھ ٺيڪ هو. جيمس سرور ۾ لاگ ان ٿيو ۽ معمول جي مشڪوڪ جڳهن کي چيڪ ڪيو. ڪو مسئلو ناهي. بهرحال، احتياط جي گهڻائي کان ٻاهر، جيمس سرور کي بند ڪيو، نيٽ ورڪ ڪارڊ کي تبديل ڪيو، ۽ سسٽم کي واپس ڪيو. هوء فوري طور تي مڪمل طور تي ڪم ڪرڻ شروع ڪيو. عملي وري ٽڪيٽون وڪڻڻ شروع ڪيون.

جيمس مارڪ کي فون ڪيو ۽ کيس صورتحال کان آگاهه ڪيو. اهو تصور ڪرڻ ڏکيو ناهي ته جيمس شايد چوڌاري لٺڻ چاهيندو آهي ۽ ڏسو ته ڇا ڪجهه غير متوقع ٿئي ٿو. هو ڏاڪڻ تان هيٺ لٿو ۽ ملازمن کان پڇڻ لڳو ته ڇا ٿيو؟ ظاهر آهي ته سسٽم ڪم ڪرڻ بند ڪري ڇڏيو آهي. انهن ان کي بند ڪيو ۽ ان تي، سڀ ڪجهه ڪم ڪيو. پر 10 منٽن کان پوء سسٽم بند ٿي ويو.

بس هن وقت ڪجهه اهڙو ئي ٿيو. اوچتو، ٽڪيٽنگ سسٽم غلطيون اڇلائڻ شروع ڪيو. اسٽاف رڙيون ڪري پيپر ٽڪيٽون ورتيون، ۽ جيمس جلدي سرور روم ڏانهن ويو. سرور سان سڀ ڪجهه سٺو لڳندو هو.

پوءِ هڪ ملازم اندر داخل ٿيو.

- سسٽم ٻيهر ڪم ڪري رهيو آهي.

جيمس حيران ٿي ويو ڇاڪاڻ ته هن ڪجهه به نه ڪيو هو. وڌيڪ واضح طور تي، ڪجھ به نه جيڪو سسٽم کي ڪم ڪندو. هن لاگ آئوٽ ڪيو، هن جو فون کنيو، ۽ پنهنجي ڪمپني جي سپورٽ لائن کي سڏيو. جلد ئي ساڳيو ملازم سرور روم ۾ داخل ٿيو.

- سسٽم هيٺ آهي.

جيمس سرور ڏانهن ڏٺو. گھڻن رنگن جي شڪلن جو هڪ دلچسپ ۽ واقف نمونو اسڪرين تي ناچ ڪيو ويو - افراتفري طور تي ڇڪڻ ۽ وچ ۾ پائپ. اسان سڀني ڏٺو آهي هن اسڪرين سيور کي ڪنهن نقطي تي. اهو خوبصورت طور تي پيش ڪيو ويو ۽ لفظي طور تي hypnotizing.

جيمس هڪ بٽڻ دٻايو ۽ نمونو غائب ٿي ويو. هو تڪڙ ۾ ٽڪيٽ آفيس ڏانهن روانو ٿيو ۽ رستي ۾ هڪ ملازم کيس واپس اچي مليو.

- سسٽم ٻيهر ڪم ڪري رهيو آهي.

جيڪڏهن توهان ڪري سگهو ٿا هڪ ذهني چهرو، اهو ئي آهي جيڪو جيمس ڪيو. اسڪرين سيور. اهو OpenGL استعمال ڪري ٿو. ۽ تنهن ڪري، آپريشن دوران، اهو سرور پروسيسر جي سڀني وسيلن کي استعمال ڪري ٿو. نتيجي طور، سرور تي هر ڪال هڪ وقت ختم ٿي ويندي آهي.

جيمس سرور روم ڏانهن موٽيو، لاگ ان ٿيو، ۽ اسڪرين سيور کي خالي اسڪرين سان خوبصورت پائپ سان تبديل ڪيو. اهو آهي، هڪ اسڪرين سيور جي بدران جيڪو استعمال ڪري ٿو 100٪ پروسيسر وسيلن جو، مون هڪ ٻيو نصب ڪيو جيڪو وسيلن کي استعمال نٿو ڪري. پوءِ مون 10 منٽن جو انتظار ڪيو ته پنھنجي اندازي کي جانچڻ لاءِ.

جيمس جڏهن ايندڙ سئنيما ۾ پهتو ته هو سوچي رهيو هو ته ڪيئن پنهنجي مئنيجر کي سمجهائي ته هن اسڪرين سيور کي بند ڪرڻ لاءِ صرف 800 ڪلوميٽر اڏام ڪيو هو.

چنڊ جي هڪ خاص مرحلي دوران حادثو

سچي ڪهاڻي. هڪ ڏينهن هڪ سافٽ ويئر بگ پيدا ٿيو جيڪو چنڊ جي مرحلي تي منحصر هو. اتي ھڪڙو ننڍڙو معمول ھو، جيڪو عام طور تي مختلف MIT پروگرامن ۾ چنڊ جي حقيقي مرحلي جي لڳ ڀڳ حساب ڪرڻ لاء استعمال ڪيو ويو. GLS هن معمول کي هڪ LISP پروگرام ۾ ٺاهيو جيڪو، جڏهن هڪ فائل لکندو هو، هڪ لڪير ڪڍي ڇڏيندو ٽائم اسٽيمپ سان لڳ ڀڳ 80 اکر ڊگھو. اهو تمام گهٽ هوندو هو ته پيغام جي پهرين لڪير تمام گهڻي ڊگهي ٿي وڃي ۽ ايندڙ لائن ڏانهن وٺي وڃي. ۽ جڏهن پروگرام بعد ۾ هن فائل کي پڙهي، اهو لعنت ڪئي. پهرين لڪير جي ڊيگهه صحيح تاريخ ۽ وقت تي منحصر آهي، انهي سان گڏ مرحلي جي تفصيل جي ڊيگهه تي وقت جي اسٽيمپ ڇپيل هئي. اهو آهي، بگ لفظي طور تي چنڊ جي مرحلي تي منحصر آهي!

پهريون پيپر ايڊيشن جرگون فائل (اسٽيل-1983) ۾ هڪ اهڙي لڪير جو مثال آهي جنهن جي ڪري بيان ڪيل بگ، پر ٽائيپ سيٽٽر ان کي ”مقرر“ ڪيو. ان کان پوء "چنڊ فيز بگ" جي طور تي بيان ڪيو ويو آهي.

بهرحال، احتياط سان فرضن سان. ڪجھ سال اڳ، CERN (يورپي سينٽر فار نيوڪليئر ريسرچ) جي انجنيئرن کي وڏي اليڪٽران-پوزيٽران ڪولائڊر تي ڪيل تجربن ۾ غلطين جو سامنا ٿيو. جيئن ته ڪمپيوٽر سائنسدانن کي نتيجو ڏيکارڻ کان اڳ هن ڊوائيس ذريعي ٺاهيل ڊيٽا جي وڏي مقدار کي فعال طور تي پروسيس ڪندا آهن، ڪيترن ئي اندازو لڳايو ته سافٽ ويئر ڪنهن به طرح چنڊ جي مرحلي لاء حساس هو. ڪيترائي مايوس انجنيئر سچ جي تري تائين پهچي ويا. غلطي چنڊ جي گذرڻ دوران ڌرتيءَ جي خراب ٿيڻ سبب 27 ڪلوميٽر ڊگھي انگوزي جي جاميٽري ۾ ٿوري تبديليءَ سبب پيدا ٿي! هيءَ ڪهاڻي فزڪس جي لوڪ ڪهاڻيءَ ۾ داخل ٿي چڪي آهي ”نيوٽن جي ريوينج آن پارٽيڪل فزڪس“ ۽ فزڪس جي سادي ۽ پراڻن قانونن ۽ جديد سائنسي تصورن جي وچ ۾ تعلق جو هڪ مثال.

ٽوائلٽ کي فلش ڪرڻ ٽرين کي روڪي ٿو

بهترين هارڊويئر بگ مون ٻڌو آهي فرانس ۾ هڪ تيز رفتار ٽرين تي. بگ جي ڪري ٽرين جي ايمرجنسي بريڪنگ ٿي، پر صرف ان صورت ۾ جڏهن بورڊ تي مسافر هئا. اهڙي هر معاملي ۾، ٽرين کي سروس مان ڪڍيو ويو، چيڪ ڪيو ويو، پر ڪجهه به نه مليو. ان کان پوء هن کي لڪير ڏانهن واپس موڪليو ويو، ۽ هو فوري طور تي هڪ اسٽاپ تي تباهه ٿي ويو.

هڪ چيڪ دوران، هڪ انجنيئر ٽرين تي سفر ڪري رهيو هو ته ٽوائلٽ ڏانهن ويو. هو جلد ئي ڌوئي ويو، بوم! هنگامي اسٽاپ.

انجنيئر ڊرائيور سان رابطو ڪيو ۽ پڇيو:

- بريڪ لڳائڻ کان اڳ ڇا ڪري رهيا هئا؟

- خير، مون نازل ٿيڻ تي سست ٿي ويو ...

اهو عجيب هو، ڇاڪاڻ ته عام آپريشن دوران ٽرين ڪيترن ئي ڀيرا سست ٿي ويندي آهي. ٽرين اڳتي وڌي وئي، ۽ ايندڙ نزول تي ڊرائيور خبردار ڪيو:

- مان سست ٿيڻ وارو آهيان.

ڪجهه به نه ٿيو.

- آخري بريڪنگ دوران توهان ڇا ڪيو؟ - ڊرائيور پڇيو.

- خير... مان ٽوائلٽ ۾ هوس...

- چڱو، پوءِ ٽوائلٽ ڏانھن وڃو ۽ توھان ڇا ڪيو جڏھن اسان وري ھيٺ وينداسين!

انجنيئر ٽوائلٽ ڏانهن ويو، ۽ جڏهن ڊرائيور خبردار ڪيو: "مان سست ٿي رهيو آهيان،" هن پاڻي کي ڦوڪيو. يقينن، ٽرين فوري طور تي روڪي وئي.

هاڻي اهي مسئلا ٻيهر پيدا ڪري سگھن ٿا ۽ سبب ڳولڻ جي ضرورت آهي.

ٻن منٽن کان پوءِ، هنن ڏٺو ته انجڻ جي بريڪ ريموٽ ڪنٽرول ڪيبل (ٽرين جي هر آخر ۾ هڪ انجڻ هئي) برقي ڪيبينيٽ جي ڀت کان ڌار ٿي وئي هئي ۽ رلي تي ليٽيل هئي جيڪا ٽوائلٽ پلگ سولينائيڊ کي ڪنٽرول ڪندي هئي... چالو ڪيو ويو، اهو بريڪ ڪيبل ۾ مداخلت پيدا ڪيو، ۽ ناڪامي جي خلاف سسٽم جي حفاظت صرف ايمرجنسي برڪنگ شامل آهي.

گيٽ وي جيڪو فورٽران کان نفرت ڪري ٿو

ڪجھ مهينا اڳ اسان ڏٺو ته سرزمين تي نيٽ ورڪ ڪنيڪشن [هي هوائي ۾ هو] تمام گهڻو سست ٿي رهيا هئا. اهو 10-15 منٽن تائين ٿي سگهي ٿو ۽ پوء اوچتو ٻيهر ٿي سگهي ٿو. ڪجهه وقت کان پوء، منهنجي ساٿي مون کي شڪايت ڪئي ته نيٽ ورڪ ڪنيڪشن سرزمين تي عام طور تي ڪم نٿو ڪري. هن وٽ ڪجهه FORTRAN ڪوڊ هو جنهن کي سرزمين تي هڪ مشين ۾ نقل ڪرڻ جي ضرورت هئي، پر اهو نه ٿي سگهيو ڇاڪاڻ ته "نيٽ ورڪ ڪافي وقت تائين FTP اپلوڊ مڪمل ڪرڻ لاءِ نه رهي."

ها، اهو ظاهر ٿيو ته نيٽ ورڪ ناڪامي تڏهن ٿي جڏهن هڪ ساٿي FTP ڪرڻ جي ڪوشش ڪئي ماخذ ڪوڊ سان فائل FORTRAN ۾ سرزمين تي هڪ مشين ڏانهن. اسان فائل کي آرڪائيو ڪرڻ جي ڪوشش ڪئي: پوء ان کي آساني سان نقل ڪيو ويو (پر ٽارگيٽ مشين کي اڻڄاتل نه هو، تنهنڪري مسئلو حل نه ڪيو ويو). آخرڪار اسان FORTRAN ڪوڊ کي تمام ننڍن ٽڪرن ۾ "ورهايو" ۽ انهن کي هڪ وقت ۾ موڪليو. گهڻا ٽڪرا بغير مسئلن جي نقل ڪيا ويا، پر ڪجھ ٽڪرا نه گذريا، يا بعد ۾ گذري ويا گهڻا ڪوششون.

جڏهن اسان مشڪلاتي پاسن جي جانچ ڪئي، اسان دريافت ڪيو ته انهن ۾ ڪجهه مشترڪ آهي: اهي سڀئي تبصري بلاڪ تي مشتمل هئا جيڪي شروع ۽ ختم ٿيڻ واري لائينن تي مشتمل هونديون آهن سرمائي سي (جيئن هڪ ساٿي FORTRAN ۾ تبصرو ڪرڻ کي ترجيح ڏني). اسان سرزمين تي نيٽ ورڪ ماهرن کي اي ميل ڪيو ۽ مدد لاءِ چيو. يقينا، اهي اسان جي فائلن جا نمونا ڏسڻ چاهيندا هئا جيڪي FTP ذريعي منتقل نه ٿي سگهيا آهن ... پر اسان جا خط انهن تائين نه پهچي سگهيا. آخرڪار اسان هڪ سادي سان گڏ آياسين بيان ڪريوڪهڙيون غير منتقلي فائلون نظر اچن ٿيون. اھو ڪم ڪيو :) شايد ان جي لائق ناهي!]

آخر ۾ اسان ان کي سمجهڻ ۾ ڪامياب ٿي ويا. ھڪڙو نئون گيٽ وي تازو نصب ڪيو ويو آھي اسان جي ڪيمپس جي حصي ۽ مکيه لينڊ نيٽ ورڪ جي وچ ۾. ان کي پيڪٽن کي منتقل ڪرڻ ۾ وڏي ڏکيائي هئي جنهن ۾ اپر ڪيز سي جي بار بار بٽ شامل هئا! انهن مان ڪجھ پيڪيٽ سڀني گيٽ وي وسيلن کي وٺي سگھن ٿا ۽ ٻين پيڪرن کي حاصل ڪرڻ کان روڪي سگھي ٿو. اسان گيٽ وي ٺاهيندڙ کي شڪايت ڪئي ... ۽ انهن جواب ڏنو: ”او، ها، توهان کي بار بار سي جي بگ سان منهن ڏيڻو پيو! اسان هن جي باري ۾ اڳ ۾ ئي ڄاڻون ٿا. اسان آخرڪار مسئلو حل ڪيو هڪ ٻئي ٺاهيندڙ کان نئين گيٽ وي خريد ڪندي (اڳوڻي دفاع ۾، FORTRAN پروگرامن کي منتقلي ڪرڻ جي ناڪامي شايد ڪجهه لاء هڪ فائدو آهي!).

ڏکيا وقت

ڪجھ سال اڳ، پرل ۾ اي ٽي ايل سسٽم ٺاهڻ تي ڪم ڪرڻ دوران فيز 40 ڪلينڪل ٽرائلز جي قيمتن کي گھٽائڻ لاءِ، مون کي 000 تاريخن تي عمل ڪرڻ جي ضرورت ھئي. انهن مان ٻه امتحان پاس نه ٿيا. اهو مون کي تمام گهڻو پريشان نه ڪيو ڇو ته اهي تاريخون ڪلائنٽ جي مهيا ڪيل ڊيٽا مان ورتيون ويون آهن جيڪي اڪثر، اسان چئون ٿا، حيرت انگيز. پر جڏهن مون اصل ڊيٽا چيڪ ڪئي ته معلوم ٿيو ته اهي تاريخون 1 جنوري 2011 ۽ 1 جنوري 2007 جون هيون، مون سمجهيو ته اهو بگ ان پروگرام ۾ موجود هو، جيڪو مون تازو لکيو هو، پر معلوم ٿيو ته ان کي 30 سال گذري چڪا آهن. پراڻو اهو ٿي سگهي ٿو پراسرار آواز انهن لاءِ جيڪي سافٽ ويئر ايڪو سسٽم سان ناواقف آهن. پئسا ڪمائڻ جي ٻي ڪمپني جي ڊگهي فيصلي جي ڪري، منهنجي ڪلائنٽ مون کي هڪ بگ کي درست ڪرڻ لاءِ ادا ڪيو جيڪو هڪ ڪمپني حادثي سان متعارف ڪرايو هو ۽ ٻيو مقصد تي. توھان لاءِ اھو سمجھڻ لاءِ ته مان ڇا جي باري ۾ ڳالھائي رھيو آھيان، مون کي انھيءَ ڪمپنيءَ بابت ڳالھائڻ جي ضرورت آھي جنھن خصوصيت شامل ڪئي جيڪا ختم ٿي بگ بڻجي وئي، ان سان گڏ ڪجھ ٻيا دلچسپ واقعا جن مون کي درست ڪيل پراسرار بگ ۾ مدد ڪئي.

سٺن پراڻن ڏينهن ۾، ايپل ڪمپيوٽرن ڪڏهن ڪڏهن پنهنجي تاريخ کي 1 جنوري، 1904 تي ري سيٽ ڪيو. سبب سادو هو: اهو تاريخ ۽ وقت جي ٽريڪ رکڻ لاءِ بيٽري تي هلندڙ ”سسٽم ڪلاڪ“ استعمال ڪيو. ڇا ٿيو جڏهن بيٽري مري ويو؟ ڪمپيوٽرن هڪ دور جي شروعات کان وٺي سيڪنڊن جي تعداد ذريعي تاريخ کي ٽريڪ ڪرڻ شروع ڪيو. epoch مان اسان جو مطلب هو اصل تاريخ جو حوالو، ۽ Macintoshes لاءِ اها 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 کي ليپ سال طور سمجهيو. جڏهن Microsoft پنهنجي پهرين اسپريڊ شيٽ جاري ڪئي، Multiplan، اهو مارڪيٽ جو ننڍڙو حصو ورتو. ۽ جڏهن هنن ايڪسل پروجيڪٽ شروع ڪيو، ته هنن نه رڳو لوٽس 1-2-3 مان قطار ۽ ڪالمن جي نالي جي اسڪيم کي نقل ڪرڻ جو فيصلو ڪيو، پر 1900 کي ليپ سال جي طور تي جان بوجھائي علاج ڪندي بگ مطابقت کي به يقيني بڻايو. اهو مسئلو اڄ به موجود آهي. اهو آهي، 1-2-3 ۾ اهو هڪ بگ هو، پر ايڪسل ۾ اهو هڪ شعوري فيصلو هو جنهن کي يقيني بڻايو ويو ته سڀئي 1-2-3 صارف ڊيٽا کي تبديل ڪرڻ کان سواءِ پنهنجي ٽيبل کي Excel ۾ درآمد ڪري سگهن ٿا، جيتوڻيڪ اهو غلط هو.

پر اتي هڪ ٻيو مسئلو هو. پهريون، مائڪروسافٽ ميڪنٽوش لاءِ ايڪسل جاري ڪيو، جنهن ۾ 1 جنوري 1904ع کان اڳ جي تاريخن جي سڃاڻپ نه هئي. ۽ ايڪسل ۾، 1 جنوري 1900ع کي دور جي شروعات سمجهيو ويندو هو. تنهن ڪري، ڊولپرز هڪ تبديلي ڪئي ته جيئن انهن جو پروگرام دور جي قسم کي سڃاڻي ۽ پنهنجي اندر اندر گهربل ڊيٽا کي گهربل دور جي مطابق محفوظ ڪري. Microsoft به ان بابت هڪ وضاحتي مضمون لکيو آهي. ۽ اهو فيصلو منهنجي بگ جو سبب بڻيو.

منهنجو ETL سسٽم حاصل ڪيو ايڪسل اسپريڊ شيٽ گراهڪن کان جيڪي ونڊوز تي ٺاهيا ويا آهن، پر ميڪ تي پڻ ٺاهي سگھجن ٿيون. تنهن ڪري، جدول ۾ دور جي شروعات يا ته جنوري 1، 1900، يا جنوري 1، 1904 ٿي سگهي ٿي. ڪيئن معلوم ڪرڻ لاء؟ ايڪسل فائل فارميٽ ۾ ضروري معلومات ڏيکاري ٿي، پر مون جيڪو پارسر استعمال ڪيو هو اهو نه ڏيکاريو (هاڻي اهو ڪري ٿو)، ۽ فرض ڪيو ته توهان هڪ مخصوص ٽيبل لاءِ دور کي ڄاڻو ٿا. مان شايد ايڪسل بائنري فارميٽ کي سمجهڻ ۽ پارسر ليکڪ ڏانهن پيچ موڪلڻ ۾ وڌيڪ وقت گذاريان ها، پر مون وٽ ڪلائنٽ لاءِ گهڻو ڪجهه ڪرڻو هو، تنهن ڪري مون جلد ئي هن دور کي طئي ڪرڻ لاءِ هڪ هوريسٽ لکيو. هوءَ سادي هئي.

ايڪسل ۾، تاريخ 5 جولاء، 1998 فارميٽ ۾ نمائندگي ڪري سگهجي ٿو "07-05-98" (بيڪار آمريڪي نظام)، "جولائي 5، 98"، "جولائي 5، 1998"، "5-جولائي-98" يا ڪجهه ٻيو فارميٽ. ٻيو بيڪار فارميٽ (عظيمانه طور تي، هڪ فارميٽ جو منهنجو ايڪسل جو نسخو پيش نه ڪيو ويو ISO 8601). جڏهن ته، جدول جي اندر، غير فارميٽ ٿيل تاريخ يا ته "35981" epoch-1900 لاءِ يا "34519" epoch-1904 لاءِ محفوظ ڪئي وئي هئي (انگن اکرن کان وٺي ڏينهن جي تعداد جي نمائندگي ڪن ٿا). مون صرف فارميٽ ٿيل تاريخ مان سال ڪڍڻ لاءِ سادو پارسر استعمال ڪيو، ۽ پوءِ غير فارميٽ ٿيل تاريخ مان سال ڪڍڻ لاءِ Excel parser استعمال ڪيو. جيڪڏهن ٻنهي قدرن ۾ 4 سالن کان فرق آهي، ته پوءِ مون کي خبر هئي ته مان هڪ سسٽم استعمال ڪري رهيو آهيان epoch-1904 سان.

مون صرف فارميٽ ٿيل تاريخون ڇو نه استعمال ڪيون؟ ڇو ته 5 جولاءِ 1998ع کي ”جولاءِ، 98“ جي شڪل ۾ ڏئي سگهجي ٿو، جنهن ۾ گم ٿيل مهيني جي ڏينهن سان. اسان ڪيترين ئي ڪمپنين کان ٽيبل حاصل ڪيا جن انهن کي ڪيترن ئي مختلف طريقن سان ٺاهيو ته اهو اسان تي (هن صورت ۾، مون کي) تاريخن کي ڄاڻڻ لاء هو. ان کان سواء، جيڪڏهن Excel اهو صحيح ٿي وڃي، ته پوء اسان کي گهرجي!

ساڳئي وقت مون کي 39082 مليا. مان توهان کي ياد ڏياريان ته لوٽس 1-2-3 1900 کي هڪ ليپ سال سمجهيو، ۽ اهو ايمانداري سان Excel ۾ ورجايو ويو. ۽ جيئن ته هن سال 1900 ۾ هڪ ڏينهن جو اضافو ڪيو آهي، ان ڏينهن لاءِ ڪيترائي تاريخ جي حساب ڪتاب غلط ٿي سگهن ٿا. اهو آهي، 39082 ٿي سگهي ٿو جنوري 1، 2011 (Macs تي) يا ڊسمبر 31، 2006 (ونڊوز تي). جيڪڏهن منهنجو ”سال پارسر“ سال 2011 کي فارميٽ ٿيل ويل مان ڪڍيو ته پوءِ سڀ ڪجهه ٺيڪ آهي. پر جيئن ته Excel parser کي خبر ناهي ته ڪهڙو دور استعمال ڪيو پيو وڃي، اهو ڊفالٽ epoch-1900 ڏانهن، سال 2006 ڏانهن موٽڻ. منهنجي درخواست ڏٺي ته فرق 5 سال هو، ان کي هڪ غلطي سمجهيو، ان کي لاگ ان ڪيو، ۽ هڪ غير فارميٽ ويل واپس ڪيو.

هن جي چوڌاري حاصل ڪرڻ لاء، مون هي لکيو (pseudocode):

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" ڊرائيوز سان ڳنڍيل هجي، ۽ رام ۾ ننڍڙي OS جيڪا "A" ڊرائيو کي ڪنٽرول ڪري ٿي، سڀني "B" ڊرائيو کي پڙهڻ ۽ لکڻ جي عملن کي نمائندو ڪري سگهي ٿي.

هر دفعي ڊرائيو "A" شروع ڪيو ويو، اهو ضروري هو ته "A" سان ڳنڍيل پرديري ڊرائيو ۾ فلاپي ڊسڪ داخل ڪرڻ لاء آپريٽنگ سسٽم کي ان جي ياداشت ۾ لوڊ ڪرڻ لاء. اهو انتهائي ابتدائي هو: ڪمپيوٽنگ پاور هڪ 8-bit مائڪرو ڪنٽرولر طرفان مهيا ڪيل هئي.

اهڙن سامان لاءِ ٽارگيٽ سامعين ڪمپنيون هيون جن وٽ تمام وڏا ڊيٽا گودام آهن - بئنڪون، پرچون زنجير، وغيره - جن کي تمام گهڻو ايڊريس ليبلز يا بئنڪ اسٽيٽس پرنٽ ڪرڻ جي ضرورت هئي.

ھڪڙو کلائنٽ ھڪڙو مسئلو ھو. هڪ پرنٽ نوڪري جي وچ ۾، هڪ خاص ڊرائيو "A" ڪم ڪرڻ بند ڪري سگهي ٿي، سڄي نوڪري کي اسٽال ڪرڻ جو سبب بڻائيندو. ڊرائيو جي آپريشن کي بحال ڪرڻ لاء، عملي کي هر شيء کي ريبوٽ ڪرڻو پيو. ۽ جيڪڏهن اهو ڇهن ڪلاڪن جي ڪم جي وچ ۾ ٿيو، ته پوء وڏي پئماني تي ڪمپيوٽر جو وقت ضايع ٿي ويو ۽ سڄي آپريشن جي شيڊول کي تباهه ڪيو ويو.

ٽيڪنيشين موڪليا ويا اسٽوريج ٽيڪنالاجيز مان. پر انهن جي بهترين ڪوششن جي باوجود، اهي آزمائشي حالتن ۾ بگ کي ٻيهر پيدا ڪرڻ ۾ ناڪام ٿي ويا: اهو لڳي ٿو ته وڏي پرنٽ نوڪرين جي وچ ۾ ٿيندي. مسئلو هارڊويئر جو نه هو، انهن هر شيءِ کي مٽائي ڇڏيو، جيڪي هو ڪري سگهن ٿا: رام، مائڪرو ڪنٽرولر، فلاپي ڊرائيو، ٽيپ ڊرائيو جو هر ممڪن حصو - مسئلو برقرار رهيو.

پوءِ ٽيڪنيشين هيڊ ڪوارٽر فون ڪري ماهر کي سڏيو.

ماهر هڪ ڪرسي ۽ ڪافي جو پيالو کنيو، ڪمپيوٽر روم ۾ اچي ويٺو- انهن ڏينهن ۾ ڪمپيوٽر لاءِ ڪمرا وقف هوندا هئا- ۽ ڏسندو هو ته اسٽاف هڪ وڏي پرنٽ جاب جي قطار ۾ بيٺو آهي. ماهر انتظار ڪري رهيو هو ته ناڪامي ٿيڻ جي - ۽ اهو ڪيو. هر ڪنهن ماهر ڏانهن ڏٺو، پر هن کي خبر نه هئي ته ائين ڇو ٿيو. تنهن ڪري هن نوڪري کي ٻيهر قطار ۾ رکڻ جو حڪم ڏنو، ۽ سڀ عملدار ۽ ٽيڪنيشن واپس ڪم تي اچي ويا.

ماهر وري ڪرسيءَ تي ويٺو ۽ ناڪاميءَ جو انتظار ڪرڻ لڳو. اٽڪل ڇهه ڪلاڪ گذري ويا ۽ ناڪامي ٿي. ماهرن کي وري ڪا به خبر نه هئي، سواءِ ان جي ته سڀ ڪجهه ماڻهن سان ڀريل ڪمري ۾ ٿيو. هن مشن کي ٻيهر شروع ڪرڻ جو حڪم ڏنو، واپس ويٺو ۽ انتظار ڪرڻ لڳو.

ٽئين ناڪاميءَ سان، ماهر ڪجهه محسوس ڪيو. ناڪامي تڏهن ٿي جڏهن اهلڪارن ٽيپ کي پرڏيهي ڊرائيو ۾ تبديل ڪيو. ان کان علاوه، ناڪامي جلدي ٿي وئي جيئن ملازمن مان هڪ فرش تي هڪ خاص ٽائل ذريعي هلندو هو.

مٿي ڪيل فرش 6 کان 8 انچ جي اوچائي تي رکيل المونيم ٽائلس مان ٺهيل هو. ڪمپيوٽرن جون ڪيتريون ئي تارون بلند ٿيل فرش جي هيٺان ڊوڙي ويون ته جيئن ڪنهن کي به حادثي سان هڪ اهم ڪيبل تي قدم رکڻ کان روڪي سگهجي. ٽائلس ڏاڍي مضبوطيءَ سان رکيا ويا هئا ته جيئن ملبي کي مٿي جي فرش هيٺان اچڻ کان روڪيو وڃي.

ماهر محسوس ڪيو ته ٽائلس مان هڪ خراب ٿي وئي هئي. جڏهن هڪ ملازم ان جي ڪنڊ تي قدم رکيو، ٽائل جي ڪنارن کي ڀرسان ٽائلس جي خلاف رگڻ لڳو. پلاسٽڪ جا حصا جيڪي ٽائلس کي ڳنڍيندا هئا انهن سان پڻ رڱجي ويا، جنهن جي ڪري جامد مائڪروڊسچارجز جو سبب بڻيو جيڪو ريڊيو فریکوئنسي مداخلت پيدا ڪيو.

اڄ، رام گهڻو بهتر آهي ريڊيو فریکوئنسي مداخلت کان محفوظ. پر انهن سالن ۾ ائين نه هو. ماهر اهو محسوس ڪيو ته هي مداخلت ياداشت کي خراب ڪري ٿو، ۽ ان سان گڏ آپريٽنگ سسٽم جي آپريشن. هن سپورٽ سروس کي سڏيو، نئين ٽائلس جو حڪم ڏنو، پاڻ کي نصب ڪيو، ۽ مسئلو غائب ٿي ويو.

اھا بلندي آھي!

ڪهاڻي هڪ سرور روم ۾ ٿي، پورٽسموت (مان سمجهان ٿو) جي آفيس جي چوٿين يا پنجين منزل تي، ڊاک واري علائقي ۾.

هڪ ڏينهن يونڪس سرور سان گڏ مکيه ڊيٽابيس کي تباهه ڪيو ويو. انهن کيس ريبوٽ ڪيو، پر هو خوشيءَ سان بار بار ڪرندو رهيو. اسان ڪنهن کي فون ڪرڻ جو فيصلو ڪيو سپورٽ سروس مان.

سپورٽ وارو ماڻهو... مان سمجهان ٿو ته هن جو نالو مارڪ هو، پر اهو فرق نٿو پوي... مان نٿو سمجهان ته مان هن کي سڃاڻان. اهو مسئلو ناهي، واقعي. اچو ته مارڪ سان لٺ، ٺيڪ؟ زبردست.

تنهن ڪري، ڪجهه ڪلاڪن بعد مارڪ پهتو (اهو ليڊس کان پورٽسموت تائين ڊگهو رستو نه آهي، توهان کي خبر آهي)، سرور تي ڦيرايو ۽ هر شيء بغير ڪم ڪيو. عام لات جي حمايت، ڪلائنٽ هن بابت تمام پريشان ٿي وڃي ٿي. مارڪ لاگ فائلن جي ذريعي ڏسڻ ۾ اچي ٿو ۽ ڪجھ به ناپسنديده نه ڳولي. پوءِ مارڪ ٽرين تي واپس اچي ٿو (يا ٽرانسپورٽ جي ڪنهن به طريقي تي هو پهتو آهي، اهو سڀني لاءِ هڪ لنگڙي ڳئون ٿي سگهي ٿي جيڪا مون کي خبر آهي ... بهرحال، اهو فرق نٿو پوي، ٺيڪ آهي؟) ۽ برباد ٿي، واپس ليڊس ڏانهن روانو ٿيو. ڏينهن.

ان ئي شام جو سرور ٻيهر حادثو ٿيو. ڪهاڻي ساڳي آهي... سرور نه اڀري. مارڪ ريموٽ مدد ڪرڻ جي ڪوشش ڪري ٿو، پر ڪلائنٽ سرور شروع نٿو ڪري سگھي.

هڪ ٻي ٽرين، بس، ليمن ميرنگو يا ٻيو ڪجهه گپ، ۽ مارڪ واپس پورٽسموت ۾ آهي. ڏس، سرور بغير ڪنهن مسئلي جي بوٽن! معجزو. مارڪ ڪيترن ئي ڪلاڪن کي جانچڻ ۾ گذاريندو آهي ته هر شي آپريٽنگ سسٽم يا سافٽ ويئر سان ترتيب ۾ آهي ۽ ليڊز لاءِ سيٽ ڪري ٿو.

ڏينهن جي وچ ۾ سرور حادثو ٿئي ٿو (ان کي آسان وٺو!). هن ڀيري اهو مناسب لڳي ٿو ته هارڊويئر سپورٽ ماڻهن کي سرور کي تبديل ڪرڻ لاءِ آڻڻ. پر نه، اٽڪل 10 ڪلاڪن کان پوءِ اهو به پوي ٿو.

صورتحال ڪيترن ئي ڏينهن تائين پاڻ کي بار بار ڪيو. سرور ڪم ڪري ٿو، اٽڪل 10 ڪلاڪن کان پوءِ حادثو ٿئي ٿو ۽ ايندڙ 2 ڪلاڪن لاءِ شروع نٿو ٿئي. انهن کولنگ چيڪ ڪيو، ميموري ليڪس، اهي سڀ ڪجهه چيڪ ڪيا، پر ڪجهه به نه مليو. پوءِ حادثا بند ٿي ويا.

هفتو بي پرواهه گذري ويو... سڀ خوش هئا. خوش ٿيو جيستائين اهو سڀ ڪجهه ٻيهر شروع ٿئي. تصوير به ساڳي آهي. 10 ڪلاڪ ڪم، 2-3 ڪلاڪ بند وقت...

۽ پوءِ ڪو ماڻهو (منهنجو خيال آهي ته انهن مون کي ٻڌايو ته هن شخص جو آئي ٽي سان ڪو به واسطو نه هو) چيو:

"اها لهر آهي!"

عجائب گهر خالي نظرن سان ملي ويو هو، ۽ ڪنهن جو هٿ شايد سيڪيورٽي ڪال بٽڻ تي هٻڪندو هو.

"اهو لوڻ سان ڪم ڪرڻ بند ڪري ٿو."

اهو لڳي ٿو هڪ مڪمل طور تي غير ملڪي تصور IT سپورٽ ڪارڪنن لاءِ، جيڪي ڪافي لاءِ ويهڻ وقت ٽائڊ ائر بڪ پڙهڻ جو امڪان ناهن. انهن وضاحت ڪئي ته اهو ڪنهن به طرح سان لڙائي سان لاڳاپيل نه ٿو ٿي سگهي، ڇاڪاڻ ته سرور ناڪامي کان سواء هڪ هفتي تائين ڪم ڪري رهيو هو.

"گذريل هفتي جي لهر گهٽ هئي، پر هن هفتي اهو وڌيڪ آهي."

انهن لاءِ ٿورڙي اصطلاح جن وٽ ياٽ لائسنس نه آهي. لڙڪن جو دارومدار قمري چڪر تي آهي. ۽ جيئن ڌرتي گردش ڪري ٿي، هر 12,5 ڪلاڪن ۾ سج ۽ چنڊ جي ڪشش ثقل جي ڇڪ هڪ سامونڊي لهر پيدا ڪري ٿي. 12,5-ڪلاڪ چڪر جي شروعات ۾ اتي هڪ تيز لھر آھي، چڪر جي وچ ۾ ھڪڙو اڀار آھي، ۽ آخر ۾ وري ھڪڙو تيز لھر آھي. پر جيئن چنڊ ​​جو مدار تبديل ٿئي ٿو، تيئن اوچائي ۽ لوڻ جي وچ ۾ فرق اچي ٿو. جڏهن چنڊ ​​سج ۽ ڌرتيءَ جي وچ ۾ هوندو آهي يا ڌرتيءَ جي سامهون پاسي (مڪمل چنڊ يا چنڊ نه هوندو آهي)، اسان کي سيزيگين ٽائيڊس ملن ٿا - سڀ کان وڌيڪ اونچي لھرون ۽ سڀ کان گھٽ لوڻ. اڌ چنڊ تي اسان کي quadrature tides ملن ٿا - سڀ کان گھٽ لھر. ٻن انتهائن جي وچ ۾ فرق تمام گهڻو گهٽجي ٿو. قمري چڪر 28 ڏينهن تائين رهي ٿو: syzygian - quadrature - syzygian - quadrature.

جڏهن ٽيڪنيشين کي سامونڊي قوتن جي جوهر جي وضاحت ڪئي وئي، انهن فوري طور تي سوچيو ته انهن کي پوليس کي سڏڻ جي ضرورت آهي. ۽ بلڪل منطقي. پر اهو ظاهر ٿيو ته دوست صحيح هو. ٻه هفتا اڳ، هڪ تباهي ڪندڙ آفيس کان پري نه هو. هر دفعي جبل ان کي هڪ خاص اونچائي تائين وڌايو، ٻيڙيء جي ريڊار پوسٽ سرور روم جي فرش جي سطح تي ختم ٿي وئي. ۽ ريڊار (يا اليڪٽرانڪ جنگي سامان، يا ڪجهه ٻيو فوجي رانديڪا) ڪمپيوٽرن ۾ افراتفري پيدا ڪئي.

راڪيٽ لاءِ پرواز جو مشن

مون کي هڪ وڏو (اٽڪل 400 هزار لائينون) راڪيٽ لانچ ڪنٽرول ۽ مانيٽرنگ سسٽم کي پورٽ ڪرڻ جو ڪم سونپيو ويو هو آپريٽنگ سسٽم جي نئين ورزن، ڪمپلر ۽ ٻولي ڏانهن. وڌيڪ واضح طور تي، سولاريس 2.5.1 کان سولاريس 7 تائين، ۽ ورڊيڪس ايڊا ڊولپمينٽ سسٽم (VADS) کان، Ada 83 ۾ لکيل، Rational Apex Ada سسٽم تائين، Ada 95 ۾ لکيل آهي. VADS Rational طرفان خريد ڪيو ويو، ۽ ان جي پيداوار هئي. متروڪ، جيتوڻيڪ Rational ڪوشش ڪئي VADS-مخصوص پيڪيجز جي مطابقت رکندڙ ورزن کي لاڳو ڪرڻ جي لاءِ Apex compiler ڏانهن منتقلي کي آسان ڪرڻ لاءِ.

ٽن ماڻهن مون کي مدد ڪئي صرف ڪوڊ صاف طور تي مرتب ڪيو. ان کي ٻه هفتا لڳا. ۽ پوءِ مون پنهنجو پاڻ تي ڪم ڪيو ته سسٽم کي ڪم ڪرڻ لاءِ. مختصر ۾، اهو هڪ سافٽ ويئر سسٽم جو بدترين فن تعمير ۽ عمل درآمد هو جنهن جو مون سامنا ڪيو هو، تنهن ڪري اهو بندرگاهن کي مڪمل ڪرڻ ۾ ٻه مهينا لڳا. سسٽم پوءِ جاچ لاءِ پيش ڪيو ويو ، جنهن ۾ ڪيترائي مهينا لڳي ويا. مون کي فوري طور تي درست ڪيو ته ڪيڙا جيڪي جاچ دوران مليا هئا، پر انهن جو تعداد جلدي گهٽجي ويو (ذريعو ڪوڊ هڪ پيداوار سسٽم هو، تنهنڪري ان جي ڪارڪردگي ڪافي معتبر طور تي ڪم ڪيو، مون کي صرف انهن مسئلن کي هٽائڻو هو جيڪي نئين ڪمپلر جي موافقت دوران پيدا ٿيا). آخرڪار، جڏهن سڀ ڪجهه ڪم ڪري رهيو هو جيئن اهو ٿيڻ گهرجي، مون کي هڪ ٻئي منصوبي ڏانهن منتقل ڪيو ويو.

۽ شڪرگذاري کان اڳ جمعه تي، فون جي گھنٽي وڳي.

راڪيٽ لانچ کي اٽڪل ٽن هفتن ۾ آزمايو ويندو، ۽ ڳڻپ جي ليبارٽري ٽيسٽ دوران، حڪمن جي ترتيب کي بلاڪ ڪيو ويو. حقيقي زندگي ۾، اهو امتحان کي ختم ڪري ڇڏيندو، ۽ جيڪڏهن انجڻ شروع ٿيڻ جي چند سيڪنڊن اندر رڪاوٽ پيدا ٿي وئي، ته معاون سسٽم ۾ ڪيترائي ناقابل واپسي ڪارناما واقع ٿيندا، جن لاءِ راڪيٽ جي ڊگهي ۽ قيمتي تياري جي ضرورت پوندي. اهو شروع نه ٿئي ها، پر ڪيترائي ماڻهو وقت جي ضايع ٿيڻ ۽ تمام گهڻو، تمام گهڻو پئسو جي باري ۾ تمام گهڻو پريشان ٿين ها. ڪنهن کي به توهان کي ٻڌائڻ نه ڏيو ته ڊپارٽمينٽ آف ڊفينس لاپرواهي سان پئسا خرچ ڪري ٿو- مان ڪڏهن به ڪنهن ٺيڪيدار مئنيجر سان نه مليو آهيان جنهن بجيٽ پهرين يا ٻي نه رکي، شيڊول جي پٺيان.

گذريل مھينن ۾، ھي ڳڻپيوڪر چئلينج سوين ڀيرا ڪيترن ئي مختلف قسمن ۾ ھليو ويو، صرف چند معمولي ھچڪپس سان. تنهن ڪري هن واقعي جو امڪان تمام گهٽ هو، پر ان جا نتيجا تمام اهم هئا. انهن ٻنهي عنصرن کي ضرب ڏيو، ۽ توهان سمجهي سگهندا ته خبر مون لاءِ ۽ ڪيترن ئي انجنيئرن ۽ مئنيجرن لاءِ هڪ تباهه ٿيل موڪل واري هفتي جي اڳڪٿي ڪئي هئي.

۽ ڌيان مون کي ادا ڪيو ويو جيئن شخص جيڪو سسٽم پورٽ ڪيو.

جيئن ته سڀ کان وڌيڪ حفاظتي-نازڪ سسٽم سان، ڪيترائي پيرا ميٽر لاگ ان ڪيا ويا، تنهنڪري اهو ڪافي آسان هو ڪوڊ جي ڪجهه لائينن کي سڃاڻڻ جيڪي سسٽم جي خراب ٿيڻ کان اڳ جاري ڪيا ويا. ۽ يقينا، انهن جي باري ۾ بلڪل ڪا به غير معمولي نه هئي؛ ساڳيا اظهار ڪاميابيء سان لفظي طور تي هزارين ڀيرا ساڳئي رن دوران ڪامياب ٿي چڪا هئا.

اسان ماڻهن کي Apex کان Rational سڏيو آهي ڇاڪاڻ ته اهي ئي هئا جن ڪمپيلر ٺاهيا ۽ انهن مان ڪجهه معمولات جيڪي ٺاهيا هئا انهن کي مشڪوڪ ڪوڊ ۾ سڏيو ويو. اهي (۽ ٻيا سڀ) متاثر ٿيا ته لفظي قومي اهميت واري مسئلي جي پاڙ تائين پهچڻ جي ضرورت هئي.

جيئن ته جرنلز ۾ ڪجھ به دلچسپ نه هو، اسان فيصلو ڪيو ته مسئلي کي مقامي ليبارٽري ۾ ٻيهر پيش ڪرڻ جي ڪوشش ڪئي وڃي. اهو ڪو آسان ڪم نه هو ڇو ته واقعو تقريباً هڪ ڀيرو في 1000 رنسن تي ٿيو. هڪ شڪي سبب اهو هو ته هڪ ڪال هڪ وينڊر جي ترقي يافته ميوٽڪس فنڪشن (VADS لڏپلاڻ واري پيڪيج جو حصو) Unlock ان لاڪ ڪرڻ جي اڳواڻي نه ڪئي. پروسيسنگ ٿريڊ جنهن کي فنڪشن سڏيو ويندو آهي پروسيس ٿيل دل جي ڌڙڪن جا پيغام، جيڪي نامزدگي هر سيڪنڊ ۾ ايندا آهن. اسان فریکوئنسي کي 10 هز تائين وڌايو، يعني 10 ڀيرا في سيڪنڊ، ۽ هلڻ شروع ڪيو. اٽڪل هڪ ڪلاڪ بعد سسٽم پاڻ کي بند ڪري ڇڏيو. لاگ ۾، اسان ڏٺو ته رڪارڊ ٿيل پيغامن جو سلسلو ساڳيو ئي هو جيئن ناڪام ٽيسٽ دوران. اسان ڪيترائي وڌيڪ رنسون ٺاهي، سسٽم کي مسلسل بند ڪيو ويو 45-90 منٽن کان پوء شروع ٿيڻ کان پوء، ۽ هر دفعي لاگ ان ساڳئي رستي تي مشتمل آهي. جيتوڻيڪ اسان ٽيڪنيڪل طور تي مختلف ڪوڊ هلائي رهيا هئاسين - پيغام جي تعدد مختلف هئي - سسٽم جو رويو ساڳيو هو، تنهنڪري اسان کي يقين هو ته هي لوڊ منظر ساڳيو مسئلو پيدا ڪري رهيو هو.

هاڻي اسان کي اهو معلوم ڪرڻو پوندو ته اظهار جي تسلسل ۾ ڪٿي بلاڪنگ واقع ٿي.

سسٽم جي هن عمل کي Ada ٽاسڪ سسٽم استعمال ڪيو، ۽ ان کي ناقابل اعتبار حد تائين خراب طور تي استعمال ڪيو. ٽاسڪ اڊا ۾ هڪ اعلي سطحي هڪجهڙائي سان قابل عمل تعمير آهن، ڪجهه عمل جي سلسلي وانگر، صرف زبان ۾ ٺاهيل آهي. جڏهن ٻن ڪمن کي گفتگو ڪرڻ جي ضرورت آهي، اهي "ملاقات قائم ڪريو"، ضروري ڊيٽا کي مٽائي، ۽ پوء ملاقات کي روڪيو ۽ انهن جي آزاد عملن ڏانهن واپس وڃو. تنهن هوندي به، نظام مختلف طور تي لاڳو ڪيو ويو. هڪ ٽارگيٽ ٽاسڪ ملڻ کان پوءِ، اهو ٽارگيٽ ٽاسڪ ٻئي ٽاسڪ سان ملندو هو، جيڪو پوءِ ٽئين ٽاسڪ سان ملندو هو، ۽ ائين ئي ڪجهه پروسيسنگ مڪمل ٿيڻ تائين. ان کان پوءِ اهي سڀ ملاقاتون پوريون ٿي ويون ۽ هر ڪم کي پنهنجي انجام ڏانهن موٽڻو هو. اهو آهي، اسان دنيا جي سڀ کان مهانگي فنڪشن ڪال سسٽم سان ڊيل ڪري رهيا هئاسين، جنهن سڄي ”ملٽي ٽاسڪنگ“ جي عمل کي روڪي ڇڏيو جڏهن ته اهو ان پٽ ڊيٽا جو حصو پروسيس ڪري رهيو هو. ۽ ان کان اڳ صرف مسئلن جو سبب نه بڻيو ڇاڪاڻ ته throughput تمام گهٽ هو.

مون هن ٽاسڪ ميڪانيزم کي بيان ڪيو آهي ڇاڪاڻ ته جڏهن هڪ ملاقات جي درخواست ڪئي وئي هئي يا مڪمل ٿيڻ جي اميد هئي، هڪ "ٽاسڪ سوئچ" ٿي سگهي ٿو. اھو آھي، پروسيسر ھڪڙي ٻئي ڪم کي پروسيسنگ شروع ڪري سگھي ٿو جيڪو عمل ڪرڻ لاء تيار آھي. اهو ظاهر ٿئي ٿو ته جڏهن هڪ ڪم ٻئي ڪم سان ملڻ لاء تيار آهي، هڪ مڪمل طور تي مختلف ڪم تي عمل ڪرڻ شروع ڪري سگهي ٿو، ۽ آخرڪار ڪنٽرول واپسي جي پهرين ملاقات ڏانهن واپسي. ۽ ٻيا واقعا ٿي سگھن ٿا جيڪي ڪم کي تبديل ڪرڻ جو سبب بڻجن؛ هڪ اهڙو واقعو هڪ سسٽم جي فنڪشن لاء هڪ ڪال آهي، جهڙوڪ پرنٽ ڪرڻ يا هڪ ميوٽڪس تي عمل ڪرڻ.

سمجھڻ لاءِ ته ڪوڊ جو ڪھڙو لڪير مسئلو پيدا ڪري رھيو ھو، مون کي ضرورت ھئي بيانن جي تسلسل ذريعي پيش رفت کي رڪارڊ ڪرڻ جو رستو ڳولڻ جي بغير ٽاسڪ سوئچ کي، جيڪو حادثي ٿيڻ کان روڪيندو. تنهنڪري مان فائدو وٺي نه سگهيس Put_Line()I/O آپريشن ڪرڻ کان بچڻ لاءِ. مان هڪ ڪائونٽر ويريئبل يا ڪا اهڙي شيءِ سيٽ ڪري سگهان ٿو، پر جيڪڏهن مان ان کي اسڪرين تي ظاهر نه ڪري سگهان ته مان ان جي قيمت ڪيئن ڏسي سگهان ٿو؟

انهي سان گڏ، جڏهن لاگ جي جانچ ڪئي وئي، اهو ظاهر ٿيو ته، دل جي ڌڙڪن پيغامن جي پروسيسنگ ۾ منجمد ٿيڻ جي باوجود، جنهن عمل جي سڀني I/O عملن کي بلاڪ ڪيو ۽ ٻين پروسيسنگ کي انجام ڏيڻ کان روڪيو، ٻيا آزاد ڪم جاري ڪيا ويا. اهو آهي، ڪم مڪمل طور تي بند نه ڪيو ويو، صرف ڪمن جو هڪ (نازڪ) سلسلو.

اهو اشارو هو ته بلاڪنگ اظهار جي تشخيص ڪرڻ جي ضرورت هئي.

مون هڪ Ada پيڪيج ٺاهيو جنهن ۾ هڪ ٽاسڪ، هڪ ڳڻپيوڪر قسم، ۽ ان قسم جو هڪ گلوبل متغير شامل هو. ڳڻپيوڪر لغوي مسئلن جي ترتيب جي مخصوص اظهار سان پابند هئا (مثال طور. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked)، ۽ پوء ان ۾ شامل ڪيل تفويض جو اظهار شامل ڪيو ويو آهي جنهن سان لاڳاپيل انگن اکرن کي عالمي متغير ڏانهن لڳايو ويو آهي. جيئن ته هن سڀني جو اعتراض ڪوڊ صرف ميموري ۾ هڪ مستقل ذخيرو ٿيل آهي، ان جي عمل جي نتيجي ۾ ٽاسڪ سوئچنگ بلڪل ممڪن نه هو. اسان بنيادي طور تي مشڪوڪ هئا اظهار جي باري ۾ جيڪي ٽاسڪ کي تبديل ڪري سگھن ٿا، ڇو ته بلاڪنگ تي عمل ٿيڻ جي بدران واپسي جي بدران واپسي تي عمل ڪيو ويو (ڪيترن ئي سببن لاء).

ٽريڪنگ جو ڪم صرف هڪ لوپ ۾ هليو ويو ۽ وقتي طور تي چڪاس ڪيو ويو ته ڇا عالمي متغير جو قدر تبديل ٿي چڪو آهي. هر تبديلي سان، قدر هڪ فائل ۾ محفوظ ڪيو ويو. پوء هڪ مختصر انتظار ۽ هڪ نئين چيڪ. مون فائل ۾ متغير لکيو ڇاڪاڻ ته اهو ڪم صرف ان وقت ڪيو ويو جڏهن سسٽم ان کي عمل لاءِ چونڊيو جڏهن ٽاسڪ کي مسئلي واري علائقي ۾ تبديل ڪيو. هن ڪم ۾ جيڪو به ٿيو سو ٻين، غير لاڳاپيل بند ٿيل ڪمن تي اثر انداز نه ٿيندو.

اها توقع ڪئي وئي ته جڏهن سسٽم مسئلي واري ڪوڊ کي عمل ڪرڻ جي نقطي تي پهچي، عالمي متغير کي ريٽ ڪيو ويندو جڏهن هر ايندڙ اظهار ڏانهن منتقل ڪيو ويندو. پوءِ ڪجهه ٿيندو جيڪو ٽاسڪ کي مٽائڻ جو سبب بڻجندو، ۽ جيئن ته ان جي عمل جي تعدد (10 هز) مانيٽرنگ ٽاسڪ کان گهٽ آهي، ان ڪري مانيٽر گلوبل ويريئبل جي قدر کي پڪڙي سگهي ٿو ۽ ان کي لکي سگهي ٿو. عام صورتحال ۾، مان حاصل ڪري سگھان ٿو ورجائڻ واري ترتيب کي ڳڻپ جي ذيلي سيٽ جو: ٽاسڪ سوئچ جي وقت متغير جا آخري قدر. جڏهن پھانسي، عالمي متغير کي وڌيڪ تبديل نه ٿيڻ گھرجي، ۽ آخري قدر لکيل آھي اھو ظاھر ڪندو ته ڪھڙي اظهار مڪمل نه ڪئي.

مون ٽريڪنگ سان ڪوڊ ڊوڙايو. هو ٿڪجي پيو. ۽ نگراني ڪلاڪ ڪم وانگر ڪم ڪيو.

لاگ ان متوقع تسلسل تي مشتمل آهي، جنهن ۾ هڪ قدر جي مداخلت ڪئي وئي هئي جنهن مان ظاهر ٿئي ٿو ته هڪ ميوٽڪس کي سڏيو ويو آهي Unlock، ۽ ڪم مڪمل نه ٿيو آهي - جيئن ته هزارين پوئين ڪالن سان معاملو آهي.

اپيڪس انجنيئر هن وقت پنهنجي ڪوڊ کي تيزيءَ سان تجزيو ڪري رهيا هئا ۽ ميوٽڪس ۾ هڪ جاءِ مليا جتي نظرياتي طور تي تالا ٿي سگهي ٿو. پر ان جو امڪان تمام گهٽ هو، ڇاڪاڻ ته ڪنهن خاص وقت تي واقعن جو صرف هڪ خاص سلسلو بلاڪ ٿيڻ جو سبب بڻجي سگهي ٿو. مرفي جو قانون، دوستو، اهو مرفي جو قانون آهي.

ڪوڊ جي ٽڪرا کي بچائڻ لاءِ مون کي ضرورت هئي، مون ميوٽڪس فنڪشن ڪالز کي تبديل ڪيو (او ايس ميوٽڪس فنڪشنلٽي جي چوٽي تي ٺهيل) هڪ ننڍڙي اصلي Ada mutex پيڪيج سان انهي ٽڪري تائين ميٽيڪس رسائي کي ڪنٽرول ڪرڻ لاءِ.

مون ان کي ڪوڊ ۾ داخل ڪيو ۽ امتحان ورتو. ست ڪلاڪ بعد ڪوڊ اڃا ڪم ڪري رهيو هو.

منهنجو ڪوڊ Rational ڏانهن جمع ڪيو ويو، جتي انهن ان کي مرتب ڪيو، ان کي جدا ڪيو، ۽ چيڪ ڪيو ته اهو ساڳيو طريقو استعمال نه ڪيو ويو آهي جيڪو مشڪلاتي ميوٽڪس افعال ۾ استعمال ڪيو ويو هو.

هي منهنجي ڪيريئر جو سڀ کان وڌيڪ ڀريل ڪوڊ جائزو هو 🙂 مون سان گڏ ڪمري ۾ اٽڪل ڏهه انجنيئر ۽ مئنيجر هئا، ٻيا ڏهه ماڻهو ڪانفرنس ڪال تي هئا - ۽ انهن سڀني ڪوڊ جي اٽڪل 20 لائنن جو جائزو ورتو.

ڪوڊ جو جائزو ورتو ويو، نون قابل عمل فائلون گڏ ڪيون ويون ۽ رسمي ريگريشن جاچ لاءِ پيش ڪيون ويون. ڪجهه هفتن کان پوء، ڳڻپيوڪر ٽيسٽ ڪامياب ٿي ويو ۽ راڪيٽ هليو ويو.

ٺيڪ آهي، اهو سڀ ڪجهه سٺو ۽ سٺو آهي، پر ڪهاڻي جو مقصد ڇا آهي؟

اهو هڪ تمام ناپسنديده مسئلو هو. لکن جون لائينون ڪوڊ، متوازي عملدرآمد، درجن کان وڌيڪ رابطي واري عمل، خراب فن تعمير ۽ خراب عمل درآمد، ايمبيڊڊ سسٽم لاءِ انٽرفيس ۽ لکين ڊالر خرچ ڪيا ويا. ڪوبه دٻاءُ نه، صحيح.

مان اڪيلو نه هو هن مسئلي تي ڪم ڪري رهيو آهيان، جيتوڻيڪ آئون اسپاٽ لائٽ ۾ هوس جيئن مان پورٽنگ ڪري رهيو هوس. پر ان جي باوجود مون اهو ڪيو، ان جو مطلب اهو ناهي ته مون ڪوڊ جون سڀ سوين هزارين لائينون سمجهي ورتيون، يا انهن کي به اسڪيم ڪيو. ڪوڊ ۽ لاگز کي سڄي ملڪ ۾ انجنيئرن پاران تجزيو ڪيو ويو، پر جڏهن انهن مون کي ناڪامي جي سببن بابت پنهنجن فرضن کي ٻڌايو، انهن کي رد ڪرڻ ۾ صرف اڌ منٽ ورتو. ۽ جڏهن مون کي نظريات جو تجزيو ڪرڻ لاءِ چيو ويندو هو، ته مان ان کي ڪنهن ٻئي جي حوالي ڪري ڇڏيندس، ڇاڪاڻ ته اهو مون لاءِ واضح هو ته اهي انجنيئر غلط رستو وٺي رهيا هئا. آواز مغرور؟ ها، اهو سچ آهي، پر مون هڪ ٻئي سبب جي ڪري مفروضن ۽ درخواستن کي رد ڪيو.

مون مسئلي جي نوعيت کي سمجهي ورتو. مون کي خبر نه هئي ته اهو ڪٿي ٿي رهيو آهي يا ڇو، پر مون کي خبر هئي ته ڇا ٿي رهيو آهي.

ڪيترن سالن کان، مون تمام گهڻو علم ۽ تجربو گڏ ڪيو آهي. مان اڊا استعمال ڪرڻ جي اڳڪٿي ڪندڙن مان ھڪڙو ھوس ۽ ان جي فائدن ۽ نقصانن کي سمجھندو ھوس. مون کي خبر آهي ته Ada رن ٽائم لائبريريون ڪم ڪيئن سنڀالينديون آهن ۽ متوازي عمل سان ڊيل ڪنديون آهن. ۽ مان سمجهان ٿو گھٽ سطح جي پروگرامنگ کي ميموري جي سطح تي، رجسٽر ۽ اسمبلر. ٻين لفظن ۾، مون کي پنهنجي فيلڊ ۾ تمام گهڻي ڄاڻ آهي. ۽ مون ان کي استعمال ڪيو مسئلو جو سبب ڳولڻ لاءِ. مون صرف بگ جي چوڌاري ڪم نه ڪيو، مون سمجهيو ته ان کي ڪيئن ڳولجي ان کي انتهائي حساس رن ٽائم ماحول ۾.

ڪوڊ سان جدوجهد جون اهڙيون ڳالهيون انهن لاءِ ڪيڏيون دلچسپ نه هونديون آهن جيڪي اهڙي جدوجهد جي خاصيتن ۽ حالتن کان واقف نه هوندا آهن. پر اهي ڪهاڻيون اسان کي سمجهڻ ۾ مدد ڪن ٿيون ته اهو واقعي مشڪل مسئلن کي حل ڪرڻ لاءِ ڇا وٺندو آهي.

واقعي سخت مسئلا حل ڪرڻ لاءِ، توهان کي صرف هڪ پروگرامر کان وڌيڪ هجڻ جي ضرورت آهي. توهان کي ڪوڊ جي ”قسمت“ کي سمجهڻ جي ضرورت آهي، اهو ڪيئن پنهنجي ماحول سان لاڳاپو رکي ٿو، ۽ ماحول پاڻ ڪيئن ڪم ڪري ٿو.

۽ پوءِ توھان وٽ توھان جي پنھنجي برباد ٿيل موڪلن واري ھفتي آھي.

جاري رکڻ لاء

جو ذريعو: www.habr.com