۱. بررسی تاریخچه لاگین‌ها و خاموشی‌ها (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 | کدهالیک

راز رکورتر های قلابی توی لینکدین که این روزا حسابی زیاد شدن

یه داستان واقعی که برای یکی از دوستای منم پیش اومده، همین مدلیه: یه سری آدم میان پیام می‌دن که شما برای فلان پوزیشن خیلی فیت هستی، رزومه‌ات رو دیدیم، پروژه‌هات جذابه، بیا یه تسک کوچیک انجام بده یا این ریپو رو ببین. ظاهر ماجرا خیلی حرفه‌ای و عادیه؛ انگار داری وارد یه فرآیند جذب معمولی می‌شی. ولی مشکل از جایی شروع می‌شه که همون «تسک کوچیک» می‌تونه یه تله باشه. توی این مقاله هم دقیقاً همین اتفاق افتاده؛ به طرف یه ریپوی گیت‌هاب دادن که مثلاً بررسیش کنه، اما داخل پروژه یه بک‌دور قایم کرده بودن که با نصب dependencyها فعال می‌شده. یعنی دیگه فقط لینک ناشناس و فایل exe خطرناک نیست؛ حتی یه پروژه گیت‌هاب برای مصاحبه کاری هم می‌تونه آلوده باشه. مخصوصاً برای بچه‌های فنی، قبل از اجرای هر پروژه ناشناس، بهتره توی محیط ایزوله، VM یا کانتینر بررسیش کنن و هیچ‌وقت همین‌طوری روی سیستم اصلی npm install نزنن. اصل مقاله رو اینجا بخونید:

https://roman.pt/posts/linkedin-backdoor/

@codehalics | کدهالیک

جالبه که این دقیقاً همون چیزیه که npm توی نسخه ۱۲ داره جدی‌تر جلوش رو می‌گیره؛ یعنی دیگه قرار نیست هر dependency همین‌طوری موقع نصب، اسکریپت‌های preinstall و install و postinstall خودش رو اجرا کنه، مگر اینکه خود پروژه صراحتاً بهش اجازه داده باشه.

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

@codehalics | کدهالیک

هر فایل، ابزار، یا نرم‌افزاری که از منبع ناشناس دریافت می‌کنید، قبل از اجرا روی سیستم اصلی‌تون، داخل یه VM تست کنید.
مثلا Virtual Machine یا همون ماشین مجازی دقیقاً برای همین ساخته شده یه محیط کاملاً ایزوله که هر اتفاقی توش بیفته، به سیستم اصلی شما آسیب نمی‌رسه. بدترین سناریو؟ فایل‌های اون VM رو پاک می‌کنید و تمام.
گزینه‌های خوبی هم در دسترس دارید:
VirtualBox — رایگان، روی ویندوز و لینوکس
UTM — گزینه عالی برای مک، مخصوصاً سیلیکون اپل

یه ایمیج ویندوز یا اوبونتو نصب کنید، هیچ اطلاعات مهمی روش نذارید، و هر چیز مشکوکی رو اول اونجا باز کنید.
چرا مهمه؟ چون یه سری فایل‌ها اطلاعاتتون رو می‌دزدن، یه سری سیستمتون رو قفل می‌کنن (باج‌افزار)، و یه سری بدون اینکه چیزی بفهمید در پس‌زمینه کار می‌کنن.
یه VM همیشگی داشته باشید یه عادت ساده که خیلی از دردسرها رو جلوگیری می‌کنه.
@codehalics | کدهالیک

یه خبر عجیب و مهم از دنیای ابزارهای برنامه‌نویسی: طبق گزارش BBC، اسپیس‌ایکس داره Cursor رو می‌خره؛ همون ادیتور هوشمندی که خیلی از دولوپرها این یکی دو سال باهاش کد زدن و عملاً تبدیل شده به یکی از جدی‌ترین ابزارهای AI coding. نکته مهم خبر فقط خود خرید نیست، اینه که ابزارهای کدنویسی با هوش مصنوعی دیگه یه فیچر خوشگل کنار IDE نیستن؛ دارن تبدیل می‌شن به دارایی استراتژیک شرکت‌های بزرگ. یعنی هر شرکتی که مدل، compute، دیتای توسعه نرم‌افزار و workflow دولوپرها رو با هم داشته باشه، می‌تونه توی موج بعدی تولید نرم‌افزار دست بالاتر رو بگیره. حالا باید دید Cursor بعد از این خرید مستقل و چندمدلی می‌مونه یا کم‌کم به سمت اکوسیستم Grok و xAI کشیده می‌شه.

لینک خبر: https://www.bbc.com/news/articles/cvgd5g7d7gyo


@codehalics | کدهالیک

کلا عمو ماسک بر خلاف عمو بابک سمت هر چیزی رفته چندین پله بهترش کرده بنظرم اولین قدمش برای رقابت با دنیای Claude Code و AntiGravity و این چیزا اینه که بره یه چیز قدرتمند و خفنی مثل کرسر رو بخره و قطعا مدلای Grok طی چندین ماه آینده حرف های زیادی روی برنامه نویسی هم دارن و تجربه نشون داده که عمو ماسک همیشه تسهیل گری کرده که یه چیزی بیشتر دیده بشه با اینکه عقاید گاها چپ گرایانه ای هم از خودش بروز میده ولی من امیدوارم که یه تکونی به قیمت گذاری های آنتروپیک و اینا میده چون الان واقعا GROK هیچ حرفی توی برنامه نویسی و کد زدن واقعا نداره بیشتر بخاطر داشتن دیتای توییتر میتونه راجب اتفاقات روز و تحلیل روزمره و اینا کمک کنه
@codehalics | کدهالیک

اگه Mac بی‌کار با چیپ Apple Silicon دارید، می‌تونید به استخر darkbloom اضافه کنید تا به صورت encrypt شده مدل‌های اُپن سورس روش ران بشه و ازش درآمد ماهیانه داشته باشید. مثلا Macbook با چیپ M1 Pro و 32 گیگ رم، اگه مدل Gemma 4 رو ۲۴ روز در ماه ران کنه، حدود ۹۰ دلار پاداش می‌گیرید! بچه‌هایی که کریپتویی هستن شاید شرکت پشت سرش به اسم EigenLayer واسشون آشنا باشه! جدیدا هم با OpenRouter برای ساپلای کردن inference قرارداد بستن!
darkbloom.dev

Amir

@codehalics | کدهالیک

ورسل یه فریم‌ورک جدید معرفی کرده به اسم Eve؛ خلاصه‌اش اینه که می‌خواد برای ساخت AI Agent همون کاری رو بکنه که Next.js برای ساخت وب‌اپ کرد. یعنی به‌جای اینکه هر تیم از صفر بیاد برای ایجنتش کلی چیز تکراری بسازه، مثل اتصال به ابزارها، اجرای امن کد، مدیریت پرامپت، لاگ و تریس، Approval انسانی، تست و دیپلوی، Eve این زیرساخت‌ها رو آماده می‌ده. توی Eve یه ایجنت عملاً یه پوشه‌ست؛ یه فایل برای مدل، یه فایل برای دستورالعمل‌ها، یه فولدر برای ابزارها، یکی برای skillها، یکی برای subagentها، یکی برای کانال‌هایی مثل Slack و Telegram و GitHub.

نیازش هم دقیقاً از اینجا میاد که ساختن Agent واقعی فقط این نیست که یه LLM صدا بزنی و بگی فلان کار رو بکن. وقتی Agent قراره توی محصول واقعی کار کنه، باید وسط کار کرش نکنه، بتونه چند ساعت یا چند روز یه فرآیند رو ادامه بده، برای کارهای حساس از آدم تأیید بگیره، کدی که تولید می‌کنه رو توی محیط امن اجرا کنه، به سرویس‌هایی مثل GitHub، Slack، Snowflake، Notion و Linear وصل بشه و بشه فهمید دقیقاً چه کاری کرده و کجا اشتباه کرده. Eve می‌خواد این تکه‌های پراکنده رو تبدیل کنه به یه فریم‌ورک استاندارد برای ساخت Agentهای Production-ready. خلاصه اگر قبلاً هر تیم داشت Agent خودش رو با چسب و سیم می‌ساخت، Vercel می‌گه بیاید از این به بعد براش اسکلت و معماری درست داشته باشیم.

https://vercel.com/blog/introducing-eve

@codehalics | کدهالیک

ایران درست میشه
وضعیت ایران :

@codehalics | کدهالیک

بچه‌ها بالاخره بعد از ۱۰ سال انتظار و کلی بحث و جدل، متد جدید HTTP به اسم QUERY رسماً تایید شد و با شماره RFC 10008 اومد بیرون! داستان از این قراره که تا الان وقتی می‌خواستیم کلی فیلتر پیچیده بنویسیم و یه دیتای خاص رو از سرور بگیریم، یا باید یه لینک کیلومتری با کوئری‌استرینگ‌های طولانی می‌ساختیم که هم محدودیت حجم داشت و هم توی لاگ‌های سرور لو می‌رفت، یا اینکه مجبور بودیم از متد POST استفاده کنیم. اما POST ذاتاً برای ایجاد تغییرات طراحی شده و ویژگی Idempotent (تکرارپذیری امن) رو نداره. متد QUERY دقیقاً برای حل همین مشکل متولد شده تا این جای خالی رو پر کنه.

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

https://www.rfc-editor.org/info/rfc10008/

@codehalics | کدهالیک

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

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

https://lore.org

@codehalics | کدهالیک

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

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

@codehalics | کدهالیک