شرح موقع meetmob الخاص بزبائن موبيليس I مع كيفية التسجيل فيه وفائدته 2019

منذ خمس سنوات ، أعلن مطورو بيثون أنهم سيتوقفون عن دعم بيثون 2 في عام 2020. لفترة طويلة ، لم يهتم أحد وكان تبني بيثون 3 بطيئًا. لكن الأمور تغيرت كثيرًا مؤخرًا حيث أن الموعد النهائي إقترب تمامًا في (1 يناير).

ديبيان تزيل وتوقف الدعم نهائيا عن بايثون 2:

بدأت تخطط دبيان للتخلص من Python 2 بالكامل من إصدارها المستقر القادم ، وبالتالي فهي تتخلص تدريجياً من أكواد Python 2 . حيث قد قاموا بإصدار أخطاء حرجة على حزم  (أي حزم دون تبعية عكسية) يطلبون نقلها إلى Python 3. وإذا لم يحدث منفذ Python 3 قريبًا بما فيه الكفاية ، فستتم إزالة هذه الحزم من دبيان (وهو ما تستند إليه Kali).

 العواقب التي تحدث على كالي جراء وقف الدعم ليبايثون 2:

هل تختفي التطبيقات:

و نظرًا لأن Kali عبارة عن توزيع مستمر ، فإنها تتلقى باستمرار تحديثات من مختبر دبيان. ويشمل ذلك عندما "تغادر" الطرود أي الحزم  لأنها تم إسقاطها من دبيان. ومع ذلك ، يمكنهم دائمًا العودة لاحقًا ، شريطة أن يقوم شخص ما بنقلهم إلى Python 3.

فلقد مررنا بالفعل بهذه حالة في  zenmap التي لم يعد مطورو nmap يحتفظون بها. وبالتالي ، لم يعد يتم بناؤها بواسطة حزمة مصدر nmap من دبيان ، ونتيجة لذلك لم يعد يظهر في كالي.

حدوث خلل للتطبيقات:

 يوجد العديد من تطبيقات Python 2 في كالي التي تستخدم وحدات وحزم يتم تعبئتها في دبيان. عندما يتخلى دبيان على إصدار Python 2 من هذه الوحدة ، يتم كسر التطبيق في kali-dev. ولا يتأثر تطبيق kali-rolling نظرًا لطريقة إدارته ، لكن الاختلاف المتزايد بين kali-dev و kali-rolling يجعل مهمة أكثر صعوبة: لا نحصل على تحديثات لهذه الحزم وهناك تطبيقات أخرى (حديثة) من شأنها أن من المحتمل أن تتطلب إصدارات جديدة من هذه الحزم.

يجب على كالي إزالة أكواد بايثون 2: 

 مقتبس من كالي لينكس:

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

تعتمد الطريقة التى يتم التعامل بها مع كل حالة  على عدة العوامل التالية:

إذا كان المنبع يعمل على دعم Python 3 ، فإننا ننتظر حتى يصبح جاهزًا.

إذا كان المنبع غير نشط أو غير مهتم بنقل الكود الخاص به إلى Python 3 ، فلدينا خيارات قليلة:

إما أن نزيل الحزمة أو نجد بعض الشوكة / التصحيح التي تضيف دعم Python 3 أو نقوم بأعمال النقل بأنفسنا (من المستبعد إلى حد ما باستثناء البرامج النصية التافهة).
 يعتمد أيضًا على نوع الحزم:
بالنسبة لمكتبة Python ، إنها عملية من خطوتين: أولاً نضيف دعم Python 3 ؛ تتم إزالة دعم Python 2 لاحقًا ، بمجرد تحديث كل التبعيات العكسية لاستخدام Python 3.

بالنسبة لتطبيق Python ، قد يكون تحديث واحد كافيًا ولكن هذا التحديث قد يعتمد على وجود تبعيات يتم نقلها إلى Python 3 أولاً.

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

للحزم التي لم تعد تضيف قيمة كبيرة ، أو التي لديها بدائل قابلة للتطبيق في كالي ، قد نزيلها في أي وقت.

كيفة يمكنك المساهمة:

 إذا ظهر أحد تطبيقاتك المفضلة ضمن حزم Kali المتأثرة أو بين الحزم المتأثرة من فريق pkg-security في دبيان ، فيجب عليك مراجعة وضعه وربما مساعدة مطوري البرامج الأولية عن طريق إرسال طلب سحب مضيفًا دعم Python 3. حتى إذا لم يكن upstream نشطًا للغاية ، فسنكون قادرين على دمج تغييراتك في Kali والحفاظ على الحزمة لفترة أطول حتى يصبح upstream نشطًا مرة أخرى.

إذا لم تكن لديك مهارات الترميز المطلوبة لهذا ، فلا يزال بإمكانك محاولة العثور على شوكة / رقعة Python 3 كتبها شخص آخر وتوجيهها إلينا في مشكلة GitLab المقابلة أو تقرير علة دبيان. أو أخبر المطورين عن مدى رغبتك في تطبيقهم وأنك ترغب في الاستمرار في الاستفادة منه ، لذلك يجب أن ينتقلوا إلى Python 3.