> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# البيض المخفي Easter Eggs: من Atari إلى محاكي الطيران في Excel
- URL: https://arabroot.io/articles/البيض-المخفي-easter-eggs-في-البرمجيات/
- Published: 2026-10-31T07:24:46.000Z
- Updated: 2026-10-31T08:25:54.000Z
- Description: قصة الكود الذي أخفاه المبرمجون داخل البرامج، من توقيع Warren Robinett في Atari إلى ألعاب Office، ولماذا منعته Microsoft وما الذي يقوله عن المراجعة والأمان وثقافة الفريق.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, قصص وتحقيقات

إذا كنت ممن استخدموا Office 97 في نهاية التسعينيات، فربما سمعت من زميل في المدرسة أو في العمل أن داخل Excel محاكي طيران كاملاً، وأنك إذا كتبت شيئاً معيناً في خانة معينة ثم ضغطت مفتاحين مع زر الرسوم البيانية فسوف تجد نفسك تطير فوق أرض غريبة. كثير منا جرب الخطوات من ورقة مطبوعة أو من مجلة حاسب، وكثير منا لم يصدق حتى رأى الشاشة تتغير. ثم اختفت هذه الأشياء من البرامج بهدوء، ولم يعد أحد يتحدث عنها إلا كذكرى. هذا المقال عن تلك الأشياء: الكود الذي كتبه المبرمجون داخل البرامج دون أن يطلبه أحد، ويسمى البيض المخفي Easter Eggs، من أين جاء، ولماذا توقف في Microsoft، وما الذي بقي منه اليوم.

والقصة ليست حنيناً فقط، فخلف كل بيضة سؤال هندسي جاد: كيف وصل كود لم يكتب له أحد مواصفة ولم يختبره فريق الجودة إلى ملايين الأجهزة؟ ومن راجعه؟ وماذا لو كان فيه خطأ أمني؟ والإجابة عن هذه الأسئلة هي ما يجعل القصة مهمة لكل من يعمل اليوم في فريق برمجي، سواءً كان يكتب الكود أو يراجعه أو يقرر ما الذي يصل إلى العميل.

وكل ما في هذا المقال مأخوذ من مصادر منشورة: محاضرة [Warren Robinett في مؤتمر GDC سنة 2015](https://www.gdcvault.com/play/1021860/Classic-Game-Postmortem?ref=arabroot.io) عن لعبته Adventure، ومقال [متحف The Strong للعب](https://www.museumofplay.org/blog/hunting-for-easter-eggs/?ref=arabroot.io)، وتدوينتا Larry Osterman من مهندسي Microsoft: [Early Easter Eggs](https://learn.microsoft.com/en-us/archive/blogs/larryosterman/early-easter-eggs?ref=arabroot.io) و[Why no Easter Eggs?](https://learn.microsoft.com/en-us/archive/blogs/larryosterman/why-no-easter-eggs?ref=arabroot.io) في أكتوبر 2005، ومدونة Raymond Chen الشهيرة The Old New Thing، وتحليل الباحث Geoff Chappell لملفات Windows 95\. أما البيض الحديث فقد شغلناه بأنفسنا في Chrome وFirefox وحاوية Debian، والصور التي تراها لها من تشغيلنا الفعلي. ولن تجد في المقال صوراً من Office أو Windows القديمة، لأنها ليست صوراً حرة، فوصفناها بالكلمات وبرسومات من عندنا.

وسوف نناقش في هذا المقال ما يلي:

- ما هو البيض المخفي، ومن أين جاءت التسمية.
- غرفة Warren Robinett السرية في لعبة Adventure على Atari 2600، ولماذا أخفى اسمه.
- بيض Microsoft الأول: من أمر RECOVER في MS-DOS إلى الدب في Windows 3.1 وشاشة أسماء Windows 95.
- الألعاب الكاملة داخل Office: متاهة Excel 95، ومحاكي الطيران في Excel 97، ولعبة Pinball في Word 97، ولعبة Dev Hunter في Excel 2000.
- مذكرة Bill Gates عن الحوسبة الجديرة بالثقة Trustworthy Computing، وما كتبه مهندسو Microsoft أنفسهم عن سبب المنع.
- البيض من زاوية الأمن ومراجعة الكود.
- البيض الذي يمكنك تشغيله اليوم، مع ما ظهر لنا فعلاً عند تشغيله.
- ما الذي يقوله البيض عن ثقافة الفريق، وقائمة قرار لفريقك.

والصورة التالية تجمع المحطات التي سوف نمر عليها:

![خط زمني للبيض المخفي في ثلاث مراحل: التوقيع السري من لعبة Adventure في 1979 واكتشافها في 1980 ثم MS-DOS 2.0 في 1983 وWindows 3.1 في 1992 وNT 3.1 في 1993، ثم الألعاب الكاملة داخل Office من Windows 95 وExcel 95 في 1995 إلى Excel 97 وWord 97 وExchange 5.0 في 1997 وExcel 2000 في 1999، ثم المنع والبيض المعلن من مذكرة Trustworthy Computing في 2002 وتدوينة Larry Osterman في 2005 إلى ديناصور Chrome في 2014 والبيض في المشاريع مفتوحة المصدر اليوم](https://arabroot.io/content/images/2026/10/software-easter-eggs-01-timeline.webp)

من توقيع سري في لعبة إلى سياسة منع في Microsoft، ثم بيض معلن في كود مفتوح

## ما هو البيض المخفي Easter Egg؟

البيضة في البرمجيات هي سلوك مخفي داخل برنامج، لا يظهر في القوائم ولا في التوثيق، ولا يصل إليه المستخدم إلا بتسلسل خطوات محدد: ضغط مفاتيح معينة معاً، أو كتابة كلمة في مكان غير متوقع، أو النقر على شعار في نافذة «حول البرنامج» About بطريقة معينة. والنتيجة غالباً شيء لا علاقة له بوظيفة البرنامج: قائمة بأسماء الفريق، أو رسالة مزاح، أو لعبة كاملة. والتسمية جاءت من عادة بعض العائلات في الغرب إخفاء بيض ملون في الحديقة في عيد الفصح ليبحث عنه الأطفال، فالفكرة واحدة: شيء مخبأ لمن يبحث عنه.

وحتى نكون دقيقين، هناك ثلاثة أشياء قريبة من البيضة ولكنها مختلفة عنها. الأول هو الخطأ البرمجي Bug، وهو سلوك لم يقصده أحد. والثاني هو الميزة غير الموثقة Undocumented Feature، وهي وظيفة حقيقية لها فائدة ولكن الشركة لم تكتب عنها. والثالث هو الباب الخلفي Backdoor، وهو كود مخفي هدفه تجاوز الحماية. والبيضة تشترك مع الثلاثة في صفة واحدة مهمة: أنها كود يعمل على جهازك دون أن تعرف به، وهذه الصفة هي التي سوف تنهي عصرها في Microsoft كما سنرى.

وتذكر Atari في مدونتها الرسمية أن التسمية نفسها لم تكن موجودة عندما ظهرت أول بيضة معروفة في ألعاب الأجهزة المنزلية، وأن موظفاً في الشركة اسمه Steve Wright هو على الأغلب من سماها كذلك بعد اكتشافها، لأن الأشياء المخبأة في الألعاب بالنسبة له تشبه البيض الذي يبحث عنه اللاعبون. وهذه البيضة الأولى هي بداية قصتنا.

## غرفة Warren Robinett السرية: توقيع Signature في لعبة Adventure

في نهاية السبعينيات كانت شركة Atari تبيع جهاز الألعاب Atari 2600 الذي تدخل فيه الألعاب على شكل خراطيش Cartridges، وكان Warren Robinett مبرمجاً شاباً في الشركة يكتب لعبة اسمها Adventure. وكما يذكر Robinett في موقعه الشخصي، صدرت اللعبة في 1979 وباعت قرابة مليون نسخة، وكانت أول لعبة من نوع الحركة والمغامرة Action-Adventure، حيث يتنقل اللاعب بين عدة شاشات ويحمل أشياء من مكان إلى آخر، وهي الفكرة التي سوف تبني عليها ألعاب مثل The Legend of Zelda لاحقاً.

![جهاز ألعاب Atari 2600 بواجهة خشبية وأربعة مفاتيح فضية في الأعلى، وبجانبه عصا تحكم Joystick سوداء بزر أحمر ووحدة تحكم دوارة](https://arabroot.io/content/images/2026/10/software-easter-eggs-12-atari-2600.webp)

جهاز Atari 2600 مع عصا التحكم، وهو الجهاز الذي عملت عليه لعبة Adventure. الصورة: Evan-Amos، ملكية عامة Public Domain، المصدر: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Atari-2600-Wood-4Sw-Set.jpg?ref=arabroot.io) (تم تصغيرها وتحويلها إلى WebP).

والقيود التقنية في ذلك الوقت تبدو اليوم غير معقولة. فحسب صفحة [محاضرة GDC](https://www.gdcvault.com/play/1021860/Classic-Game-Postmortem?ref=arabroot.io)، كان على اللعبة كلها أن تدخل في شريحة ذاكرة قراءة فقط ROM حجمها 4 كيلوبايت، أي 4,096 بايت، وفيها 30 غرفة و18 كائناً من 12 نوعاً: المربع الذي يمثل اللاعب، والكأس الذي يبحث عنه، وثلاث قلاع بمفاتيحها، وثلاثة تنانين وسيف، وخفاش يسرق ما تحمله، ومغناطيس وجسر. ويذكر Robinett في موقعه أن ذاكرة المتغيرات RAM كانت 128 بايت فقط، وأن المعالج 6502 بسرعة 1.2 ميجاهرتز. ولاحظ أن هذه الصفحة التي تقرأها الآن أكبر من اللعبة كلها بعشرات المرات.

### لماذا أخفى اسمه؟ الاعتراف Credit بعمل المطور

السبب بسيط ومؤلم: Atari في ذلك الوقت لم تكن تذكر أسماء مطوري ألعابها، لا على العلبة ولا في اللعبة. وتقول صفحة [محاضرة GDC](https://www.gdcvault.com/play/1021860/Classic-Game-Postmortem?ref=arabroot.io) إن Robinett أخفى شاشة تكشف اسمه وأنه صاحب اللعبة «في وقت لم تكن Atari مستعدة فيه لنسب الألعاب إلى صانعيها علناً»، وإن جهده هذا ساهم في معركة المطورين لنيل الاعتراف بعملهم. وفي [لقاء مع إذاعة WBUR سنة 2016](https://www.wbur.org/hereandnow/2016/12/21/atari-secret-room?ref=arabroot.io) روى Robinett القصة نفسها: لم يحصل على ذكر لاسمه فغضب، فصنع غرفة سرية وكتب فيها اسمه.

![Warren Robinett يقف على مسرح مؤتمر GDC 2015 خلف منصة حمراء عليها شعار المؤتمر، يرفع يده اليمنى ويرتدي قميصاً أخضر مخططاً، وخلفه ستارة حمراء](https://arabroot.io/content/images/2026/10/software-easter-eggs-13-robinett-gdc-2015.webp)

Warren Robinett في محاضرته عن صناعة Adventure في مؤتمر GDC في مارس 2015\. الصورة: Official GDC، رخصة [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/?ref=arabroot.io)، المصدر: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Classic%5FGame%5FPostmortem-%5FAdventure%5F%2816119757653%29.jpg?ref=arabroot.io) (تم قصها وتصغيرها وتحويلها إلى WebP).

### النقطة الرمادية Grey Dot: كيف تصل إلى الغرفة؟

والطريقة التي أخفى بها الغرفة ذكية بقدر ما هي بسيطة. فكما يشرح [متحف The Strong](https://www.museumofplay.org/blog/hunting-for-easter-eggs/?ref=arabroot.io)، وضع Robinett في اللعبة كائناً حجمه بكسل واحد اسمه النقطة الرمادية Grey Dot، ولونه مثل لون الجدران تقريباً، فلا يراه اللاعب إلا إذا كان يبحث عنه. فإذا وجد اللاعب النقطة وحملها إلى المكان الصحيح، استطاع أن يعبر من خلال جدار لا يعبره أحد، ويدخل غرفة مكتوب فيها بخط عمودي: Created by Warren Robinett.

![شاشة من لعبة Adventure: أرضية رمادية بين شريطين بنفسجيين في الأعلى والأسفل، وفي الوسط نص عمودي بحروف زرقاء كبيرة مكتوب فيه Created by Warren Robinett، ومربع بنفسجي صغير يمثل اللاعب على اليسار](https://arabroot.io/content/images/2026/10/software-easter-eggs-14-adventure-room.webp)

الغرفة السرية في Adventure كما تظهر في اللعبة: توقيع عمودي في غرفة لا يدخلها إلا من وجد النقطة الرمادية. الصورة: ملكية عامة Public Domain لأنها نص بسيط، المصدر: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Adventure%5FEasteregg.PNG?ref=arabroot.io) (تم تكبيرها وتحويلها إلى WebP).

وهنا لاحظ شيئاً مهماً من زاوية الهندسة: في لعبة حجمها 4 كيلوبايت، كل بايت له ثمن، ومع ذلك وجد Robinett مكاناً لكائن إضافي وغرفة إضافية ونص، ولم يلاحظ أحد في Atari ذلك قبل أن تصنع الشركة الخراطيش وتبيعها. أي أن الكود دخل المنتج النهائي دون أن يراجعه أحد مراجعة تكشفه، وهذه أول ملاحظة سوف تتكرر في كل قصة بعدها.

### ماذا فعلت Atari بعد الاكتشاف؟

يذكر [متحف The Strong](https://www.museumofplay.org/blog/hunting-for-easter-eggs/?ref=arabroot.io) أن إدارة Atari لم تكن تعرف بوجود الغرفة حتى أرسل لها لاعب عمره 15 سنة رسالة يشرح فيها كيف وصل إليها، وفكرت الشركة في إعادة إنتاج اللعبة لحذف البيضة أو تغييرها، ولكنها وجدت أن ذلك مكلف جداً، فتركتها كما هي. ثم حدث العكس تماماً: صارت الأشياء المخبأة عادة في ألعاب Atari ثم في الصناعة كلها، لأن اللاعبين أحبوا البحث عنها.

والدرس الأول من هذه القصة لا يخص الأمان، وإنما يخص الإدارة: المبرمج الذي لا يجد اسمه على عمله سوف يجد طريقة ليضعه بنفسه. فالبيضة الأولى في ألعاب الأجهزة المنزلية لم تكن مزحة، وإنما احتجاج صامت على عدم الاعتراف، وسوف نعود إلى هذه الفكرة عندما نتحدث عن ثقافة الفريق.

## بيض Microsoft الأول: من MS-DOS إلى Windows 3.1

في Microsoft بدأت القصة مبكراً جداً. فيروي Larry Osterman، وهو مهندس قضى عقوداً في الشركة، في تدوينة [Early Easter Eggs](https://learn.microsoft.com/en-us/archive/blogs/larryosterman/early-easter-eggs?ref=arabroot.io) أن أقدم بيضة يعرفها في MS-DOS كانت في أمر `RECOVER`. وهذا الأمر كان يفترض أن يستعيد البيانات المقروءة من ملف فيه قطاعات تالفة Bad Sectors، ولكنه إذا شغلته على القرص كله كان يجمع كل الملفات من كل المجلدات في المجلد الرئيسي ويسميها بأسماء مثل `FILE0001.REC`، أي أنه يحول قرصك المنظم إلى كومة ملفات بلا أسماء. وقبل أن يفعل ذلك كان يسألك: هل تريد الاستمرار (Y/N)؟

وفي هذا السؤال بالذات كانت البيضة: في MS-DOS 2.0 فقط، إذا ضغطت Ctrl مع حرف معين عند هذا السؤال، يطبع الأمر رسالة فيها الاسم المختصر لأحد المطورين وعبارة «Microsoft Rules!». ويقول Osterman إنه لا يعرف أحداً وصل إلى هذه البيضة بالطريقة الصحيحة، ولكن Peter Norton، صاحب أدوات Norton الشهيرة، كتب عنها في عمود صحفي بعد أن وجد نصها بأداة `strings` التي تطبع كل النصوص المقروءة داخل الملف التنفيذي. وهذه ملاحظة تقنية تستحق الانتباه: البيضة كانت مخفية عن المستخدم، ولكنها لم تكن مخفية عمن يقرأ الملف نفسه، وهذا ما يفعله المهاجمون والباحثون الأمنيون كل يوم.

### الدب Bear في Windows 3.1

في Windows 3.1 الذي صدر في 1992 أصبحت البيضة أكبر بكثير. فحسب [أرشيف eeggs.com](https://eeggs.com/items/469.html?ref=arabroot.io) الذي جمع خطوات البيض في تلك الفترة، كنت تضغط Ctrl وAlt وShift معاً، ثم تفتح نافذة About Program Manager من قائمة المساعدة، وتنقر نقراً مزدوجاً على أحد ألوان شعار Windows، وتكرر ذلك ثلاث مرات. في المرة الأولى يظهر إهداء، وفي الثانية علم Windows يرفرف، وفي الثالثة شخصية كرتونية تقف أمام سبورة تمر عليها أسماء المبرمجين.

وأحد الوجوه التي قد تظهر في تلك الشاشة دب. ويشرح Raymond Chen، أحد أقدم مهندسي فريق Windows، في تدوينة [Why does Windows 95 have functions called BEAR, BUNNY and PIGLET?](https://devblogs.microsoft.com/oldnewthing/20030818-00/?p=42873&ref=arabroot.io) أن Bear كان تميمة فريق Windows 3.1، وهو دب محشو كان يحمله Dave، أحد كبار المبرمجين في الفريق، وأن من يشغل بيضة Windows 3.1 سوف يرى رسماً كرتونياً لهذا الدب. والطريف أن الدب ترك أثراً في الكود نفسه، فهناك دوال في مكتبات واجهة Windows 95 اسمها BEAR وBUNNY على اسم دمى الفريق، ودوال في النواة اسمها PIGLET على اسم دمية مبرمج آخر.

وهذه التفاصيل الصغيرة تقول لك الكثير عن الفريق في تلك الفترة: مجموعة صغيرة نسبياً، تعرف بعضها جيداً، وتعتبر الكود مكاناً شخصياً تترك فيه آثارها. وهي نفس الثقافة التي أنتجت بيضة أخرى في Windows NT 3.1، حيث كانت عبارة I LOVE NT تفتح بيضة فيها أسماء الفريق، وقد كتبنا قصة ذلك الفريق في مقال [قصة Windows NT وDave Cutler](https://arabroot.io/articles/%D9%82%D8%B5%D8%A9-windows-nt-%D9%88-dave-cutler/). ولهذه البيضة بالذات قصة أخرى سوف نصل إليها في قسم الأمان.

## شاشة أسماء فريق Windows 95: البيضة المكتوبة بلغة C++

في Windows 95 وصلت شاشة الأسماء إلى أشهر أشكالها. فإذا أنشأت مجلداً جديداً على سطح المكتب ثم غيرت اسمه ثلاث مرات متتالية إلى ثلاث عبارات محددة، ثم فتحته، فإنك لا ترى ملفات، وإنما أسماء فريق Windows 95 تطفو فوق سماء زرقاء فيها سحب، مع موسيقى هادئة. وقد شرح الباحث Geoff Chappell، الذي قضى سنوات في تحليل ملفات Windows، هذه الآلية بالتفصيل في صفحة [The Windows 95 Easter Egg](https://geoffchappell.com/notes/windows/retro/windows95easteregg.htm?ref=arabroot.io).

والتفاصيل التقنية في تحليله مثيرة للاهتمام، لأنها تبين أن من كتب البيضة فكر في إخفائها جيداً:

- الكود موجود داخل الملف `SHELL32.DLL`، أي داخل الواجهة الرسومية نفسها التي تعرض سطح المكتب والمجلدات.
- العبارات الثلاث التي تكتبها لا توجد في الملف كنص يمكن أن تجده أداة مثل `strings`، وإنما الملف يحفظ ثلاث بصمات Hash بطول 32 بت، ويحسب بصمة كل اسم جديد تكتبه ويقارنها، مع عداد يتابع عمليات إعادة التسمية.
- نص الأسماء نفسه محفوظ في مورد Resource داخل الملف بعد عملية XOR مع القيمة `0x95`، فلا يظهر هو أيضاً كنص مقروء.
- والموسيقى ملف MIDI اسمه `Clouds.mid`.

ويضيف Chappell ملاحظة عن الحجم: بحسب عده، تأخذ البيضة قرابة 58 كيلوبايت داخل `SHELL32.DLL`، إضافة إلى ملف الموسيقى والصور، وهو رقم أكبر بكثير من التقدير الذي ذكر علناً في تلك الفترة. وفي جهاز كان يأتي بذاكرة 4 أو 8 ميجابايت، هذا ليس رقماً صغيراً. ويذكر Chappell أيضاً أن الخطوات انتشرت في مجلات مثل InfoWorld وNewsweek خلال أسابيع من صدور النظام في 1995، أي أن السر لم يبق سراً طويلاً.

![مقارنة بين تسلسل تفعيل بيضتين: في Excel 97 تفتح ورقة جديدة وتضغط F5 وتكتب X97:L97 ثم Enter ثم Tab لتصبح الخلية النشطة M97 ثم تضغط Ctrl وShift مع زر Chart Wizard فيظهر عالم ثلاثي الأبعاد إذا كان DirectDraw مثبتاً، وفي Windows 95 تنشئ مجلداً وتغير اسمه ثلاث مرات إلى ثلاث عبارات إنجليزية فيقارن SHELL32 بصمات Hash ثم تفتح المجلد فتظهر أسماء الفريق فوق السحب مع موسيقى Clouds.mid](https://arabroot.io/content/images/2026/10/software-easter-eggs-02-excel97-trigger.webp)

لا قائمة ولا زر: تسلسل خطوات يتحقق منه الكود في كل مرة، ولا يصل إليه أحد بالصدفة

أما كيف دخلت البيضة إلى النظام، فيرويها Raymond Chen بنفسه في تدوينة [How to sneak the Windows 95 credits screen into the build without anybody noticing](https://devblogs.microsoft.com/oldnewthing/20210824-00/?p=105602&ref=arabroot.io) في 2021\. ويقول إن كود شاشة الأسماء كان الجزء الوحيد المكتوب بلغة C++ في واجهة Windows 95، بينما كتب الباقي بلغة C مع قليل من لغة التجميع Assembly، وإن اختيار C++ كان في ذلك الوقت اختياراً على حافة التقنية، لأن اللغة لم تكن قد وصلت إلى معيار رسمي بعد. ويصحح Chen في نفس التدوينة فكرة شائعة، فالإدارة لم تكن جاهلة تماماً بالأمر، وكان هناك مدير يعرف بشاشة الأسماء، وهو نفسه جلس مع من كتبوها ليراجع قائمة الأسماء التي سوف تظهر.

وهنا نصل إلى نقطة دقيقة: هل كانت بيضة Windows 95 كوداً مخفياً عن الشركة؟ ليس تماماً، فبعض المديرين كانوا يعرفون. ولكنها كانت مخفية عن العميل، وغير موثقة، ولم تمر على نفس مسار الاختبار الذي تمر عليه أي ميزة في النظام. وهذا الفرق بين «مخفي عن الإدارة» و«مخفي عن العميل» هو ما سوف يركز عليه Osterman لاحقاً.

## ألعاب كاملة داخل Office: من Excel 95 إلى Excel 2000

إذا كانت شاشات الأسماء في Windows صغيرة نسبياً، فإن فرق Office ذهبت إلى أبعد من ذلك بكثير، ووضعت ألعاباً كاملة داخل برامج المكاتب. وحتى اليوم تجد من يسأل عنها، ففي منتدى Microsoft Q&A سأل مستخدم عن [قائمة بيض Office التي قرأها في مجلة](https://learn.microsoft.com/en-us/answers/a/237939?ref=arabroot.io): متاهة Excel، ومحاكي الطيران في Excel 97، وPinball في Word 97، وDev Hunter في Office 2000، وجاءه الرد من حساب موظفة في Microsoft بأن هذه النسخ خرجت من الدعم ولا توجد بيئة لاختبارها، وأن Microsoft توقفت عن إضافة البيض ضمن مبادرة Trustworthy Computing في 2002.

### متاهة Hall of Tortured Souls في Excel 95

في Excel 95، كما يوثق [أرشيف eeggs.com](https://eeggs.com/items/719.html?ref=arabroot.io)، كنت تذهب إلى الصف 95 وتحدده كاملاً، ثم تضغط Tab لتصبح الخلية B95 هي النشطة، ثم تفتح نافذة About Microsoft Excel وتضغط Ctrl وAlt وShift معاً مع النقر على زر الدعم الفني Tech Support. والنتيجة نافذة اسمها Hall of Tortured Souls، وهي متاهة ثلاثية الأبعاد تتحرك فيها بلوحة المفاتيح على طريقة ألعاب تلك الفترة مثل Doom، وفي نهاية الممر أسماء المبرمجين. وإذا التفت إلى الجدار المقابل وكتبت كلمة سر معينة، يفتح الجدار على غرفة أخرى فيها صور الفريق.

لاحظ الرقم 95 في الصف المطلوب، فهو رقم الإصدار نفسه. وهذه عادة سوف تتكرر في البيضة التالية، وهي طريقة ذكية لتقليل احتمال أن يصل إليها مستخدم بالصدفة: من الذي يحدد الصف 95 كاملاً ثم يفتح نافذة About ويضغط ثلاثة مفاتيح معاً؟

### محاكي الطيران Flight Simulator في Excel 97

وهذه هي البيضة التي يتذكرها أغلب من عاش تلك الفترة. فحسب [أرشيف eeggs.com](https://eeggs.com/items/718.html?ref=arabroot.io)، كانت الخطوات كالتالي: تفتح ورقة عمل جديدة، وتضغط F5 لتفتح نافذة الانتقال Go To، وتكتب `X97:L97` ثم Enter، ثم تضغط Tab مرة واحدة فتصبح الخلية النشطة `M97`، ثم تضغط Ctrl وShift معاً وتنقر على زر معالج الرسوم البيانية Chart Wizard. وبدلاً من معالج الرسوم، تظهر نافذة فيها عالم ثلاثي الأبعاد تطير فوقه بالفأرة، الزر الأيمن للأمام والأيسر للخلف، وفي مكان ما من هذا العالم لوحة عليها أسماء الفريق.

وتفصيل صغير يقول لك الكثير عن عقلية من كتبها: المحاكي يحتاج مكتبة DirectDraw الخاصة بالرسومات، فإذا لم تكن مثبتة كانت تظهر رسالة ساخرة معناها أن الأمر كان سيكون أمتع بكثير لو كان عندك DirectDraw، ولكن بما أنه ليس عندك فعليك أن تكتفي بهذا، ثم تظهر الأسماء. أي أن المبرمج فكر في حالة الخطأ، وكتب لها مساراً بديلاً، وهذا بالضبط ما نطلبه من أي ميزة حقيقية. ويذكر الأرشيف أيضاً أن العالم في المحاكي كروي، فإذا طرت في خط مستقيم فسوف تعود إلى نفس المكان.

والمفارقة أن هذه البيضة كانت مكتوبة بعناية تقنية حقيقية: محرك رسومات ثلاثي الأبعاد، وتحكم بالفأرة، وتعامل مع غياب مكتبة الرسومات، داخل برنامج جداول حسابات. ولكن كل هذه العناية لم تمر على مواصفة يقرأها فريق الجودة، ولم يكتب لها أحد حالة اختبار، ولم يعرف بها العميل الذي دفع ثمن البرنامج.

### لعبة Pinball في Word 97

وفي Word 97 كانت هناك لعبة كرة الدبابيس Pinball. ويوثق [أرشيف eeggs.com](https://eeggs.com/items/763.html?ref=arabroot.io) خطواتها: تكتب كلمة Blue في مستند جديد، وتحددها وتجعلها بخط عريض Bold ولون أزرق، ثم تكتب مسافة بعدها، ثم تفتح نافذة About وتنقر على شعار Word مع Ctrl وShift. وتظهر لعبة Pinball تتحكم فيها بحرف Z للذراع اليسرى وحرف M للذراع اليمنى. ولاحظ هنا أن الشرط ليس مكان الخلية كما في Excel، وإنما تنسيق الكلمة نفسها، أي أن الكود كان يقرأ حالة المستند ويقارنها بشرط محدد قبل أن يقرر ماذا يفعل عند النقر على الشعار.

### لعبة Dev Hunter في Excel 2000

وفي Excel 2000 جاءت آخر هذه الألعاب الكبيرة: لعبة سيارات اسمها Dev Hunter، وهي من البيض المذكور في [سؤال Microsoft Q&A](https://learn.microsoft.com/en-us/answers/a/237939?ref=arabroot.io) السابق. وكانت تعمل في مكونات Office الخاصة بالويب، أي عندما تحفظ ورقة العمل كصفحة ويب تفاعلية وتفتحها في المتصفح، وكانت تحتاج DirectX مثبتاً لتعمل. ومع تحديثات Service Pack اللاحقة لم تعد البيضة تعمل كما كانت، كما تجمع [قائمة Wikipedia لبيض منتجات Microsoft](https://en.wikipedia.org/wiki/List%5Fof%5FEaster%5Feggs%5Fin%5FMicrosoft%5Fproducts?ref=arabroot.io) من مصادرها، ولم يأت بعدها في Office شيء بهذا الحجم.

وإذا نظرت إلى هذه الألعاب الأربع معاً، فسوف ترى نمطاً واضحاً: كل إصدار من Office كان أكبر من الذي قبله، وكل بيضة كانت أكبر من التي قبلها، من متاهة إلى محاكي طيران إلى لعبة سيارات داخل المتصفح. ثم توقف كل شيء فجأة، والسبب جاء في مذكرة واحدة.

## مذكرة Gates والحوسبة الجديرة بالثقة Trustworthy Computing

في بداية الألفية كانت سمعة Microsoft الأمنية في أسوأ حالاتها، فالفيروسات والديدان Worms تنتشر عبر ثغرات في Windows وOutlook وخادم الويب IIS، والشركات الكبيرة والحكومات بدأت تسأل بجدية إن كانت تستطيع الاعتماد على هذه البرامج. وفي 15 يناير 2002 أرسل Bill Gates مذكرة إلى كل موظفي الشركة نشرت [The Register نصها الكامل](https://www.theregister.com/2002/01/17/ms%5Fhighest%5Fpriority%5Fmust/?ref=arabroot.io)، يعرف فيها الحوسبة الجديرة بالثقة Trustworthy Computing بأنها حوسبة متوفرة وموثوقة وآمنة مثل الكهرباء والماء والهاتف.

والجملة التي غيرت أولويات الشركة في تلك المذكرة هي: «عندما نواجه اختياراً بين إضافة ميزات وحل مشاكل الأمان، يجب أن نختار الأمان». وقد يبدو أن هذه الجملة لا علاقة لها بالبيض، ولكن فكر فيها قليلاً: إذا كانت الميزة الحقيقية التي طلبها العملاء يجب أن تنتظر حتى يحل الفريق مشاكل الأمان، فما وضع كود لم يطلبه أحد أصلاً، ولا يعرف عنه فريق الأمان شيئاً؟

وقد شرحنا في مقال [من أمن المعلومات إلى الأمن السيبراني](https://arabroot.io/articles/%D9%85%D9%86-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D9%85%D8%B9%D9%84%D9%88%D9%85%D8%A7%D8%AA-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-%D8%A7%D9%84%D8%AA%D8%A7%D8%B1%D9%8A%D8%AE-%D9%88%D8%A7%D9%84%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA/) كيف تحولت النظرة إلى الأمان في تلك الفترة من شيء يضاف في النهاية إلى شيء يبدأ مع التصميم، ومذكرة Gates كانت إحدى أهم نقاط هذا التحول في صناعة البرمجيات.

## لماذا توقفت Microsoft؟ ما كتبه Larry Osterman

في أكتوبر 2005 نشر Larry Osterman تدوينة [Early Easter Eggs](https://learn.microsoft.com/en-us/archive/blogs/larryosterman/early-easter-eggs?ref=arabroot.io) عن بيضة MS-DOS، وختمها بجملة قصيرة: «اليوم، إضافة Easter Egg إلى نظام تشغيل من Microsoft سبب فوري للفصل من العمل». وأثارت الجملة نقاشاً واسعاً في التعليقات وخارجها، فكثير من القراء رأوا أن المنع قسوة على المبرمجين وقتل لروح المرح، فكتب في اليوم التالي تدوينة [Why no Easter Eggs?](https://learn.microsoft.com/en-us/archive/blogs/larryosterman/why-no-easter-eggs?ref=arabroot.io) يشرح فيها السبب، وهي أوضح نص كتبه أحد مهندسي Microsoft عن الموضوع.

### الحجة الأولى: الثقة Trust

يربط Osterman المنع مباشرة بمبادرة Trustworthy Computing، ويقول إن أحد جوانبها أن تستطيع الوثوق بما هو موجود على جهازك، وهذا يعني ألا يكون على جهازك شيء لم يخطط له أحد. ثم يطرح السؤال الذي يلخص الموضوع كله: إذا كانت الشركة التي تصنع البرنامج الموجود على كل جهاز في مؤسستك لا تستطيع أن تمنع مطوريها من إدخال ميزات غير موثقة، حتى لو كانت بريئة مثل البيضة، فكيف تتأكد أنهم لم يدخلوا ميزة أخرى غير موثقة؟

ويضيف أن الوصول إلى الكود المصدري Source Code لا يحل المشكلة، لسببين. الأول أن أحداً لن يراجع أكثر من عشرة ملايين سطر قبل أن يثبت النظام. والثاني أن Ken Thompson، أحد صانعي Unix، أثبت في محاضرته عند استلام جائزة Turing بعنوان [Reflections on Trusting Trust](https://www.cs.cmu.edu/~rdriley/487/papers/Thompson%5F1984%5FReflectionsonTrustingTrust.pdf?ref=arabroot.io) أن الكود المصدري نفسه لا يكفي، لأن المترجم Compiler الذي يبني البرنامج يمكن أن يضيف إليه ما ليس في المصدر. ويذكر Osterman أن كثيراً من الشركات والحكومات تملك فعلاً الكود المصدري لمنتجات Microsoft، ويتساءل: كيف سيكون رد فعلهم عندما يجدون كوداً مخفياً، ثم يقال لهم إنه «مفاجأة خاصة» للمستخدمين؟ سوف يتساءلون مباشرة عن المفاجآت الأخرى في الكود.

### الحجة الثانية: البيضة نفسها فيها أخطاء Bugs

وهنا يأتي المثال الذي وعدنا به. يقول Osterman إن بيضة NT 3.1 كان فيها خطأ: صممت لتعمل عندما يكتب أحد عبارة I LOVE NT، ولكنها كانت تعمل أيضاً مع أي عبارة تتكون من نفس الحروف بترتيب مختلف، فكانت عبارة NOT EVIL تفتحها هي أيضاً. خطأ مضحك، ولكنه يكشف شيئاً جاداً: الكود الذي لم يختبره أحد يتصرف بطرق لم يتوقعها كاتبه، حتى لو كان كاتبه مهندساً ممتازاً في فريق مثل فريق NT.

ثم يعترف Osterman بشيء شخصي، فهو نفسه شارك في بيض خادمي POP3 وNNTP في Exchange 5.0\. والمهم في قصته أنهم فعلوا كل شيء «بالطريقة الصحيحة» ظاهرياً: سجلوا البيضة كخطأ في نظام تتبع الأخطاء، وكتب مدير المنتج لها مواصفة، وكتب قائد الاختبار حالات اختبار، بل سألوا القسم القانوني عن طريقة ذكر الموظفين المتعاقدين في قائمة الأسماء. ومع ذلك يقول إنهم ما كان يجب أن يفعلوها، لأنهم لم يخبروا العملاء، وهذا لا يغتفر خاصة في خادم شبكة.

ويسأل: ماذا لو كان في كود البيضة تجاوز سعة المخزن المؤقت Buffer Overflow أو ثغرة أخرى؟ كيف نشرح للعملاء أن دودة انتشرت عبر الإنترنت بسبب غرور مطورينا؟ ثم يكمل أنهم أخطأوا فعلاً، فكما كان في بيضة NT خطأ، كان في بيضة Exchange خطأ جعلها ترسل البيضة رداً على أوامر في البروتوكول غير الأوامر المقصودة. وعندما ناقش الموضوع مع Raymond Chen، أخبره Chen أن برنامج البريد الذي يستخدمه فعلياً بروتوكول IMAP اصطدم بهذا الخطأ، ولم يكن سعيداً بذلك.

![مقارنة بين مسارين: الميزة العادية تمر بمواصفة ثم مراجعة الكود ثم الاختبار ثم المراجعة الأمنية ثم التوثيق، والبيضة المخفية تبدأ بفكرة مطور ثم تتجاوز المراجعة والاختبار والتوثيق وتصل إلى جهاز العميل، وتحتهما أربعة مخاطر: ثغرة أمنية مثل Buffer Overflow، وتفعيل بالخطأ كما حدث مع NOT EVIL وخادم Exchange، وفقدان الثقة لأن من لا يمنع مزحة غير موثقة قد لا يمنع باباً خلفياً، وزيادة الحجم والانطباع السيئ](https://arabroot.io/content/images/2026/10/software-easter-eggs-03-hidden-risk.webp)

الميزة تمر على عدة أعين قبل أن تصل إلى العميل، والبيضة تتجاوز أغلبها عن قصد

### الحجة الثالثة: التضخم Bloat والانطباع

والحجة الأخيرة عند Osterman أقل تقنية ولكنها حقيقية: العملاء يرون البيض علامة على تضخم البرامج Bloat، ويغضبون عندما يكتشفونه. فمن يدفع ثمن برنامج فيه أخطاء تعطله كل يوم، ثم يكتشف أن داخله محاكي طيران، سوف يسأل سؤالاً منطقياً: لماذا يصرف المبرمجون وقتهم على هذا بدل إصلاح ما يزعجني؟ حتى لو كانت الإجابة الحقيقية أن البيضة كتبت في وقت فراغ مبرمج واحد، فالانطباع يبقى. وينهي Osterman تدوينته بجملة تلخص الموقف كله: الأمر يتعلق بالثقة وبالمهنية، وجميل أن ترى اسمك على الشاشة، ولكن ليس جميلاً أن يكلفنا ذلك ثقة عملائنا.

## البيض من زاوية الأمن Security: من المزحة إلى الباب الخلفي

قد تقول إن البيضة شيء بريء، وإن الكلام عن الأبواب الخلفية مبالغة. ولكن انظر إلى الأمر بعين من يدافع عن نظام، وسوف تجد أن الفرق بين البيضة والباب الخلفي ليس في الآلية، وإنما في النية فقط. فكلاهما كود:

- لا يظهر في المواصفة ولا في التوثيق.
- يعمل فقط عندما يتحقق شرط سري لا يعرفه إلا كاتبه.
- يحاول أن يختبئ من القراءة، كما رأينا في بصمات Hash وعملية XOR في Windows 95.
- يصل إلى أجهزة العملاء دون أن يختبره أحد غير كاتبه.

ومن يراجع الكود لا يرى النية، وإنما يرى السلوك. لذلك فإن أي عملية مراجعة تستطيع أن تمرر بيضة دون أن تلاحظها، تستطيع أيضاً أن تمرر باباً خلفياً بنفس الطريقة. وهذه ليست فكرة نظرية، فقد رأينا في 2024 كيف دخل باب خلفي حقيقي إلى مكتبة الضغط xz بعد سنوات من بناء الثقة مع المشرفين عليها، وكيف أخفى المهاجم الكود داخل ملفات اختبار تبدو بريئة، وقد رويناها في مقال [كيف اكتشف Andres Freund الباب الخلفي في xz](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%A7%D9%83%D8%AA%D8%B4%D9%81-andres-freund-%D8%A7%D9%84%D8%A8%D8%A7%D8%A8-%D8%A7%D9%84%D8%AE%D9%84%D9%81%D9%8A-%D9%81%D9%8A-xz/). والتقنيات التي استخدمها ذلك المهاجم، من الإخفاء داخل بيانات تبدو عادية إلى التفعيل بشرط محدد، هي في جوهرها نفس تقنيات البيض القديم، ولكن بنية مختلفة.

وهناك جانب آخر يعرفه كل من عمل في الأمان: سطح الهجوم Attack Surface. فكل سطر كود موجود في المنتج هو سطر يمكن أن يكون فيه خطأ، والكود الذي لا يحتاجه المنتج ليؤدي وظيفته هو سطح هجوم بلا فائدة. ومحرك رسومات ثلاثي الأبعاد داخل برنامج جداول حسابات، يقرأ مدخلات الفأرة ولوحة المفاتيح ويتعامل مع مكتبات الرسومات، هو بالضبط هذا النوع من الكود. ولم نقرأ عن ثغرة معروفة في محاكي Excel، ولكن هذا لا يعني أنه كان آمناً، وإنما يعني فقط أن أحداً لم يبحث بجدية، أو أن من وجد شيئاً لم يعلنه.

ولهذا السبب بالذات تطلب معايير الأمان الحديثة أن يكون كل كود في المنتج مرتبطاً بمتطلب معروف، وأن يمر بمراجعة يعرف فيها المراجع ما الذي يجب أن يفعله الكود. وقد شرحنا في مقال [متطلبات الأمان ومراجعة الكود مع OWASP ASVS](https://arabroot.io/articles/%D9%85%D8%AA%D8%B7%D9%84%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D8%A7%D9%86-%D9%88%D9%85%D8%B1%D8%A7%D8%AC%D8%B9%D8%A9-%D8%A7%D9%84%D9%83%D9%88%D8%AF-%D9%85%D8%B9-owasp-asvs/) كيف تتحول هذه الفكرة إلى قائمة تحقق عملية، وفي مقال [أمن سلسلة التوريد البرمجية](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D8%B3%D9%84%D8%B3%D9%84%D8%A9-%D8%A7%D9%84%D8%AA%D9%88%D8%B1%D9%8A%D8%AF-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/) كيف تتأكد أن ما يصل إلى السيرفر هو فعلاً ما راجعه الفريق.

## البيض الذي يمكنك تشغيله اليوم: تجربة عملية Lab

هل يعني هذا أن البيض انتهى؟ لا، ولكنه تغير. فالبيض الذي ما زال حياً اليوم يعيش في مكانين: مشاريع مفتوحة المصدر يقرأ كودها أي شخص، وشركات قررت أن تعلن عن البيضة بدل أن تخفيها. وقد شغلنا كل ما في هذا القسم بأنفسنا: Chrome 156 وFirefox 157 على Windows، وحاوية Debian 13 trixie فيها Python 3.13.5 وVim 9.1 وEmacs 30.1 وapt 3.0.3\. والجدول التالي يجمعها قبل التفاصيل:

![ثماني بطاقات لبيض يمكن تشغيله اليوم: ديناصور Chrome عبر chrome://dino، وصفحة الروبوتات في Firefox عبر about:robots، ومبادئ Python عبر import this، وimport antigravity الذي يفتح رسمة xkcd، وبقرة apt عبر apt moo مع aptitude moo، ومعنى الحياة في Vim عبر :help 42، وطبيب Emacs النفسي عبر M-x doctor، وسجل Notepad عبر .LOG وهي ميزة موثقة](https://arabroot.io/content/images/2026/10/software-easter-eggs-04-try-today.webp)

كل هذه البيضات معلنة: في كود منشور، أو في توثيق رسمي، أو في مدونة الشركة نفسها

وإذا أردت أن تكرر ما فعلناه في الطرفية، فهذه الأوامر كلها:

```bash
docker run -it --rm debian:trixie-slim bash
apt-get update && apt-get install -y python3 vim emacs-nox aptitude
python3 -c "import this"
python3 -c "from __future__ import braces"
apt moo
aptitude -vvvvvv moo
vim -c "help 42"
emacs -nw -Q -f doctor
```

### ديناصور Chrome: chrome://dino

أشهر بيضة اليوم هي لعبة الديناصور التي تظهر في Chrome عندما ينقطع الإنترنت. وقصتها موثقة في [مدونة Google سنة 2018](https://blog.google/products/chrome/chrome-dino/?ref=arabroot.io)، حيث تحدث فريق التصميم الذي صنعها: Edward Jung وSebastien Gabriel وAlan Bettes. وتقول المدونة إن فكرة لعبة الجري التي لا تنتهي ظهرت في بداية 2014، وقدمت ضمن إعادة تصميم صفحة الخطأ في سبتمبر 2014، ووصلت إلى كل المنصات في ديسمبر من نفس السنة، وكان اسمها الداخلي Project Bolan. واختيار الديناصور مزحة مقصودة: عندما ينقطع الإنترنت فأنت عائد إلى «عصور ما قبل التاريخ». وتذكر المدونة أن اللعبة صممت لتصل أقصى مدة لها إلى قرابة 17 مليون سنة، وهي تقريباً المدة التي عاش فيها الديناصور T-Rex على الأرض، وأن الناس كانوا يلعبون قرابة 270 مليون مرة في الشهر.

وليس عليك أن تقطع الإنترنت لتلعب، فالفريق أضاف عنوان `chrome://dino`. وقد فتحناه في نسخة Chrome بلا واجهة Headless، فظهرت عبارة Press space to play، ثم أرسلنا ضغطة المسافة من السكربت ولم نضغط أي مفتاح بعدها، فركض الديناصور حتى اصطدم بأول صبار وظهرت عبارة GAME OVER بنتيجة 46\. وهذه تجربة «ماذا يحدث لو» بسيطة: اللعبة لا تحتاج أي شيء غير مفتاح واحد، ولهذا يلعبها الجميع.

![لعبة ديناصور Chrome بعد انتهاء الجولة: الديناصور المرسوم بالبكسلات اصطدم بصبار على اليسار، وفي الوسط عبارة GAME OVER وزر إعادة اللعب، وفي الأعلى على اليمين النتيجة HI 00046 00046، وسحابتان رماديتان](https://arabroot.io/content/images/2026/10/software-easter-eggs-05-chrome-dino.webp)

chrome://dino في Chrome 156: ضغطة مسافة واحدة ثم لا شيء، فاصطدم الديناصور بأول صبار بنتيجة 46\. لقطة من تشغيلنا الفعلي

والفرق بين هذه اللعبة ومحاكي Excel ليس في الحجم ولا في الفكرة، وإنما في أنها ميزة معلنة: لها فريق معروف، وكودها جزء من مشروع Chromium المفتوح في مجلد [صفحات أخطاء الشبكة](https://chromium.googlesource.com/chromium/src/+/main/components/neterror/resources/?ref=arabroot.io)، ويمر بنفس المراجعة والاختبار مثل أي كود آخر في المتصفح. وعندما كتبنا السكربت الذي يلعب، احتجنا أن نقرأ هذا الكود لنعرف كيف نسأل اللعبة إن كان الديناصور قد اصطدم، وهذا بالضبط ما لم يكن ممكناً مع بيض Office.

### روبوتات Firefox: about:robots

وفي Firefox، إذا كتبت `about:robots` في شريط العنوان، تظهر صفحة بعنوان Welcome Humans! فيها روبوت صغير ورسالة من الروبوتات: جئنا بسلام. وتحتها قائمة من الجمل، أولها صياغة لقانون Isaac Asimov الأول للروبوتات: لا يجوز للروبوت أن يؤذي إنساناً أو أن يسمح بأذاه بالتقاعس، والباقي إشارات لأفلام وروايات خيال علمي يعرفها محبوها، ثم جملة أخيرة صغيرة: ولديهم خطة. أخذنا اللقطة بنسخة Firefox 157.0.1 في الوضع بلا واجهة مع ملف تعريف مؤقت فارغ، عبر الأمر `firefox --headless --screenshot about:robots`.

![صفحة about:robots في Firefox: صورة روبوت لعبة صغير أحمر وفضي، وعنوان Welcome Humans!، ثم جملة We have come to visit you in peace and with goodwill!، وقائمة من أربع جمل عن الروبوتات أولها Robots may not injure a human being، ثم جملة And they have a plan، وزر Try Again](https://arabroot.io/content/images/2026/10/software-easter-eggs-06-firefox-robots.webp)

about:robots في Firefox 157: صفحة ترحيب من الروبوتات بقانون Asimov الأول. لقطة من تشغيلنا الفعلي

### بيض Python: import this

وفي لغة Python أكثر من بيضة، وأشهرها `import this`، والتي تطبع مبادئ اللغة كما كتبها Tim Peters، وهي موثقة رسمياً في [PEP 20: The Zen of Python](https://peps.python.org/pep-0020/?ref=arabroot.io). وتقول الوثيقة إن المبادئ عشرون، كتب منها تسعة عشر فقط. وعندما شغلنا الأمر طبع المبادئ التسعة عشر، من «الجميل أفضل من القبيح» إلى «النطاقات Namespaces فكرة رائعة، فلنكثر منها».

![نافذة طرفية فيها ثلاثة أوامر Python: الأول import this يطبع The Zen of Python by Tim Peters والمبادئ التسعة عشر، والثاني يطبع بداية المتغير this.s بنص مشفر بطريقة ROT13 يبدأ بعبارة Gur Mra bs Clguba، والثالث from __future__ import braces يرد بخطأ SyntaxError: not a chance](https://arabroot.io/content/images/2026/10/software-easter-eggs-07-python.webp)

import this في Python 3.13.5، والنص نفسه محفوظ مشفراً داخل الملف، ثم رد اللغة على من يطلب الأقواس. لقطة من تشغيلنا الفعلي

والتفصيل الطريف يظهر في السطر الثاني من الصورة: النص ليس محفوظاً في ملف [this.py](https://github.com/python/cpython/blob/main/Lib/this.py?ref=arabroot.io) كما تراه، وإنما مشفراً بطريقة ROT13 التي تزيح كل حرف 13 موضعاً، فالمتغير `this.s` يبدأ بعبارة `Gur Mra bs Clguba`، والملف يفك التشفير ثم يطبع. وهي نفس فكرة XOR في Windows 95، أي إخفاء النص عن القراءة المباشرة، ولكن مع فرق كبير: الملف منشور في مستودع اللغة، وأي شخص يستطيع أن يقرأه ويفهم ما يفعله في دقيقة.

والبيضة الثانية في نفس الصورة: إذا حاولت أن تطلب من Python استخدام الأقواس المعقوفة بدل المسافات البادئة عبر `from __future__ import braces`، فالرد خطأ في الصياغة SyntaxError برسالة واحدة: not a chance، أي «مستحيل». وهو رد اللغة على نقاش قديم بين مبرمجيها حول المسافات البادئة.

### import antigravity: ماذا يحدث بلا متصفح؟

والبيضة الثالثة `import antigravity`، وهي تفتح في المتصفح رسمة [xkcd رقم 353](https://xkcd.com/353/?ref=arabroot.io) التي يطير فيها شخص لأنه كتب `import antigravity` في Python. ولكن ماذا يحدث إذا شغلتها في حاوية Docker لا يوجد فيها متصفح؟ هذا ما شغلناه، والنتيجة في الصورة: لا شيء على الشاشة، ورمز الخروج صفر، أي أن الأمر نجح دون أي رسالة.

![نافذة طرفية: الأمر python3 -c import antigravity لا يطبع شيئاً ورمز الخروج 0، ثم محتوى الملف antigravity.py الذي يستورد webbrowser وhashlib ويستدعي webbrowser.open على رابط xkcd.com/353 ثم يعرف دالة geohash تستخدم MD5](https://arabroot.io/content/images/2026/10/software-easter-eggs-08-antigravity.webp)

في حاوية بلا متصفح لا يظهر شيء، والسبب في الملف نفسه: سطر واحد يطلب فتح الرابط. لقطة من تشغيلنا الفعلي

والسبب واضح عندما تقرأ الملف [antigravity.py](https://github.com/python/cpython/blob/main/Lib/antigravity.py?ref=arabroot.io)، وقد طبعناه في نفس الصورة: الملف يستدعي `webbrowser.open("https://xkcd.com/353/")`، ومكتبة `webbrowser` تبحث عن متصفح في النظام، فإذا لم تجد شيئاً تعيد قيمة خطأ دون أن ترفع استثناء Exception، والملف لا يفحص هذه القيمة. وفي الملف أيضاً دالة اسمها `geohash` تنفذ خوارزمية من رسمة xkcd أخرى رقمها 426\. وهذه ملاحظة صغيرة ولكنها تستحق التوقف: حتى البيضة البسيطة تتعامل مع بيئة لم يتوقعها كاتبها، وهي هنا تفشل بصمت، وهو سلوك مقبول في بيضة ولكنه سيئ جداً في كود حقيقي.

### بقرة apt: apt moo

وفي Debian وUbuntu، إذا كتبت `apt moo` تظهر بقرة مرسومة بالرموز تسألك: هل خرت اليوم؟ وأول ما ظهر لنا قبل البقرة كان سطر تحذير: WARNING: apt does not have a stable CLI interface. وهذا التحذير لا علاقة له بالبيضة، فهو يظهر لأننا شغلنا `apt` من سكربت وليس من طرفية تفاعلية، والأداة تنبهك إلى أن مخرجاتها قد تتغير بين الإصدارات، وأن السكربتات يجب أن تستخدم `apt-get` بدلاً منها. وفي آخر سطر من مساعدة `apt-get --help` ستجد جملة تشير إلى نفس البيضة: This APT has Super Cow Powers.

![نافذة طرفية: الأمر apt moo يطبع تحذيراً عن واجهة الأوامر ثم بقرة مرسومة بالرموز وعبارة Have you mooed today، ثم الأمر aptitude moo بمستويات متزايدة من الخيار -v: لا يوجد بيض في هذا البرنامج، ثم حقاً لا يوجد، ثم ألم أقل لك، ثم توقف، ثم حسناً إذا أعطيتك بيضة هل ستذهب، ثم حسناً لقد فزت مع رسمة، ثم في المستوى السادس تفسير الرسمة: فيل يأكله ثعبان](https://arabroot.io/content/images/2026/10/software-easter-eggs-09-apt-moo.webp)

apt 3.0.3 وaptitude 0.8.13 في Debian trixie: بقرة، ثم برنامج ينكر وجود البيض حتى يستسلم في المستوى السادس. لقطة من تشغيلنا الفعلي

أما الأداة الأخرى `aptitude` فلها بيضة أذكى. فعندما تكتب `aptitude moo` ترد: لا يوجد بيض في هذا البرنامج. وكلما أضفت حرف `v` إلى خيار التفاصيل Verbose زاد إصرارها ثم ضيقها: حقاً لا يوجد، ثم ألم أقل لك، ثم توقف!، ثم «حسناً، إذا أعطيتك بيضة هل ستذهب؟»، ثم في المستوى الخامس تستسلم وترسم شكلاً، وفي المستوى السادس تشرح الرسمة: فيل يأكله ثعبان، وهي إشارة إلى الرسمة الأولى في رواية الأمير الصغير. وهنا مزحة على البيض نفسه: برنامج ينكر وجود البيض، وإنكاره هو البيضة.

### Vim: معنى الحياة في :help 42

وفي محرر Vim، إذا كتبت `:help 42` فإنك تصل إلى نهاية فصل في دليل المستخدم، وفي الإصدار 9.1 الذي شغلناه كان الملف [usr\_42.txt](https://vimhelp.org/usr%5F42.txt.html?ref=arabroot.io#42)، وفيه سؤال «ما معنى الحياة والكون وكل شيء؟» وهو السؤال الذي جوابه 42 في رواية The Hitchhiker's Guide to the Galaxy، ثم ملاحظة أن Douglas Adams، الوحيد الذي كان يعرف السؤال الحقيقي، قد توفي للأسف.

![شاشة Vim تعرض نهاية ملف usr_42.txt: سطر What is the meaning of life, the universe and everything? مع الوسم *42*، ثم جملة عن Douglas Adams، ثم خط فاصل ورابط الفصل التالي usr_43.txt، وفي الأسفل اسم الملف usr_42.txt مع readonly و366 سطراً](https://arabroot.io/content/images/2026/10/software-easter-eggs-10-vim-42.webp)

:help 42 في Vim 9.1، ملتقطة من طرفية حقيقية عبر tmux. لقطة من تشغيلنا الفعلي

وفي Vim بيضة أخرى صغيرة من نفس الرواية: الأمر `:help!` بعلامة تعجب. شغلناه فظهر في أسفل الشاشة سطر واحد: `E478: Don't panic!`، أي «لا تذعر»، وهي العبارة المكتوبة على غلاف الدليل في الرواية. ولاحظ أن لها رقم خطأ حقيقي مثل أي رسالة خطأ في المحرر، أي أنها موثقة في قائمة رسائل الخطأ نفسها.

![شاشة Vim صغيرة فارغة بعلامات التلدة في بداية الأسطر، وفي السطر الأخير رسالة E478: Don't panic!](https://arabroot.io/content/images/2026/10/software-easter-eggs-10b-vim-help-bang.webp)

:help! في Vim 9.1 ترد برسالة خطأ لها رقم حقيقي. لقطة من تشغيلنا الفعلي

### طبيب Emacs النفسي: M-x doctor

ومحرر Emacs يحمل قائمة كاملة من التسالي يوثقها دليله الرسمي في صفحة [Amusements](https://www.gnu.org/software/emacs/manual/html%5Fnode/emacs/Amusements.html?ref=arabroot.io)، منها ألعاب مثل Tetris وSnake، ومنها نكتة `M-x butterfly` المأخوذة من رسمة xkcd عن «المبرمجين الحقيقيين». وأشهرها `M-x doctor`، وهو معالج نفسي يحاورك على طريقة برنامج ELIZA الذي كتبه Joseph Weizenbaum في الستينيات، وقد ذكرناه في مقال [قصة الذكاء الاصطناعي](https://arabroot.io/articles/%D9%82%D8%B5%D8%A9-%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A-%D9%85%D9%86-%D8%AA%D9%88%D8%B1%D9%86%D8%BA-%D8%A7%D9%84%D9%89-chatgpt/). والدليل يقول إنك تنهي كل جملة بضغط Enter مرتين.

شغلنا Emacs في الطرفية داخل جلسة tmux، وكتبنا له جملتين من يوم عمل عادي، والتقطنا الشاشة كما هي:

![شاشة Emacs في الطرفية: الطبيب يقول I am the psychotherapist. Please, describe your problems، فنكتب I am tired of debugging this code، فيرد Why do you say you are tired of debugging this code، ثم نكتب My manager wants the release tonight، فيرد Is it because of your plans that you say your manager wants the release tonight، وفي الأسفل سطر الحالة باسم المخزن *doctor*](https://arabroot.io/content/images/2026/10/software-easter-eggs-11-emacs-doctor.webp)

M-x doctor في Emacs 30.1: يعيد صياغة كلامك على شكل سؤال، تماماً كما كانت ELIZA تفعل. لقطة من تشغيلنا الفعلي

لاحظ كيف يعمل: كتبنا «أنا متعب من تتبع الأخطاء في هذا الكود»، فرد «لماذا تقول إنك متعب من تتبع الأخطاء في هذا الكود؟». أي أنه أخذ الجملة وقلب الضمائر وأضاف سؤالاً، دون أن يفهم شيئاً. والرد الثاني أطرف: سألنا إن كان قول «مديري يريد الإصدار الليلة» سببه «خططنا». وهذه الطريقة البسيطة هي التي جعلت بعض من جربوا ELIZA في الستينيات يظنون أنها تفهمهم، كما روى Weizenbaum نفسه لاحقاً.

### سجل Notepad: ميزة موثقة تشبه البيضة

وأخيراً شيء يظنه كثيرون بيضة وهو ليس كذلك. ففي Notepad على Windows، إذا كتبت `.LOG` في أول سطر من ملف نصي وحفظته، فإن Notepad يضيف التاريخ والوقت في نهاية الملف كل مرة تفتحه، فيصبح الملف دفتر يوميات بسيطاً. وهذه ميزة موثقة رسمياً في صفحة [Help in Notepad](https://support.microsoft.com/en-us/windows/apps/help-in-notepad?ref=arabroot.io) من Microsoft تحت سؤال «كيف أستخدم Notepad لإنشاء ملف سجل؟». ولم نلتقط لها صورة، لأنها تحتاج جهاز Windows شخصياً، ووصف Microsoft لها يكفي. والدرس منها أن الشيء المخفي عن أغلب المستخدمين ليس بالضرورة بيضة: ما دام موثقاً ومختبراً، فهو ميزة لم يقرأ عنها أحد فقط.

## لماذا لا يقلقنا هذا البيض؟ المخفي مقابل المعلن في المصدر المفتوح Open Source

إذا كانت حجج Osterman صحيحة، فلماذا لا نطالب بحذف بقرة apt وديناصور Chrome؟ الإجابة أن هذه البيضات تختلف عن بيض Office في كل نقطة جعلت Microsoft تمنعه:

| السؤال                    | بيض التسعينيات المخفي                          | البيض المعلن اليوم                                |
| ------------------------- | ---------------------------------------------- | ------------------------------------------------- |
| هل الكود مقروء؟           | مغلق، ومخفي حتى داخل الملف بالتشفير والبصمات   | منشور في مستودع عام مثل CPython وChromium وDebian |
| هل مر بمراجعة؟            | غالباً لا، أو مراجعة شكلية من زميل يعرف السر   | نفس مراجعة أي تعديل في المشروع                    |
| هل يعرف به العميل؟        | لا، والهدف أن يكتشفه بنفسه                     | نعم، موثق في الدليل أو في مدونة الشركة            |
| هل يتعامل مع مدخلات خطرة؟ | محركات رسومات وبروتوكولات شبكة كما في Exchange | غالباً نص ثابت يطبع على الشاشة                    |
| من يتحمل مسؤوليته؟        | مطور واحد أو مجموعة صغيرة                      | المشروع كله، مثل أي ميزة أخرى                     |

أي أن المشكلة لم تكن في المرح نفسه، وإنما في الإخفاء. فعندما تصبح البيضة جزءاً معلناً من المنتج، تمر على المراجعة والاختبار، ويعرف بها من يشغل البرنامج، فإنها تفقد كل ما كان يجعلها خطراً، وتبقى فقط الابتسامة. ولاحظ أن بيضة Exchange التي رواها Osterman مرت على مواصفة واختبار، ومع ذلك اعتبرها خطأ لأنها لم تعلن للعملاء، فالإعلان هو الشرط الذي لا يمكن تجاوزه.

## ماذا يقول البيض عن ثقافة الفريق Team Culture؟

لو نظرت إلى البيض كمشكلة أمنية فقط، فسوف يفوتك نصف القصة. فالبيضة الأولى كتبها Robinett لأنه لم يجد اسمه على عمله، وشاشات الأسماء في Windows وOffice كانت في أغلبها قوائم بأسماء من عملوا على النظام، أي أنها كانت محاولة من المبرمجين ليقولوا: نحن هنا، ونحن من صنع هذا. وعندما منعت Microsoft البيض، منعت الطريقة، ولكن الحاجة بقيت.

والشركات الذكية اليوم تلبي هذه الحاجة بطرق علنية. فالمشاريع مفتوحة المصدر تنشر أسماء كل من ساهم في كل إصدار في ملاحظات الإصدار Release Notes، وسجل Git نفسه يحفظ اسم كاتب كل سطر، والفرق الداخلية في الشركات تكتب أسماء الفريق في صفحة الإصدار الداخلية أو في عرض إطلاق المنتج. وأحد القراء اقترح في تعليقات تدوينة Osterman نفسها الحل البسيط: ضعوا أسماء الفريق في نافذة About بشكل معلن، فيحصل المطورون على الاعتراف، ويعرف العميل ما على جهازه.

وهناك ملاحظة ثانية عن الثقافة، وهي أن البيض كان يعيش في الفرق التي تعتبر الكود ملكاً شخصياً لكاتبه. فعندما يكتب مبرمج جزءاً من النظام وحده، ولا يقرأ أحد كوده بجدية، يستطيع أن يضيف فيه ما يريد. أما الفرق التي تعتبر الكود ملكاً للجميع، ويقرأ فيها كل تعديل شخص آخر على الأقل، فالبيضة فيها صعبة جداً، لأن المراجع سوف يسأل: ما هذا الكود؟ ومن طلبه؟ وهذا بالضبط ما نريده من المراجعة، سواءً كان الكود مزحة أو باباً خلفياً أو مجرد خطأ. وقد كتبنا في مقال [مراجعة كود الذكاء الاصطناعي دون أن تصبح شكلية](https://arabroot.io/articles/%D9%85%D8%B1%D8%A7%D8%AC%D8%B9%D8%A9-%D9%83%D9%88%D8%AF-%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A-%D8%AF%D9%88%D9%86-%D8%A7%D9%86-%D8%AA%D8%B5%D8%A8%D8%AD-%D8%B4%D9%83%D9%84%D9%8A%D8%A9/) عن خطر المراجعة التي تكتفي بالموافقة، وهو نفس الخطر هنا.

وملاحظة ثالثة لا يجب أن نخفيها: المنع الكامل له ثمن. فقد كتب عدد من القراء في تعليقات تدوينتي Osterman أن البيض كان طريقة لإظهار شخصية الفريق، وأن كتابته في وقت الفراغ كانت ترفع حماس المبرمجين، وأن المنع يجعل الشركة تبدو بلا روح. وهذه حجة لها وزنها، والحل ليس في أن تختار بين المرح والأمان، وإنما في أن تعطي المرح مكاناً معلناً: صفحة أسماء الفريق، أو لعبة معلنة مثل ديناصور Chrome، أو رسالة طريفة في مكان موثق مثل `aptitude moo`.

## ماذا نتعلم؟ قائمة قرار Decision Checklist لفريقك

إذا كنت تقود فريقاً اليوم، فقد يأتيك مبرمج متحمس يريد أن يضع شيئاً طريفاً في المنتج، أو قد تجد في مراجعة كود شيئاً لا تعرف من طلبه. وهذه الأسئلة تساعدك على القرار:

| السؤال                                              | إذا كانت الإجابة نعم                                           | إذا كانت الإجابة لا                               |
| --------------------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------- |
| هل الشيء مسجل كمهمة يعرفها الفريق ومالك المنتج؟     | تابع إلى السؤال التالي                                         | لا يدخل الفرع الرئيسي، مهما كان صغيراً            |
| هل سوف يمر بنفس المراجعة والاختبار مثل أي ميزة؟     | تابع                                                           | هذا هو تعريف الكود المخفي، ارفضه                  |
| هل سوف تعلنه في التوثيق أو ملاحظات الإصدار؟         | تابع                                                           | العميل يجب أن يعرف ما على جهازه، كما قال Osterman |
| هل يقرأ مدخلات من المستخدم أو من الشبكة؟            | عامله كأي سطح هجوم، مع مراجعة أمنية                            | الخطر أقل، ولكن المراجعة تبقى                     |
| هل المنتج يعمل في بيئة حساسة مثل بنك أو جهة حكومية؟ | الأفضل أن تضع المرح خارج المنتج: صفحة الفريق أو عرض الإطلاق    | بيضة معلنة صغيرة قد تكون مقبولة                   |
| هل الدافع الحقيقي هو الاعتراف بعمل الفريق؟          | حل المشكلة الأصلية: أسماء في نافذة About أو في ملاحظات الإصدار | لا بأس بالمرح ما دام معلناً                       |

والدروس التي نراها تستحق أن تبقى من هذه القصة:

- الكود الذي لا يعرفه أحد لا يختبره أحد: من NOT EVIL في NT إلى بيضة Exchange التي أزعجت برنامج Raymond Chen، كل بيضة لها قصة خطأ، لأنها خرجت من مسار الجودة.
- المراجعة التي تمرر مزحة تمرر باباً خلفياً: الفرق في النية، والمراجع لا يرى النية، فاجعل سؤال «من طلب هذا الكود؟» جزءاً من كل مراجعة.
- الإخفاء داخل الملف لا يحمي: Peter Norton وجد بيضة MS-DOS بأداة `strings`، وGeoff Chappell فك بصمات Windows 95، والمهاجم يفعل نفس الشيء مع أسرارك.
- كل سطر في المنتج سطح هجوم: الكود الذي لا يخدم وظيفة المنتج يضيف خطراً دون فائدة، سواءً كان بيضة أو ميزة قديمة لم يعد أحد يستخدمها.
- الإعلان يحول البيضة إلى ميزة: ديناصور Chrome وبقرة apt مقبولة لأنها معلنة ومراجعة، لا لأنها أصغر.
- الاعتراف بالفريق حاجة حقيقية: Robinett أخفى اسمه لأن Atari رفضت أن تذكره، فأعط فريقك مكاناً معلناً لأسمائهم قبل أن يبحثوا عن مكان مخفي.

## الخلاصة Summary

- البيض المخفي Easter Eggs سلوك مخفي داخل البرامج، لا يظهر في التوثيق، ويصل إليه المستخدم بتسلسل خطوات سري.
- أول بيضة معروفة في ألعاب الأجهزة المنزلية كتبها Warren Robinett في لعبة Adventure سنة 1979 لأن Atari لم تكن تذكر أسماء المطورين، وتركتها Atari لأن إعادة الإنتاج كانت مكلفة.
- في Microsoft بدأ البيض من MS-DOS 2.0، ثم صار شاشات أسماء في Windows 3.1 وWindows 95، ثم ألعاباً كاملة في Office: متاهة Excel 95، ومحاكي الطيران في Excel 97، وPinball في Word 97، وDev Hunter في Excel 2000.
- بعد مذكرة Bill Gates عن Trustworthy Computing في يناير 2002 توقفت Microsoft عن البيض، وشرح Larry Osterman السبب في 2005: الثقة، والأخطاء في البيض نفسه، والحجم والانطباع.
- البيضة والباب الخلفي يتشابهان في كل شيء إلا النية، ولهذا فإن المراجعة التي تمرر أحدهما تمرر الآخر.
- البيض الحي اليوم معلن ومراجع: `chrome://dino` و`about:robots` و`import this` و`apt moo` و`:help 42` و`M-x doctor`، وكلها شغلناها وصورناها بأنفسنا.
- الحاجة التي صنعت البيض، وهي الاعتراف بعمل الفريق، ما زالت حقيقية، والحل أن تعطيها مكاناً معلناً.

وإذا أعجبتك هذه القصة فاقرأ معها [قصة Windows NT وDave Cutler](https://arabroot.io/articles/%D9%82%D8%B5%D8%A9-windows-nt-%D9%88-dave-cutler/) لترى الفريق الذي كتب بيضة I LOVE NT وثقافة الجودة الصارمة فيه، و[قصة الباب الخلفي في xz](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%A7%D9%83%D8%AA%D8%B4%D9%81-andres-freund-%D8%A7%D9%84%D8%A8%D8%A7%D8%A8-%D8%A7%D9%84%D8%AE%D9%84%D9%81%D9%8A-%D9%81%D9%8A-xz/) لترى الوجه الخطير لنفس تقنيات الإخفاء، و[قصة الذكاء الاصطناعي](https://arabroot.io/articles/%D9%82%D8%B5%D8%A9-%D8%A7%D9%84%D8%B0%D9%83%D8%A7%D8%A1-%D8%A7%D9%84%D8%A7%D8%B5%D8%B7%D9%86%D8%A7%D8%B9%D9%8A-%D9%85%D9%86-%D8%AA%D9%88%D8%B1%D9%86%D8%BA-%D8%A7%D9%84%D9%89-chatgpt/) التي تبدأ من ELIZA التي يقلدها طبيب Emacs. ومن الجانب العملي، اقرأ [ما هي جودة الكود وكيف تقيسها](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%8A-%D8%AC%D9%88%D8%AF%D8%A9-%D8%A7%D9%84%D9%83%D9%88%D8%AF-code-quality-%D9%88%D9%83%D9%8A%D9%81-%D8%AA%D9%82%D9%8A%D8%B3%D9%87%D8%A7/) و[متطلبات الأمان ومراجعة الكود](https://arabroot.io/articles/%D9%85%D8%AA%D8%B7%D9%84%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D8%A7%D9%86-%D9%88%D9%85%D8%B1%D8%A7%D8%AC%D8%B9%D8%A9-%D8%A7%D9%84%D9%83%D9%88%D8%AF-%D9%85%D8%B9-owasp-asvs/).

## سجل التحديثات Changelog

- أكتوبر 2026: كتابة القصة من مصادرها المنشورة (محاضرة Robinett في GDC، متحف The Strong، تدوينات Larry Osterman وRaymond Chen، تحليل Geoff Chappell، مذكرة Gates، مدونة Google)، وتشغيل البيض الحديث في Chrome 156 وFirefox 157 وحاوية Debian 13 فيها Python 3.13.5 وVim 9.1 وEmacs 30.1 وapt 3.0.3.