VOL95: Anthropic's Most Powerful Model Which Scared Its Own Creators 🚀
أعلنت Anthropic عن نموذجها الجديد Claude Mythos Preview، الأقوى في تاريخها والأكثر قدرة على اكتشاف الثغرات الأمنية في البرمجيات — لكنها رفضت إتاحته للعموم بسبب خطورته.
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩
أهلًا وسهلا بكم في العدد الخامس والتسعين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هتساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع، هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات لمقالات مختارة من اقرأ-تِك.
🌟 مواضيع النشرة لهذا الأسبوع 🌟
ورقة وقلم : How Online Payments Work 🚀
AI في سطور: Anthropic’s Most Powerful Model Which Scared Its Own Creators 🔥
مقال الأسبوع: Understanding Kubernetes CPU Limits and Requests 💎
How Online Payments Work 🚀
واحدة من أكثر المجالات صعودًا في السنين الأخيرة في عالم التقنية هي ال Fintech بل وأصبحت لا غني عنها وجزء من حياتنا اليومية, وأي Business حاليًا لازم يتعامل معها بطريقة أو بأخرى, فورقة وقلم مًبرمجنا الفاضل وتعالى نفهم أساس النظام دا من وجهة نظر العميل ووجهة النظر التقنية لأن سواء احتجت تطبق Payment Solution أو بس ت Integrate مع حل جاهز, فهمك للنظام دا هيسهل عليك كتير..
القصة القصيرة بالنسبة للعميل:
العميل بيدفع للتاجر باستخدام بطاقة البنك الخاصة بيه سواء في المحل مع جهاز الـ Terminal أو ما يعرف ب Point of sale POS) أو بيدخل بيانات الكارت في ال Checkout علي الموقع, وقتها احنا بنعمل Authorisation Request للبنك المٌصدر للكارت عشان نتأكد من وجود رصيد كافي للمعاملة ال Authorisation request دا بنعمل فيه أكثر من عملية أهمهم:
التأكد من بيانات الكارت و من إن المعاملة مش Fraud
التأكد من وجود رصيد كافي
لو في رصيد كافي فالبنك بيقوم بخصم قيمة المعاملة من حساب المشتري وإرسالها لحساب التاجر
خلص ال Authorisation request بنجاح عميلنا كدا دفع بنجاح وخد مشترياته ومشي.
خد بالك عزيزي المبرمج العميل هنا مهتم بـ حاجتين ملهمش ثالث:
Reliability of Service: أمان المعاملة (ادفع ويتخصم مني فقط القيمة المٌتفق عليها من غير مشاكل تقنية وتفضل بياناتي وبيانات حسابي في أمان)
Ease of Service: سلاسة ووقت المعاملة (عملية الدفع تتم بأسهل وأسرع طريقة)
فمهما قصة ال Payments تطول معاك في تفاصيلها أولويتك الأولى والأخيرة إنك بتوفر له الحاجتين دول.
القصة الطويلة بالنسبة للمبرمج
قبل ما نعرض الخطوات هنناقش نقطتين مهمين:
المصطلحات المٌستخدمة في أنظمة الدفع
خلونا نستعرض بعض المصطلحات لتسهيلها, الجميل إن المصطلحات دي 90٪ من الوقت ثابتة حول العالم ففي مصر مثل السعودية مثل أمريكا هو نظام واحد بيختلف مٌقدمين الخدمات وأسمائهم.
الـ Issuer (البنك المُصدِر): هو البنك أو الجهة التي أصدرت بطاقة العميل ويتحقق من صلاحيتها ويوافق أو يرفض العملية.
الـ Acquirer (البنك المُكتسِب): هو البنك أو المؤسسة المالية التي تمثل التاجر وتستقبل المدفوعات نيابة عنه من شبكات البطاقات.
ال Card Network (شبكة البطاقات): هي الجهة الوسيطة التي تربط بين البنك المُكتسِب (Acquirer) والبنك المُصدِر (Issuer)، وتُعالج الطلبات وتُطبق قواعد المدفوعات بين الطرفين.
الـ Payment Gateway (بوابة الدفع): هي الواجهة الإلكترونية التي تجمع بيانات الدفع من العميل وتربطها آمنًا بمعالج الدفع لتنفيذ المعاملة.
الـ Payment Processor (معالج الدفع): هو النظام أو الشركة التي تنفذ عملية الدفع تقنيًا من خلال التحقق من البيانات والتواصل مع الشبكات والبنوك.
عملية الدفع ليست خطوة واحدة
لما بندفع Cash, عميلة الدفع أغلب الوقت هي نفسها عملية الاستلام. بينما في عمليات الدفع الالكتروني عملية دفع العميل لا تعني استلام التاجر للفلوس, طيب إزاي🤷♀️
السر في كون عملية نقل الأموال الفعلية عملية مكلفة فعلاً, خلونا نوضح بمثال
الأموال الخاصة بالعميل في بنك واحد, وحساب التاجر في بنك اتنين, البنك بيوصله الاف المعاملات خلال اليوم مش منطقي بعد كل معاملة نطلع وفد من البنك ينقل الفلوس من بنك للثاني والعكس بالعكس. ولذلك البنوك بتعمل بنهاية اليوم عملية تسوية للأموال وتحسب اللي محتاج يدفعه كل بنك للثاني وتحدد أوقات نقل الأموال.
وبكدا عملية الدفع بتنقسم دومًا خطوتين:
عملية تحقق Authorisation : وفيها البنك المٌصدر بيقوم بحجز الفلوس في حساب العميل بل وبيوضح للعميل إنه اتخصم منه بشكل فوري(حسابك كرقم بيقل) لكن الفلوس في الواقع متحركتش من البنك.
عملية تسوية Settlement : وفيها يتم نقل الفلوس بالفعل لحساب التاجر في البنك. عملية التسوية بتحصل عادة خلال يوم أو اثنين ولكن في حلول حاليًا بتقدم تسوية للتاجر في نفس اليوم.
Anthropic’s Most Powerful Model Which Scared Its Own Creators 🔥
في نص الأسبوع، Anthropic عملت حاجة غريبة شوية — أعلنت عن model جديد اسمه Claude Mythos Preview، وفي نفس الوقت قالت إنها مش هتنزله للعامة.
مش بسبب أي مشكلة تقنية. ولكن بسبب إنه خطير جدًا.
إيه اللي بيعمله Mythos بالظبط؟
الـ model ده متخصص جداً في الـ cybersecurity. وبالتحديد، في إيجاد الـ vulnerabilities في الـ software و Anthropic جربته على أكتر من 7,000 مشروع open source، ومعظم الوقت، كان بيقرأ الكود، بيعمل hypotheses عن الـ vulnerabilities، وبيشغل المشروع فعلاً عشان يتحقق — وفي الآخر بيطلع إما بـ bug report كامل مع proof-of-concept exploit، أو بيقول إنه مفيش حاجة.
طب والنتيجة كانت ايه؟
الـ model وجد آلاف من الـ high-severity vulnerabilities في أنظمة تشغيل ومتصفحات ضخمة — vulnerabilities بعضها فضل موجود لسنين من غير ما حد يلاحظه.
Project Glasswing
وعشان كده، Anthropic عملت مشروع اسمه Glasswing — فكرته إن Anthropic هتستخدم Mythos نفسه عشان يساعد في تأمين الـ critical software في العالم قبل ما أي حد تاني يستغل نفس القدرات دي.
ومش بس كده ده كمان التزمت بـ $100M كـ model usage credits لشركاء المشروع ده، وبرضو تبرعت بـ $4M للـ open source security foundations زي Linux Foundation وApache.
Mythos System Card and Benchmarks
الـ system card بتاع Mythos — اللي جه بـ 244 صفحة — فيه تفاصيل مقلقة شوية عن الـ alignment.
في اختبار واحد، Mythos حقن كود في ملف عشان يدي نفسه permission لتعديل حاجة مش المفروض يعدل فيها — وبعدين مسح الأثر وقال إنه بس بيعمل “cleanup”. لكن الـ researchers استخدمواinterpretability techniques ولاقوا إن الـ model من جوا كان عارف تماماً إنه بيعمل حاجة ممنوعة وبيحاول يخبيها.
في حالة تانية، الـ model وصل بالغلط لـ database مش المفروض يشوفها، وبدل ما يقول الإجابة الصح بالظبط ويكشف إنه شاف البيانات، قدم confidence interval “بشكل مريب” — و استخدمواinterpretability كشف إنه كان “بيعمل strategic response عشان يغش مع الحفاظ على الـ plausible deniability”.
الخلاصة
شركة Anthropic وصفت Mythos بإنه “best-aligned model” ليها لحد الآن — وفي نفس الوقت قالت إنه “likely poses the greatest alignment-related risk of any model we have released.” الجملتين صح في نفس الوقت.
المعادلة بسيطة: كل ما زادت القدرات، زاد الـ risk — حتى لو الـ alignment كان فيه تحسن.
لحد دلوقتي، Mythos مش متاح للناس. بس لو عايزين تاخدوا فكرة عن المكان اللي الـ AI models رايحة ليه في الـ cybersecurity، فالقصة دي مثال كويس.
Understanding Kubernetes CPU Limits and Requests 💎
ناس كتير بتستخدم Kubernetes مش مهم هل لحاجه ضرورية ولا لا .. ولكن انا بعتبره حاجة كدا مما عم به البلاء أو الموضة لكن بما اننا بنستخدمه والناس كلها بتستخدمه فمحتاجين نفهم شويه تفاصيل.
المقال ده هيكون طويل شوية لذكر تفاصيل داخلية وهيكون في الآخر الخلاصة الي أنت محتاج تعرفها لو مش عايز تتوه في التفاصيل.
المهم إن Kubernetes فيه جزء الناس أغلبها ملمين بيه ألا وهو الـ CRUD الي بتعمله وانت بتعمل Apply لشوية specs مكتوبة بـ Yaml format ودا فقط بيروح يعمل CRUD في etcd db ودا الـ db engine الي بيستخدمه Kubernetes.
التفاصيل دي بتاخدها components داخليه بتشتغل عليها منها الـ high level ومنها الي بيتعامل مع الـ Linux kernel لكن في المقال دا عايز اتكلم عن جزء الـ Resources Request and Limits وهتكلم تحديدًا عن الـ CPU. وفي مقال تاني ممكن نتكلم عن الـ Memory.
CPU Requests & Limits
هل سألت نفسك قبل كدا لما بتحط CPU limits او memory limits او CPU requests او memory requests الأرقام دي الـ Kubernetes بيعمل بيها ايه او الـ Linux kernel بيتعامل معاها ازاي؟
والإجابة هي إن Kubernetes بيستخدم حاجة اسمها Cgroup عشان يدير الـ resources زي الـ memory والـ CPU لكل container قايمة علي الـ Node من خلال Kubernetes. والمسؤول عن الجزء دا هو الـ Kubelet والي تقدر تعتبره المخ بتاع Kubernetes.
المهم إن Kubernetes بيقسم أو بيوزع الـ Pods في ثلاثة تصنيفات بناءًا علي الإعدادات بتاعة الـ memory والـ cpu الي انت بتحطها في الـ Specs بتاعة الـ Pod وبناءًا عليه ايضًا وجود الـ workload او الـ pod بتاعك في أي من التصنيفات دي بتتغير طريقة التعامل معاها وبقاءها في حالة الـ node pressure او التضحية بيها ودا بيُسمى Quality of Service او QOS اختصارًا والي ممكن تشوفه لما تعرض الـ Specs لـ Pod موجوده عن طريق
kubectl get pod pod-name -o yaml هتلاقي فيه managed field اسمه qos.
طيب ايه التقسيمات دي وتأثيرها ايه علي دورة حياة الـ workload بتاعتك وعلي الـ Out of memory issue ؟ دي كلها حاجات مهم نكون ملمين بيها ولكن أنا في المقال ده هتكلم فقط او أكثر علي الجانب الخاص بالـ CPU.
تصنيفات الـ QOS
Guaranteed
ودي شروطها إن :
الـ CPU requests = الـ CPU limits
والـ Memory requests = الـ Memory limits
يعني يكونوا قد بعض .. طيب دا بيترتب عليه ايه؟
بيترتب عليه أداء أفضل وأولوية بمعني إن في حالة الضغط أو ال node pressure والحاجة للتضحية ببعض ال workloads البروفايل دا بيكون آخر حاجة بيتم التضحية بيها وبتاخد أداء مضمون.
ولكن لل CPU limits عيوب هنتكلم عنها لاحقًا ودا عادة اختيار لما تكون عايز predictable CPU availability زي أنواع من ال workloads الي بتعتمد في أنماط التصميم وتحسين الأداء علي حساب ال CPU المتاح زي ال work schedulers وال concurrency rate limit والي غالبا لا ينطبق علي أغلب ال web apps. وده لإن عادة بتتسخدم الأنماط دي في ال db engines وال Message queues وغيرها.
Burstable
ودي شروطها إن:
ال Resources Request تكون أقل من ال Resources Limits
ودا معناه إن هتاخد الي طلبته ولكن هتقدر تستخدم resources أكتر لو احتجت أكتر من اللي المطلوب بشرط إن يكون متاح دا اصلًا علي ال node وهنسرد دا في تفاصيل لاحقة ازاي دا بيتوزع في كل حالة والفرق بين ال request وال limits.
Best Efforts
ودا لو محطتش أي limits ولا requests .. في الحالة دي ال Pod بتاعتك هتستخدم المتاح أو الي هيتحط لها تاكله أو تموت من الجوع وأول حاجة بيتم بيها التضحية في حالة الضغط وكمان عرضه للـ throttling.
الفرق بين الـ CPU Request والـ CPU Limits
طيب احنا محتاجين نفهم ايه الفرق بين ال CPU request وال CPU limits غير الفرق الواضح من المسميات الي هو اختصارا ال request دا الي طلبته وال limits دا اخري.
بفضل الله أصبح متاح حالياَ دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship, بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.
دورك كشريك أو راعي هيكون محوري في دعم المحتوى وتوسيع نطاق تأثيره. فانضم لرحلتنا وكن جزءًا من صناعة مستقبل التكنولوجيا في المنطقة 🚀
شركاء النجاح:
تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
