مثل اینکه Bun قراره کم‌کم با Rust ری‌رایت بشه، ولی هنوز این‌جوری نیست که رسماً و یک‌باره بگن «Zig رفت، Rust اومد». چیزی که فعلاً توی ریپوی گیت‌هابش دیده می‌شه، یه راهنمای مرحله‌ایه برای پورت کردن فایل‌های Zig به Rust. توی Phase A قراره برای هر فایل Zig، یه فایل Rust کنار همون فایل ساخته بشه و منطقش تا جای ممکن همون‌جوری منتقل بشه؛ حتی لازم نیست همون اول کامپایل هم بشه. بعداً توی Phase B میان این کدها رو crate به crate درست و قابل کامپایل می‌کنن.

نکته جالبش اینه که Bun نمی‌خواد تبدیل بشه به یه پروژه Rust معمولی. توی داکیومنتش صریح گفته از چیزهایی مثل tokio، hyper، futures، async fn و حتی std::fs و std::net استفاده نکنید. یعنی می‌خوان event loop، مدل async، syscallها و معماری خود Bun حفظ بشه. پس ماجرا بیشتر شبیه یه مهاجرت کنترل‌شده‌ست برای اینکه پروژه پایدارتر، امن‌تر، قابل نگهداری‌تر و برای contributorها قابل‌دسترس‌تر بشه؛ نه اینکه صرفاً چون Rust ترند شده یا سریع‌تره، Zig رو بذارن کنار.

https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd5730ef1549e88407701a5

@codehalics | کدهالیک

این پترن‌ها رو همیشه سعی کنید ببینید و یاد بگیرید؛ اینکه یه پروژه بزرگ چطوری تصمیم می‌گیره از یه زبان بره سمت یه زبان دیگه، چطوری مسیرش رو فازبندی می‌کنه، چی رو نگه می‌داره و چی رو عوض می‌کنه، خودش یه کلاس درس کامل از مهندسی نرم‌افزار و مدیریت تغییره.

@codehalics | کدهالیک

یکی اومده باگ Copy Fail رو که روی بعضی لینوکس‌های جدیدتر می‌تونه باعث گرفتن دسترسی root بشه، داخل کانتینر تست کرده؛ چیزی شبیه کانتینرهای Docker یا Podman.

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

توضیحات این اکسپلویت رو توی لینک پایین نوشته :

https://www.dragonsreach.it/2026/05/04/cve-2026-31431-copy-fail-rootless-containers/

@codehalics | کدهالیک

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

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

https://muddy.jprs.me/posts/2026-05-03-the-best-is-over/

@codehalics | کدهالیک

داکر یه آپدیت خیلی باحال این هفته داده

داکر از نسخه ۲۹ به بعد برای نصب‌های جدید، به‌صورت پیش‌فرض از containerd image store استفاده می‌کنه. فرقش با روش قدیمی مثل overlay2 اینه که به‌جای storage driverهای کلاسیک، از snapshotterها استفاده می‌کنه. نتیجه‌اش اینه که داکر بهتر می‌تونه ایمیج‌های چندپلتفرمی رو لوکال بسازه و نگه دارد، با SBOM و provenance کار کند، کانتینرهای Wasm را اجرا کند و حتی از snapshotterهای پیشرفته برای lazy pulling یا توزیع peer-to-peer استفاده کند. برای بیشتر کاربرها این تغییر خیلی محسوس نیست و فلوهای معمول داکر تقریباً همون قبلیس.

اما یک نکته مهم : containerd image store معمولاً فضای بیشتری از دیسک می‌گیرن، چون لایه‌های ایمیج را هم به‌صورت compressed نگه می‌دارد و هم extract شده. اگر از نسخه‌های قبلی داکر آپدیت کرده باشین ، خودکار به این مدل نمیرین و باید دستی در daemon.json فعالش کنین. نکته مهم‌تر اینکه با عوض کردن storage backend، ایمیج‌ها و کانتینرهای قبلی پاک نمیشن ولی موقتاً مخفی میشن و اگر برگردید به overlay2 دوباره دیده میشن. پس قبل از مهاجرت، مخصوصاً روی محیط‌های حساس، بهتر عه ایمیج‌های مهم را push یا export کنین.

https://docs.docker.com/engine/storage/containerd

@codehalics | کدهالیک

آپاچی یه آپدیت امنیتی مهم برای وب‌سرور خودش منتشر کرده؛ نسخه 2.4.67 که از ۴ می ۲۰۲۶ در دسترس قرار گرفته. این آپدیت برای رفع چند آسیب‌پذیری امنیتی اومده و مهم‌ترینش مربوط به ماژول HTTP/2 هست؛ همون بخشی که اگر روی سرور فعال باشه، ممکنه در نسخه قبلی یعنی 2.4.66 باعث کرش کردن سرویس یا در شرایط خاص حتی اجرای کد از راه دور بشه. به زبان ساده‌تر، اگر کسی سروری با Apache نسخه آسیب‌پذیر داشته باشه و HTTP/2 هم فعال باشه، بهتره این آپدیت رو جدی بگیره.

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

https://x.com/i/trending/2051638152490848405

@codehalics | کدهالیک

نویسنده این مقاله میگه یه نرم‌افزار کوچیک به اسم Nonograph ساخته که رایگانه، متن‌بازه و همه می‌تونن ازش استفاده کنن. خودش حدود ۶۰۰ دلار خرج کرده تا منتشرش کنه، بیشترش هم برای بررسی‌های امنیتی بوده، ولی حالا بدون پول ازش استفاده می‌کنن.

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

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

پ.ن : البته منظورش ایران نیست اینجا ما با سیلی صورتمون سرخ نگه میداریم :) ولی پروژه های اوپن سورس خفن ایرانی کم نداریم مثل هیدیفای و ...


https://nonogra.ph/write-some-software-give-it-away-for-free-05-05-2026

@codehalics | کدهالیک

ادامه قوانین مهندسی نرم افزار !

یه مفهومی توی تیم‌های نرم‌افزاری هست به اسم Bus Factor. خیلی ساده یعنی چند نفر اگر از تیم حذف بشن، پروژه می‌خوابه؟ مثلا اگر فقط یک نفر بلد باشه سیستم پرداخت چطوری کار می‌کنه، فقط یک نفر دیتابیس رو بفهمه، یا فقط یک نفر بدونه دیپلوی چطوری انجام میشه، Bus Factor اون بخش میشه ۱. یعنی تیم عملا روی دانش یک نفر قفل شده و با نبودنش همه‌چیز کند، مبهم یا متوقف میشه.

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

#lawsofsoftwareengineering

@codehalics | کدهالیک

یه مثال خیلی خوب برای Bus Factor، خود لینوکسه.

از بیرون به‌نظر میاد پروژه خیلی به لینوس توروالدز وابسته‌ست، ولی سوال اینه: چطوری کاری کرد که Bus Factor پروژه عملاً ۱ نمونه؟

یکی از جواب‌های مهمش Git بود.

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

لپ کلام: لینوس فقط آدم مهم پروژه نبود؛ سیستمی ساخت که پروژه بدون قفل شدن روی یک آدم، زنده بمونه.

فک نکنم از این قشنگ تر میشد باس فکتور و هندل کردنش توی لینوکس رو توضیح داد دی:

#lawsofsoftwareengineering

@codehalics | کدهالیک

آنتروپیک با همکاری جدیدی با اسپیس‌ایکس، ظرفیت پردازشی خود را به‌طور جدی افزایش داده است.طبق این توافق، کلاد قرار است از تمام ظرفیت دیتاسنتر Colossus 1 استفاده کند؛ ظرفیتی که بیش از ۳۰۰ مگاوات توان اضافی (معادل بیش از ۲۲۰ هزار GPU انویدیا) در اختیارش قرار می‌دهد.این افزایش ظرفیت باعث شده محدودیت‌های استفاده از Claude Code و Claude API به شکل قابل توجهی بالا برود.از امروز:

محدودیت ۵ ساعته Claude Code برای پلن‌های Pro، Max و Team دو برابر شده است.

محدودیت ساعات شلوغ (peak hours) برای کاربران Pro و Max حذف شده.

نرخ محدودیت API برای مدل‌های Opus نیز به‌طور قابل توجهی افزایش یافته.

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


@codehalics | کدهالیک

بچه ها من قراره تو این Organization گیتهاب راجع به کوبرنتیز اون چیزایی که بلدم رو بنویسم ممنون میشم هم کمک کنین دیده شه وهم باهم کانتریبیوت هم داشته باشیم عالی میشه

https://github.com/K8S-Academy/Pods

@codehalics | کدهالیک

سایمون ویلیسون، یکی از معروف‌ترین آدم‌های حوزه AI و برنامه‌نویسی، میگه مرز بین «vibe coding» و برنامه‌نویسی حرفه‌ای با کمک هوش مصنوعی داره کم‌کم از بین میره. قبلاً vibe coding یعنی فقط به AI بگی یه چیزی بسازه بدون اینکه حتی کدهاشو نگاه کنی؛ بیشتر برای پروژه‌های شخصی و فان. ولی الان ابزارهایی مثل Claude Code اون‌قدر خوب شدن که حتی برنامه‌نویس‌های حرفه‌ای هم دارن بدون چک کردن تک‌تک خط‌ها از خروجی AI توی پروژه‌های واقعی استفاده می‌کنن.

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

https://simonwillison.net/2026/May/6/vibe-coding-and-agentic-engineering/

@codehalics | کدهالیک

یکم از مزایای ایرانی بودن بگم براتون که امروز مجبور شدم برای بیلد پروژم ۳۵۰ ت بدم رانفلر اجازه بده از میرورهاش استفاده کنم و قسمت جالب ماجرا اینه که کلا برای سه تا پروژه که بیلد گرفتم و صرفا سیگنیچر پکیج رو چک کرده چون از قبل نود ماژولش رو داشتم ۱۰۰۰ تا از کوت هام مصرف شده و ۲۰۰۰ تا دیگ مونده یعنی خوش بینانه دو بار دیگ میتونم بیلد بگیرم :))))))))

خلاصه این چیزا توی خارج قفله ولی ما داریم تو ایران خیلی جذاب و خنده دار باهاش برخورد میکنیم

اینترنت اصلا میخوایم چیکار بنظرم بزارید بیشتر از این قطع بشه اینطور درآمد زایی هم برای مملکتمون میاره :)))))))
@codehalics | کدهالیک

داخل "کار باشه" (گروهمون )

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

خوبیه کار باشه اینه که دسته بندی داره یعنی شما بر اساس توانایی شغلی که دارید مثلا پروداکت دیزاینر وارد تاپیک میشید و تمامی مشاغل شغلی ها رو از بالا به پایین میخونید و اپلای میکنید

اگر مایل بودید حتما جوین بشید به گروهمون

@job_bashe

بریم ادامه قوانین مهندسی نرم افزار

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

البته این قانون همیشه هم معجزه نمی‌کنه. فقط اوپن‌سورس بودن کافی نیست؛ باید آدم‌هایی واقعاً در حال بررسی و مشارکت باشن. مثلاً باگ معروف Heartbleed توی OpenSSL دو سال مخفی مونده بود، با اینکه پروژه کاملاً متن‌باز بود. یعنی «چشم زیاد» وقتی مفیده که واقعاً کسی داره نگاه می‌کنه. به همین خاطر این قانون بیشتر از اینکه یه حقیقت مطلق باشه، یه یادآوریه که همکاری، شفافیت و کد ریویو جمعی معمولاً کیفیت نرم‌افزار رو بهتر می‌کنه.

#lawsofsoftwareengineering

@codehalics | کدهالیک

FYI : For Your Information

باگ معروف Heartbleed یه حفره امنیتی خیلی خطرناک توی کتابخونه‌ی OpenSSL بود که سال ۲۰۱۴ کشف شد. OpenSSL همون چیزیه که خیلی از سایت‌ها برای رمزنگاری و HTTPS ازش استفاده می‌کنن. مشکل از یه قابلیت به اسم “Heartbeat” اومده بود؛ هکر می‌تونست به سرور یه درخواست تقلبی بفرسته و سرور بدون بررسی درست، بخشی از حافظه‌ی خودش رو پس بده. تو اون حافظه ممکن بود اطلاعات خیلی حساس مثل پسورد، کوکی لاگین، پیام‌ها یا حتی کلید خصوصی SSL وجود داشته باشه.

چیزی که Heartbleed رو ترسناک‌تر کرد این بود که این باگ حدود دو سال توی یه پروژه‌ی اوپن‌سورس بسیار معروف وجود داشت و کسی متوجهش نشده بود. این دقیقاً شد ضد مثال معروف برای Linus’s Law؛ یعنی صرف اینکه کد جلوی چشم همه باشه کافی نیست، باید آدم‌های متخصص واقعاً کد رو بررسی کنن. بعد از افشای باگ، کلی سایت بزرگ مجبور شدن سریع OpenSSL رو آپدیت کنن، سرتیفیکیت‌هاشون رو عوض کنن و از کاربرها بخوان پسوردهاشون رو تغییر بدن.

@codehalics | کدهالیک

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

@codehalics | کدهالیک

یه مفهوم من درآوردی دیگ هم داریم به اسم Rubber Duck Debugging

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

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

فرقش با Linus’s Law اینه که اون میگه «چشم‌های بیشتر = احتمال بیشتر برای پیدا شدن باگ»، ولی Rubber Duck Debugging میگه «شفاف توضیح دادن مسئله = احتمال بیشتر برای فهمیدن باگ».
هردوشون روی این ایده سوارن که باگ وقتی از حالت مبهم توی ذهنت خارج بشه، پیدا کردنش راحت‌تر میشه.

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

@codehalics | کدهالیک

فک کنم فقط منم که از مرگ آدمای بی گناه ناراحت میشم :) نه؟

@codehalics | کدهالیک

کلودفلر امروز یه مقاله ای رو منتشر کرد راجب به اینکه چطوری بعد از اون باگ خطرناک CopyFail
یعنی همونی که لینوکس های ۲۰۱۷ به بعد رو دسترسی روت میشد روشون گرفت رو روی همه سروراش پچ کرده اونا تو مقاله ای که امروز ریلیز کردن گفتن :

وقتی آسیب‌پذیری Copy Fail منتشر شد، تیم‌های امنیت و مهندسی Cloudflare تقریباً همزمان وارد عمل شدن. اول از همه بررسی کردن که کدوم نسخه‌های کرنل داخل زیرساختشون آسیب‌پذیره و چقدر از سرورها درگیرن. همزمان تیم امنیت exploit رو تحلیل کرد تا بفهمه حمله دقیقاً چه رفتاری روی سیستم ایجاد می‌کنه. نکته جالب این بود که سیستم تشخیص رفتار مشکوک Cloudflare بدون هیچ آپدیت یا rule جدیدی، همون موقع exploit رو شناسایی کرد و alert داد. یعنی ابزارشون فقط دنبال «اسم باگ» نبود؛ رفتار غیرعادی مثل تلاش برای privilege escalation رو تشخیص می‌داد. بعد از اون، تیم امنیت شروع کرد کل لاگ‌ها و فعالیت سرورها رو برای ۴۸ ساعت گذشته بررسی کردن تا مطمئن بشن قبل از عمومی شدن باگ کسی ازش سوءاستفاده نکرده. حتی hash فایل‌های سیستمی و ارتباطات شبکه رو هم چک کردن تا اثری از دستکاری یا persistence وجود نداشته باشه.

از اون طرف تیم کرنل باید سریع جلوی exploit رو می‌گرفت، ولی مشکل این بود که patch کامل نیاز به آپدیت و reboot تعداد خیلی زیادی سرور داشت و این کار زمان‌بره. برای همین اول یک mitigation موقت ساختن. اونا با استفاده از eBPF و bpf-lsm اومدن دسترسی به بخش آسیب‌پذیر کرنل رو فقط برای برنامه‌هایی که واقعاً لازم داشتن باز گذاشتن و بقیه درخواست‌ها رو بلاک کردن. قبل از فعال کردن این محدودیت هم کل زیرساخت رو مانیتور کردن تا مطمئن شن سرویس مهمی ناخواسته قطع نمیشه. بعد از آماده شدن patch رسمی لینوکس، کرنل جدید رو اول داخل دیتاسنترهای staging تست کردن و بعد کم‌کم با سیستم rollout خودشون روی کل شبکه deploy کردن. نتیجه نهایی این بود که بدون downtime جدی و بدون آسیب به مشتری‌ها، کل زیرساخت یا patch شد یا زیر mitigation امن قرار گرفت.

https://blog.cloudflare.com/copy-fail-linux-vulnerability-mitigation/

@codehalics | کدهالیک