اگه دوست دارید در مورد submodule های git بدونید در حدی که اگر مجبور شدید استفاده کنید گیج نشید، این مطلب خیلی خوبی بود
https://www.cyberdemon.org/2024/03/20/submodules.html

اگه می‌خواید حجم فایل pdfتون رو کاهش بدید با کمک ghostscript لینوکس می‌تونید ولی رابط کاربری تمیزی نداره. به جاش می‌تونید از این اسکریپت استفاده کنید و هرچقدر که دوست دارید حجم/کیفیتش رو کاهش بدید. امکانات دیگه‌ای مثل سیاه‌وسفید کردن هم داره.
https://github.com/aklomp/shrinkpdf

بیاید اول یکم مرور کنیم که Fuzzing چیه. فرض کنید یک فانکشن‌ای نوشتید که چهار تا عدد از تایپ integer رو به عنوان پارامتر دریافت میکنه. فرض کنید تابع‌تون چیزی شبیه به اینه :

fun foo(int x, int y, int z, int t) {
    
    // bunch of statements

    if ( (x^t+1)^3 + (2.3*y)^2.3 - 0.8*(z^4) == 0) { // call the condition as 'f'
        Bug();
    }

    // bunch of statements
}

همونطور که ملاحظه می‌کنید، توی برنامه‌ما یک point ای وجود داره که اگر reachable باشه به باگ می‌خوریم. حالا سوالی که وجود داره اینه که بفهمیم آیا این امکان وجود داره که شرط f ارضا بشه یا خیر. برای اینکه به جواب سوال‌مون برسیم، باید یک decision procedure پیاده‌ کنیم که به عنوان ورودی فرمول f رو ازمون بگیره، و بهمون true یا false برگردونه. یک computer scientist اولین سوالی که به ذهنش میرسه اینه که آیا این مسئله محاسبه پذیره یا خیر و اگر هست با از نظر پیچیدگی در چه کلاسی قرار داره. به طور خلاصه خدمتتون میگم که این مسئله undecidable هستش. حالا سوالی که پیش میاد اینه که چیکار کنیم؟ رهاش کنیم بره؟ خب قطعا نه. یه راهی که از دهه ۵۰ میلادی، یعنی از زمان پانچ کارت ها وجود داره اینه که بیایم شروع کنیم با یک الگوریتم Pseudo random number generating برای این ۴ تا متغیر value جنریت کنیم و چک کنیم ببینیم که آیا این فرمول تحت اون assignment ارضا میشه یا نه. اگر شد که خب میگیم بله reachable هستش و برنامه مون باگ داره. اگر نشد... خب بیاید این یه تیکه رو فعلا اسکیپ کنیم :)

حالا قضیه‌ی Fuzzing هم ریشه‌اش برمیگرده به random testing اما قطعا با رندوم تستینگ فرق داره. می‌تونیم بگیم رندوم تستینگ ساده‌ترین و naive ترین نوع Fuzzing هستش. تکنیک‌های Fuzz testing با توسعه‌ای که از دهه ۹۰ تا الان داشتن، ساختارمند شدند و باهوش تر عمل می‌کنند. یک سری‌هاشون از نوع generation-based یعنیتوی هر iteration ورودی‌ها رو از اول تعیین می‌کنند. یک سری‌هاشونم mutation-based هستند و میان input ها رو modify می‌کنند. فاز تستینگ‌ها به شکل white و black و gray box انجام میشن. بلک باکس اینطوریه که fuzzer هیچی از ساختار برنامه نمی‌دونه. gray box یعنی اینکه ما نیاز داریم کمی instrumentation روی کدمون انجام بدیم و به طبع white box هم که مشخص میشه چیه.

فازری که داچمن رفته سراغش از نوع gray-box و mutation-based هستش. منتهی باهوش تره، یعنی بلده که mutation هاش رو به سمت یک سری هدف و یا coverage خاص که از پیش براش مشخص شدن هدایت کنه. اصلاحا به این نوع فازرها میگن Directed Grey-box fuzzing. این تکنیک توسعه‌ و پیاده‌سازیش توسط آقای Abhik Roychoudhury و تیمش صورت گرفته. ایشون یه گروه بسیار سوپر و قوی توی دانشگاه NUS دارن که تو حوزه‌ی Fuzzing و Automated Program Repair فعاله. بسیار توصیه می‌کنم اگر به این بحثا علاقه‌مند هستید برید و کارشون رو بخونید.

تا اینجا مقدمه بود میریم سراغ بحث اصلی.

اگه دوست دارید در مورد ingress و ingress controller توی کوبرنتیز بدونید این مطلب خوبیه و سعی می‌کنه پیش‌نیازهای لازمش هم تا حدی پوشش بده:
https://traefik.io/glossary/kubernetes-ingress-and-ingress-controller-101/

شاید خبرش به گوشتون رسیده باشه که سیستم‌های مبتنی بر ویندوز و آژور در سراسر جهان، دیروز ترکیدن و کار و زندگی مردم فلج شده.
به عنوان کسی که این ترکیدن رو لایو تجربه کرد (داشتم روی یه تیکت تو پرتال شرکت کامنت می‌ذاشتم. بعد از سیو، کل سامانه غیب شد. 😬) بیاین با مفهومی به اسم SLA آشناتون کنم.

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

مثلا شما به مایکروسافت می‌گید یک ترابایت حافظه ابری می‌خوام که عکسای عروسیمو بریزم روش. مایکروسافت به شما می‌گه این عکس‌ها ۹۹ درصد مواقع در دسترس هستن. یعنی شما ۹۹ درصد مواقع اگر تلاش کنین عکسا رو باز کنین، باز می‌شن. اون ۱ درصد رو می‌ذارن تا برای مشکلات احتمالی دست خودشونو باز بذارن. اگر برقی رفت، هکی اتفاق افتاد، سروری سوخت، کسی نتونه بیاد یقه‌شونو بگیره که چرا سرویسی که به من فروختی خرابه.

این توافق بین شما و مایکروسافت اسمش می‌شه Service Level Agreement یا SLA. یعنی شما با مایکروسافت توافق کردین که سرویسی که ازش می‌گیرین چند درصد مواقع قطعا سالمه. برای مصارف شخصی شاید ۹۹ درصد خیلی عدد خوبی به نظر بیاد، ولی این عدد یعنی توی یک سال جمعا حدود ۳ روز ممکنه سیستم بهتون ارائه نشه. پس برای بیزنس‌هایی که مشتری دارن ۹۹ هم به اندازه کافی خوب نیست. ممکنه نیاز داشته باشن سرویسشون در سال فقط یک ساعت داون باشه، و براش ۹۹.۹۹ درصد تضمین بگیرن. یا درخواست کنن که بیش‌تر از ۵ دقیقه در سال سیستم خراب نباشه، و تضمین ۹۹.۹۹۹ بگیرن.

اگر سرویس‌دهنده (در این مثال، مایکروسافت) دچار مشکلی بشه و نتونه SLA رو رعایت کنه، باید جریمه بده. مثلا شرکت ما دیروز بیش از ۴ ساعت دسترسی به پرتال نداشت، و اگر SLA شون روی ۹۹.۹۹ بوده باشه قطعا بهشون جریمه پرداخت می‌شه.

اگر بی‌کارین، می‌تونین توی سایت uptime.is هی درصد وارد کنین، ببینین با هر درصد چند ساعت در روز سیستمتون داون خواهد بود. 😁

درسته کدک h265 یا HEVE خیلی بهمون کمک میکنه حجم ویدیوهای با کیفیت کمتر بشه، اما یه کدک دیگه هم هست که نسبتا جدید تره و compression بسیار بهتری داره. اونم av1 هست که پارسال شرکت متا برای استوری های اینستاگرام ازش استفاده کرد.
یه نکته خیلی جالب اینه که چون encode کردن ویدیو ها با این کدک منابع بیشتری نیاز داره و زمانبر تر هست، یوتیوب فقط برای ویدیو هایی که در مدت زمان کم وایرال میشن ازین کدک استفاده میکنه.
جزییات بیشتر این کدک رو اینجا میتونید ببینید
https://www.youtube.com/watch?v=BMAccTJBDjE

من از این سایت/پروژه khoj خیلی خوشم اومد. یه پروژه‌اس که رابط وب و واتساپ و ... داره و امکان این رو می‌ده که با agentهای مختلف هوش مصنوعی‌ش ارتباط برقرار کنید، فایل اپلود کنید و بگید بر اساس اون (و نوتهای obsidianتون) و ... بهتون جواب بده.
نکته مهمش اینه که می‌تونید self hostش کنید و لوکال بهش بگید که از ollama استفاده کن یا api chatgpt
رابط کاربری نسبتا خوبی داره و نسخه رایگانش که خودشون هاست کردن هم به خوبی کار می‌کنه ولی محدودیت تعداد پیام داره قاعدتا.

https://github.com/khoj-ai/khoj

نکته: رابط کابریش بهترین نیست ولی اینکه اینقدر امکانات داره و باگ‌هاشم مانع استفاده ازش نمیشه و قابل استفاده و open source و eslf hostئه باعث می‌شه مشکلات رابط کاربریش به چشم نیاد.

دوست دارید با گیت پوش، کدتون رو روی سرورتون دیپلوی کنید؟
ابزارهای مختلفی برای اینکار هستن که یکی از کوچک ترین هاش پیکو هست:
https://github.com/piku/piku

اگه دوست دارید در مورد کرنل لینوکس و زمان بندها و pidها بیشتر بدونید این مطلب رو توصیه میکنم:
چه پروسسی در کرنل، pid 0 داره؟
https://blog.dave.tf/post/linux-pid0/

یه مطلب خوب در مورد معرفی وب اسمبلی
https://vrgl.ir/g268k

توضیح بسیار خوب و روونی داره و مدل ذهنی خوبی ایجاد میکنه

یکی هم مقاله فیگما راجع به همین موضوع رو کامنت کرده بود که به نظر جالب میاد

https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/

به بهانه‌ی این مطلب چند تا نکته در مورد خوندن کد بگم:

۱- خوندن کد خوبه و هر کدی هم باشه کلا خوبه. مثل کتاب خوندن. از نظر من کد خوندن مثل رمان و کتاب خوندنه.

۲- با خوندن کد بیشتر و بهتر، کدهای بهتری هم خواهید نوشت. یادگیری دیزاین پترن و اصول کد تمیز خوبه ولی دیدن اینکه در عمل چه چیزی باعث خوب شدن کد می‌شه یه چیز دیگه‌ست و اگه کد بخونید از بقیه جلو می‌افتید.

۳- همونطور که وقتی الفبا رو یاد گرفتیم نمیشه انتظار داشت که آثار شکسپیر رو بخونیم، قاعدتا اگه اولین کدی که می‌خونیم کد لینوکس باشه، خیلی چیزاشو متوجه نمی‌شیم. می‌شه اول از چیز‌های ساده‌تر شروع کرد.

۴- یه سری پروژه‌ها (مثلا minix) به هدف اینکه سورس کد قابل فهمی داشته باشن نوشته می‌شن و یه سری دیگه به هدف پرفورمنس و کاربردی بودن و ... شروع کردن از اونایی که سورس کد مرتب تر و ساده‌تری دارن قطعا توصیه می‌شه. مخصوصا اگه ایده‌ی کلی از اون سیستمی که پیاده‌سازی می‌شه نداریم. مثلا اگه نمی‌دونیم سیستم‌عامل چطوری کار می‌کنه بهتره اول کتاب در موردش بخونیم. بعد یه کتاب یا منبعی که سورس‌کد رو توضیح داده بخونیم (یا همین مینیکس که سورس کد ساده و با کامنتی داره). و در نهایت می‌تونیم (شاید بتونیم) سورس کد یه سیستم‌عامل واقعی رو بخونیم.

۵- خوندن کد خیلی وقتا مثل کتاب نیست که از اول شروع کنیم تا آخر بریم، بلکه به شکل چرخیدن تو یه جنگل بزرگه. می‌چرخیم و جاهای جالبش رو نگاه می‌کنیم. مثلا همین که فایل cgroupش رو باز می‌کنیم. گاهی هم سعی می‌کنیم ساختارمندتر کار کنیم مثلا main رو باز می‌کنیم و از اونجا می‌ریم جلو. (البته اگه mainی در کار باشه!)

۶- (شاید نظر نامحبوب) خیلی وقتا نیازی نیست همه‌ی کد رو خونده باشیم یا حتی فهمیده باشیم تا بتونیم یه contributionی انجام بدیم. برای انجام یه تغییر کافیه بدونیم کلیت داستان چیه (مثلا main چطوری کار می‌کنه، قسمتی که کد من رو کال می‌کنه چطوریه و معماری و پوشه‌بندی کلی چطوریه) و تغییرمون رو در جای درستش اعمال کنیم. مثلا اگه می‌خوایم کوئری بهینه‌تری برای دیتابیس بنویسیم خیلی وقتا نیاز نیست که بدونیم تو dockerfile چه خبره یا مثلا تو http handler دقیقا چه اتفاقی می‌افته. یا در مثال لینوکسش، اگه می‌خوایم در مورد cgroup بیشتر بدونیم قاعدتا نیاز نیست در مورد درایورهای گرافیک چیز زیادی بدونیم. مخصوصا اگه معماری کد خوب باشه و الکی چیزا رو به هم متصل نکرده باشه.

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

امروز کلا بحث runC بود. از docker و containerd شروع شد. و در نهایت من کل روز رو صرف خوندن همین یک دونه فایل در کرنل کردم. cgroup. سعی کردم یه شهود کلی بگیرم. یه سری پیچیدگی‌ها رو از فهمیدنشون دست کشیدم ولی خب واقعا مفید بود. برای بار هزارم درود بر torvalds.

این مطلب به زبان ساده توضیح میده jwt چیه و چه کاربردی داره و چطوری کار می‌کنه.
https://dev.to/manav-1011/jwt-explained-19o6

دوست دارید به ویم سوییچ کنید ولی بار اول و دوم ناامید شدید؟
این دوستمون هم همینطور ولی بلاخره به cool kids club پیوست.
https://emanuelcepoi.com/preview/66785dd2d3170dd0332a47d9