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

در زبان Go می‌توان برنامه را به‌گونه‌ای کامپایل کرد که بتوان از داخل کدهای C یا C++‎، توابع Go را فراخوانی کرد. برای این کار، کد Go را با گزینه‌ی ‎-buildmode=c-shared کامپایل می‌کنیم تا یک کتابخانه‌ی اشتراکی (مثل ‎.so یا ‎.dll) تولید شود و سپس آن را در کد C/C++‎ فراخوانی می‌کنیم. داخل envoy از این قابلیت استفاده کردند تا بتوانیم یک filter به زبان Go پیاده‌سازی کنیم.

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

بعضی‌ها مشکل کد نوشتن با AI را این‌طور می‌بینند که دیگه هیچ‌چیز دقیق، عمیق و درست نیست. من واقعاً مشکل رو اینجا نمی‌بینم؛ در واقع، این رو مشکل جدیدی نمی‌بینم.

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

از نظر من، مشکلی که الان شیوع پیدا کرده، تولید کدهاییه که مسئولش از مکانیسمش سر در نمیاره. کدی که «عظیمه، مثل فیل. پر سر و صداست. هیاهوه. دیوانه است. پر هرج‌ومرجه اما مدفوعه». یک فایل ۵۰۰ خطی که یک فیچرو پیاده کرده —که اتفاقاً درست هم کار می‌کنه— ولی کمتر کسی توان و حوصلهٔ این رو داره بشینه و کار شخص دیگه‌ای رو بخونه تا عمیقاً بفهمه؛ به‌خصوص که نرخ تولید PRهایی با تعداد تغییرات بالا به لطف AIها، در حال بیشتر و بیشتر شدنه. مشکلی که قبلا هم در سطح خرد با ظهور امثال استک‌اوورفلو بیشتر جون گرفت و الان رشد کرده و دست و پا در آورده.

آقای کامران وفا به همراه سه نفر دیگه به عنوان
University Professor
در دانشگاه هاروارد انتخاب شدند.
این عنوان بالاترین عنوان برای اعضای هیات علمی در هاروارد هست، که نشون دهنده شایستگی بالای این افراد، اعتبار علمی شون و تاثیرگذاری شون هست.
سه نفر دیگه در زمینه زیست شناسی، حقوق و اقتصاد کار می کنند.
https://www.harvardmagazine.com/university-news/harvard-university-professors-appointed-distinguished-faculty

کتاب معروف ایشون با عنوان
Puzzles to Unravel the Universe
که در مورد مسائل معروف در ریاضی و فیزیک هست و پیش زمینه خاصی هم نمی خواد درک مسائلش.
عجیبه که این کتاب تا الان ترجمه نشده.
همه چیزهایی که کسی دوست داره به طور عمومی در مورد فیزیک بدونه و دانشش رو نداشته یا وقتش رو یا...اینجا اومده. حتی در مورد دیدگاه مذهبی یه سری فیزیک دان معروف مثل انیشتین و هاوکینگ و... صحبت کرده.
کتاب رو تقدیم کرده به همسر، فرزندان و پدر و مادرش.

یکی از دوستان گفتند ظاهرا ترجمه شده.

___________________________

مثل غذایی که هوسش رو کنی ولی اون موقع نخوریش، مثل کبابی که سرد شده، اگر یک مشکل رو سر وقتش حل نکنی دیگه حل شدنش نمیچسبه.

امروز بعد از روز‌ها آزمون و خطا، انگولک کردن پارامترهای هر دو طرف، سورس و داکیومنت رو بررسی کردن و کلی نظریه‌پردازی، مشکل integration بین celery و SQS رو حل کردیم. هدف چی بود؟ خیلی ساده اما اساسی: تسک‌هایی که failed میشند بعد از retry کردن به تعداد لازم و failed شدن، می‌رفتند توی DLQ. کار بدیهی که اما انجام نمی‌شد.

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

سعی کردم دوبار یه پروژه‌ی کوچیک بیارم بالا برای تست SQS و سلری. اول خیال کردیم که این ستاپ داره درست کار می‌کنه، پس مشکل از سرویس ما بود. وقتی با هزار جنگولک‌بازی تونستم کاری کنم که پیام بعد از به اکسپشن خوردن بره توی DLQ، میدیدم پیام‌هایی که فیلد نشدند هم به DLQ روانه میشند. انگار سلری همیشه داشت ACK میداد به SQS. پس چرا کانفیگ‌های یک‌سان دارند نتیجه‌ی متفاوت میدند؟!

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

شروع کردیم به دیباگ کردن سلری و خوندن سورسش. گشتیم و break point ها زیر و روی هم تلنبار شدند. تا این که لای این نقطه‌های قرمز چشممون به جمال نامبارک یک شرط روشن شد:

if task.acks_on_timeout_or_failure

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

در نهایت یک آرگومان به تسک‌ها دادیم و تمام. همه‌چیز درست کار می‌کرد. بجز این، در این حین فهمیدیم که این هم مهمه که مقدار visibility timeout چی ست بشن. گاهی تا سلری یک پیام رو ACK کنه به خاطر لانگ رانینگ بودن تسک یا هرچیزی، اینقدر طولانی میشد که اگر visibility timeout رو کم می‌ذاشتیم، دوباره یکی از وورکر‌ها برش میداشت و بنا به تعداد ریترای‌هایی که روی SQS تعریف شده، خودش قبل از تکمیل پردازشش می‌رفت توی DLQ چون هیچ‌کدوم از وورکر‌ها acknowledgeش نکردن.

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

داشتم فکر می‌کردم که چرا به آشپزی میگن هنر؟ آشپزی در معنای عام و از نظر کاری که عموماً می‌کنیم بیشتر دقت و مهارت رعایت دستور‌العمل و مهندسیه. دیگه برنج و تن ماهی و زیتون رو شما بزک کنی، اسمش هر هنری هست، هنر آشپزی (!) نیست.

پی‌نوشت: اگر غلط تو جمله‌ها هست یا گنگه ببخشید. با چشم نیمه‌باز داشتم تایپ ‌می‌کردم.
#روزمره

موسیقی متن بازی شاهکار Ghost of Tsushima

Ghost of Tsushima - Way of the Ghost

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

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

پایان رضا شاه؛ آناتومی یک سقوط

ای خنک چشمی که آن گریانِ اوست
وی همایون دل که آن بریان اوست

آخر هر گریه آخِر خنده‌ایست
مردِ آخر بین، مبارک بنده‌ایست

مولانا

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

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

تا ۶.۵-۷ معمولا اونجا میمونم. موقع برگشت هم دیگه هوا کامل تاریک شده. اگر هفت بزنم بیرون حتی کمتر دانشجو اون اطراف می‌بینم. هربار برنامه‌ی برگشت همینه: از این دستگاه تف‌کن ساختمون یه شیرکاکائو XL گرم میگیرم، زیپ بادگیر رو میدم بالا و آروم از اونجا تا مترو قدم میزنم.

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

#روزمره

مایکروسافت توی نسخه‌ی جدید ویندوز ۱۱، امکان فعال‌سازی ویندوز با روش معروف به KMS38 رو‌غیرفعال کرده. روشی که اغلب فعال‌سازهای مرسوم از اون استفاده میکردند.

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

KMS38 DEPRECATION AND REMOVAL

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

مرا عشقت ز جان آذر برآره
زپیکر مشت خاکستر برآره

نهال مهرت از دل گر ببرند
هزاران شاخه دیگر برآره

باباطاهر

/Spotify

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

The mystic, the cricketer and the spy: Pakistan’s game of thrones

از توییت کاتخون.

آقا این داستان outage دیروز کلودفلر خیلی چیز جالبیه. خودشون تو این پست درباره اینکه چه اتفاقی افتاده توضیحات مبسوط دادن ولی اینکه تهش میفهمی تمام اتفاقات بخاطر یه errorی بوده که به درستی هندل نشده جالبه. اگر حوصله خوندن هم ندارید من یه توضیح ریز بدم که اینا یه ماژول bot management دارن که یه اسکوری به درخواست‌ها میده که آیا درخواست از طرف باته یا نه. بعد این ماژول، که یه مدل MLی هست، یه فیچر فایلی رو لود میکنه و این فیچر فایل هم براساس یه کوئری رو کلاستر کلیک هاوسشون هر چند دقیقه جنریت میشه و تو نتورکشون propagate میشه. حالا اینا یه سری تغییرات میدن رو permission system کلیک هاوس و سایز این فیچر فایل‌ها افزایش پیدا میکنه و این ماژول یه لیمیتی رو سایز فیچر فایل داشته. بعد این خطا میخورده و هندل نمیشده و باعث پنیک کردن میشده.

Determining why CPUs are busy is a routine task for performance analysis, which often involves profiling stack traces. Profiling by sampling at a fixed rate is a coarse but effective way to see which code-paths are hot (busy on-CPU). It usually works by creating a timed interrupt that collects the current program counter, function address, or entire stack back trace, and translates these to something human readable when printing a summary report.

Profiling data can be thousands of lines long, and difficult to comprehend. Flame graphs are a visualization for sampled stack traces, which allows hot code-paths to be identified quickly.

USENIX ATC '17: Visualizing Performance with Flame Graphs

این روزا راه به راه حرف از Brendan Gregg (نویسنده‌ی کتاب معروف و بسیار خوب Systems Performace) میاد وسط و این واسم جالبه. البته این که این روزا که جسته و گریخته Systems Performance رو می‌خونم هم بی‌تاثیر نیست. چون اونی که حرف رو میاره وسط اکثرا خودمم 😁 دلیلش هم اینه که هر خطی که میخونم ازش کلی چیز جدید هست که یاد بگیرم و کلی کنکجاوی جدید واسم به‌وجود میاره. امشب که با حسین داشتیم گپ می‌زدیم، صحبت از Cilium شد و بعد هم رسید به eBPF و آخر رسید به این مستند. که واسم جالب بود.

eBPF: Unlocking the Kernel [OFFICIAL DOCUMENTARY]

The main part of the ETH Student Summer Research Fellowship programme at ETH Zurich is devoted to doing research in one of the available

Time frame: 1 July – 31 August approx.
Please note that the time and duration of the fellowship is fixed to cover the full two months of July and August.

Bachelor’s and Master’s students worldwide with an expected graduation date earliest during the spring semester the year after the 2-month fellowship.

Research Areas in Computer Science

Data Management & Machine Learningchevron

Information & System Securitychevron

Computer Systemschevron

Intelligent Interactive Systems & Physical Computingchevron

Programming Languages & Software Engineeringchevron

Theory & Algorithmschevron

Visual Computingchevron

ددلاینش هم ۱۶ دسامبره.

https://inf.ethz.ch/studies/summer-research-fellowship.html

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

وقتی پای صحبت کسایی که توی این نظام مشغولن میشینید (بجز افراد حاضر در برنامه‌ی پرگار) می‌بینید ماجرا خیلی پیچیده‌تر و پر ایرادتر از اون چیزیه که متصوریم.

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

پرگار: نظام درمانی در اروپا و آمریکا

دیروز خبر اومد که آهنگ‌های اسپاتیفای و متادیتاشون رو بار خاور زدن و بردن. چیزی حدود ۳۰۰ ترابایت دیتا که بر اساس محبوبیت به صورت تورنت توزیع شدن. بزرگترین مجموعه‌ی عمومی از متادیتای آهنگ‌ها در اینترنت با حدود ۲۵۶ میلیون آهنگ و ۱۸۶ میلیون قطعه‌ی یکتا بر اساس کد IRSC (یک کد استاندارد یکتا برای ثبت موزیک و موزیک ویدیو). کی این کار رو کرده؟ احتمالا آخرین‌جایی که به ذهنتون خطور می‌کنه: annas-archive


این آمار‌هایی که خودشون گذاشتن:‌

Spotify has around 256 million tracks. This collection contains metadata for an estimated 99.9% of tracks.
We archived around 86 million music files, representing around 99.6% of listens. It’s a little under 300TB in total size.
We primarily used Spotify’s “popularity” metric to prioritize tracks. View the top 10,000 most popular songs in this HTML file (13.8MB gzipped).
For popularity>0, we got close to all tracks on the platform. The quality is the original OGG Vorbis at 160kbit/s. Metadata was added without reencoding the audio (and an archive of diff files is available to reconstruct the original files from Spotify, as well as a metadata file with original hashes and checksums).
For popularity=0, we got files representing about half the number of listens (either original or a copy with the same ISRC). The audio is reencoded to OGG Opus at 75kbit/s — sounding the same to most people, but noticeable to an expert.
The cutoff is 2025-07, anything released after that date may not be present (though in some cases it is).
This is by far the largest music metadata database that is publicly available. For comparison, we have 256 million tracks, while others have 50-150 million. Our data is well-annotated: MusicBrainz has 5 million unique ISRCs, while our database has 186 million.
This is the world’s first “preservation archive” for music which is fully open (meaning it can easily be mirrored by anyone with enough disk space).

یک پست رو بلاگشون منتشر کردن که راجع‌به این ماجرا توضیح میده و هم چند تا آمار جالب منتشر کردم از این دیتا. این هم Spotify wrapped واقعی که annas-archive برای خود اسپاتیفای آماده کرد :)

Backing up Spotify

یک ترد توی هکر نیوز هم برای این خبر باز شده و کلی بحث و نظر توش داره رد و بدل میشه. خلاصه‌ش و موضوعات اصلی مورد بحث رو اینجا توی جمنیا می‌تونین بخونین:
‌
Spotify Backup Discussion Summary

توی همین ترد هم راجع‌به ابعاد فنی این ماجرا صبحت شده که مستقیم میارم:

Cracked DRM at Scale: Spotify's DRM had been cracked to allow downloading at this scale. While individual "Spotify rippers" (like zspotify or librespot) have existed for years, they usually work slowly. This project managed to parallelize the process to download 86 million tracks.

Audio Quality Clues: The downloaded files are 160kbps OGG Vorbis (for popular tracks) and 75kbps OGG Opus (for unpopular tracks).
bitrate matches Spotify’s Free Tier or standard web-player quality. It confirms they likely automated millions of free accounts rather than paying for Premium (which offers 320kbps).

Technique: This implies they likely used a leaked Widevine L3 CDM (Content Decryption Module). L3 is the lowest security level of Widevine DRM, often running in software on browsers/Android devices, and is frequently exploited to decrypt streams on generic hardware.