مقاله‌های رسمی

Agent Lee: دستیار هوش مصنوعی کلادفلر که تو داشبورد کنارت نشسته

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

چطور کار می‌کنه

Agent Lee از دکمه‌ی «Ask AI» تو گوشه‌ی بالا-راست هر صفحه‌ی داشبورد باز می‌شه. فرقش با یه چت‌بات معمولی این‌جاست که جواب‌هاش صرفاً بر اساس مستندات نیست؛ وقتی سؤالی می‌پرسی، واقعاً به تنظیمات zone، رکوردهای DNS، و قوانین امنیتی خود اکانتت سر می‌زنه و بر اساس داده‌ی واقعی جواب می‌ده، نه صرفاً یه توضیح کلی از مستندات.

چه کارهایی از دستش برمیاد

جواب دادن بر اساس داده‌ی واقعی اکانت: می‌تونی بپرسی «SSL mode زون من رو چیه؟» یا «چرا این رکورد DNS پراکسی نشده؟» و Agent Lee مستقیم از تنظیمات واقعی اکانتت جواب می‌ده.

انجام عملیات نوشتنی (با تأیید تو): اینجاست که فرقش با یه چت‌بات ساده معلوم می‌شه. می‌تونی به زبون طبیعی بگی «یه رکورد A برای blog.example.com به آی‌پی ۱۹۲.۰.۲.۱۰ اضافه کن» یا «Always Use HTTPS رو برای zone من فعال کن»، و Agent Lee دقیقاً نشونت می‌ده قراره چیکار کنه و منتظر تأیید صریح تو می‌مونه؛ هیچ تغییری بدون OK گرفتن از تو اجرا نمی‌شه.

دیاگنوستیک شبکه: می‌تونه DNS lookup بزنه، گواهی SSL/TLS رو چک کنه، یا اطلاعات WHOIS/RDAP یه دامنه رو دربیاره؛ بدون این‌که نیاز باشه بری سراغ یه ابزار جدا.

تولید نمودار و visualization: اگه بپرسی «نمودار ترافیک هفت روز اخیرم رو نشونم بده» یا «نرخ خطای ۲۴ ساعت گذشته چه شکلیه؟»، Agent Lee مستقیم تو همون پنل چت، نمودار مربوطه رو رسم می‌کنه.

چیزی که به Amazon Q شبیه‌ش می‌کنه

اگه با Amazon Q Developer یا دستیارهای مشابه تو کنسول‌های ابری دیگه کار کرده باشی، مدل Agent Lee دقیقاً همون فلسفه‌ست: به‌جای این‌که بین چند صفحه‌ی تنظیمات بری و بگردی، یه دستیار همیشه در دسترس داری که هم context اکانتت رو می‌شناسه، هم می‌تونه مستقیم براش اقدام کنه. تفاوت مهمش با یه ابزار جستجوی صرف اینه که واقعاً دسترسی write داره، هرچند این دسترسی همیشه پشت یه مرحله‌ی تأیید دستی قفله.

به چه چیزهایی دسترسی داره و به چه چیزهایی نه

از نظر دسترسی داده، Agent Lee می‌تونه به تنظیمات zone، رکوردهای DNS، قوانین فایروال و WAF، اسکریپت‌ها و route های Workers، اسم باکت‌های R2، تنظیمات Cloudflare Tunnel، و متادیتای پلن و مصرف اکانت سر بزنه. در مقابل، به روش‌های پرداخت، تاریخچه‌ی صورت‌حساب، پسورد و API token ها، لاگ‌های خام یا داده‌ی Logpush، و داده‌ی اکانت‌های دیگه هیچ دسترسی‌ای نداره.

مکالمات به‌صورت جدا برای هر کاربر، با استفاده از Durable Objects ذخیره می‌شن و طبق سیاست نگه‌داری داده‌ی کلادفلر تا یک سال باقی می‌مونن. یه نکته‌ی جالب اینه که فعلاً Agent Lee به مکالمات قبلی رجوع نمی‌کنه؛ یعنی هر سشن از صفر شروع می‌شه و چیزی از گفتگوهای قبلی به یاد نمی‌مونه.

محدودیت‌هاش

Agent Lee نمی‌تونه اسکریپت Workers بنویسه یا کد اپلیکیشن تولید کنه، جایگزین پشتیبانی کلادفلر برای مسائل صورت‌حساب یا بازیابی اکانت نیست، و بین چند اکانت مختلف کار نمی‌کنه؛ هر سشن محدود به همون اکانتیه که باهاش لاگین کردی. همچنین کاملاً اختیاریه: اگه پنل Ask AI رو باز نکنی، هیچ داده‌ای بهش فرستاده نمی‌شه.

در حال حاضر کجا در دسترسه

فعلاً Agent Lee تو مرحله‌ی beta هست و فقط برای اکانت‌های پلن Free در دسترسه. طبق اعلام کلادفلر، این ویژگی‌ها و رفتارها ممکنه تغییر کنن، پس اگه امروز باهاش کار می‌کنی، انتظار داشته باش رفتارش تو ماه‌های آینده تکامل پیدا کنه.

Bun vs Deno vs Node.js: کدوم رو انتخاب کنیم

هر سه‌ی این‌ها یه runtime کامل جاوااسکریپت/تایپ‌اسکریپت هستن؛ یعنی هر کدوم می‌تونه کد سمت سرور رو اجرا کنه، پکیج نصب کنه، و پروژه رو build کنه. تفاوتشون تو فلسفه‌ی طراحی، عملکرد، و چیزیه که هر کدوم به‌صورت پیش‌فرض بهت می‌دن. تو این مقاله این سه تا رو کنار هم می‌ذاریم تا ببینیم کدوم برای چه نوع پروژه‌ای منطقی‌تره.

Node.js: استاندارد جا‌افتاده

Node.js از سال ۲۰۰۹ وجود داره و به همراه npm (package manager پیش‌فرضش) میاد. مزیت اصلیش، بلوغ و اکوسیستمشه: تقریباً هر کتابخونه‌ای که فکرش رو بکنی رو npm داره، مستندات و Stack Overflow پر از جواب برای هر مشکلیه، و تقریباً هر سرویس هاستینگ و CI/CD ای ازش پشتیبانی می‌کنه.

نقطه‌ضعفش هم دقیقاً از همین قدمت میاد. Node.js از پایه برای جاوااسکریپت طراحی شده و پشتیبانی از TypeScript نیاز به یه مرحله‌ی جدا برای compile داره (با ts-node یا tsc). npm هم به‌خاطر معماری قدیمیش (پوشه‌ی node_modules تودرتو) نسبت به جایگزین‌های جدیدتر کندتره، هرچند نسخه‌های اخیرش (با فلگ workspace و lockfile بهتر) این فاصله رو کم کرده.

# نصب و اجرا با npm
npm init -y
npm install express
node index.js

Bun: تمرکز روی سرعت

Bun یه runtime کاملاً جدیده که با Zig نوشته شده و از موتور JavaScriptCore (همون موتور Safari) استفاده می‌کنه، نه V8 که تو Node و Deno استفاده می‌شه. هدف اصلیش سرعته: هم سرعت اجرای کد، هم سرعت نصب پکیج‌ها، که تو خیلی از benchmark ها به‌طور محسوسی از npm و yarn سریع‌تره.

نکته‌ی جذاب Bun اینه که TypeScript رو به‌صورت native پشتیبانی می‌کنه، بدون نیاز به هیچ compile جداگانه‌ای:

# اجرای مستقیم یه فایل تایپ‌اسکریپت
bun run index.ts

# نصب پکیج، خیلی سریع‌تر از npm
bun install express

یه مزیت دیگه‌ی Bun اینه که به‌جای اینکه فقط یه runtime باشه، package manager، bundler، و test runner رو هم داخل خودش داره؛ یعنی برای خیلی از پروژه‌ها دیگه نیازی به ابزارهای جدا مثل webpack یا Jest نداری. نقطه‌ضعف اصلیش هم اینه که هنوز نسبتاً جوونه (اولین نسخه‌ی ۱.۰ اواخر ۲۰۲۳ اومد بیرون)، پس ممکنه بعضی پکیج‌های npm که به رفتارهای خیلی خاص Node.js وابسته‌ن، روش درست کار نکنن.

curl در مقابل wget: کدوم رو کِی استفاده کنیم

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

فلسفه‌ی طراحی این دو فرق داره

wget از اول برای یه کار مشخص ساخته شده: دانلود فایل، به‌خصوص دانلودهای بزرگ و طولانی که ممکنه قطع بشن. به همین خاطر ویژگی‌هایی مثل ادامه دادن دانلود ناقص، دانلود recursive (گرفتن یه سایت کامل با تمام لینک‌هاش)، و کار کردن بدون نیاز به یه session تعاملی جزو ذات wget هستن.

curl از اول یه چیز دیگه بود: یه ابزار برای انتقال داده با هر پروتکلی که می‌تونی تصورش کنی (HTTP، HTTPS، FTP، SFTP، حتی SMTP و IMAP)، با تمرکز روی کنترل کامل روی request. برای همین امروز curl تبدیل شده به ابزار پیش‌فرض برای تست کردن API ها، چون بهت اجازه می‌ده هر جزئیات یه HTTP request رو (method، header، body، auth) دقیق کنترل کنی.

دانلود ساده‌ی یه فایل

# wget
wget https://example.com/file.zip

# curl (باید صراحتاً بگی خروجی رو تو یه فایل ذخیره کنه)
curl -O https://example.com/file.zip

اینجا فرق مهمی هست: wget به‌صورت پیش‌فرض خروجی رو تو یه فایل ذخیره می‌کنه، ولی curl به‌صورت پیش‌فرض محتوا رو مستقیم تو ترمینال چاپ می‌کنه، مگه این‌که با فلگ -O (ذخیره با همون اسم فایل تو URL) یا -o filename (ذخیره با اسم دلخواه) بهش بگی که فایل رو ذخیره کنه. این تفاوت دقیقاً از همون فلسفه‌ی طراحی میاد؛ wget برای دانلود ساخته شده، curl برای انتقال و بازی با داده.

کار با API و HTTP request های پیچیده

اینجا جاییه که curl واقعاً می‌درخشه. فرض کن می‌خوای یه POST request با JSON body و یه auth header بفرستی:

Next.js 16.3 منتشر شد؛ تجربه توسعه بهتر شده

اگر چند ماه با یک پروژه‌ی واقعی Next.js کار کرده باشی، احتمالاً با چند دردسر آشنا هستی.

همان لحظه‌ای که پروژه بزرگ‌تر می‌شود، next dev دیگر مثل روزهای اول سبک نیست. یک تغییر کوچک در کد ممکن است باعث شود چند ثانیه منتظر بمانید تا همه چیز دوباره آماده شود. Buildهای CI طولانی‌تر می‌شوند و روی بعضی سیستم‌ها حتی باز کردن پروژه تبدیل به یک تست صبر می‌شود.

Next.js 16.3 دقیقاً روی همین مشکلات دست گذاشته است.

ما قبلا یکسری از آپدیت هایی که خود وبسایت نکست داده بود را بررسی کردیم مثل instant navigation, Ai Improvements و تغییرات توربو پک. نکته‌ی جالب اینجاست که بخش زیادی از این تغییرات بدون اینکه حتی یک خط کد پروژه‌ات را تغییر بدی فعال می‌شوند.

یعنی ممکن است فقط با تغییر نسخه‌ی Next.js، همان پروژه‌ی قبلی سریع‌تر اجرا شود.

بهبودهایی که همین امروز روی پروژه‌های موجود تأثیر می‌گذارند

بخش مهم معرفی Next.js 16.3 همین جمله است: این نسخه برای پروژه‌های موجود هم بهبود دارد.

معمولاً وقتی یک نسخه‌ی جدید منتشر می‌شود، اولین سوال این است که «چه API جدیدی اضافه شده؟»

اما این بار سوال بهتر این است که:

«توی پروژه‌ی فعلی من چه چیزی بهتر می‌شود؟»

جواب کوتاه:

مصرف کمتر RAM در حالت توسعه

cuid و cuid2: چرا نسخه‌ی دوم عملاً از صفر بازنویسی شد

وقتی میخوای برای رکوردهای دیتابیست یک شناسه‌ی یکتا بسازی، احتمالاً اول به auto increment فکر میکنی، بعد به UUID، و اگه دنبال چیزی سبک‌تر و url-friendly تر باشی، به cuid میرسی. ولی نکته‌ای که خیلی وقت‌ها گم میشه اینه که cuid و cuid2 دو چیز کاملاً متفاوتن — نه یک آپدیت جزئی، بلکه یک بازطراحی کامل با فرض‌های امنیتی متفاوت.

cuid اصلی چی بود

cuid (نسخه‌ی اول) حدود سال ۲۰۱۲ ساخته شد تا یک جایگزین برای auto-increment ID و UUID باشه که هم یکتا باشه، هم قابل مرتب‌سازی بر اساس زمان تولید (chronologically sortable)، و هم برای استفاده توی URL راحت‌تر از UUID باشه (چون کوتاه‌تره و کاراکترهای عجیب مثل خط‌تیره‌ی اجباری UUID رو نداره).

ساختار یک cuid از چند بخش تشکیل شده: یک پیشوند ثابت (c)، timestamp، یک شمارنده (counter)، اطلاعاتی از fingerprint ماشین و پردازش (که شامل چیزهایی مثل هاست‌نیم و شناسه‌ی پردازش میشد)، و یک بخش تصادفی. مثال یک cuid واقعی این شکلیه:

cljk3f2j40000qzrmn831i7rn

چرا cuid کنار گذاشته شد

مشکل اصلی cuid وقتی خودش رو نشون داد که مسائل امنیتی جدی‌تری مطرح شد. چون بخشی از cuid از fingerprint ماشین (host/process info) و timestamp قابل پیش‌بینی ساخته میشه، این یعنی تا حدی میشه از روی خود ID، اطلاعاتی درباره‌ی زیرساخت سرور یا ترتیب دقیق تولید رکوردها استنباط کرد. علاوه بر این، چون بخش زمانی cuid قابل پیش‌بینیه، در برخی سناریوها میشه با حدس زدن IDها، رکوردهای مجاور رو enumerate کرد — دقیقاً همون چیزی که یک شناسه‌ی یکتا نباید اجازه بده.

مشکل دیگه، performance بود: تولید fingerprint ماشین و بعضی محاسبات cuid اصلی روی برخی محیط‌ها (مخصوصاً serverless که هر بار یک instance جدید بالا میاد) کند و ناسازگار عمل میکرد.

cuid2 چطور این مشکلات رو حل کرد

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

اول، امنیت رمزنگاری. cuid2 به‌جای تکیه به fingerprint قابل‌پیش‌بینی ماشین، از یک تابع هش امن (SHA3) روی ترکیبی از entropy تصادفی، timestamp، counter، و یک مقدار fingerprint ضعیف‌تر و کم‌اهمیت‌تر استفاده میکنه. نتیجه‌ی نهایی یک رشته‌ست که از نظر آماری غیرقابل‌پیش‌بینیه — یعنی حتی اگه بدونی الگوریتم چطور کار میکنه، نمیتونی ID بعدی رو حدس بزنی یا از روی یک ID موجود، ID های مجاورش رو enumerate کنی.

Elasticsearch: قدرتمند، سنگین، و نه همیشه انتخاب درست

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

Elasticsearch واقعاً چیه

Elasticsearch یک موتور جستجو و آنالیز توزیع‌شده‌ست که روی Apache Lucene ساخته شده. کارش فقط «پیدا کردن یک رشته توی متن» نیست؛ یک سیستم کامله برای indexing متن با امتیازدهی relevance، فیلتر کردن روی فیلدهای ساختاریافته، اجرای aggregation های پیچیده (مثل «میانگین قیمت به تفکیک دسته‌بندی»)، و مقیاس‌پذیری روی چند نود همزمان. برای همینه که توی سیستم‌های لاگ‌مانیتورینگ (مثل استک ELK)، جستجوی محصولات فروشگاه‌های بزرگ، و تحلیل داده‌ی حجیم این‌قدر رایجه.

چرا سنگین حساب میشه

مشکل اصلی Elasticsearch این نیست که کند باشه؛ مشکل اینه که برای اجرا شدن، منابع قابل توجهی میخواد. چون روی JVM (جاوا) اجرا میشه، حداقل نیاز به چند صد مگابایت تا چند گیگابایت heap memory داره، حتی برای یک نود توسعه‌ای کوچیک. توصیه‌ی رسمی برای یک نود production معمولاً از ۲ تا ۴ گیگابایت رم شروع میشه و برای دیتاست‌های بزرگ‌تر به‌سرعت بالا میره. علاوه بر این، Elasticsearch برای کار درست نیازمند تنظیمات سیستم‌عاملیه (مثل افزایش vm.max_map_count روی لینوکس)، و راه‌اندازی یک کلاستر واقعی (با نودهای master و data جدا) خودش یک پروژه‌ی مجزاست، نه یک نصب پنج‌دقیقه‌ای.

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

Meilisearch و رقبای سبک‌تر

Meilisearch یک موتور جستجوی متن‌باز است که با Rust نوشته شده و از ابتدا برای سادگی و سرعت راه‌اندازی طراحی شده، نه برای مقیاس عظیم. تفاوتش با Elasticsearch از همون لحظه‌ی نصب معلومه: یک باینری تک‌فایلی که بدون JVM، بدون تنظیمات پیچیده، و با مصرف رم بسیار پایین‌تر (معمولاً چند ده مگابایت برای دیتاست‌های متوسط) اجرا میشه. جستجوش هم به‌صورت پیش‌فرض typo-tolerant است — یعنی حتی اگه کاربر کلمه رو غلط تایپ کنه، نتیجه‌ی درست رو پیدا میکنه — بدون این‌که نیاز به تنظیم دستی داشته باشه.

Grok حالا برات اپلیکیشن کامل میسازه؛ آشنایی با Build Mode و grok.me

خیلی وقت‌ها یک ایده‌ی ساده توی ذهن آدم شکل میگیره — یک ماشین‌حساب مخصوص یک کار خاص، یک صفحه‌ی landing برای یک پروژه‌ی جانبی، یک داشبورد کوچیک برای دنبال کردن یک سری عدد — ولی چون کدنویسی بلد نیستی یا وقت راه‌اندازی محیط توسعه رو نداری، ایده همون‌جا میمونه. این دقیقاً همون شکافیه که SpaceXAI (همون شرکتی که قبلاً به اسم xAI میشناختیمش) با قابلیت جدید Grok به اسم Build Mode میخواد پرش کنه.

Build Mode چیه

Build Mode یک قابلیت تازه‌ست که همین چند روز پیش، ۲۸ ژوئیه ۲۰۲۶، برای مشترکین SuperGrok Heavy به‌صورت early beta فعال شد. ایده‌ش اینه که به‌جای این‌که Grok فقط یک تکه کد بهت بده که خودت باید کپی کنی و جایی اجرا کنی، مستقیم توی همون چت یک پیش‌نمایش زنده و کاملاً کاربردی از چیزی که خواستی میسازه. بعد میتونی با زبان طبیعی — نه با نوشتن کد — بگی چیدمان عوض بشه، رنگ‌ها تغییر کنه، یک ویژگی اضافه بشه، یا منطق برنامه فرق کنه.

این قابلیت روی وب (grok.com)، اپ iOS و اپ اندروید در دسترسه، یعنی محدود به یک پلتفرم خاص نیست.

چی میشه باهاش ساخت

طبق اعلام رسمی SpaceXAI، دامنه‌ی چیزهایی که Build Mode ازش پشتیبانی میکنه نسبتاً گسترده‌ست:

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

انتشار: لینک grok.me یا دامنه‌ی خودت

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

رقابتی که Grok تازه واردش شده

این حرکت SpaceXAI رو مستقیم وارد بازاری میکنه که این چند وقته اسمش شده «vibe coding» — رویکردی که در اون به‌جای نوشتن کد، با پرامپت و زبان طبیعی نرم‌افزار میسازی. رقبای این میدون کم نیستن: Google AI Studio که امکان تبدیل پرامپت به اپلیکیشن‌های native اندروید رو داره، Claude Artifacts خود آنتروپیک، و ChatGPT Codex از OpenAI. تفاوتی که Grok روش تأکید کرده اینه که میخواد این تجربه رو تا حد امکان غیرتخصصی نگه داره — بدون نصب محلی، بدون تنظیمات پیچیده، صرفاً پرامپت، پیش‌نمایش، و ویرایش.

مدل‌های MiMo شیائومی: وقتی یه غول سخت‌افزاری وارد بازی LLM می‌شه

شیائومی بیشتر با گوشی و لوازم هوشمند شناخته می‌شه — ولی از اوایل ۲۰۲۶ یه سری مدل زبانی با برند MiMo منتشر کرده که توی جامعه‌ی مدل‌های open-weight سروصدا کرده. نسل فعلی شامل MiMo-V2، V2-Pro، V2-Flash، و جدیدترین V2.5 می‌شه — با نسخه‌های Mixture-of-Experts که تعداد پارامترهاشون توی نسخه‌های Pro به یه تریلیون پارامتر می‌رسه.

قبل از هر چیز، یه تجربه‌ی مستقیم:

تست فارسی: جایی که انتظارش نداشتم

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

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

ولی یه محدودیت هم پیدا کردم که مهمه: context window اسماً ۲۵۶K توکن داره، ولی بعد از حدود ۳۰ دقیقه کار یا session طولانی، مدل شروع می‌کنه به فراموش کردن جزئیاتی که اول گفتی. کار رو انجام می‌ده، ولی اون constraint خاصی که گذاشتی یا اون قالب که مشخص کردی ممکنه رعایت نشه. این همون مشکلیه که توی خیلی از مدل‌ها با context window بلند وجود داره: داشتن یه window بزرگ با attention یکنواخت روی همه‌ی اون window فرق داره.

پس برای task های کوتاه‌تر — ترجمه، تحلیل متن، دستورات مشخص — عالیه. برای agentic task های طولانی‌مدت که ساعت‌ها طول می‌کشه، باید حواست باشه.

چی خوبه

استدلال و کدنویسی: توی benchmark هایی مثل AIME، نسخه‌های V2.5 نمره‌هایی می‌گیرن که با مدل‌های top رقیبه. جامعه‌ی LocalLLaMA و Artificial Analysis هر دو از این مدل‌ها توی رتبه‌بندی‌های agentic بالا می‌آورن. کدنویسی، شبیه‌سازی وب، و multi-step task ها جایی‌ان که MiMo معمولاً خوب عمل می‌کنه.

سرعت: نسخه‌های UltraSpeed به بیش از هزار توکن در ثانیه می‌رسن و بعضی تست‌ها سه هزار توکن در ثانیه رو هم گزارش کردن. برای agentic loop هایی که زمان پاسخ مهمه، این عدد فرق محسوسی می‌کنه.

ارزش: نسخه‌ی non-Pro از نظر هزینه خیلی رقابتیه. Artificial Analysis اون رو با Intelligence Index حدود ۴۹ رتبه‌بندی می‌کنه — که در همون محدوده‌ی مدل‌های proprietary گران‌تره، با قیمت خیلی کمتر. کاربرهای زیادی از Reddit و LocalLLaMA از اون به‌عنوان «بهترین ارزش الان» یاد می‌کنن.

Wayland در برابر X11: چرا همه دارن مهاجرت می‌کنن و آیا واقعاً ارزشش رو داره؟

یه حقیقت ساده از همون اول: اگه شش ماه پیش لینوکس نصب کردی روی یه ماشین معمولی، احتمالاً الان روی Wayland هستی — حتی اگه ندونی. Fedora 40+، Ubuntu 24.04+، Arch، GNOME 49، و KDE Plasma 6 همه به‌صورت پیش‌فرض به Wayland رفتن. این دیگه یه بحث «آینده‌ی Linux» نیست. این وضعیت الان هست.

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

X11 چه مشکلی داشت

X11 در ۱۹۸۴ طراحی شد — و معماریش دقیقاً همون‌قدر که از اون زمان انتظار داری، قدیمیه.

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

اوایل ۲۰۲۵ سه آسیب‌پذیری بحرانی (CVE-2025-62229، CVE-2025-62230، CVE-2025-62231) توی X.Org پیدا شد — باگ‌هایی که بعضی‌هاشون از بیست سال پیش توی کد بودن. اینا isolated incident نبودن؛ نشونه‌ی یه codebase چهل‌ساله‌ان که maintenance-only شده. هیچ توسعه‌ی فعالی روی X.Org اتفاق نمی‌افته — فقط security patch.

مشکل معماری دیگه‌ای هم وجود داره: رندرینگ کند. هر frame باید از برنامه به X server و بعد به compositor بره — این double-buffering بی‌دلیل توی hardware مدرن کاملاً غیرضروریه و توی بعضی حالت‌ها باعث tearing می‌شه.

Wayland چطور متفاوته

Wayland یه «سرور» مرکزی نداره. هر اپلیکیشن مستقیم به یه off-screen buffer رندر می‌کنه، و compositor مستقیم با driver کار می‌کنه تا frame نهایی رو به مانیتور بفرسته. واسطه نیست.

نتیجه‌های عملی این معماری:

امنیت: هر اپلیکیشن فقط ورودی‌های خودش رو می‌بینه. keylogger نوشتن روی Wayland از طریق protocol عملاً غیرممکنه. البته XWayland — که X11 appها رو روی Wayland اجرا می‌کنه — همچنان این ایزوله‌سازی رو نداره، ولی native Wayland appها ندارن.

رندر تمیزتر: چون compositor مستقیم با GPU کار می‌کنه، screen tearing توی حالت‌های معمولی اتفاق نمی‌افته. توی سیستم‌های با refresh rate بالا یا HiDPI این فرق محسوسه.

Hermes Agent: یک agent رایگان که میتونه کارای جالبی انجام بده

یه اعتراف صادقانه قبل از شروع: آنچه روی کاغذ درباره‌ی Hermes Agent نوشته شده — که «به‌طور خودکار یاد می‌گیره» — دقیقاً اون‌طوری که ادعا می‌شه کار نمی‌کنه. skill document می‌سازه، ولی به اون شکل خودکار و بی‌دردسری که تبلیغش می‌شه نیست. این رو از تجربه‌ی مستقیم می‌گم، نه از بنچمارک.

ولی اگه این انتظار رو کنار بذاری و بفهمی که Hermes واقعاً چی هست، یکی از بهترین agentهای open-source ای خواهد بود که امتحان کردی.

واقعیت: چقدر prompting می‌خواد

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

این یعنی Hermes «agent برای همه» نیست. agent‌ای است که با یه اپراتور حواس‌جمع، خوب کار می‌کنه.

ترکیب با 9Router: چرا مهمه

جذاب‌ترین بخش ماجرا اینجاست: Hermes با هر OpenAI-compatible endpoint ای کار می‌کنه. یعنی می‌تونی 9Router رو جلوش بذاری و از مدل‌های رایگان یا ارزون استفاده کنی — و Hermes همون کاری رو می‌کنه که با Claude یا GPT-4 انجام می‌داد.

عملاً می‌شه از agentی استفاده کرد که performance‌اش به agentهای گرون نزدیکه، با هزینه‌ای که نزدیک به صفره. این ترکیب رو امتحان کردم و کار می‌کنه.

skill ها: چیزی که واقعاً ارزش داره

یه چیز که در عمل خیلی کاربرد داشت، سیستم skill هست — نه اون چیزی که agent خودش می‌سازه، بلکه skill هایی که خودت با Claude می‌سازی و بهش می‌دی. می‌تونی یه workflow پیچیده رو یه بار به‌درستی توصیف کنی، بذاریش توی یه skill، و بعد هر بار که Hermes به اون task می‌رسه، از همون توصیف استفاده کنه. این‌طوری دیگه لازم نیست هر بار از اول توضیح بدی.

چیزی که کشف کردم: sudo ندید

یه هشدار جدی: دسترسی sudo بهش ندید.

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

9Router: وقتی rate limit دیگه نمی‌تونه جلوی کار کردن رو بگیره

یه اتفاق آشناست: وسط یه session طولانی با Claude Code یا Codex، یه پیام می‌بینی که quota تموم شده. نه اینکه کارت تموم شده — quota تموم شده. بعد یا باید صبر کنی تا reset بشه، یا دستی بری سراغ یه provider دیگه، یا tool رو ببندی و بری سراغ یه API key دیگه.

9Router برای همین مشکل ساخته شده. یه gateway محلی که بین ابزار AI تو و بیش از ۶۰ provider قرار می‌گیره، و وقتی یه provider به سقف رسید، خودکار به یه جایگزین می‌ره — بدون اینکه لازم باشه چیزی بزنی یا session رو قطع کنی.

ایده‌ی اصلی: سه tier، یه fallback خودکار

9Router روی یه مدل routing سه‌لایه کار می‌کنه:

Tier 1 — Subscription: اشتراک‌هایی که از قبل داری. Claude Code، OpenAI Codex، GitHub Copilot، Cursor. اگه اشتراک داری، 9Router اول از اینها استفاده می‌کنه.

Tier 2 — Cheap: مدل‌هایی که API key می‌خوان ولی ارزونن. GLM به ازای هر میلیون توکن ۰.۶۰ دلار، MiniMax M2.7 به ازای هر میلیون توکن ۰.۲۰ دلار، Kimi با ۹ دلار در ماه. وقتی Tier 1 تموم شد، اینجا میاد.

Tier 3 — FREE: iFlow، Qwen، Kiro، OpenCode. کاملاً رایگان و بدون محدودیت ثابت. آخرین سنگر.

وقتی quota یه provider در Tier 1 تموم می‌شه، 9Router خودکار به Tier 2 می‌ره. وقتی Tier 2 هم تموم شد، به Tier 3 می‌ره. از نظر tool تو — Cursor، Cline، Claude Code — هیچ اتفاقی نیفتاده. همون endpoint جواب می‌ده.

نصب و راه‌اندازی

npm install -g 9router
9router

همین. یه dashboard محلی باز می‌شه که می‌تونی providerها رو اضافه کنی — OAuth برای اشتراک‌ها، API key برای بقیه. بعد هر tool ای که داری رو به این endpoint اشاره بده:

http://localhost:20128/v1

زبان برنامه‌نویسی Verse, انقلاب در توسعه متاورس و بازی‌سازی؟

دنیای بازی‌سازی و اینترنت سه‌بعدی (متاورس) با سرعتی سرسام‌آور در حال حرکت است. تا پیش از این، توسعه‌دهندگان بازی‌ها مجبور بودند میان زبان‌های پیچیده و سطح پایینی مثل C++ (برای کارایی بالا) یا ابزارهای اسکریپت‌نویسی بصری و محدود، دست به انتخاب بزنند. اما کمپانی اپیک گیمز (Epic Games) با معرفی ابزار Unreal Editor for Fortnite (UEFN) از یک برگ برنده رونمایی کرد: زبان برنامه‌نویسی ورس (Verse).

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

زبان Verse چیست و چرا متولد شد؟

زبان Verse یک زبان برنامه‌نویسی چندپارادایمی (Multi-Paradigm) است که ویژگی‌های برنامه‌نویسی تابعی (Functional)، منطقی (Logic) و امری (Imperative) را به شکلی نوآورانه با هم ترکیب کرده است. اپیک گیمز این زبان را با سه اصل بنیادی طراحی کرده است:

فقط کد است (It's just code): پیچیده‌ترین مفاهیم بازی و شبیه‌سازی، در قالب ساختارهای اولیه و خوانای متنی بیان می‌شوند.
یک زبان برای همه چیز (Just one language): ساختارهای یکسانی برای زمان کامپایل (Compile-time) و زمان اجرا (Run-time) استفاده می‌شود.
اول متاورس (Metaverse first): این زبان از پایه برای یک محیط شبیه‌سازی جهانی، توزیع‌شده و زنده طراحی شده است؛ جایی که کدهای نوشته شده باید سال‌ها بدون مشکل و با حفظ سازگاری عقب‌رو (Backward Compatibility) اجرا شوند.

Claude Fable 5 و Claude Mythos 5 منتشر شدند - قدرتمندترین مدل‌های جدید Anthropic

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

این دقیقاً همان اتفاقی است که برای خانواده Claude Mythos افتاد.

در ۹ ژوئن ۲۰۲۶، Anthropic از دو مدل جدید به نام‌های Claude Fable 5 و Claude Mythos 5 رونمایی کرد. این معرفی، اوج یک فرآیند چند ماهه بود که از آوریل همان سال آغاز شده بود — زمانی که Anthropic برای اولین بار ثابت کرد مدل‌های هوش مصنوعی می‌توانند به مرزهایی برسند که انتشار بی‌قید و شرط آن‌ها دیگر گزینه‌ای مطمئن نیست.

در این مقاله، با تکیه بر اعلامیه رسمی Anthropic، تمام جوانب این دو مدل را بررسی می‌کنیم.

پیش‌زمینه: داستان Mythos Preview

برای درک Fable 5 و Mythos 5، باید به آوریل ۲۰۲۶ برگردیم.

در آن ماه، Anthropic اولین مدل از خانواده Mythos-class خود را با نام Claude Mythos Preview معرفی کرد. اما برخلاف تمام مدل‌های قبلی، این مدل به صورت عمومی منتشر نشد. دلیل آن چیز غیرمنتظره‌ای بود: Mythos Preview توانسته بود آسیب‌پذیری‌هایی در سیستم‌عامل‌ها و مرورگرهای اصلی شناسایی کند — بدون اینکه اصلاً برای این هدف طراحی شده باشد.

به بیان دیگر، این مدل توانایی‌هایی داشت که در دست افراد نادرست می‌توانست به ابزاری خطرناک تبدیل شود.

Anthropic در پاسخ به این وضعیت، پروژه‌ای به نام Project Glasswing راه‌اندازی کرد: یک برنامه همکاری کنترل‌شده با سازمان‌های منتخب، از جمله Apple، Google، Amazon، Microsoft، Cisco، JPMorgan Chase و دولت ایالات متحده. هدف این پروژه استفاده از توانایی‌های Mythos برای تقویت امنیت زیرساخت‌های حیاتی بود — نه بهره‌برداری از آن برای حمله.

چند هفته بعد، Anthropic دسترسی را به حدود ۱۵۰ سازمان در بیش از پانزده کشور گسترش داد. و حالا، با معرفی Fable 5، برای اولین بار این فناوری در اختیار عموم قرار گرفته است.

Claude Fable 5 چیست؟

Claude Fable 5 اولین مدل Mythos-class است که برای همه کاربران در دسترس قرار گرفته. Anthropic درباره آن صریح است: «توانایی‌های Fable 5 از هر مدلی که تا به حال به صورت عمومی عرضه کرده‌ایم فراتر می‌رود.»

Dreaming در ChatGPT چیست؟ انقلاب جدید OpenAI در حافظه هوش مصنوعی

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

در این مقاله بررسی می‌کنیم که Dreaming چیست، چگونه کار می‌کند، چه تفاوتی با سیستم حافظه قبلی ChatGPT دارد و چرا می‌تواند آینده دستیارهای هوش مصنوعی را متحول کند.

Dreaming چیست؟

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

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

چرا سیستم حافظه قبلی کافی نبود؟

حافظه اولیه ChatGPT در سال 2024 معرفی شد و عملکردی شبیه به یک دفترچه یادداشت داشت. برای مثال اگر به ChatGPT می‌گفتید:

«یادم باشد ماه آینده به سنگاپور سفر می‌کنم.»

این موضوع ذخیره می‌شد و در گفتگوهای آینده قابل استفاده بود.

اما این روش چند مشکل اساسی داشت:

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

Dreaming چگونه کار می‌کند؟

برخلاف سیستم قدیمی، Dreaming صرفاً اطلاعات را ذخیره نمی‌کند؛ بلکه آن‌ها را به صورت مداوم بازبینی، خلاصه‌سازی و بازسازی می‌کند.

OpenAI توضیح می‌دهد که این سیستم از یک فرآیند پس‌زمینه برای ترکیب اطلاعات به دست آمده از گفتگوهای مختلف استفاده می‌کند تا یک حافظه یکپارچه و به‌روز از هر کاربر بسازد.

Claude Opus 4.8: خوب است یا نه؟ بررسی صادقانه از نگاه کاربران

بررسی نظرات کاربران X، لینکدین و فضای توسعه نرم‌افزار – ژوئن ۲۰۲۶

آنتروپیک در ۲۸ می ۲۰۲۶، تنها ۴۱ روز پس از انتشار Opus 4.7، نسخه جدید Claude Opus 4.8 را معرفی کرد. سرعت بالای این به‌روزرسانی باعث شد بسیاری از کاربران بپرسند: آیا این فقط یک آپدیت جزئی است یا واقعاً ارزش ارتقا دارد؟

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

دسته اول: نظر توسعه‌دهندگان و برنامه‌نویسان

اگر بازخوردهای منتشرشده در X، لینکدین، Reddit و انجمن‌های تخصصی را بررسی کنیم، یک الگوی مشخص دیده می‌شود: اکثر توسعه‌دهندگان از Opus 4.8 رضایت دارند، اما تقریباً هیچ‌کس آن را یک انقلاب بزرگ نمی‌داند.

نقاط قوتی که بیشتر توسعه‌دهندگان به آن اشاره کرده‌اند

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

یکی از مهم‌ترین تغییرات این نسخه این است که مدل کمتر از گذشته خطاهای خودش را پنهان می‌کند. آنتروپیک ادعا می‌کند Opus 4.8 حدود چهار برابر کمتر از نسخه قبلی اشکالات کد تولیدشده را بدون هشدار رها می‌کند. بسیاری از کاربران اولیه نیز این موضوع را تأیید کرده‌اند.

دن شیپر، نویسنده و فعال حوزه AI، Opus 4.8 را بهترین مدلی توصیف کرده که تاکنون برای کدنویسی و کارهای تخصصی استفاده کرده است و معتقد است تفاوت آن با 4.7 بیشتر از چیزی است که شماره نسخه نشان می‌دهد.

کاتی پارات، توسعه‌دهنده نرم‌افزار، نیز گفته پس از ناامیدی از Opus 4.7، این نسخه دوباره اعتماد او را به Claude برگردانده است.

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

بررسی سیستم عامل linux - لینوکس از صفر تا بینهایت

زمان مطالعه: حدود ۵ دقیقه

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

لینوکس یکی از این سیستم‌عامل‌هاست که مثل یک دوست قابل اعتماد، قدرتمند و انعطاف‌پذیر عمل می‌کند.

اما لینوکس دقیقاً چیست، از کجا آمده و به چه دردی می‌خورد؟ در این مقاله به زبان ساده به این سؤالات پاسخ می‌دهیم.

لینوکس چیست؟

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

اما چیزی که لینوکس را خاص می‌کند، این است که متن‌باز (Open Source) است. یعنی کدهایش برای همه در دسترس است و هرکسی می‌تواند آن را تغییر دهد، بهبود بدهد یا حتی نسخه خودش را بسازد. مثل این است که دستور پخت یک غذا را داشته باشید و بتوانید آن را به سلیقه خودتان تغییر دهید!

از کجا آمده؟

داستان لینوکس از سال ۱۹۹۱ شروع شد. یک دانشجوی فنلاندی به نام لینوس توروالدز تصمیم گرفت یک سیستم‌عامل رایگان و قابل تغییر بسازد. او هسته اولیه لینوکس (که به آن کرنل می‌گویند) را نوشت. این هسته مثل قلب سیستم‌عامل است که با سخت‌افزار ارتباط برقرار می‌کند.

لینوکس از یک پروژه دیگر به نام یونیکس الهام گرفته بود. یونیکس یک سیستم‌عامل قدرتمند بود که در دهه ۱۹۷۰ برای کامپیوترهای بزرگ ساخته شده بود، اما گران و محدود بود. لینوکس آمد تا شبیه یونیکس باشد، اما رایگان و برای همه در دسترس.

با کمک برنامه‌نویس‌های داوطلب از سراسر دنیا، لینوکس کم‌کم بهتر شد و به چیزی تبدیل شد که امروز می‌بینیم. شرکت‌ها و افراد زیادی نسخه‌های مختلف لینوکس را ساختند که به آن‌ها توزیع (Distribution) می‌گویند، مثل اوبونتو، فدورا یا دبیان.

به چه دردی می‌خورد؟

لینوکس مثل یک ابزار همه‌کاره است که در جاهای مختلف استفاده می‌شود. بیایید چند کاربرد اصلی‌اش را ببینیم:

رایانه‌های شخصی: اگر دوست دارید سیستمی سبک، امن و رایگان داشته باشید، می‌توانید لینوکس را روی لپ‌تاپ یا کامپیوترتان نصب کنید. مثلاً اوبونتو برای کاربران معمولی خیلی ساده و کاربرپسند است.