تغییر سایز نمایشگر ماوس در GDM

یک چیزی که در برنامه ای که در پست قبلی معرفی کردم نبود، تغییر اندازه کرسر ماوس در GDM بود که متاسفانه توسعه دهنده برنامه این رو لحاظ نکرده. افرادی که از رزولوشن های بالا استفاده میکنن ممکنه کرسر ماوس رو بسیار ریز در GDM ببینن. 

برای اصلاح این مشکل ترمینال رو باز کنید و با دستور su به کاربر root لاگین کنید و سپس با دستور زیر اندازه مورد نظرتون رو اعمال کنید:

sudo -u gdm dbus-launch gsettings set org.gnome.desktop.interface cursor-size 24

البته قبلش میتونید بجای set از get (و حذف سایز در انتهای دستور) استفاده کنید تا ببینید سایزی که الان تنظیم شده چی هستش و بر مبنای اون، سایز مورد نظرتون رو تنظیم کنید.

تغییر تنظیمات GDM به راحتی آب خوردن

قبلا برای تغییر در GDM (لاگین منیجر گنوم) باید کلی سرچ میکردیم و توی گوشه گوشه فروم ها و ویکی ها یکی دو خط کامند پیدا میکردیم و اگه شانس میاوردیم تغییر مورد نظرمون رو به درستی اعمال می کردیم. ولی حالا می تونیم با یک ابزار فوق العاده هر تغییری که بخوایم رو به صورت گرافیکی اعمال کنیم. یک نگاهی به صفحه برنامه بندازیم:

این تغییرات شامل 

• تغییر تم، آیکن ها، فونت، در GDM
• تغییر کرسر ماوس
• بکگراند (رنگ یا تصویر)
• تغییر سرعت حرکت ماوس
• فعال/غیر فعال کردن برخی موارد مثل امکان restart و ...
• ...

برای نصب این برنامه در توزیع های مبتنی بر Arch کافیه پکیج gdm-settings رو از AUR نصب کنید. در مورد توزیع های دیگه هم به صفحه github برنامه مراجعه کنید.

AppImage چیست؟

appimage یک فرمت برای توزیع نرم افزار های قابل حمل در لینوکسه که برای نصب و اجرا نیازی به دسترسی روت نداره.
این فرمت اولین بار در سال ۲۰۰۴ و تحت عنوان klik منتشر شد.توسعه این فرمت ادامه داشت تا در سال ۲۰۱۱ اسمش به PortableLinuxApps و در سال ۲۰۱۳ به appimage تغییر کرد.
appimage تلاش میکنه که شرایط احرا شدن یک برنامه رو بدون نیاز به اجازه ریشه,قابل حمل بودن و تمیز نگه داشتن سیستم عامل پایه فراهم کنه.

ویژگی ها:
با appimage شما میتونید برنامه هارو بدون اینکه نصب کنید اجرا کنید.اینطوری سیستم شما خیلی تمیز تر میمونه.
در واقع appimage یک نسخه فشرده شده از نرم افزاره که توسط FUSE قابلیت اجرایی پیدا میکنه.
برای استفاده از appimage شما نیازی به اجازه روت یا ریشه ندارین که این باعث میشه کاربران بیشتری بتونن از این برنامه استفاده کنن و حتی در مواردی امن تره.
یکی از ویژگی های خوب دیگش قابل حمل بودنشه.که میتونید این فایل رو رو هر حافظه ای مثل فلش همراه خودتون داشته باشین و روی سیستمای لینوکسی ازش استفاده کنید.

تاریخچه:
اولین نسخه appimage که klik نام داشت در سال ۲۰۰۴ توسط سمیون پیتر طراحی شد و تحت لایسنس GPL منتشر شد.klik توسط مرورگر کار میکرد به این صورت که کاربر با وارد کردن یک URL به صورت//:klik نرم افزار رو دریافت و استفاده میکرد.
کاربر با وارد کردن URL یک فایل recipe (دستور العمل ) دانلود میکرد که برای تولید فایل .cmg استفاده میشد. و بعد میتونست از برنامه استفاده کنه.
در حالت کلی هم بسته های .deb ابتدا به فایل .cmg تبدیل میشن .
با استفاده از klik فقط ۸ برنامه به طور همزمان قابل اجرا بود.(به دلیل محدودیت نصب تصاویر فشرده با هسته لینوکس)
نسخه بعدی این برنامه یعنی klik2 در حال توسعه بود اما هرکز به مرحله بتا نرسید.حدودا در ۲۰۱۱ پروژه klik ناپدید شد و صفحه اصلی برای مدتی آفلاین بود.

سیمون پیتر یک پروژه جانشین با نام PortableLinuxApps با اهداف مشابه در آن زمان آغاز کرد. ابن فن آوری به عنوان مثال  با مخزن portablelinuxgames.org هماهنگ شده که صدها بازی ویدیویی با منبع باز را ارائه میده.

در حدود 2013، نرم افزار دوباره از portableLinuxApps به AppImage تغییر نام داد. و تحت لایسنس  MIT منتشر شد.در حال حاضر توسعه این فرمت بر روی گیت هاب انجام میشه.

انجام Hybernate بعد از مدت مشخصی Suspend

ما معمولا در لینوکس سیستم رو suspend میکنیم. خب این کار هزینه داره و از باتری یا برق برای فعال بودن استفاده میکنه. میتونیم در آرچی ها با سرویسی که در ادامه ایجاد میکنیم به سیستم میگیم که اگر بعد از ۲ ساعت suspend کسی resume نکرد، سیستم رو hybernate کن. این طوری مصرف باتری‌مون بهینه تر میشه و منطقی تر هم هست. البته به شرطی که swap داشته باشید.

ابتدا باید سرویس مورد نظرمون رو در systemd بسازیم:

--------------------------------------------------------
sudo gedit /etc/systemd/system/suspend-to-hibernate.service
--------------------------------------------------------

[Unit]
Description=Delayed hibernation trigger
Documentation=https://bbs.archlinux.org/viewtopic.php?pid=1420279#p1420279
Documentation=https://wiki.archlinux.org/index.php/Power_management
Conflicts=hibernate.target hybrid-sleep.target
Before=sleep.target
StopWhenUnneeded=true

[Service]
Type=oneshot
RemainAfterExit=yes
Environment="WAKEALARM=/sys/class/rtc/rtc0/wakealarm"
Environment="SLEEPLENGTH=+2hour"
ExecStart=-/usr/bin/sh -c 'echo -n "alarm set for "; date +%%s -d$SLEEPLENGTH | tee $WAKEALARM'
ExecStop=-/usr/bin/sh -c '\
  alarm=$(cat $WAKEALARM); \
  now=$(date +%%s); \
  if [ -z "$alarm" ] || [ "$now" -ge "$alarm" ]; then \
     echo "hibernate triggered"; \
     systemctl hibernate; \
  else \
     echo "normal wakeup"; \
  fi; \
  echo 0 > $WAKEALARM; \
'

[Install]
WantedBy=sleep.target

و بعد سرویس رو فعال می کنیم:

1. sudo systemctl enable disable-usb-wakeup.service
2. sudo systemctl start disable-usb-wakeup.service

بهبود کارایی لینوکس با I/O scheduler جدید کرنل 4.12

یکی از وظایف اصلی هسته سیستم عامل، مدیریت دستگاه‌های ورودی و خروجی سیستم یا به اصطلاح I/O می‌باشد. برنامه‌های مختلفی که نیاز به دسترسی به دستگاه‌ها ورودی و خروجی دارند درخواست‌های خود را به هسته سیستم عامل ارسال می‌کنند و هسته سیستم عامل با توجه به تعداد درخواست‌هایی که برای دستگاه‌های مختلف وجود دارد، این درخواست‌ها را در صف قرار داده و برای انجام زمانبندی می‌کند. شیوه زمانبندی این درخواست‌ها تاثیر به سزایی در سرعت و پاسخگویی سیستم دارد. معمولا به دلیل کند بودن بعضی از دستگاه‌های ذخیره‌سازی همانند دیسک‌های سخت نسبت به سایر بخش‌های اصلی سیستم همچون CPU و RAM، عملیات I/O به عنوان یکی از دلایل اصلی کند بودن سیستم و پاسخگو (Responsive) نبودن برنامه‌ها می‌باشد.

روش‌ها و الگوریتم‌های مختلفی برای زمانبندی I/O وجود دارد. روش‌هایی که تاکنون در هسته لینوکس برای زمانبندی I/O استفاده می‌شد شامل CFQ، NOOP و Deadline بود. با ظهور دستگاه‌های ذخیره‌سازی جدید که قادر به انجام صدها و هزاران درخواست I/O در ثانیه می‌باشند، نیاز به روش‌های زمانبندی جدید که قادر به استفاده از این پتانسیل عظیم باشد بیش از پیش حس می‌شد. یکی از بهبودهایی که از کرنل نسخه 3.13 وارد هسته لینوکس شد multiqueue block layer بود که منجر به افزایش کارایی سیستم در استفاده از دستگاه‌های ذخیره سازی با کارایی بالا می‌شود. منتها این مکانیزم به خودی خود بدون وجود الگوریتم‌های زمانبندی که از این مکانیزم استفاده کنند فایده چندانی نداشت. ولی سرانجام در کرنل نسخه 4.12 دو زمانبند جدید که از این مکانیزم استفاده می‌کنند وارد هسته لینوکس شد. این الگوریتم‌ها به ترتیب BFQ و Kyber می‌باشند. زمانبند BFQ مکانیزمی است که بیشتر برای استفاده در دیسک‌های سخت HDD استفاده می‌شود که منجر به بهبود زمان تاخیر برنامه‌های تعاملی و بهبود کارایی سیستم می‌شود. الگوریتم Kyber هم بدلیل پیچیدگی کمتر نسبت به BFQ برای دیسک‌های SSD و سریعتر استفاده ‌می‌شود.

به تازگی کرنل 4.12 وارد مخازن آرچ شد و کاربران آرچ امکان استفاده از این مکانیزم‌های جدید رو پیدا کردند. این زمانبند‌ها در حالت عادی فعال نیستند و برای فعال شدن آنها باید کارهای زیر را انجام بدید. توصیه می‌کنم که اگر سیستم شما از HDD استفاده می‌کند از BFQ استفاده کنید و برای SSD ترجیحا از Kyber و یا از روش‌های فعلی موجود استفاده کنید.

در حالت عادی زمانبند CFQ در آرچ استفاده می‌شود که برای دیدن زمانبند مورد استفاده در دیسک مورد نظر خود از دستور زیر استفاده کنید در اینجا دیسک sda رو چک میکنیم:

$ cat /sys/block/sda/queue/scheduler
noop deadline [cfq]

برای استفاده از زمانبندهای چند صفی (multiqueue) ابتدا بایستی پارامترهای scsi_mod.use_blk_mq=1 dm_mod.use_blk_mq=1 را به پارامترهای بوت کرنل اضافه کنیم برای اینکار با فرض استفاده از GRUB به عنوان boot loader مورد استفاده اعمال زیر را انجام دهید:

ابتدا فایل etc/default/grub/ را با ویرایشگر مورد نظر خود باز کرده و پارامترهای گفته شده را به مقادیر موجود در جلوی گزینه GRUB_CMDLINE_LINUX_DEFAULT اضافه کنید یعنی به این صورت:

GRUB_CMDLINE_LINUX_DEFAULT="scsi_mod.use_blk_mq=1 dm_mod.use_blk_mq=1"

سپس با دستور زیر فایل تنظیمات گراب را بروزرسانی کنید:

$ sudo grub-mkconfig -o /boot/grub/grub.cfg

در مرحله بعد برای استفاده از زمانبند BFQ برای تمامی دیسک‌های سیستم یک rule جدید برای udev ایجاد می‌کنیم. به این منظور ابتدا دستور زیر را برای ایجاد rule جدید اجرا کنید:

$ sudo nano /etc/udev/rules.d/10-bfq.rules

سپس محتویات زیر را درون این فایل قرار دهید:

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="bfq"

در مرحله بعد سیستم خود را ریبوت کرده و بعد از بالا آمدن سیستم چک کنید که زمانبند BFQ برای دیسک شما مورد استفاده قرار گرفته باشد:

$ cat /sys/block/sda/queue/scheduler
mq-deadline kyber [bfq] none

همانطور که می‌بینید زمانبند bfq برای دیسک sda سیستم مورد استفاده قرار گرفته است. برای استفاده از Kyber هم به همین شیوه عمل می‌شود منتها در rule ایجاد شده برای udev به جای bfq گزینه kyber رو قرار بدید:

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="kyber"

تنظیم درجه حرارت Gnome Night Light

حتما میدونید که گنوم در نسخه های جدید دارای یک ویژگی خوب شده به نام Gnome Night Light. این همون کار Redshift رو برای ما میکنه که قبلا در موردش نوشته بودم. هدف اینه که با تاریک شدن فضا، درجه رنگ آبی مانیتور کمتر بشه تا چشم ها کمتر خسته بشن و همچنین ریتم خواب شبانه روزی ما کمتر تحت تاثیر نور مانیتور قرار بگیره.
با اومدن این ویژگی به تنظیمات خود گنوم کار بسیار راحت شده و شما فقط کافیه از Displays اون رو روشن کنید و زمانی رو که میخواید فعال بشه تعیین کنید. یعنی حد فاصل بین غروب آفتاب تا طلوع آفتاب روز بعد (که به وسیله ip مشخص میکنه)، و یا اینکه بصورت دستی خودتون مشخص کنید.

اما وقتی این رو فعال میکنید متوجه میشید که صفحه نمایش خیلی زرد میشه! و هیچ چیزی وجود نداره تا درجه حرارت رنگ رو تغییر بدیم و از این زردی زیاد درش بیاریم. خوشبختانه این کار در سطح dconf قابل انجام هست. کافیه شما به مسیر زیر در dconf-editor برید و عدد دلخواهتون رو وارد کنید.

/org/gnome/settings-daemon/plugins/color/night-light-temperature

و این هم معنی این عددها است:

• 1000 — Lowest value (super warm/red)
• 4000 — Default night light on temperature
• 5500 — Balanced night light temperature
• 6500 — Default night light off temperature
• 10000 — Highest value (super cool/blue)

مخازن مانجارو روی سرورهای ایران

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

مخازن مانجارو وجود نداشت، با ایمیلی که بهشون زدم اونها ظرف مدت بسیار کوتاهی پاسخ دادند و مخازن مانجارو هم به این لیست اضافه شد. اینجا چند نکته وجود داره که لازمه بنویسم:

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

اگر شما کاربر مانجارو هستید و میخواید که این رو امتحان کنید، فایل زیر رو باز کنید و سرورهای دیگه رو کامل پاک کنید و سرور ایران رو بهش اضافه کنید. بعد هم دیتابیس رو رفرش کنید:

sudo gedit /etc/pacman.d/mirrorlist
-------------------------------------------
Server = http://repo.sadjad.ac.ir/manjaro/stable/$repo/$arch

sudo pacman -Syy

در خط سرور عبارت stable در توضیحات سایت دانشگاه سجاد branch$ نوشته شده. که میبایست در این فایل تغییر کنه. در غیر این صورت با پیام خطای سینک مواجه میشید. نسخه های دیگه unstable و testing هستتند.

گزارش های سیستم را محدود تر کنیم

لینوکس از راه های مختلفی گزارش های زیادی در مورد نحوه فعالیت سیستم ثبت میکنه. از پروسه بوت گرفته تا همین الان که دارید این متن رو میخونید. این گزارشات در یک جایی از سیستم ذخیره میشن و بعد از مدت مشخصی حذف میشن.
گاهی این نگه داشته شدن اینهمه لاگ (گزارش) چندان ضرورتی نداره و باعث میشه پروسه بوت کمی دچار تاخیر هم بشه. ما میتونیم از طریقی یکی از این گزارش ها رو که توسط journalctl تولید میشن محدود کنیم. این طوری هم منابع کمتری از سیستم صرف تولید و نگه داری این گزارش ها میشه و هم موقع بوت چند ثانیه ای صرف جویی میشه.
قبلش دستور زیر رو بزنید تا زمان بوت رو بهتون بگه:

systemd-analyze

و دستور زیر رو هم بزنید تا جزء به جزء بگه کدوم از سرویس ها چقدر زمان مصرف کردن تا اجرا بشن

systemd-analyze blame

بستگی داره روی سیستمتون چه سرویس هایی نصب داشته باشید. مثلا ممکنه کسی Plymouth (انیمیشن موقع بوت) داشته باشه و مقدار زیادی زمان بخاطر اون صرف شده باشه.
و اما برای کمتر کردن لاگهای journalctl فایل زیر رو با ویرایشگر دلخواهتون باز کنید

sudo gedit /etc/systemd/journald.conf

طبق عکس زیر اون مقادیری که بنفش هستند تغییر بدید و اگر پشتشون # هست بردارید

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

و قسمت systemmaxuse هم برای اینه که حداکثر فضایی که قراره به این لاگها اختصاص داده بشه چقدر باشه. مقدار کمتر به این معنیه که فضای کمتری در اختیار داشته باشن. این برای موقعی مناسبه که شما میخواید لاگها رو روی هارد نگه دارید. نه روی مموری. هرچند اینجوری مموری هم کمتر اشغال میشه.

بعد از ذخیره این تغییرات، یک بار دستور زیر رو اجرا کنید تا لاگ های قبلی پاک بشن

sudo rm -rf /var/log/journal/*

رزلوشن 4k و مشکل ریز بودن بعضی نرم افزارها در لینوکس

این روزها دیگه کم کم مانیتورهای 4k دارن روی لپتاپ ها سر و کله هاشون پیدا میشه. صرف نظر اینکه ما در یک مانیتور لپتاپ به یه همچین رزلوشنی نیاز داریم یا نه، مشکلی بوجود میاد که وقتی همچین لپتاپی میخریم چاره ای برای حلش نداریم.
در این رزلوشن اکثر برنامه های قدیمی، و اونهایی که خودشون رو نتونستن با تکنولوژی بروز کنند فونت برنامه و آیکنهای اون برنامه به قدری ریز هستند که عملا شما رو در استفاده از اونها پشیمون میکنه.
در لینوکس، حداقل در دسکتاپ گنوم این طور بوده که خود بدنه اصلی دسکتاپ و برنامه های وابسته به پروژه گنوم با این تکنولوژی سازگار هستند و مشکلی از این بابت وجود نداره. اما وقتی کار به استفاده از برنامه هایی مثل GIMP یا برنامه های قدیمی میرسه، این مسئله نمود پیدا میکنه.
گنوم در تنظیمات Tweaks برای حل این مشکل از window scaling و scaling factor استفاده کرده که با بیشتر کردن مقدار اونها تا حدی این موضوع بر طرف شه. اما با این کار کل محتوای مانیتور بزرگ میشه و باز هم ناهماهنگی زشتی بوجود میاد.
تنها راه چاره ای که من پیدا کردم این بود که بیخیال رزلوشن 4k بشیم و در تنظیمات Displays حداکثر رزلوشنی که در اون مشکلی بوجود نمیاد رو انتخاب کنیم

یعنی رزلوشن 1152 در 2048. در این عدد دیگه برنامه ای ریز نیست و برنامه های دیگه هم اندازه درستی دارند و همه چیز هماهنگه. و نیازی به افزایش scalingها نیست. و همچنین تغییر محسوسی در کیفیت تصویر نخواهید دید.

غیر فعال کردن Auto extract در Nautilus جدید

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

با فعال / غیر فعال کردن این گزینه میتونید این ویژگی رو کنترل کنید.