لینک کوتاه مطلب : https://hsgar.com/?p=5138

تبریک می گوییم: ما اکنون در مورد مشارکت های منبع باز شما نظر داریم

نوشته شده در شنبه 9 جولای 2022

من در مورد مسائل زنجیره تامین مطالب زیادی نوشتم و می ترسم نظرات بیشتری داشته باشم که بخواهم به اشتراک بگذارم. روز جمعه من به همراه بسیاری از افراد دیگر در جامعه پایتون به خاطر ایجاد آن به من تبریک گفتند
یک بسته بحرانی. هنگامی که بسته‌ها در سطح معینی از پذیرش در مقایسه با بارگیری‌های جهانی قرار می‌گیرند، حیاتی تلقی می‌شوند. در حال حاضر اگر یک بسته “بحرانی” را حفظ می کنید به این معنی است که باید یک تأیید کننده چند عاملی ثبت نام کنید. به نظر می رسد که نتیجه فرضی عدم ثبت نام در 2FA عدم امکان انتشار نسخه های جدید است. واکنش درونی من به این ایمیل مثبت نبود.

از نقطه نظر شاخص بسته، افزایش حفاظت برای بسته های حیاتی بسیار منطقی است. اجرای یک فهرست بسته گران است و کاربران ایندکس بسته واقعاً می خواهند احتمال به خطر افتادن بسته ای را که به آن وابسته هستند کاهش دهند. از نظر تئوری، این نوع حفاظت واقعاً باید برای هر بسته اعمال شود. این کاری نیست که PyPI انجام داد، آنها تصمیم گرفتند که مرزی بین بسته های “بحرانی” و سایر بسته ها ترسیم کنند.

از نقطه نظر شاخص، من واقعاً این را درک می کنم، اما به عنوان یک توسعه دهنده نرم افزار منبع باز، در این مورد کاملاً دچار تعارض هستم. پیامی که برای من به عنوان یک نگهدارنده وجود دارد کاملاً واضح است: هنگامی که یک پروژه به بحرانی رسید، شاخص می‌خواهد مقدار مشخصی از کنترل را اعمال کند. از منظر شاخص، اعمال محدودیت های بیشتر برای چنین پروژه ای در محدوده شرایط خدمات آن است.

با این حال، هنگامی که من یک پروژه منبع باز ایجاد می کنم، انتخاب یک بسته “بحرانی” ایجاد نمی کنم. این می شود که با پذیرش در طول زمان. در حال حاضر پیامد یک بسته حیاتی بودن بسیار خفیف است: فقط باید 2FA را فعال کنید. اما اکنون یک خط کشیده شده است و من مطمئن نیستم که چرا اعمال محدودیت های بیشتر به نفع شاخص نیست.

به‌جای اینکه بار را بر دوش کاربر بسته‌ها بگذاریم، اکنون چیزها را بر دوش توسعه‌دهنده‌ای قرار می‌دهیم که قبلاً زحمت و زمان خود را صرف آن می‌کند. از نقطه نظر این شاخص، عدم اجرای قوانین برای همه یک فایده است، زیرا برخی از این قوانین ممکن است استفاده از شاخص را سنگین کند، اما قرار دادن بار فقط بر روی بسته‌های مهم، به همان اندازه به پذیرش آسیب نمی‌زند. همانطور که قبلاً ذکر شد، من نمی خواهم این موضوع را مطرح کنم که 2FA سنگین نیست، این یک چیز معقول است. اما به وضوح این شاخص آن را به اندازه کافی سنگین می داند که آن را برای همه اجرا نمی کند. هر چند مهمتر این است که چه چیزی می تواند در آینده اتفاق بیفتد.

آینده ای فرضی وجود دارد که در آن قوانین سخت تر می شوند. می توان تصور کرد که یک شاخص می خواهد امضای رمزنگاری بسته های تازه منتشر شده را اعمال کند. یا ایندکس می‌خواهد بازیابی بسته‌های حیاتی را فعال کند اگر نویسنده پاسخ ندهد یا کارهای بدی با بسته انجام ندهد. به عنوان مثال منتشر نشدن یک بسته مهم برای اکوسیستم یک مشکل است. می‌توان شرایطی را تصور کرد که در آن صورت، نگه‌دارندگان شاخص، رکورد آن بسته روی شاخص را در اختیار می‌گیرند تا آسیب را خنثی کنند. به همین ترتیب، بیش از حد قابل تصور است که یک شاخص آینده به بسته‌هایی نیاز داشته باشد که حداقل استانداردی را برای بسته‌های مهم مانند SLO خاص برای پاسخ به درخواست‌های دریافتی حیاتی (امنیتی، قوانین علامت تجاری و غیره) اعمال کنند.

من فکر می کنم به عنوان یک توسعه دهنده منبع باز که از ایندکس به صورت رایگان استفاده می کند، نمی توانم چیز زیادی از آن بخواهم. من از بسیاری جهات تابع قوانین و الزاماتی هستم که این شاخص رعایت می کند. در برخی از اکوسیستم ها واقعاً انتخاب زیادی وجود ندارد زیرا فقط شاخص اولیه قادر به ارائه بسته ها است یا شاخص های جایگزین به سختی حفظ می شوند. همچنین به نفع شاخص اولیه نیست که اجازه دهد بسته‌های خارج از شاخص وجود داشته باشند، زیرا در این صورت قوانینی که این شاخص می‌خواهد اعمال کند نمی‌تواند اجرا شود.

بنابراین اگر بخواهم چیزی را آرزو کنم، پس آن شاخص هیچ سیاستی فراتر از تغییرناپذیری دارایی ها ندارد و در عوض از یک لایه مستقل از شاخص برای اعمال سیاست ها استفاده می کنیم.

در دنیای زنگار موزیلا پروژه ای را آغاز کرد که کاملا امیدوارکننده به نظر می رسد به نام
بار – دامپزشک. این مبتنی بر این ایده است که کاربران بسته ها می توانند وابستگی ها و مهمتر از همه نسخه های فردی آنها را بررسی کنند. شما می توانید بررسی های خود را با دیگران یا حداقل در سازمان خود به اشتراک بگذارید. یک ابزار تعاملی وجود دارد که به شما در فرآیند بررسی کمک می کند. این به شما کمک می کند کد منبع، تفاوت های بین نسخه های بررسی شده را بررسی کنید، تغییرات را به شما نشان دهد و موارد دیگر. بعد از اینکه درباره نسخه فردی تصمیم گرفتید، می توانید گواهی خود را تأیید کنید و دیگران نیز می توانند از آن استفاده کنند. دیگران معمولاً به معنای همان شرکت هستند، اما می توان تصور کرد که این شرکت نیز به شرکت های مستقل یا دیگران برای انجام این بررسی ها تبدیل می شود.

برای من مهم‌ترین بخش بررسی این است که بر اساس نسخه‌ها است و نه بر اساس افرادی که پشت آن هستند. به یک معنا مردم مهم نیستند، کد مهم است. من می توانم یک روز یک انسان کاملاً کارآمد باشم و روز دیگر دچار یک اختلال روانی می شوم و کار احمقانه ای انجام می دهم. من خوشحالم که نسخه‌های بررسی‌شده خاص را می‌پذیرم، اما لزوماً نمی‌خواهم فقط به آخرین نسخه یک بسته ارتقا دهم. اگر بسته ها از شخصی به شخص دیگر منتقل شوند، این کار بهتر عمل می کند.

آنچه در مورد آن دوست دارم بار - دامپزشک رویکرد این است که نگرانی های مربوط به اجرای یک شاخص را از بررسی جدا می کند. همچنین به این معنی است که در تئوری می توان چندین شاخص رقیب ارائه کرد و هنوز هم می توان بررسی کرد. مهمتر از همه، اصطکاک بررسی را به جامعه ای که بیشتر به این موضوع اهمیت می دهد، می رساند: کاربران تجاری. به جای اینکه نگهبانان منبع باز مجبور باشند از حلقه های بیشتری عبور کنند، بررسی می تواند به دیگران برون سپاری شود. ممکن است «دفتر اسناد رسمی» معتمد ظاهر شود که برای رایج‌ترین نسخه‌های کتابخانه بررسی می‌کند و تا زمانی که بررسی نشود، نسخه جدیدی را تأیید نمی‌کند. زیبایی بالقوه این سیستم همچنین این است که یک نسخه حل کننده می تواند وابستگی ها را در کتابخانه های بررسی شده محدود کند. این می تواند تعداد کل نسخه های بسته های مورد استفاده در یک شرکت یا پروژه را تا حد زیادی کاهش دهد. به‌جای اینکه توسعه‌دهندگان در یک محیط تجاری به آخرین نسخه به‌روزرسانی می‌کنند و احتمالاً به چیزی که حاوی کرم است ارتقا می‌دهند، این ارتقا فقط به آخرین نسخه بررسی‌شده‌ای که شرکت قبلاً پذیرفته است، می‌رود.

شاید بتوانیم آینده‌ای برای فهرست‌های بسته پیدا کنیم که در آن نگه‌دارنده‌های بسته‌ها بار بیشتری را تحمل نکنند، زیرا اینترنت بسته به آن شروع شده است. تقصیر خالق نیست که خلقت آنها محبوب شد.

لینک منبع

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.