اصن اینکه میگن بزرگ شدی میخوای چیکاره شی مزخرف ترین چیزی هست که از یه بچه میپرسیم، به توچه مردک! میخوام بخورم بخوابم ماشین کنترلی بسازم :)))

درخت مرکل چیست؟

اگر یک فایل حجیم رو دانلود کرده باشید و توی فرایند دانلود مشکلی پیش اومده باشه حتما اهمیت اطمینان از صحت داده‌ها رو حس کردید. راه حل کلاسیک برای اطمینان از صحت داده‌ها گرفتن هش اونا و ارائه‌اش از طریق یک کانال جانبی است(مثلا گذاشتن روی سایت). مثل وقتی که یک فایل iso لینوکس رو دانلود می‌کنید برای اطمینان از اینکه فایل درست دانلود شده هش فایل رو می‌گیرید و با هش‌ای که روی سایت قرار گرفته مقایسه می‌کنید. همیشه هم لازم نیست همه هش رو مقایسه کنید. عموما چون بی‌نظمی هش خیلی بالاست چند رقم اول و آخرش هم برای چک کردن کفایت میکنه (در واقع انتروپی بخشی از هش با انتروپی کلش یکیه). اما خب اینجا چند تا مشکل هست؛

اول اینکه خود هش رو چطور برسونیم دست کاربر؟ گذاشتن هش روی سایت بر اساس اطمینان به سایت هم از نظر مالکش و هم از نظر در دسترس بودنش کار میکنه. خب اگر به مالک اطمینان نداشته باشیم چی؟ اگر سایت از دسترس خارج بشه چی؟ اگر آلوده به بد افزار بشه چی؟

ادامه در: 👇
https://ariyan-eghbal.github.io/posts/merkle-tree/

از آریان اقبال
@knowpow

بحث از کارای گرافیکی و موتور های بازی سازی و چند سکویی بود که رسیدیم به کتابخونه ی Compose که Jetbrains توسعه اش داده، در حقیقت اینا از کتابخونه ی Jetpack compose یه کلون گرفتن و شروع کردن برای مالتی پلتفرم کاتلین توسعه دادنش. Jetpack مجموعه کتابخونه های زیرساختی هست که گوگل برای اندروید توسعه داده و این کامپوز رو هم توش نوشته، حالا کامپوز چیه؟ کامپوز یه کتابخونه برای توسعه ی لایه ی کاربری از طریق کد هست، یعنی ساختار دیروزی کد توی اندروید که با xml پیاده سازی میشد رو گذاشتن کنار و این رو معرفی کردن، من چند روزی هست(به اجبار) با این کتابخونه سر و کله میزنم و بنظرم باحال اومد، رفتم پی داستان رو گرفتم دیدم بلههه، گوگل داره اینجا از کتابخونه ی خودش به اسم Skia استفاده میکنه، این کتابخونه سال ۲۰۰۵ توسط دوتا مهندس توی شرکت اسکای‌پی نوشته شد و سال ۲۰۱۱ توسط گوگل خریداری شد تا توی اندروید استفاده بشه، حالا کامپوز با اسکیا چیکار میکنه؟!

کامپوز میاد یه لایه روی اسکیا میکشه و با پارامتر های ورودی پارامتر های دیگه رو رسم میکنه، تو Compose، شما میتونید با استفاده از توابع و API های مختلف، شکل های مختلفی رو ایجاد کنین و اون ها رو در صفحه نمایش برای کاربر نمایش بدین، مثلا شما می توانید با استفاده از تابع DrawLine توی Skia، یه خط رو روی صفحه رسم کنید، حالا کامپوز میاد همینکارو برای شما انجام میده، شاید با خودتون بگین خب ما اینجا کاتلین رو داریم اونجا سی++، کی این دوتارو به هم وصل میکنه؟ بازم JNI میاد وسط…

از اونجا که Skia یه موتور دو بعدی هست و قادر به رسم شکل ها و عناصر گرافیکی مختلفه، Jetpack Compose می تونه از اون برای رسم همه چیز از خطوط ساده تا اشکال پیچیده تر مثل نمودارها و نمایشگرهای داده های پیشرفته استفاده کنه، با استفاده از Skia، Jetpack Compose می تونه برای رسم عناصر UI با کیفیت بالا و بدون افت کیفیت در اندازه های مختلف صفحه نمایش به خوبی عمل کنه، لازمه بگم که تفاوت این ساختار با ساختار قبلی اول از همه هسته های اون در رندر کردن پارامتر های صفحه نمایش هست و دوم نحوه‌ی رندرینگ، در ساختار قبلی از ساختار View و ViewGroup استفاده میشه ولی این ساختار از Composable ها استفاده میکنه که ساختاری پویا هستن و به state ها واکنش نشون میدن، همونطور که گفتم از کامپوز از موتور skia استفاده میکنه ولی ساختار قبلی از OpenGL ES که در هسته ی اندروید موجوده.

حالا دوتا نکته ی جالب داریم، اولی اینکه شما توی کامپوز ها بازم میتونین از ساختار ویو قبلی اندروید استفاده کنید! و مورد دوم هم اینه که کامپوز بدون وابستگی و انتشار هیچ نسخه ای از گوگل برای پایه‌ی کرنل سیستم عامل منتشر شده، یعنی کد شما از اندروید ۴.۱ تا آخرین ورژن اندروید بدون هیچ اپدیت سیستم عاملی کار میکنه.

@knowpow

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

این تعداد ابتلا و مراجعه از نظر پزشکی برایم طبیعی نبود. اما نکته‌ی غیرطبیعی‌تر این بود که همین افراد، بعد از گذشت یک بازه‌ی زمانی نه مریض می‌شدند و نه به درمانگاه مراجعه می‌کردند؛ الّا در موارد واقعاً ضروری. انگار یکباره حالشان خوب می‌شد و به مسیر طبیعیِ سلامت و بیماری باز می‌گشتند.

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

دوست پزشک ما می‌گفت هیچ‌وقت فکر نمی‌کردم حکیمانه‌ترین نکته‌ی زندگی‌ام را نه در دانشگاه و درس‌ها و کتابهای پزشکی؛ بلکه، از یک زندانی حرفه ای بیاموزم که:

«اگر قدرت تغییر چیزی را داری، جسارت تغییر آن را داشته باش و با بهانه‌های پوچ و مزخرف مانند کرم‌ها در لجن دست‌وپا نزن؛ و اگر فعلاً موقعیت یا توان و قدرت تغییر آن را نداری، شجاعت پذیرشش را داشته باش، آن را بپذیر و خودت را با آن برای داشتنِ یک زندگیِ بهینه در همان وضعیت تنظیم کن؛ تا در یک برزخِ انتظاری عمر و توان و انرژی‌ات را بیهوده هدر ندهی».


دکتر محسن زندی

@knowpow

خوندن این پست صابر که پایین لینکش رو گذاشتم من رو عمیقا ناراحت میکنه، فکر کردن به اینکه این دنیا چ قد شخمیه و میتونه چه قدر بی رحم باشه، یه جوون ۳۵ ۳۶ ساله که توی زندگی هممون غیر مستقیم نقش داشته داره اینجوری درد میکشه و کاری از دستم برنمیاد اعصاب و روانم رو بهم میریزه. میدونین این باعث میشه بعضی وقتا به این فکر کنم که همه ی ما روزی بخواییم نخواییم میمیریم، همه ی فکرایی که نتونستیم با کسی در میونشون بزاریم، بنویسم و به کسی بفرستیم یا کاری کنیم جایی بمونه، همه ی فکرا و ایده هایی که داشتیم، همه ی تجربه و حس هایی که تجربه کرده بودیم میره زیر خاک بدون اینکه کسی ازشون خبری داشته باشه، نمیدونم زندگی همینقدر بی رحمه یا من دارم با عینک بدی بهش نگاه میکنم؟!

بشر از مادر ایام نمیزاد ای کاش
تا عنان در کف تقدیر نمیداد ای کاش
زندگی نیست که زندان مکافات است این
کس به زندان مکافات نماناد ای کاش
شهریار


https://rastikerdar.blog.ir/1402/

@knowpow

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

اگر از فونت‌هاش استفاده می‌کنیم، شاید الان دونیت ما بیشتر از قبل به کارش بیاد.
لینک دونیت:
https://www.payping.ir/@saber

به امید بهبود هر چه زودتر صابر عزیز.

این ویدیو نشون میده که ناسا چطور توی دهه ی ۶۰ راکت Saturn V رو کنترل میکرد،‌ واقعا عجیبه، ساختار مموری رو میتونین با چشم ببینید،یه سری گره وجود داره که اینا نسبت به هم مغناطیسی میشن، وقتی یه گره به یه جهت مغناطیسی بشه ینی یک اگه برعکسش باشه یعنی صفر، به همین سادگی(!)

https://www.youtube.com/watch?v=dI-JW2UIAG0&t=71s

اینجا دو مدل سیستم عامل داریم که مدل اول Time Sharing و مدل دوم هم Multi Programing هست

توی مدل اول کرنل میاد بدون توجه به وضعیت پروسس cpu رو از پروسس میگیره و به پروسس دیگه میده، یعنی اگر فکر کنید ما ۵ تا پروسس داریم و هر کدوم یه مدت t طول میکشه انجام بشن، کرنل دائما میاد این t رو بر اساس یک زمان‌بندی مشخص (scheduling) تخصیص رو انجام میده و cpu رو در اختیار اون پروسس میزاره، یعنی اگر بگیم که ما ۵ تا پروسس رو روی یک هسته‌ی cpu اجرا میکنیم و هرکدوم میانگین ۱ دقیقه طول میکشه باید در نهایت ۵ دقیقه وقت برای انجام شدن این پروسس ها در نظر بگیریم که این کاملا اشتباهه، ما اینجا وقت تلف شده داریم! از کجا؟! از کرنل، یعنی وقتی که کرنل میاد cpu رو از p1 بگیره و به p2 بده در حقیقت خودش هم داره اجرا میشه، ما زمانی که کرنل داره اجرا میشه رو میتونیم به عنوان وقت تلف شده در نظر بگیریم،‌چون در حقیقت هیچ کار مفیدی انجام نشده، پس داریم که:

Total time = sum(kernel time) + t p1..p5

مدل دوم هم مدل Multi Programing هست که کرنل cpu رو در اختیار یک پروسس میزاره و بر خلاف مدل قبلی منتظر پروسس میمونه تا وقتی که پروسس وارد وضعیت waiting بشه(اینجا من فقط در مورد IO حرف میزنم)، مثلا منتظر کارت شبکه بمونه تا یه دیتایی بیاد، وقتی که پروسس بلاک میشه و میره توی وضعیت waiting کرنل میاد و cpu رو به پروسس بعدی میده.

از دید کاربر مدل اولی بهتره چون همزمان میتونه هم توی ورد تایپ کنه، هم آهنگ گوش بده هم منتظر نوتیفیکشن ها تلگرامش باشه، ولی از دید سرعت انجام شدن کار ها مدل Multi Programing سریعتره چون کمتر کرنل وارد میشه و در نتیجه زمان تلف شده ی کمتری داریم.


@knowpow

روس ها توی مسابقات برنامه نویسی همیشه جزو تاپ ترین ها بودن، چرا اینو گفتم؟! چون یکی از محصولات خوبی که هرروز ازش استفاده میکنیم و پر از نوآوری هست و کیفیت کاملا متفاوتی داره هم توسط مهندسای روسی که خودشون جزو تاپ ۱۰ مسابقات بودن ساخته شده: بله تلگرام.

حتی یکی از بزرگترین سایت های مسابقات (codeforces) هم توسط روس ها ساخته و میزبانی میشه و تلگرام هم پشتیبانی مالی میکنه از این سابت، حالا من دوتا کانال توی این پست میخوام معرفی کنم که میاد از همین سایت مباحث الگوریتم و ساختمان های داده که بنظرم مهم ترین رکن مهندسی نرم افزار هست رو به روشی که توی مسابقات بهش فکر میکنند و سریع کد مینویسن یاد میده، یعنی به شما competitive programming یاد میده،

کانال اول از Errichto، برنده ی چند ده مدال از مسابقات برنامه نویسی، لهستان
https://www.youtube.com/@Errichto

کانال دوم از Colin Galen، مدال طلا توی مسابقات بین المللی، ایالات متحده:
https://www.youtube.com/c/ColinGalen



@knowpow

در میان کثافت اینستاگرام، تو یوتوب باش با چنین محتوایی...

این 16 دقیقه آینده خیلی ها رو تغییر میده، در دنیای احتمالات شاید یکی از این "خیلی ها" سی سال دیگه نوبل فیزیک ببره؛ و البته در دنیای احتمالات، یک نوجوون ایرانی پشت فیلترینگ این فرصت رو از دست میده. (محسن طهماسبی)

https://www.youtube.com/watch?v=ErMSHiQRnc8

چرا NGINX انقدر وحشتناک سریعه؟!
بخش اول: Traffic Routing

--------------------------------------

مدتی بود دنبال پروژه ای بودم که با هدف عمیق تر شدن توی مفاهیم شبکه و کانکارنسی بتونم با سی++ پیاده سازی کنم، هم فال بود و هم تماشا.
بعد از یه مدت تصمیم گرفتم سمت وب‌سرورها برم و رفتار اونارو زیر بار بررسی کنم، سورس NGINX رو دانلود کردم و شروع کردم به بیلد کردنش و بعد از سر و کله زدن با openssl در نهایت بیلدش کردم، هدف من بیشتر مشاهده ی رفتار NGINX روی حالتی بود که میخواست Load balancing کنه.

طبق چیزی که دیدم NGINX میاد و به دو روش معمول ترافیک رو به سمت سرور های مقصد ارسال میکنه، به طوری که میتونیم بگیم به روش Reverse proxy داره ترافیک رو سمت سرور مقصد هدایت میکنه. وقتی درخواستی از سمت کلاینت ارسال میشه NGINX اون رو دریافت میکنه و طبق الگوریتمی سرور مقصد رو انتخاب میکنه و روش یه سوکت جدید باز میکنه همچنین ممکنه از سوکت های قبلی که اماده داره به سرور مقصد استفاده کنه تا زمان Connection Establishing رو کاهش بده، بعد ترافیک رو از کلاینت میخونه و به سمت سرور اصلی فوروارد میکنه و منتظر جواب میمونه(بخش های بعدی میگم چطور) بعد از اینکه جواب از سرور مقصد دریافت شد اون رو به کلاینت برمیگردونه و تمام.

حالا چرا گفتم ۲ روش؟ چون هم میتونه این کار رو توی لایه ی ۴ نتورک مدل OSI انجام بده هم میتونه توی لایه ی ۷ مدل OSI انجام بده، اگه بخواییم بهتر متوجه بشیم من هم میتونم به NGINX بگم که درخواست هارو بر اساس هدر، سشن یا اندپوینت هدایت کنم(لایه‌ی ۷)، هم میتونم اجازه بدم بر اساس IP یا PORT کاربر این اتفاق بیوفته(لایه‌ی ۴).

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

@knowpow

اگه اینجا اون ریورس پروکسی که توی عکس میبینیم رو بهش یه لاجیکی اضافه کنیم که تصمیم بگیره با یه مبنایی ترافیک رو به یه مقصدی هدایت کنه در حقیقت ما یه لودبالانسر ساختیم

لود بالانسرها به همین سادگی هم نیستن ولی کلیت ماجرا اینه

@knowpow

چرا NGINX انقدر وحشتناک سریعه؟!
بخش دوم: Blocking I/O

--------------------------------------

توی بخش قبلی فهمیدیم که NGINX ترافیک روتینگ رو توی لایه‌ی چهار و لایه‌ی هفت مدل OSI انجام میده و از مدل Reverse Proxy استفاده میکنه.

حالا باید بدونیم چطور NGINX چندین هزار رکویست رو در لحظه میتونه مدیریت کنه؟!
خب NGINX میاد از Nonblocking I/O برای مدیریت کانکشن ها استفاده میکنه، ولی من اول میخوام بریم ببینیم که اصلا Blocking I/O چیه که Nonblocking I/O هم وجود داره؟ اصن چرا باید بلاک بشه چیزی؟

زمانی که برنامه ای میخواد به IO دسترسی پیدا بکنه باید یه سری فرایند رو بگذرونه که این کارها زمانبره و به صورت blocking انجام میشه، یعنی فرض کنید اگر برنامه‌ای میخواد یک فایلی باز کنه تا اون رو بخونه باید فرایند زیر رو طی کنه:

۱- سیستم کال: باید درخواست باز کردن فایل رو با سیستم کال open بدین
۲- تغییر حالتCPU: کرنل برای اینکه بتونه این درخواست رو پردازش کنه نیاز داره که CPU رو به حالت کرنل تغییر بده(چرا؟ چون سوئیچ ضروریه و دسترسی مستقیم به سیستم فایل و منابع سخت افزاری کاری محسوب میشه که فقط کرنل مجازه انجام بده)
۳- صحت سنجی آدرس: اول کرنل شروع میکنه ببینه ادرس فایلی که دادین درسته بعد هم چک میکنه ببینه که آیا شما مجازین که این کار رو انجام بدین یا نه
۴-تخصیص فایل: در نهایت اگه مراحل قبل موفق باشه، کرنل یه file handler یا file descriptor به این فایل تخصیص میده
۵- بررسی قفل فایل: کرنل اینجا چک میکنه ببینه کسی قبل از شما این فایل رو قفل کرده یا نه و اگه کسی نباشه به این فایل یک lock در نظر میگیره و فایل رو باز میکنه
۶-بازگشت توصیفگر فایل: بعد از باز کردن فایل، کرنل file descriptor رو بعد از اینکه CPU به حالت یوزر برگشت به شما برمیگردونه و شما باقی کارها رو با اون file descriptor انجام میدین

خب این مسیر کلی بود که پروسس شما برای باز کردن یه فایل ساده انجام میداد، الان میخوام بگم کدوم مراحل ممکنه پروسس شمارو بلاک کنه و بیشتر از طبق معمول طول بکشه، تغییر حالت CPU از کرنل به یوزر یه کار هزینه بره ولی من چون توی همه‌ی سیستم کال ها اینکارو انجام میدیم دیگه درنظرش نمیگیرم، حالا توی مرحله ی ۳ اگه ادرسی که دادین روی یه هارد مکانیکی باشه یا روی دیسکتون بار خوندن و نوشتن بالایی وجود داشته باشه میتونه اینکار بلاک بشه، توی مرحله ی ۳ چک کردن دسترسی ها نیازی به کار خاصی نداره و سریع انجام میشه، توی مرحله ی ۴ هم کارا سریع انجام میشن ولی اگه کرنل به حد مجاز توصیفگرهای فایل(file descriptor)هایی که باز هستن نزدیک بشه و نیاز به مدیریت و تخصیص مجدد ریسورس داشته باشه ممکنه بیشتر از حد معمول طول بکشه
توی مرحله ی ۵ هم پتانسیل بلاک شدن وجود داره چون اگر پروسس دیگه ای فایل رو قفل کرده باشه، کرنل باید منتظر آزاد شدن قفل باشه که طبیعتا منتظر موندن کرنل یعنی بلاک شدن پروسس ما.
توی مرحله‌ی اخر تنها کاری که مجبوری انجام بدیم و بازگشت به حالت کاربر هست و تمام

جمع بندی:
هر کاری که نیاز به I/O داشته باشه به احتمال خیلی زیاد پروسس شمارو بلاک میکنه و باید منتظر تموم شدن کاری که درخواست کردیم باشیم، چرا گفتم به احتمال خیلی زیاد؟! چون توی حالت عادی که باری روی سیستم نیست تمامی باس های داده خالیه و همه میتونن راحت رفت و آمد کنن، ولی وقتی بار سیستم میره بالا و باس های داده مثل اتوبان کرج-تهران میشه و دیگه همه چی مثل قبل نیست، باید برای باز کردن فایل که یه کار ساده محسوب میشه صبر کنیم و پروسسمون رو بلاک کنیم، و این اصلا برای سیستسم خوب نیست. دقت کنید که ما حاضریم هزینه ی انجام دادن تسک رو بدیم ولی نباید ریسورس سیستم رو برای کاری مثل منتظر موندن برای خلوت شدن باس داده یا در دسترس بودن lock انجام بدیم، اینکاره که سیستم رو کند میکنه، مگر نه من اگه بخوام یه فایل یه میلیون سطری رو بخونم هیچ چاره ای ندارم جز اینکه خط به خط این فایل رو بخونم و هزینه ی این تسک رو باید بدم چون هیچ راه فراری وجود نداره غیر از اینکه خط به خط فایل خونده بشه، ولی میتونم یه مکانیزم استفاده کنم که سیستم رو منتظر باز شدن قفل فایل، ازاد شدن باس داده و هرچیز دیگه ای نکنم! اسم این مکانیزم Nonblocking I/O هست که توی پست بعدی صحبت میکنم در موردش.

@knowpow

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

خیلی خوشحال میشم کانالم رو به کسایی که فکر میکنید براشون مفیده معرفی کنید

من یه مهندس نرم افزار هستم که بیشتر سمت بهبود پرفورمنس سیستم ها بوده و تا امروز بخش موبایل و کرنل موبایل بودم و الان هم در مورد سیستم های توزیع شده، کرنل لینوکس و نتورکینگ میخونم و اینجا در موردشون مینویسم.

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


@knowpow