Jump to content

Frequently asked questions (فارسی)

From ArchWiki

عمومی

ارچ لینوکس چیست؟

به مقاله آرچ لینوکس مراجعه کنید.

چرا نباید از آرچ استفاده کنم؟

ممکن است نخواهید از آرچ استفاده کنید, اگر:

  • شما توانایی/زمان/تمایل لازم برای یک توزیع گنو/لینوکس 'do-it-yourself' را ندارید.
  • شما به پشتیبانی از معماری غیر از x86_64 نیاز دارید.
  • شما موضع محکمی در مورد استفاده از توزیعی دارید که فقط نرم‌افزارهای آزاد تعریف‌شده توسط گنو را ارائه می‌دهد.
  • شما معتقدید که یک سیستم عامل باید خودش را پیکربندی کند، به صورت آماده اجرا شود و مجموعه‌ای کامل از نرم‌افزارها و محیط دسکتاپ را به صورت پیش‌فرض روی رسانه نصب داشته باشد.
  • شما یک توزیع گنو/لینوکس با انتشار غلتان نمی‌خواهید.
  • شما از سیستم عامل فعلی خود راضی هستید.

چرا باید از آرچ استفاده کنم؟

چون آرچ بهترینه.

آرچ از چه معماری‌هایی پشتیبانی می‌کند؟

آرچ فقط از معماری x86_64 (که گاهی اوقات amd64 نیز نامیده می‌شود) پشتیبانی می‌کند. پشتیبانی از i686 در نوامبر 2017 متوقف شد[۱] .

توزیع‌های مشتق‌شده‌ای برای معماری i686 [۲] و پردازنده‌های ARM [۳] وجود دارد که هر کدام کانال‌های اجتماعی خود را دارند. آن‌ها توسط آرچ لینوکس پشتیبانی نمی‌شوند.

اگر مایلید آرچ از معماری‌های دیگر پشتیبانی کند، می‌توانید در تلاش‌های موجود برای پورت کردن کمک کنید یا خودتان شروع به کار کنید. بینید Getting involved#Help porting Arch Linux to other architectures.

آیا آرچ از استاندارد سلسله مراتب فایل سیستم (FHS) بنیاد لینوکس پیروی می‌کند؟

آرچ لینوکس با استفاده از مدیریت کننده سرویس systemd، سلسله مراتب فایل سیستم را برای سیستم عامل‌ها دنبال می‌کند. برای توضیح هر دایرکتوری به همراه نام آنها به file-hierarchy(7) مراجعه کنید. به طور خاص، /bin, /sbin و /usr/sbin پیوندهای نمادین به /usr/bin هستند و /lib و /lib64 پیوندهای نمادین به /usr/lib می‌باشند.

من کاملاً با گنو/لینوکس مبتدی هستم. آیا باید از آرچ استفاده کنم؟

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

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

همچنین به Arch terminology#RTFM و راهنمای نصب مراجعه کنید.

آیا آرچ برای استفاده به عنوان سرور، دسکتاپ یا ورک استیشن طراحی شده است؟

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

من واقعاً آرچ را دوست دارم، به جز اینکه تیم توسعه باید ویژگی X را پیاده‌سازی کند.

وارد عمل شوید، کد/راهکار خود را در اختیار جامعه قرار دهید. اگر مورد توجه جامعه و تیم توسعه قرار گیرد، شاید ادغام شود. جامعه آرچ با مشارکت و به اشتراک گذاری کد و ابزارها رونق می‌گیرد.

نسخه جدید کی در دسترس قرار خواهد گرفت؟

نسخه‌های آرچ لینوکس صرفاً یک محیط زنده برای نصب یا بازیابی هستند که شامل بسته meta package base و چند بسته دیگر می‌شوند. این نسخه‌ها معمولاً در نیمه اول هر ماه منتشر می‌شوند.

آیا آرچ لینوکس توزیع پایداری است؟ آیا مرتباً با مشکل خرابی مواجه خواهم شد؟

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

برای نکاتی در مورد چگونگی پایدار کردن هرچه بیشتر سیستم آرچ لینوکس، به مقاله System maintenance مراجعه کنید.

آرچ به مطبوعات بیشتری نیاز دارد (مثلاً تبلیغات)

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

آرچ به توسعه‌دهندگان بیشتری نیاز دارد

احتمالاً همینطور است. می‌توانید وقت خود را داوطلبانه اختصاص قرار دهید! از forums، کانال‌های IRC و mailing lists دیدن کنید و ببینید چه کارهایی باید انجام شود. برای جزئیات بیشتر به بخش Getting involved مراجعه کنید.

Installation

Arch needs an installer. Maybe a GUI installer?

A guided installer with a text-based user interface is available. See archinstall for details.

I installed Arch, and now I am at a shell! What now?

See General recommendations.

Which desktop environment or window manager should I use?

Since many are available to you, use the one that best fits your needs. Have a look at the Desktop environment and Window manager articles.

What makes Arch unique amongst other "minimal" distributions?

See Arch compared to other distributions.

System maintenance

See also System maintenance.

Why is my internet so slow compared to other operating systems?

Is your network configured correctly? Have a look at the Network configuration article. For advanced setups, you may also want to look at traffic shaping.

One of the most commonly used kernels, linux, tends to be newer than the kernel of other, more stable, Linux distributions. Because of that, you may rarely experience a kernel regression or driver bug, especially if using Wi-Fi. Do note that the vast majority of those bugs are not Arch Linux-specific as Arch Linux only applies the most basic of patches. This needs to be taken upstream. See #I have found an error with package X. What should I do?.

Why is Arch using all my RAM?

Essentially, unused RAM is wasted RAM.

Many new users notice how the Linux kernel handles memory differently than they are used to. Since accessing data from RAM is much faster than from a storage drive, the kernel caches recently accessed data in memory. The cached data is only cleared when the system begins to run out of available memory and new data needs to be loaded.

We could distinguish the difference from free command: 

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           377Gi        40Gi       146Gi       1.1Gi       196Gi       337Gi
Swap:          377Gi       1.1Gi       376Gi

It is important to note the difference between "free" and "available" memory. In the above example, a system with 377 GiB of total RAM appears to be using more than half of it, with only 146 GiB as free memory. However, 196 GiB of it is "buff/cache". There is still 337 GiB available for starting new applications, without swapping. See free(1) for details. The result of all this? Performance!

See this wonderful article if your curiosity has been piqued. There is also a website dedicated to clearing this confusion: https://www.linuxatemyram.com/.

Where did all my free space go?

The answer to this question depends on your system. There are some fine utilities that may help you find the answer.

Why am I unable to log in?

Have you mistyped your password or cancelled a sudo command three times in fifteen minutes? If so, you have triggered a prevention mechanism against brute-force attacks: see Security#Lock out user after three failed login attempts for more details.

Does Arch "phone home"?

In short? No.

In more details:

You may want to voluntarily "phone home" by contributing to the pkgstats project that collects anonymous data of package popularity to help Arch developers prioritize their efforts.

Package management

See the pacman, pacman/Tips and tricks and Official repositories pages for more answers.

I have found an error with package X. What should I do?

First, you need to figure out if this error is something the Arch team can fix. Often it is not (e.g. Firefox crashes may be the fault of the Mozilla team); this is called an upstream error, see Bug reporting guidelines#Upstream or Arch?. If it is an Arch problem, there is a series of steps you can take:

  1. Search the forums for information. See if anyone else has noticed it.
  2. Post a bug report with detailed information on the Arch Linux bug tracker in GitLab.
  3. If you would like, write a forum post detailing the problem and the fact that you have reported it already. This will help prevent a lot of people from reporting the same error.

Arch packages need to use a unique naming convention. ".pkg.tar.zst" is too long and/or confusing

This has been discussed on the Arch mailing list. Some proposed a .pac file extension, but there is no plan to change the package extension. As Tobias Kieslich, one of the Arch developers, put it, "A package is a [compressed] tarball! And it can be opened, investigated and manipulated by any tar-capable application. Moreover, the mime-type is automatically detected correctly by most applications."

Pacman needs a library so other applications can easily access package information

Pacman is a front-end to libalpm(3)—the "Arch Linux Package Management" library—which allows alternative front-ends, like a GUI front-end, to be written.

Pacman needs feature X!

If you think an idea has merit, you may choose to discuss it on pacman-dev. Also check https://gitlab.archlinux.org/pacman/pacman/-/issues for existing feature requests.

However, the best way to get a feature added to pacman or Arch Linux is to implement it yourself. The patch or code may or may not be officially accepted, but perhaps others will appreciate, test and contribute to your effort.

I just installed Package X. How do I start it?

If you are using a desktop environment like KDE or GNOME, the program should automatically show up in your menu if it comes with a desktop entry. If you are trying to run the program from a terminal and do not know the binary name, use: 

$ pacman -Qlq package_name | grep /usr/bin/

Why is there only a single version of each shared library in the official repositories?

Several distributions, such as Debian, have different versions of shared libraries packaged as different packages: libfoo1, libfoo2, libfoo3 and so on. In this way it is possible to have applications compiled against different versions of libfoo installed on the same system.

In case of a distribution like Arch, only the latest packaged versions are officially supported. By dropping support for outdated software, package maintainers are able to spend more time ensuring that the newest versions work as expected. As soon as a new version of a shared library becomes available from upstream, it is added to the repositories and affected packages are rebuilt to use the new version.

What if I run a full system upgrade and there will be an update for a shared library, but not for the applications that depend on it?

This scenario should not happen at all. Assuming an application called foobaz is in one of the official repositories and builds successfully against a new version of a shared library called libbaz, it will be updated along with libbaz. If, however, it does not build successfully, foobaz package will have a versioned dependency (e.g. libbaz 1.5), and will be removed by pacman during libbaz upgrade, due to a conflict.

If foobaz is a package that you built yourself and installed from AUR, you should rebuild foobaz against the new version of libbaz. If the build fails, report the bug to the foobaz developers.

Is it possible that there is a major kernel update in the repository, and that some of the driver packages have not been updated?

No, it is not possible. Major kernel updates (e.g. linux 3.5.0-1 to linux 3.6.0-1) are always accompanied by rebuilds of all supported kernel driver packages. On the other hand, if you have an unsupported driver package (e.g. from the AUR) installed on your system, then a kernel update might break things for you if you do not rebuild it for the new kernel. Users are responsible for updating any unsupported driver packages that they have installed.

What to do before upgrading?

Follow the System maintenance#Upgrading the system section.

A package update was released, but pacman says the system is up to date

pacman mirrors are not synced immediately. It may take over 24 hours before an update is available to you. The only options are be patient or use another mirror. MirrorStatus can help you identify an up-to-date mirror.

Upstream project X has released a new version. How long will it take for the Arch package to update to that new version?

Package updates will be released when they are ready. The specific amount of time can be as short as a few hours after upstream releases a minor bugfix update to as long as several weeks after a large package group's major update. The amount of time from an upstream's new version to Arch releasing a new package depends on the specific packages and the availability of the package maintainers. Additionally, some packages spend some time in the testing repository, so this can prolong the time before a package is updated. Package maintainers attempt to work quickly to bring stable updates to the repositories. If you find a package in the official repositories that is out of date, go to that package's page at the package website and flag it.

If you are lucky, it might work, for a time. Regardless, it is not a proper solution, because:

  • Libraries do not change versions randomly – the API/ABI will have likely changed (possibly with bits removed), and whether those changes affect the usage is just a matter of luck.
  • The symlink would be untracked by a package manager. Beginners who immediately try to hack on system library files are in the greatest risk of making an unwanted change that they cannot diagnose/fix, which a package manager helps to guard against.
  • A slight alternative of dumping the old library file into the filesystem, untracked, would be forgotten about, and not have potential security bugs noticed/patched.

Instead, e.g. use/write a compat (compatibility) package, which provides the required library version.

64-bit

How do I determine if my processor is x86_64 compatible?

If your processor is x86_64 compatible, you will have the lm (long mode) flag in /proc/cpuinfo. For example, 

$ grep -w lm /proc/cpuinfo

Under Windows, using the freeware CPU-Z helps determine whether your CPU is 64-bit compatible. CPUs with AMD's instruction set "AMD64" or Intel's solution "EM64T" should be compatible with the x86_64 releases and binary packages.

Why 64-bit?

It is faster under most circumstances and as an added bonus also inherently more secure due to the nature of Address space layout randomization (ASLR) in combination with Position-independent code (PIC) and the NX Bit which is not available in the stock i686 kernel due to disabled Physical Address Extension (PAE). If your computer has more than 4 GiB of RAM, only a 64-bit OS will be able to fully utilize it.

Programmers also increasingly tend to care less about 32-bit ("legacy") as "new" x86 CPUs typically support the 64-bit extensions.

There are many more reasons we could list here to tell you to avoid 32-bit, but between the kernel, userspace and individual programs it is simply not viable to list every last thing that 64-bit does much better these days.