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

🚫 بر اساس دستور دولت ایالات متحده، حتی غیرآمریکایی‌های ساکن در آمریکا (ازجمله کارمندان انتروپیک) هم نباید به فیبل ۵ و میتوس ۵ دسترسی داشته باشند.


حالا ما یه چارتا هدر و فوتر باهاش درست کردیم انقد ننه من غریبن بازی نداشت آقای آنتروپیک

@codehalics | کدهالیک

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

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

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

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

ازشون میتونین کمک بگیرین
@jobzlingo


@codehalics | کدهالیک

یه خبر امنیتی خیلی خفن اومده: تیم Depthfirst می‌گه ایجنت امنیتی خودکارشون تونسته ۲۱ تا Zero-day توی FFmpeg پیدا کنه؛ همون FFmpeg معروفی که تقریباً همه‌جا هست، از مرورگرها و سرویس‌های استریم گرفته تا ابزارهای تبدیل و پردازش ویدئو. جذابیت ماجرا اینه که این باگ‌ها بعد از کلی بررسی امنیتی سنگین توسط تیم‌هایی مثل Google و Anthropic پیدا شدن و بعضی‌هاشون ظاهراً ۱۵ تا ۲۰ سال توی کد خوابیده بودن. از اون مهم‌تر، خروجی ایجنت فقط «احتمالاً اینجا باگه» نبوده؛ برای هر مورد ورودی قابل بازتولید ساخته که ثابت کنه مشکل واقعاً وجود داره. یکی از نمونه‌ها هم تا حد Primitive برای اجرای کد از راه دور جلو رفته؛ یعنی اگر FFmpeg یک استریم RTSP مخرب رو باز کنه، ماجرا می‌تونه جدی بشه. خلاصه اینکه AI توی امنیت داره از مرحله حرف و دمو رد می‌شه و کم‌کم وارد فاز شکار واقعی باگ‌های عمیق توی کدهای قدیمی و سخت می‌شه.

https://depthfirst.com/research/21-zero-days-in-ffmpeg

@codehalics | کدهالیک

نسخه جدید Docker Desktop 4.77 منتشر شد؛ آپدیتی که بیشتر روی پایداری، دیباگ و بهبود تجربه توسعه‌دهنده‌ها تمرکز دارد. در این نسخه امکان خروجی گرفتن از لاگ‌ها اضافه شده، جست‌وجوی لاگ‌ها قابلیت Case-sensitive گرفته، ابزارهای اصلی مثل Docker Engine، Buildx، containerd، Docker Agent و MCP Gateway آپدیت شده‌اند و نصب و آپدیت اکستنشن‌ها هم با pinned manifest digest امن‌تر شده است. در کنار این‌ها، چند باگ مهم هم در Windows و WSL رفع شده؛ از جمله مشکل گیر کردن Docker Engine در حالت Starting و مشکل خروج تمیز از برنامه در Windows Containers mode.

https://docs.docker.com/desktop/release-notes/

@codehalics | کدهالیک

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

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

https://tonsky.me/blog/every-frame-perfect/

@codehalics | کدهالیک

این مقاله یه نکته مهم درباره کار با AI و مخصوصاً AI Coding می‌گه: خیلی به «کانتکست بزرگ» مدل‌ها اعتماد نکنین. اینکه یه مدل می‌گه ۲۰۰ هزار، یک میلیون یا حتی دو میلیون توکن کانتکست داره، الزاماً یعنی همه اون اطلاعات رو با کیفیت خوب نمی‌فهمه و نگه نمی‌داره. نویسنده می‌گه کانتکست مدل‌ها یه فضای کاملاً هوشمند و یکدست نیست؛ انگار یه بخشی ازش «منطقه باهوش»ه که مدل هنوز دقیق و تیز کار می‌کنه، ولی وقتی چت خیلی طولانی می‌شه و فایل‌ها، لاگ‌ها، تست‌ها و توضیحات زیاد واردش می‌کنی، کم‌کم وارد «منطقه کندتر و گیج‌تر» می‌شه.

این دقیقاً برای برنامه‌نویس‌ها مهمه؛ چون وقتی با Coding Agent کار می‌کنی، خیلی راحت وسوسه می‌شی کل ریپو، چندتا فایل، لاگ خطا، خروجی تست و کلی توضیح رو بریزی توی یه سشن و انتظار داشته باشی مدل همه‌چیز رو مثل اول بفهمه. اما واقعیت اینه که مدل ممکنه وسط کار جزئیات مهم رو فراموش کنه، تصمیم‌های قبلی یادش نمونه یا روی بخش‌های کم‌اهمیت زیادی گیر بده. پیشنهاد مقاله اینه که با کانتکست مثل بودجه رفتار کنیم: سشن‌ها رو بیش از حد طولانی نکنیم، خروجی‌های مهم رو خودمون تبدیل کنیم به یه سند کوچیک، اسپک، پلن یا خلاصه دقیق و برای ادامه کار، یه سشن تازه رو با همون اطلاعات تمیز و ضروری شروع کنیم. خلاصه اینکه به‌جای اینکه همه‌چیز رو داخل یه چت بی‌پایان نگه داریم، بهتره کار رو مرحله‌به‌مرحله و با مستندات کوچیک و قابل‌اتکا جلو ببریم.

https://garrit.xyz/posts/2026-05-06-dont-trust-large-context-windows

@codehalics | کدهالیک

دیروز داشتم یه مقاله خیلی جالب روی arXiv برای دانشگاه کرونل رو می‌خوندم که استاد شریف زارچی معرفیش کرده بود توی ویدیو اخیرش درباره اینکه وقتی با مدل‌های زبانی کار می‌کنیم، «همه اطلاعات رو اول کار بدیم» بهتره یا «کم‌کم و مرحله‌به‌مرحله توضیح بدیم». نتیجه‌اش برای من خیلی مهم بود، چون دقیقاً به تجربه روزمره ما با ChatGPT و ابزارهای AI Coding ربط داره.

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

https://arxiv.org/abs/2505.06120

@codhalics | کدهالیک

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

از این بات میتونین قابلیت های جدید فرمتینگ تلگرام رو ببینید !
@richtextdemobot

@codehalics | کدهالیک

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

@codehalics | کدهالیک

We found an outage. Our engineers are investigating… 😂

@codehalics | کدهالیک

خب درست شد سایت و حالا بیاید موشکافی کنیم که در همچین لحظاتی باید چیکار کرد!

@codehalics | کدهالیک

قبل از اینکه بریم سراغ مچ‌گیری از دیتاسنتر، بیاید اول با یک اصطلاح خفن مهندسی آشنا بشیم: ترابل‌شوتینگ (Troubleshooting) که تو تیم‌های فنی بهش میگن «تی‌شوت» (T-Shoot) کردن.

تی‌شوت کردن یعنی چی؟
تی‌شوت کردن یعنی پیدا کردنِ ریشه‌ی یک مشکل (Root Cause) به صورت سیستماتیک و علمی، به جای حدس زدن و چشم‌بسته عمل کردن.

خیلی وقت‌ها وقتی سرور یا اپلیکیشن می‌خوابه، برنامه‌نویس‌های تازه‌کار شروع می‌کنن به حدس زدن: "شاید رم پر شده؟ شاید کد من باگ داره؟ شاید دیتابیس قفل کرده؟" و الکی سرور رو ری‌استارت می‌کنن. به این کار میگن Trial and Error (آزمون و خطا).

اما یک مهندس ارشد (Senior) وقتی با قطعی مواجه میشه، تی‌شوت می‌کنه. یعنی مثل یک کارآگاه جنایی وارد صحنه جرم میشه و میگه:

«من حدس نمی‌زنم، من لاگ‌ها رو می‌خونم.»

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

@codehalics | کدهالیک

سناریویی که اتفاق افتاد این بود

داستان از این قرار بود که سرور لینوکس شما که میزبان سرویس‌های حساسی مثل دیتابیس پستگرس روی داکر بود، ناگهان خاموش شده و از دسترس خارج میشه. وقتی سرور دوباره روشن میشه و شما از پشتیبانی دیتاسنتر (یا شخصی که سرور رو ازش خریدی) پیگیری می‌کنی، در جواب میگن: "ما کاری نکردیم، سرور از سمت ما مشکلی نداشته، احتمالاً خودتون از داخل لینوکس دستور خاموشی دادید یا سرورتون کرش کرده!"

در این لحظه، به جای اینکه حرفشون رو بپذیریم یا شروع کنیم به حدس زدن، تصمیم گرفتیم مثل یک مهندس ارشد وارد فاز T-Shoot (ترابل‌شوتینگ) بشیم و از خود سیستم‌عامل به عنوان شاهد استفاده کنیم.

@codehalics | کدهالیک

۱. بررسی تاریخچه لاگین‌ها و خاموشی‌ها (last -x)
اولین قدم این بود که ببینیم آیا کسی دکمه خاموشی رو زده؟
خروجی دستور last نشون داد که آخرین باری که سرور به صورت نرمال shutdown شده، مربوط به ماه‌ها پیش بوده.

۲. مدرک سخت‌افزاری: وحشتِ سیستم‌فایل (recovering journal)
وقتی لینوکس نرمال خاموش میشه، درایوها رو با احترام می‌بنده (Unmount). ما رفتیم سراغ لاگ‌های لحظه روشن شدن سرور با دستور:
journalctl -b | grep -i "recovering journal"
چی پیدا کردیم؟ دیدیم سرویس systemd-fsck به شدت درگیر ریکاوری کردن پارتیشن‌های sda2، lv_var و lv_home شده! این یعنی درایوها در حالت کثیف (Dirty) رها شده بودن و برقشون یهو قطع شده بوده. این اولین "تیر خلاص" به ادعای پشتیبانی بود.

۳. مدرک اپلیکیشنی: اعترافِ پستگرس (PostgreSQL)
دیتابیس‌ها به شدت روی داده‌ها حساسن. ما رفتیم سراغ لاگ کانتینر دیتابیس:
docker logs <container_id>
چی پیدا کردیم؟ این شاه‌بیتِ ماجرا بود! پستگرس لاگ انداخته بود که:
database system was not properly shut down; automatic recovery in progress
یعنی دیتابیس وسط کار خفه شده بود! تازه پستگرس زمان دقیق قطعی رو هم لو داد: ۱۴ ژوئن ساعت ۲۱:۳۱. اینجا دیگه ۱۰۰٪ مطمئن شدیم که سرور به صورت Hard Power Cut خاموش شده.

۴. مدرک پلتفرمی: تقلای انجین داکر (Docker Daemon)
برای اینکه نشون بدیم حتی داکر هم غافلگیر شده، لاگ‌های سرویس داکر رو چک کردیم:
journalctl -u docker.service -b
چی پیدا کردیم؟ ده‌ها خط ارور با عنوان Removing stale sandbox. این نشون داد که داکر نتونسته در زمان قطعی، سیگنال SIGTERM رو به کانتینرها بفرسته و محیط‌های شبکه‌ای (Sandboxes) رو به درستی پاک کنه. در نتیجه موقع روشن شدن، مجبور شده زباله‌های به‌جا مونده از دفعه قبل رو دستی پاک کنه.

۵. اثبات بی‌گناهی لینوکس (رد کردن ادعای کِرَش)
برای اینکه پشتیبانی نتونه بگه "لینوکس خودتون باگ خورده و هنگ کرده":

پوشه کرش‌های هسته لینوکس (/var/crash/) رو چک کردیم و دیدیم total 0 (کاملاً خالی) است. یعنی کرنل لینوکس در کمال سلامت بوده.

تاریخچه دستورات ترمینال رو هم چک کردیم (history) و هیچ دستور خاموشی‌ای در زمان قطعی پیدا نشد.

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


نتیجه این T-Shoot:
به جای اینکه با پشتیبانی سرِ اینکه "کی مقصره" دعوا کنیم، مدارک فنی رو کوبیدیم روی میز! بهشون ثابت کردیم که سیستم‌عامل، داکر و دیتابیس ما همگی گزارش یک قطعی ناگهانی برق یا Force Stop از سمت هایپروایزرِ اون‌ها رو دادن.

@codehalics | کدهالیک