کدهالیک | codehalic

ران‌تایم معروف جاوااسکریپت یعنی بان ، ظاهراً وارد یک فاز خیلی جدی شده: Jarred Sumner، سازنده اصلی Bun، گفته نسخه بازنویسی‌شده‌ی Bun با Rust الان روی Linux x64 glibc حدود ۹۹.۸٪ تست‌های قبلی پروژه رو پاس می‌کنه. نکته عجیب‌تر اینه که خودش می‌گه این بازنویسی حدود ۹۶۰ هزار خط کد بوده و از حدود ۶ روز قبل شروع شده؛ یعنی این‌طور نبوده که فقط یه ایده آزمایشی باشه، بلکه کد واقعاً کار می‌کنه و تست‌ها رو رد می‌کنه. دلیل اصلی این حرکت هم ظاهراً دردسرهای همیشگی memory leak، کرش و مشکلات پایداری بوده. Jarred می‌گه با Rust، کامپایلر می‌تونه خیلی از مشکلات مربوط به طول‌عمر آبجکت‌ها و مدیریت حافظه رو زودتر بگیره، destructorها بهتر کنترل می‌شن، و بخش‌های خطرناک کد هم با unsafe واضح‌تر دیده می‌شن؛ همین باعث می‌شه تیم راحت‌تر سراغ تمیزکاری و ریفکتور بره. قرار هم هست یه بلاگ‌پست مفصل منتشر کنن درباره اینکه این تغییر برای آینده Bun، بنچمارک‌ها، مصرف حافظه و نگهداری پروژه چه معنایی داره. @codehalics | کدهالیک

ابزار اوپن سورسی ساختم که به Claude Code و بقیه ایجنت‌های لوکال اجازه می‌ده صفحه رو ببینن و با موس، کیبورد و کروم کار کنن. نکته باحالش اینه که وقتی AI داره با سیستم کار می‌کنه، تو هم دقیقاً می‌بینی چی می‌بینه و چیکار می‌کنه؛ هرجا هم حس کردی اوضاع عجیب شد، سریع می‌تونی جلوشو بگیری. خیلی بدرد دیزاین های پیکسل پرفکت میخوره فیگما رو بهش نشون بدی یا یه سایت بهش نشون بدی عینشو با تمام فانکشنالیتیش بزنه ! https://github.com/MehdiEskandari/claude-eye @codehalics | کدهالیک

کدهالیک از امروز روی برنامک های ویجیتیفای اضافه شده و میتونید مستقیما دوره های برنامه نویسی خیلی راحت تر بدون ثبت نام پیچیده ببینید ! ویجیتفای یک اکستشن نیوتب برای مرورگر هاست ( مشابه دستیار ) تفاوتش در اینه که اولا اوپن سورسه و دوما دیتایی از شما و سرچ هاتون و فعالیت هاتون به هیچ وجه ذخیره نمیکنه برای همین بسیار بسیار سیف تر از دستیار عه و تازه از همه مهم تر هم فیچر های بیشتری داره و هم اینکه کاملا رایگانه ! تازه رو نت ملی هم میتونید نصبش کنید و اضافش کنید به اکستشن هاتون نحوه نصبشم اینجا آموزش داده https://widgetify.ir/install پ.ن : این اصلا تبلیغ نیست صرفا معرفی یه پروژه اوپن سورسه و خیلی خفنه حتما نصبش کنید ! @codehalics | کدهالیک

اینو هم توی قوانین و مقرراتش نوشته این توصیه هم بهتون بکنم یه روزی از هر سرویسی خواستین استفاده کنین این صفحه رو بخونین که بعدا براتون مشکل لگال پیش نیاد بعضا شروطی توش مینویسن که شما بخاطر اینکه حوصله ندارید نمیخونید ولی دقیقا جایی که میخواید از حقتون دفاع کنین نمیتونید چون تایید دادید قوانین و مقرراتتو خوندیم و تایید دادیم ! @codehalics | کدهالیک

شکن در صورتی که ازش استفاده ناجور کنین اکانتتون رو بن میکنه و به مراجع امنیتی ذی صلاح اطلاع میده صرفا نوشتم که در جریان باشید ازش استفاده نکنید حتی المقدور براتون مشکلی ایجاد نشه یه وقت @codehalics | کدهالیک

بچه‌ها گفتم شاید به درد شما هم بخوره: این اپ رو از گیت‌هاب دانلود کنین، میتونین لینک ویدئوهای یوتیوب رو از گوگل(یا هرجا) بهش بدین تا واستون با نت ملی دانلود کنه. #اینترنت_آزاد_حق_همه_مردم https://github.com/Kurdeus/Meli-Action Mahdi Karbakhsh Ravari @codehalics | کدهالیک

این مقاله ای که امروز خوندم و خلاصشو میخوام بهتون بگم راجب یه مدل تفکر الگوریتمی خیلی باحال صحبت میکنه که بهش میگیم Collisions یا برخورد ها مثلا فرض کنین قراره یه آیدی برای هر کس جنریت کنیم احتمال برخورد ( تکراری شدنش ) چطوری محاسبه میشه ! از همین تفکر الگوریتمی توی اتک به یه سرور یا ریسورس استفاده میشه ! بعد میاد همین رو توی یه مثال خیلی باحال تو مقاله میگه که خلاصش اینه : می‌گه ما معمولاً احتمال برخوردها رو کمتر از چیزی که واقعاً هست حس می‌کنیم. مثلاً فکر می‌کنیم برای اینکه دو نفر تولد یکسان داشته باشن باید جمع خیلی بزرگی باشه، ولی فقط با ۲۳ نفر احتمال این اتفاق حدود ۵۰٪ می‌شه. دلیلش اینه که ما فقط به یک جفت خاص فکر نمی‌کنیم؛ بین ۲۳ نفر کلی جفت مختلف وجود داره که هرکدوم می‌تونن تولد مشترک داشته باشن، پس شانس کلی خیلی زود بالا می‌ره. بعد متن همین ایده رو به هش‌ها وصل می‌کنه. توی هش‌کردن، مثل اینه که آدم‌ها رو بندازیم داخل روزهای تقویم؛ فقط اینجا آدم‌ها می‌شن ورودی و روزها می‌شن خروجی ممکن هش. اگر تعداد ورودی‌ها زیاد بشه، بالاخره دو ورودی مختلف ممکنه یک خروجی هش یکسان بدن؛ به این می‌گن collision یا برخورد. Birthday Attack هم از همین استفاده می‌کنه: مهاجم دنبال یک خروجی خاص نیست، فقط می‌خواد هر دو ورودی‌ای پیدا کنه که هش یکسان بدن، برای همین این حمله خیلی زودتر از چیزی که در نگاه اول فکر می‌کنیم ممکن می‌شه. https://0xkrt26.github.io/math_behind_security/2026/05/08/birthday-problem.html @codehalics | کدهالیک

⁨FYI⁩: ⁨For Your Information⁩ اگه بخوایم خیلی خودمونی بگیم، ⁨HTTP⁩ هم مثل خیلی چیزهای وب نسل به نسل بهتر شده. اولش ⁨HTTP/0.9⁩ بود. خیلی ساده و خام. فقط می‌گفت یه صفحه رو بده، سرور هم همون صفحه رو برمی‌گردوند. نه ⁨header⁩ درست‌وحسابی داشت، نه ⁨status code⁩، نه چیز خاصی. بعد ⁨HTTP/1.0⁩ اومد و وب یکم جدی‌تر شد. چیزهایی مثل ⁨header⁩، کدهای وضعیت مثل ⁨404⁩ و ⁨200⁩، و پشتیبانی بهتر از انواع فایل‌ها اضافه شد. یعنی دیگه فقط صفحه ساده ⁨HTML⁩ نبود. بعد رسیدیم به ⁨HTTP/1.1⁩ که سال‌ها ستون فقرات وب بود. مهم‌ترین بهبودش این بود که لازم نبود برای هر درخواست یه اتصال جدید ساخته بشه. اتصال می‌تونست باز بمونه و چندتا درخواست از همون مسیر رد بشه. ولی هنوز مشکل داشت، چون درخواست‌ها تا حدی پشت هم گیر می‌کردن و برای سایت‌های سنگین امروزی ایده‌آل نبود. بعد ⁨HTTP/2⁩ اومد و گفت به جای اینکه درخواست‌ها یکی‌یکی تو صف بمونن، چندتا درخواست همزمان از یه اتصال رد بشن. به این میگن ⁨multiplexing⁩. همچنین ⁨header⁩ها هم فشرده‌تر شدن و کلی چیز برای سرعت بهتر اضافه شد. برای همین سایت‌ها با کلی فایل ⁨CSS⁩، ⁨JS⁩، عکس و فونت بهتر لود می‌شدن. بعدش ⁨HTTP/3⁩ اومد که تغییر اصلیش زیرساخت انتقاله. ⁨HTTP/1.1⁩ و ⁨HTTP/2⁩ معمولا روی ⁨TCP⁩ بودن، ولی ⁨HTTP/3⁩ روی ⁨QUIC⁩ کار می‌کنه، و ⁨QUIC⁩ هم روی ⁨UDP⁩ ساخته شده. نتیجه‌اش اینه که اتصال سریع‌تر بالا میاد، روی اینترنت ناپایدار بهتر جواب میده، و وقتی مثلا گوشی از وای‌فای میره روی دیتای موبایل، اتصال کمتر می‌پره. فعلا نسل اصلی جدید همینه، یعنی ⁨HTTP/3⁩. چیزی به اسم ⁨HTTP/4⁩ به عنوان استاندارد رایج و رسمی نداریم. @codehalics | کدهالیک

⁨FYI⁩: ⁨For Your Information⁩ کوییک ( نه ماشین سایپا ) یه پروتکل جدیده که پشت ⁨HTTP/3⁩ استفاده میشه. ایده‌اش اینه که به جای ⁨TCP⁩، روی ⁨UDP⁩ کار کنه تا اتصال سریع‌تر بالا بیاد، وقتی اینترنت بالا پایین میشه بهتر دوام بیاره، و مثلا وقتی گوشی از وای‌فای میره روی دیتا، اتصال کمتر بپره. فرقش با ⁨TCP⁩ کلاسیک اینه که فقط به ⁨IP⁩ و پورت وابسته نیست و چیزی به اسم ⁨Connection ID⁩ داره. برای همین جابه‌جایی شبکه و ⁨load balancing⁩ باهاش تمیزتر انجام میشه. واسه همین نویسنده میگه برای ⁨Voice AI⁩، استفاده از ⁨QUIC⁩ خیلی منطقی‌تر از ⁨WebRTC⁩ عه. چون هم ⁨latency⁩ کمتری میده، هم کنترل بهتری روی ارسال داده داری، هم لازم نیست اون همه هک عجیب برای ⁨WebRTC⁩ بزنی. ⁨HTTP/3⁩ هم رسما روی ⁨QUIC⁩ تعریف شده. حالا نکته ایران اینه که ⁨QUIC⁩ معمولا روی ⁨UDP⁩ و پورت ۴۴۳ میاد بالا. فیلترچی‌ها هم اگه نتونن دقیق و تمیز تشخیص بدن چی به چیه، راحت‌ترین کار براشون اینه که ⁨UDP/443⁩ یا خود ⁨QUIC⁩ رو کلا ببندن. قبلا ⁨OONI⁩ درباره ایران گفته بود شواهد قوی هست که ⁨QUIC⁩، که ⁨HTTP/3⁩ بهش وابسته است، احتمالا با بستن ⁨UDP/443⁩ کامل بلاک شده بود. گزارش‌های فنی‌تر و کامیونیتی هم بعدا نوشتن که ⁨QUIC⁩ روی خیلی از شبکه‌های ایران غیرفعال یا محدود شده. نتیجه‌اش اینه که خیلی از مرورگرها بی‌سروصدا برمی‌گردن روی ⁨HTTP/2⁩ و ⁨TCP⁩. ولی چیزهایی که واقعا روی ⁨QUIC⁩ حساب کرده باشن، مثل بعضی روش‌های تونل، ⁨VPN⁩، ⁨WebTransport⁩ یا سرویس‌های ⁨realtime⁩، یا کند میشن یا کلا نمیان بالا. @codehalics | کدهالیک

FYI : FOR YOUR INFORMATION QUIC یه پروتکل جدیده که پشت HTTP/3 استفاده میشه و ایده‌اش اینه که به جای TCP، روی UDP کار کنه تا اتصال سریع‌تر بالا بیاد، وقتی اینترنت بالا پایین میشه بهتر دوام بیاره، و مثلا وقتی گوشی از وای‌فای میره روی دیتا، اتصال کمتر بپره. فرقش با TCP کلاسیک اینه که فقط به IP و پورت وابسته نیست و چیزی به اسم Connection ID دارد، برای همین جابه‌جایی شبکه و load balancing باهاش تمیزتر انجام میشه. واسه همین نویسنده میگه برای Voice AI، QUIC خیلی منطقی‌تر از WebRTC عه، چون هم latency کمتری میده، هم کنترل بهتری روی ارسال داده داری، هم لازم نیست اون همه هک عجیب برای WebRTC بزنی. HTTP/3 هم رسما روی QUIC تعریف شده. حالا نکته ایران اینه که QUIC معمولا روی UDP پورت ۴۴۳ میاد بالا، و فیلترچی‌ها اگر نتونن دقیق و تمیز تشخیص بدن چی به چیه، راحت‌ترین کار براشون اینه که UDP/443 یا خود QUIC رو کلا ببندن. قبلا OONI درباره ایران گفته بود شواهد قوی هست که QUIC، که HTTP/3 بهش وابسته است، احتمالا با بستن UDP/443 کامل بلاک شده بود. گزارش‌های فنی‌تر و کامیونیتی هم بعدا نوشتن که QUIC روی خیلی از شبکه‌های ایران غیرفعال یا محدود شده. نتیجه‌اش اینه که خیلی از مرورگرها بی‌سروصدا برمی‌گردن روی HTTP/2 و TCP، ولی چیزهایی که واقعا روی QUIC حساب کرده باشن، مثل بعضی روش‌های تونل، VPN، WebTransport یا سرویس‌های realtime، یا کند میشن یا کلا نمیان بالا. @codehalics | کدهالیک

این مقاله تازه نوشته شده راجب به استفاده از webRTC در ChatGPT نوشته که بنظر کار اشتباهی بوده ! میگه استفاده از WebRTC برای Voice AI انتخاب خوبی نیست، چون WebRTC ذاتا برای تماس زنده ساخته شده، نه برای اینکه صدای کاربر با دقت کامل به مدل هوش مصنوعی برسه. توی تماس تصویری اگه اینترنت بد بشه، WebRTC برای پایین نگه داشتن تأخیر، بسته‌های صدا رو می‌ندازه دور. این برای مکالمه آدم‌ها قابل تحمله، ولی برای AI بده، چون اگه بخشی از پرامپت صوتی خراب یا حذف بشه، مدل ممکنه کل منظور کاربر رو اشتباه بفهمه. از نظر نویسنده بهتره کاربر ۲۰۰ میلی‌ثانیه بیشتر صبر کنه، ولی صدای دقیق‌تری ارسال بشه. بخش فنی‌تر حرفش هم اینه که WebRTC در مقیاس بزرگ دردسر زیاد دارد: کلی پروتکل و استاندارد توی هم قاطی شده، راه‌اندازی اتصالش چندین رفت و برگشت شبکه می‌خواهد، load balancing سخت می‌شود و شرکت‌ها مجبور می‌شوند کلی هک و راه‌حل اختصاصی بسازند. پیشنهادش اینه که برای Voice AI اول حتی WebSocket ساده بهتره، چون با زیرساخت‌های فعلی راحت‌تر scale می‌شود. ولی در حالت ایده‌آل باید رفت سمت QUIC یا WebTransport، چون اتصال سریع‌تر، جابه‌جایی بهتر بین وای‌فای و موبایل، و load balancing تمیزتری دارد. خلاصه حرفش اینه: OpenAI کار سختی رو در مقیاس خیلی بزرگ انجام داده، ولی به نظرش اصل انتخاب WebRTC برای این محصول اشتباهه. https://moq.dev/blog/webrtc-is-the-problem/ @codehalics | کدهالیک

فک کنم الان فهمیدم چرا لینوس تروالدز راجب AI گفت هوش مصنوعی الان ۹۰٪ مارکتینگ و ۱۰٪ واقعیته بنظرم واقعیتشو توی این چند هفته که ۳ تا کریتیکال باگ روی کرنل زد متوجه بشه :)))) @codehalics | کدهالیک

باز دوباره یه آسیب‌پذیری خیلی خطرناک برای لینوکس پیدا شده به اسم «Dirty Frag» که می‌تونه روی اکثر distroهای اصلی به کاربر عادی دسترسی root بده. مشکل اینجاست که exploitش عمومی شده ولی هنوز همهٔ سیستم‌ها patch نگرفتن، برای همین الان یکی از حساس‌ترین زمان‌ها برای حمله‌های لینوکسیه. https://www.openwall.com/lists/oss-security/2026/05/07/8 @codehalics | کدهالیک

متأسفانه AI یه کاری کرده که کم‌کم تشخیص دادن متخصص واقعی از ShowMan سخت شده. حس می‌کنم آدمی که ۱۰، ۱۵ سال توی یه حوزه زحمت کشیده، شب‌بیداری کشیده، تجربه جمع کرده و هنوزم کار باکیفیت تولید می‌کنه، کنار کسی قرار گرفته که تا دیروز فقط با کد بازی می‌کرده و حالا با چند تا ابزار AI خودش رو هم‌سطح متخصص نشون میده. مشکل این نیست که AI بده؛ مشکل اینه که فاصله بین «بلد بودن» و «بلد به نظر رسیدن» خیلی کم شده. به نظرم بهترین مثالش تفاوت فرش دستباف با فرش ماشینیه. فرش ماشینی تمیزتر، ارزون‌تر و سریع‌تر تولید میشه، ولی اون روح و حس فرش دستباف رو نداره. توی فرش دستباف، هر گره یه دلیل داره. می‌تونی از بافنده بپرسی چرا این طرح اینجاست، چرا اون رنگ عوض شده، چرا اون گره اون‌طوری خورده. پشت هر قسمتِ کار، ساعت‌ها فکر، تجربه و زندگی خوابیده. ولی فرش ماشینی فقط خروجیه؛ تمیز و دقیق، اما بی‌روح. حس می‌کنم خیلی از چیزایی که امروز با AI تولید میشن هم همینن. شاید از بیرون قشنگ و کامل به نظر برسن، ولی اون عمق، رنج، تجربه و روحی که توی کار یه آدم واقعی هست رو ندارن. شاید همه با این نگاه موافق نباشن، ولی اگر یه بار از این زاویه به موضوع نگاه کنی، احتمالاً می‌فهمی منظورم چیه. کن متوجه میشی @codehalics | کدهالیک

این مقاله داره میگه اینترنت کم‌کم زیر حجم محتوای کم‌ارزشِ ساخته‌شده با AI خفه میشه. مشکل از جایی شروع میشه که هر کسی با چند تا پرامپت یه اپ، مقاله، ویدیو یا repo درمیاره و سریع توی Reddit و Hacker News و Slack پخشش می‌کنه، انگار شاهکار ساخته. حرفش اینه که صرف این‌که AI تونسته چیزی برات تولید کنه، دلیل نمیشه بقیه هم باید وقتشونو صرف دیدنش کنن. به نظرش خیلی از این پروژه‌ها بیشتر هیجان لحظه‌ای‌ان تا چیزی که واقعاً به درد کامیونیتی بخوره. اصل حرفش درباره نسبت «سیگنال به نویز» توی اینترنت امروزه. یعنی وقتی همه شروع کنن به پست کردن خروجی خام AI، پیدا کردن کار باکیفیت سخت میشه و کم‌کم آدمای واقعی و متخصص از کامیونیتی خسته میشن و کنار می‌کشن. خودش بین «استفاده خوب از AI» و «AI slop» فرق میذاره؛ اگه AI کمک کنه یه آدم واقعاً چیز مفید و فکرشده‌ای بسازه، عالیه. ولی اگر فقط برای جلب توجه، گرفتن engagement یا تولید محتوای بی‌فکر باشه، داره فضای اینترنتو نابود می‌کنه. خلاصه حرفش اینه که «با AI بساز، نه این‌که فقط خروجی AI رو روی سر بقیه خالی کنی.» لینک مقاله @codehalics | کدهالیک

OmniRoute یه هاب هوش مصنوعیه برای برنامه‌نویسا؛ یعنی به‌جای درگیر شدن با تحریم، quota، قطع شدن Claude یا محدودیت GPT، همه مدل‌های AI رو از یه آدرس واحد مدیریت می‌کنی. خودش بین Claude، GPT، Gemini، DeepSeek و حتی مدل‌های رایگان سوییچ می‌کنه تا وسط کار coding گیر نکنی. برای ابزارهایی مثل Cursor، Cline، Claude Code و Codex ساخته شده و مخصوص کساییه که هر روز با AI کد می‌زنن. ویژگی خفن پروژه اینه که مصرف توکن و هزینه رو شدید کم می‌کنه؛ لاگ‌ها، خروجی ترمینال و context طولانی رو فشرده می‌کنه تا هم ارزون‌تر دربیاد هم context دیرتر پر بشه. تازه سیستم proxy و bypass تحریم هم داره، برای همین بین دولوپرهای ایران، روسیه و کشورهایی که سرویس‌های AI محدودن خیلی محبوب شده؛ عملاً یه «مرکز کنترل AI» می‌سازه که همیشه یه مدل آماده‌ی fallback داره تا کارت نخوابه. https://github.com/diegosouzapw/OmniRoute @codehalics | کدهالیک

خب دوستان خوشبو بودیم جلوی کولرم نشستیم ! مثل که دوباره جنگ شروع شد 🙂 #off_topic @codehalics | کدهالیک

Only legends know @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/ @codehalic | کدهالیک

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