بار اولین بار که این توقف آشنا توجه من را جلب کرد، هنگامی بود که از فرمان **sort** برای پردازش چند صد مگابایت متن لاگ استفاده میکردم. تا آن زمان همیشه آن را نادیده میگرفتم. این مورد زمانی ظاهر میشود که از **du -sh** برای کاوش دایرکتوریهای پروژه یا **ls -la** در پوشههای پر از artefacts ساخت استفاده میکنم.
بار اول که این مکث آشنا توجه من را جلب کرد، هنگامی بود که از فرمان sort برای مرور چند صد مگابایت متن لاگ استفاده میکردم. تا آن زمان همیشه آن را نادیده میگرفتم. این مکث هنگام استفاده از du -sh برای مرور پوشههای پروژه یا ls -la در پوشههای پر از artefactهای ساخت ظاهر میشود.
GNU coreutils در لینوکس به پایهایترین ابزارها شباهت دارد و غیرقابل تغییر به نظر میرسند. اما به محض اینکه دریافت کردم «قابلیت اطمینان» همیشه به معنای بهینه بودن نیست، بهویژه روی سختافزارهای مدرن، فهمیدم زمان امتحان چیزی متفاوت رسیده است. بنابراین، uutils، بازنویسی Rust از GNU coreutils، گزینه بعدی من شد. من با جابجایی یک فرمان، سپس فرمان دیگری، شروع کردم و غالباً uutils سریعتر بود. اگر زمان قابل توجهی را در ترمینال میگذرانید، اینها ارزش امتحان دارند.
اصطافی که دیگر متوجه آن نمیشدید، بهظاهر در نگاه اول مخفی بود
«بهاندازه کافی سریع» تنها زمانی احساس سرعت میکند که آن را با چیز دیگری مقایسه کنید
اگر بهدلیل اینکه چیزی طبیعی بهنظر میرسد، بهدقت توجه نکنید، ممکن است فرض کنید محدودیتهای آن عادی هستند. به همین دلیل همیشه آن مکثی که هنگام لیستکردن یک پوشه بزرگ پیش از چاپ رخ میدهد، را نادیده میگرفتم. تاخیری که هنگام مرتبکردن لاگها در حین دیباگ دریافت میکنید میتواند جریان کار شما را مختل کند. احتمالا آن را به ورودی/خروجی دیسک نسبت میدهید.
در دستگاههای مدرن، مشاهده که این فرضیات چقدر قدیمی شدهاند، آسانتر است. این ماشینها دارای درایوهای NVMe فوقالعاده سریع هستند و هستههای CPU معمولاً توسط ابزارهای کاربری متوسط بهدرستی استفاده نمیشوند. با این حال، به دلیل استفاده همچنان از چندین ابزار که از دوران سختافزاری متفاوتی میآیند، آنها تکنخی و محافظهکارند. بیشتر محدودیتهایی که آنها بر پایه آن ساخته شدند، دیگر صادق نیستند.
هیچکس coreutils را benchmark یا زیر سؤال نمیبرد چون همیشه کار میکنند. در واقع، وقتی به بهرهوری بالاتر میخواهیم، ترجیح میدهیم پرامپتهایمان را تنظیم کنیم و هسته را بهدست بزنیم. اما مقایسه خروجی بهصورت کنار هم نشان داد که مشکل از ابزار بود.
چه اتفاقی میافتد وقتی ابزارهای پایهای برای سختافزار مدرن بازنویسی میشوند
چگونه uutils/coreutils تحت بار متفاوت رفتار میکند
با چند سال تلاش و صدها مشارکتکننده، uutils در تلاش است تا تقریباً سازگاری کامل با GNU را فراهم کند. این ابزارها را در Rust بازسازی میکند و توزیعهای جدیدی مانند Ubuntu 25.10 اکنون بهصورت پیشفرض آن را همراه دارند.
اولین فرمانی که واقعاً توجه من را جلب کرد sort بود. بر روی یک فایل لاگ چند صد مگابایتی، GNU sort ۲٫۸۱۹ ثانیه زمان واقعی (۱۰٫۲۰۴ ثانیه زمان CPU کاربر) صرف کرد، در حالی که پیادهسازی Rust همین کار را در ۰٫۰۹۲ ثانیه زمان واقعی انجام داد. فرمان wc نیز در مقایسه با چند لاگ بزرگ، احساس سرعت بیشتری داشت. کپیبرداری دستهایی از فایلهای کوچک بسیاری نشان داد که اختلاف سرعت کافی برای تشخیص وجود دارد. همه فرمانها که امتحان کردم سریعتر نبودند، اما به اندازه کافی یافتۀ مناسب بود تا ادامه دهم آنها را جایگزین کنم.
پاسخگویی سریع، نکته برجسته بود. این اولین بار بود که فرمانها بهنظر میرسید همانگاه که انتظار داشتم تمام میشوند. این تفاوت در حین دیباگ، بهویژه وقتی که بهسرعت تکرار میکنید یا ابزارها را در خطوط لوله زنجیرهای میکشید، اهمیت زیادی دارد.
برخی ابزارها عملکرد برابر داشتند و چند مورد خاص بهتر با بهینهسازیهای بالغ GNU سازگار بودند. اما تفاوت این است که پیادهسازیهای Rust احساس میشوند که بیشتر برای سختافزارهای چند هستهای مدرن مناسبند.
تفاوت ایمنی و سازگاری هنگام فشار دادن به آن ظاهر میشود
چرا یک بازنویسی مدرن بیش از سرعت، تغییرات دیگری ایجاد میکند
اگرچه سرعت را دوست داشتم، چیزی که من را به استفاده از این ابزارها نگه میداشت سازگاری بود. مدل ایمنی حافظه Rust از تمام دستههای باگی که در ابزارهای مبتنی بر C رایج هستند — overflow بافر، استفاده پس از آزادسازی، ارجاع به اشارهگر تهی — جلوگیری میکند بدون اینکه نیاز به محافظهای دستی داشته باشد. حتی اگر مستقیماً اینها را نمیبینید، قابلیت پیشبینی یک عنصر اساسی است اگر ورودیهای حجیم به ابزار خط فرمان بدهید.
من عموماً رفتار پاکتری را تجربه میکردم، شامل خطاهای صریح و شکستهای پیشبینیپذیر در مجموعهدادههای بزرگ، متنهای خراب یا الگوهای ورودی غیرمعمول. برای مثال، انتقال متن UTF-8 خراب به uu-cut بلافاصله خطای صریحی را نشان داد، در حالی که GNU cut خروجی غیرمنتظرهای تولید کرد. این به این معنی نیست که GNU coreutils ناپایدار هستند، اما داشتن ابزارهای پایهای ساختهشده با تضمینهای ایمنی مدرن از ابتدا، حتی دلگرمکنندهتر است.
Uutils همچنین یک فرهنگ تست پیشرفته دارد که شامل یکپارچهسازی مستمر در تمام مجموعه ابزارهایش است. این عامل مهمی است که به اعتماد تبدیل میشود اگر به شدت به اسکریپتها و خودکارسازی وابسته باشید.
جایگزینی ابزارهای اصلی سیستم بهنظر خطرناک میآید — اما اینگونه نیست
چگونه uutils را بهصورت ایمن تست کنیم بدون اینکه به سیستم پایه خود دست بزنیم
GNU coreutils احساسی شبیه یکی از اجزای لینوکس که اکنون جایگزینهای مدرن بهتری دارند، دارد. ممکن است فکر کنید جایگزینی آن خطرناک است، اما این فقط به این دلیل است که قابلیت بازگردانی آن را نمیفهمید. وقتی uutils نصب میشود، هیچچیزی بازنویسی نمیشود زیرا بهصورت پیشفرض با پیشوند uu- نصب میشود. بهعنوان مثال، شما uu-sort و uu-ls دارید. میتوانید هر دو نسخه را کنار هم مقایسه کنید. این نوعی تست A/B برای فرمانهاست.
برای راهنماییهای عملی درباره coreutils مدرن مشترک شوید
میتوانید حتی یک گام جلوتر بروید و PATH خود را بهصورت موقت تنظیم کنید. به این ترتیب، نیازی به حذف هیچیک از فایلهای GNU قبل از الویت دادن به باینریهای Rust ندارید. با بازگرداندن PATH به حالت قبلی، به تنظیمات اصلی برمیگردید.
یک خلأ کوچک سازگاری با uutils وجود دارد، اما این عمدتاً به ترکیبهای نامعمول پرچمها مربوط میشود. گاهی اوقات ممکن است بهدلیل رفتارهای قدیمی POSIX باشد که بهطور معمول فعال نمیکنید. اگر یک ایستگاه کاری شخصی دارید، میتوانید به‑راحتی هر تغییری را بازگردانید و آزمایش خطر کمی دارد.
دستوراتى که هرگز سؤال نکردید، لیاقت نگاهی دوباره را دارند
من فکر نمیکنم همه بلافاصله GNU را جایگزین کنند. اما نکته مهمتر این است که این لایه از لینوکس که هرگز سؤال نمیکنیم یخ زده نیست. هیچکدام از دستوراتى که روزانه استفاده میکنید مقدس نیستند. واقعیت این است که با تعویض آنها ممکن است چند دقیقه در روز صرفهجویی کنید و بهرهوری بیشتری داشته باشید.
نه لینوکس، نه ویندوز. چیزی بهتر.