💢 فیش ورژن 4 و تغییر Keybind های دیفالت

توی fish shell از ورژن 4 به بعد، اومدن bind های پیش‌فرض رو عوض کردن و ماسل مموری کاربرای قدیمی رو به چالش کشیدن. مثال تفاوت alt+backspace بین ورژن 3 و 4:

🔹Version 3

curl https://wttr.in/Tehran  # before
curl https://wttr.in/        # after

🔸Version 4

curl https://wttr.in/Tehran  # before
curl                         # after

توی ورژن 3 کلمه پاک میشه ورژن 4 توکن.

🛠 راه حل

اگه مثل من به ورژن 3 عادت دارید، برای برگشتن به رفتار قدیمی فایل fish_user_key_bindings.fish رو توی مسیر زیر بسازید:

~/.config/fish/functions/

و کد زیر رو داخلش paste کنید:

function fish_user_key_bindings
    bind alt-left       prevd-or-backward-word
    bind alt-right      nextd-or-forward-word
    bind alt-backspace  backward-kill-word
    bind alt-delete     kill-word

    bind ctrl-left      backward-token
    bind ctrl-right     forward-token
    bind ctrl-backspace backward-kill-token
    bind ctrl-delete    kill-token
    bind ctrl-alt-h     backward-kill-word
end

اسم فایل و فانکشن نه تنها باید با هم یکی باشن، بلکه باید دقیقا همین اسم باشن — چون fish_user_key_bindings یه هوک هاردکد‌شده fish هست که بعد از لود شدن bind های پیش‌فرض صدا زده میشه.

پ.ن: فیش یه مکانیزم autoload داره که هر فایلی توی
~/.config/fish/functions/
قرار بگیره به عنوان یه فانکشن مستقل لود میشه.

🔗 Issue 10926

🔘 @TerminalNotes <- #linux #fish

📌 #Tool: eBPF

اگه دواپس کار میکنید احتمالا اسم eBPF رو شنیدید. یه تکنولوژی که خیلی‌ها از شرکت‌ها مثل نتفلیکس و فیسبوک بهش وابسته‌ان.

تا قبل از eBPF، اگر می‌خواستید بدونید "دقیقا" توی سیستم‌عامل چه خبره، یا می‌خواستید روی ترافیک شبکه کنترل داشته باشید (مثل فیلتر کردن پکت‌ها یا load balancing سفارشی)، دو راه داشتید:

۱. تغییر سورس کرنل: که خب زمان بره.
۲. ماژول‌های کرنل: که دسترسی کامل داشتن، ولی یه باگ کوچیک توشون کافی بود تا همه چیز بیاد پایین.

🧭 راه حل مدرن: eBPF

خیلی ساده، eBPF یه ماشین مجازی (Virtual Machine) کوچیک و امنه که داخل خودِ کرنل لینوکس زندگی می‌کنه.
شما می‌تونید برنامه بنویسید، اون‌ها رو به کرنل تزریق کنید و کرنل اون‌ها رو اجرا کنه. اما با این مزیت که:

🔹 امنیت تضمین شده: قبل از اجرا، یه بخشی به اسم Verifier کد شما رو چک می‌کنه تا مطمئن شه لوپ بی‌نهایت نداره یا به حافظه غیرمجاز دسترسی پیدا نمی‌کنه.
🔹 بدون توقف: برای اجرای این برنامه‌ها نیازی به ریستارت کردن سیستم یا کامپایل دوباره کرنل نیست.
🔹 سرعت بالا: کدها به صورت JIT (Just-In-Time) کامپایل می‌شن و با سرعت Native اجرا می‌شن.

این تکنولوژی نیروی محرکه نسل بعدی ابزارهای شبکه و نظارت (Observability) هست.

⚖️ کاربردش کجاست

تقریبا هر جایی که نیاز به سرعت و دید عمیق هست:

• مانیتورینگ و Observability: ابزارهایی که نشون میدن کدوم پروسس داره چه فایل‌هایی رو باز می‌کنه یا چه پکت‌هایی رو می‌فرسته (بدون سربار ابزارهای قدیمی).
• شبکه: فیلتر کردن و مدیریت ترافیک.

🛑 البته قدرت همیشه درست به کار نمیره. این ابزار قابلیت DPI هم داره که سانسورچی توی ایران ازش برای بلاک کردن و کنترل ترافیک مردم استفاده میکنه.

شرکت هایی که ازش استفاده میکنن و چطور رو میتونید اینجا از سایت رسمی ببینید.

💠 جمع‌بندی

امروزه کار با eBPF با وجود زبونایی مثل Go و پایتون و کتابخونه‌های جدید راحت شده و نوشتن ابزارهایی که مستقیم با کرنل حرف می‌زنن خیلی ساده‌تر شده.

یه پروژه قدیمی با Go پیدا کردم که ساده پراسس های سیستم رو لایو مانیتور میکنه. چون قدیمیه یکم ریفکتورش کردم و پست های بعدی میذارمش میتونید چک کنید و ابزار خودتون رو بنویسید.

قبلش برای درک برنامه لازمه چندتا مفهوم لینوکسی مثل یوزر اسپیس و کرنل اسپیس توضیح داده بشه که پست بعد می‌نویسم.

🔘 @TerminalNotes <- #linux #ebpf

📌 #Concept: Kernel Space & Userspace

یه رستوران بزرگ رو تصور کنید:

• مشتری (برنامه‌ها): شما که توی سالن رستوران نشستید و می‌خواید غذا سفارش بدید. مشتری‌ها اجازه ندارن وارد آشپزخانه بشن یا دست به وسایل آشپزخونه بزنن.
• گارسون (System Calls): واسطه بین شما و آشپزخونه هست. منو رو جلوتون میذاره و سفارشتون رو به آشپزخونه میبره.
• آشپز و آشپزخونه (Kernel): قلب اصلی رستوران که دسترسی کامل به همه امکانات داره، غذا میپزه، و کارهای مهم رو انجام میده.

به همین ترتیب Kernel space و userspace از هم جدا میشن و از طریق یه راه ارتباطی ایمن که syscall باشه با هم دیگه ارتباط میگیرن.

💢 چرا این جداسازی؟

1. امنیت

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

2. پایداری

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

🔆 نحوه سفارش تا تحویل با System Calls

1. انتخاب غذا: شما از منو (API سیستم عامل) چیزی مثل "پیتزا" انتخاب می‌کنید. برای مثال برنامه میخواد یه فایل رو باز کنه.
2. گارسون سفارش رو میبره: فراخوانی سیستمی (syscall) مثل ()open شروع به کار میکنه و یه وقفه نرم‌افزاری ایجاد میکنه که CPU رو از حالت User به حالت Kernel تغییر میده.
3. آشپز سفارش رو آماده میکنه: کرنل با دسترسی کامل به منابع سیستم، درخواست رو پردازش می‌کنه، فایل رو باز می‌کنه، دیتا رو میخونه یا تو دیسک می‌نویسه.
4. غذا سرو میشه: نتیجه به برنامه برمیگرده و CPU دوباره به حالت User برمیگرده.

خلاصه که نمیتونید داد بزنید "آشپز! پیتزا بده!". باید از طریق گارسون (syscall) سفارش بدهید.

❇️ مزایای این معماری و جمع بندی

این طراحی باعث می‌شه:
• هر برنامه در فضای امن خودش کار کنه و نتونه کار دیگران رو خراب کنه.
• اگه یه برنامه مشکل پیدا کرد، کل سیستم از کار نیوفته.
• منابع حیاتی سیستم (مثل دیسک، CPU و غیره) تحت کنترل کامل کرنل باشن.

🔘 @TerminalNotes <- #linux

قدیم WMهای مبتنی بر X مثل Lego بودن و باید اجزای مختلف جداگونه انتخاب و سرهم میشد؛ مثال:

• Compositor
• Bar
• Notification daemon
• Wallpaper manager
• Application launcher
• Clipboard manager
• Session management (e.g. lock screen)
و غیره.

توی Wayland، به‌خاطر طراحی پروتکل، کمپوزیتور باید مسئولیت window management رو هم به عهده بگیره. علاوه بر این، ابزارهای جدیدی به اسم Desktop Shell بیشتر مطرح شدن که مجموعه‌ای از موارد بالا (نوار، اعلان‌ها، لانچر و موارد مشابه) رو یکجا ارائه میدن و نیاز به سرهم‌کردن جز به‌ جز رو کمتر می‌کنن. دوتا از خوباش در حال حاضر DMS و Noctalia هستن.

سرجمع، WM زدن این روزا خیلی راحت شده. مثل قدیم زمان بر نیست دیگه.

🔘 @TerminalNotes <- #linux #wm