Jump to content

Frequently asked questions (עברית)

From ArchWiki

Related articles

כללי

מהו Arch Linux?

ראו את הערך Arch Linux.

מתי לא כדאי להשתמש ב-Arch?

כדאי לחשוב פעמיים לפני שבוחרים ב-Arch, אם:

  • אין לכם היכולת, הזמן או הרצון להתמודד עם הפצת GNU/Linux מסוג "עשה זאת בעצמך" (DIY).
  • אתם זקוקים לתמיכה בארכיטקטורה שאינה x86_64.
  • חשוב לכם עקרונית להשתמש בהפצה שכוללת אך ורק תוכנה חופשית, כפי שהוגדרה על ידי GNU.
  • אתם מצפים שמערכת ההפעלה תגדיר את עצמה, תעבוד "מהקופסה", ותגיע עם ערכת תוכנות וסביבת שולחן עבודה מלאות כבר במדיית ההתקנה.
  • אינכם מעוניינים בהפצת GNU/Linux מסוג "הפצה מתגלגלת" (עדכונים רציפים, בלי גרסאות עם מספור קבוע).
  • אתם מרוצים ממערכת ההפעלה הנוכחית שלכם.

למה כדאי לי להשתמש ב-Arch?

כי Arch היא הטובה ביותר.

באילו ארכיטקטורות Arch תומכת?

Arch תומכת אך ורק בארכיטקטורת x86_64 (המכונה לעיתים amd64). התמיכה ב-i686 הופסקה בנובמבר 2017 [1].

קיימות הפצות נגזרות לארכיטקטורת i686 [2] ולמעבדי ARM [3], ולכל אחת מהן ערוצי קהילה משלה. הן אינן נתמכות על ידי Arch Linux עצמה.

מי שרוצה ש-Arch תתמוך בארכיטקטורות נוספות מוזמן לסייע במאמצי ה-porting (התאמת התוכנה לארכיטקטורה חדשה) הקיימים, או להתחיל מאמץ משלו. ראו Getting involved#Help porting Arch Linux to other architectures.

האם Arch עוקבת אחר תקן ה-FHS (Filesystem Hierarchy Standard) של ה-Linux Foundation?

Arch Linux עוקבת אחר מבנה מערכת הקבצים המיועד למערכות שמשתמשות במנהל השירותים systemd (התוכנה שמנהלת את תהליך האתחול ואת השירותים הרצים ברקע ברוב הפצות הלינוקס המודרניות). ראו file-hierarchy(7) להסבר על כל ספרייה וייעודה. בפרט, /bin, /sbin ו-/usr/sbin הם קישורים "סמליים" (קיצור דרך בתוך מערכת הקבצים, שמצביע לקובץ או לתיקייה אחרת ואינו מכיל תוכן משלו) אל /usr/bin, ו-/lib ו-/lib64 הם קישורים סמליים אל /usr/lib.

אני מתחיל/ה לגמרי ב-GNU/Linux. כדאי לי להשתמש ב-Arch?

כמי שמתחילים ורוצים להשתמש ב-Arch צריכים להיות מוכנים להשקיע זמן בלימוד מערכת חדשה, ולקבל את העובדה ש-Arch נבנתה כהפצת "עשה זאת בעצמך" - המשתמשים הם אלו שמרכיבים את המערכת.

לפני שפונים לבקש עזרה, מומלץ לבצע חיפוש עצמאי באינטרנט, בפורום ובתיעוד המצוין שמציעה ה-ArchWiki. לא בכדי המשאבים האלה עומדים לרשותכם. הושקעו בהם אלפי שעות התנדבות.

ראו גם Arch terminology#RTFM ואת מדריך ההתקנה.

Arch מיועדת לשימוש כשרת? כמחשב שולחני? כתחנת עבודה?

Arch לא נבנתה עבור סוג שימוש מסוים, אלא עבור סוג משתמשים מסוימים. Arch מיועדת למשתמשים מיומנים שנהנים מהאופי ה"עשה זאת בעצמך" שלה, ומנצלים אותו כדי לעצב את המערכת בדיוק לפי הצרכים שלהם. לכן, בידיים של קהל היעד שלה, Arch יכולה לשמש כמעט לכל מטרה. רבים משתמשים ב-Arch גם על מחשבים שולחניים וגם כתחנות עבודה. וכמובן, archlinux.org, aur.archlinux.org וכמעט כל התשתית של Arch רצים בעצמם על Arch.

אני מאוד אוהב/ת את Arch, רק שצריך להוסיף את פיצ'ר X

הצטרפו לפעילות ותרמו את הקוד או הפתרון שלכם לקהילה. אם הקהילה וצוות הפיתוח יעריכו את התרומה, יש סיכוי שהיא תשולב. קהילת Arch מתקיימת בזכות תרומה ושיתוף של קוד וכלים.

מתי תצא הגרסה החדשה?

גרסאות Arch Linux הן בעצם סביבה חיה להתקנה או להצלה, שכוללת את חבילת המטא base ועוד מספר חבילות. הגרסאות יוצאות בדרך כלל במחצית הראשונה של כל חודש.

האם Arch Linux היא הפצה יציבה? האם המערכת תישבר לעיתים קרובות?

בסופו של דבר, המשתמשים הם האחראים ליציבות המערכת שלהם, שהיא הפצה מתגלגלת. הם קובעים מתי לעדכן, ומטמיעים שינויים נדרשים לפי הצורך. פנייה לקהילה מניבה בדרך כלל עזרה תוך זמן סביר. ההבדל בין Arch להפצות אחרות בהקשר הזה הוא ש-Arch היא באמת הפצת "עשה זאת בעצמך". תלונות על "שבירה" של המערכת אינן במקומן ואינן פרודוקטיביות, שכן שינויים ב-upstream (פרויקט המקור שממנו מגיעה התוכנה, לפני שהיא נארזת ומופצת על ידי Arch) אינם באחריות מפתחי Arch.

ראו את הערך תחזוקת המערכת לטיפים כיצד לשמור על מערכת Arch Linux יציבה ככל האפשר.

ל-Arch דרושה יותר חשיפה תקשורתית (כלומר, פרסום)

ל-Arch כבר יש לא מעט סיקור תקשורתי. המטרה של Arch Linux אינה להיות "גדולה", אלא לצמוח בצורה אורגנית וברת-קיימא בקרב קהל היעד שלה.

ל-Arch דרושים יותר מפתחים

יכול להיות. אתם מוזמנים להתנדב! בקרו בפורומים, בערוצי ה-IRC וברשימות התפוצה, ובדקו מה עוד צריך. ראו גם מעורבות בקהילה לפרטים נוספים.

התקנה

כמה זיכרון RAM נדרש כדי לאתחל את הסביבה החיה?

תלוי אם משתמשים בקובץ ה-ISO או ב-netboot, דרישות הזיכרון להרצת הסביבה החיה נעות בין 1 GiB ל-2.5 GiB בהתאמה. במחשבים עם מעבד גרפי משולב (integrated GPU), יעמוד לרשותכם פחות זיכרון, כי חלק ממנו שמור לשבב הגרפי.

ל-Arch צריכה להיות תוכנת התקנה. אולי אפילו עם ממשק גרפי?

קיימת תוכנת התקנה מודרכת עם ממשק טקסטואלי. ראו archinstall לפרטים.

התקנתי את Arch, ועכשיו אני מול שורת פקודה! מה עכשיו?

ראו המלצות כלליות.

באיזו סביבת שולחן עבודה או מנהל חלונות כדאי להשתמש?

יש הרבה אפשרויות, ולכן כדאי לבחור את זו שהכי מתאימה לצרכים שלכם. אפשר להעיף מבט בערכים סביבת שולחן עבודה ומנהל חלונות.

מה מייחד את Arch מבין הפצות "מינימליות" אחרות?

ראו Arch בהשוואה להפצות אחרות.

תחזוקת המערכת

ראו גם תחזוקת המערכת.

למה האינטרנט שלי איטי יותר בהשוואה למערכות הפעלה אחרות?

האם הרשת מוגדרת נכון? כדאי לעיין בערך הגדרת רשת. להגדרות מתקדמות יותר, אפשר גם לבדוק traffic shaping (עיצוב תעבורה - שליטה בקצב ובעדיפות של סוגי תעבורת רשת שונים).

אחד הקרנלים הנפוצים ביותר, linux, נוטה להיות חדש יותר מהקרנל (kernel - הליבה של מערכת ההפעלה, שמתקשרת ישירות עם החומרה) של הפצות לינוקס יציבות יותר. בגלל זה, ייתכן שתיתקלו לעיתים נדירות ברגרסיית קרנל (regression - באג שמופיע בגרסה חדשה בפונקציונליות שעבדה תקין בגרסה קודמת) או בבאג של דרייבר, בעיקר בשימוש ב-Wi-Fi. שימו לב שרוב הבאגים הללו אינם ספציפיים ל-Arch Linux, כיוון ש-Arch Linux מיישמת רק את התיקונים (patches) הבסיסיים ביותר. יש להעביר את הדיווח ל-upstream. ראו #מצאתי תקלה בחבילה X. מה עליי לעשות?.

למה Arch משתמשת בכל ה-RAM שלי?

בגדול, זיכרון RAM שלא בשימוש הוא זיכרון מבוזבז.

משתמשים חדשים רבים שמים לב שקרנל הלינוקס מנהל זיכרון אחרת ממה שהם רגילים אליו. מכיוון שגישה לנתונים מה-RAM מהירה בהרבה מגישה לכונן אחסון, הקרנל שומר במטמון (cache) נתונים שניגשו אליהם לאחרונה. הנתונים במטמון נמחקים רק כשהמערכת מתחילה להיגמר לה זיכרון פנוי וצריך לטעון נתונים חדשים.

אפשר להבחין בהבדל בפקודה free: 

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

חשוב להבחין בין זיכרון "free" (פנוי) לזיכרון "available" (זמין). בדוגמה שלמעלה, נראה שמערכת עם 377 GiB RAM משתמשת ביותר מחצי ממנו, כשרק 146 GiB "פנויים". אבל 196 GiB מתוכם הם "buff/cache". עדיין יש 337 GiB זמינים להרצת תוכנות חדשות, בלי צורך ב-swap (שטח בדיסק שמשמש כגיבוי לזיכרון ה-RAM). ראו free(1) לפרטים. התוצאה של כל זה? ביצועים!

מי שהסקרנות שלו התעוררה מוזמן לקרוא את המאמר הנהדר הזה. יש גם אתר שהוקדש כולו להבהרת הבלבול הזה: https://www.linuxatemyram.com/.

לאן נעלם לי כל שטח האחסון הפנוי?

התשובה תלויה במערכת הספציפית שלכם. יש כמה כלים מצוינים שיכולים לעזור למצוא אותה.

למה אני לא מצליח/ה להתחבר?

הקלדתם סיסמה שגויה או ביטלתם פקודת sudo שלוש פעמים תוך רבע שעה? אם כן, הפעלתם בטעות מנגנון הגנה מפני התקפות brute-force (ניסוי שיטתי של כל הסיסמאות האפשריות). ראו Security#Lock out user after three failed login attempts לפרטים נוספים.

האם Arch "מתקשרת הביתה" ?

בקצרה? לא.

בפירוט:

  • משתמשי NetworkManager בטח יודעים שהוא מבצע בדיקות קישוריות אוטומטיות. כתובת ה-URL שמשמשת לבדיקה נמסרת על ידי Arch, שמתחייבת שלא לתעד גישות אליה.
  • לקוחות NTP (Network Time Protocol - פרוטוקול לסנכרון שעון המחשב מול שרתים מדויקים ברשת) בהגדרות ברירת המחדל שלהם משתמשים במאגר ספקי NTP של NTP Pool Project (לפי הכללים שלו).
  • כפי שמוסבר בהערה ב-pacman/Package signing#Upgrade system regularly, טיימר של systemd רץ פעם בשבוע כדי לעדכן חתימות חדשות עבור מפתחות מהימנים קיימים. גם כאן אין תיעוד של אף גישה.
  • כלי עדכון רשימת המראות Reflector (למי שמשתמש בו) מוריד את רשימת המראות (mirrors - שרתים חיצוניים שמארחים עותק של מאגר החבילות הרשמי) מ-archlinux.org.

מי שרוצה יכול "להתקשר הביתה" מרצונו, על ידי תרומה לפרויקט pkgstats, שאוסף נתונים אנונימיים על פופולריות חבילות כדי לעזור למפתחי Arch לתעדף את המאמצים שלהם.

ניהול חבילות

לתשובות נוספות ראו את הדפים pacman, pacman/Tips and tricks והמאגרים הרשמיים.

מצאתי תקלה בחבילה X. מה עליי לעשות?

קודם כול, צריך לברר אם מדובר בתקלה שצוות Arch יכול לתקן. לרוב זה לא כך (למשל, קריסות של Firefox עשויות להיות באחריות צוות Mozilla). זו נקראת תקלת upstream, ראו Bug reporting guidelines#Upstream or Arch?. אם מדובר בתקלה של Arch עצמה, אפשר לפעול כך:

  1. לחפש בפורומים ולבדוק אם מישהו אחר כבר נתקל בזה.
  2. לפתוח דיווח תקלה עם פרטים מלאים במערכת מעקב הבאגים של Arch Linux ב-GitLab.
  3. אפשר גם לכתוב פוסט בפורום שמתאר את הבעיה ומציין שכבר דווחה. זה עוזר למנוע דיווחים כפולים.

לחבילות Arch דרושה מוסכמת שמות ייחודית. הסיומת ".pkg.tar.zst" ארוכה מדי ו/או מבלבלת

הנושא כבר נדון ברשימת התפוצה של Arch. היו הצעות לסיומת .pac, אבל אין כרגע תוכנית לשנות את סיומת החבילות. כפי שניסח זאת טוביאס קיזליך, אחד ממפתחי Arch: "חבילה היא ארכיון tar [דחוס]! וכל תוכנה שיודעת לפתוח tar יכולה לפתוח, לבדוק ולערוך אותה. יתרה מזו, רוב היישומים מזהים את סוג הקובץ (mime-type) אוטומטית ובאופן נכון."

ל-pacman דרושה ספרייה שדרכה תוכנות אחרות יוכלו לגשת בקלות למידע על חבילות

pacman הוא ממשק חזית (front-end - שכבת הממשק שמול המשתמש) ל-libalpm(3), ספריית "ניהול החבילות של Arch Linux", שמאפשרת לכתוב ממשקי חזית חלופיים, כולל ממשק גרפי.

ל-pacman דרוש פיצ'ר X!

אם יש לכם רעיון שנראה לכם בעל ערך, אפשר לדון בו ב-pacman-dev. כדאי גם לבדוק אם כבר יש בקשת פיצ'ר דומה ב-https://gitlab.archlinux.org/pacman/pacman/-/issues.

אבל הדרך הטובה ביותר להוסיף פיצ'ר ל-pacman או ל-Arch Linux היא ליישם אותו בעצמכם. ייתכן שהתיקון או הקוד לא יתקבלו רשמית, אבל ייתכן שאחרים יעריכו, יבדקו ואף יתרמו למאמץ שלכם.

התקנתי חבילה X. איך מריצים אותה?

אם אתם משתמשים בסביבת שולחן עבודה כמו KDE או GNOME, התוכנה אמורה להופיע אוטומטית בתפריט אם היא כוללת desktop entry. אם אתם מנסים להריץ את התוכנה מטרמינל ולא יודעים את שם הקובץ הבינארי, אפשר להשתמש בפקודה: 

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

למה יש רק גרסה אחת של כל ספרייה משותפת במאגרים הרשמיים?

בהפצות מסוימות, כמו Debian, גרסאות שונות של ספריות משותפות ארוזות כחבילות נפרדות: libfoo1, libfoo2, libfoo3 וכן הלאה. כך אפשר להתקין על אותה מערכת תוכנות שקומפלו מול גרסאות שונות של libfoo.

בהפצה כמו Arch נתמכות רשמית רק הגרסאות האחרונות של כל חבילה. כשמפסיקים לתמוך בתוכנה מיושנת, מתחזקי החבילות מצליחים להשקיע יותר זמן בלוודא שהגרסאות החדשות עובדות כמו שצריך. ברגע שגרסה חדשה של ספרייה משותפת מתפרסמת ב-upstream, היא מתווספת למאגרים, והחבילות שתלויות בה נבנות מחדש כדי להשתמש בגרסה החדשה.

מה קורה אם מריצים עדכון מערכת מלא, ויש עדכון לספרייה משותפת אך לא לתוכנות שתלויות בה?

תרחיש כזה לא אמור לקרות בכלל. נניח שתוכנה בשם foobaz נמצאת באחד המאגרים הרשמיים ונבנית בהצלחה מול גרסה חדשה של ספרייה בשם libbaz, אז היא תתעדכן יחד עם libbaz. אבל אם היא לא נבנית בהצלחה, לחבילת foobaz תהיה תלות עם גרסה מוגדרת (למשל libbaz 1.5), ו-pacman יסיר אותה בזמן עדכון libbaz, בגלל הקונפליקט.

אם foobaz היא חבילה שבניתם בעצמכם והתקנתם מה-AUR, כדאי לבנות אותה מחדש מול הגרסה החדשה של libbaz. אם הבנייה נכשלת, דווחו על הבאג למפתחי foobaz.

יכול להיות שיש עדכון קרנל משמעותי במאגר, בלי שחלק מחבילות הדרייברים עודכנו?

לא, זה לא יכול לקרות. עדכוני קרנל משמעותיים (למשל מ-linux 3.5.0-1 ל-linux 3.6.0-1) תמיד מלווים בבנייה מחדש של כל חבילות דרייברי הקרנל הנתמכים. עם זאת, אם מותקנת במערכת חבילת דרייבר לא נתמכת (למשל מה-AUR), עדכון קרנל עלול לשבור אותה אם לא תיבנה מחדש עבור הקרנל החדש. המשתמשים אחראים לעדכן בעצמם כל חבילת דרייבר לא נתמכת שהתקינו.

מה כדאי לעשות לפני עדכון?

כדאי לפעול לפי הסעיף System maintenance#Upgrading the system.

עדכון חבילה שוחרר, אבל pacman טוען שהמערכת מעודכנת

המראות של pacman לא מסתנכרנות מיידית, ויכולות לעבור יותר מ-24 שעות עד שהעדכון יהיה זמין. האפשרויות הן להמתין בסבלנות או לעבור למראה אחרת. MirrorStatus יכול לעזור לאתר מראה מעודכנת.

פרויקט X שחרר גרסה חדשה ב-upstream. כמה זמן ייקח עד שחבילת Arch תתעדכן לגרסה הזו?

עדכוני חבילות משתחררים כשהם מוכנים. משך הזמן יכול לנוע בין כמה שעות בודדות אחרי עדכון תיקון קטן ב-upstream, ועד כמה שבועות אחרי עדכון גדול של קבוצת חבילות שלמה. הזמן תלוי בחבילות הספציפיות ובזמינות מתחזקי החבילה. בנוסף, יש חבילות ששוהות זמן מה במאגר ה-testing, מה שיכול להאריך את זמן העדכון. מתחזקי החבילות משתדלים לעבוד מהר כדי להביא עדכונים יציבים למאגרים. אם מצאתם חבילה במאגרים הרשמיים שאינה מעודכנת, bumpbuddy אמור להתריע אוטומטית למתחזק, הודות לקבצי ה-nvchecker שבכל מאגר (ראו דוגמה זו בחבילת chromium).

אם אני צריך/ה גרסה ישנה יותר של ספרייה מותקנת, אפשר פשוט ליצור קישור סמלי לגרסה החדשה?

אם יש לכם מזל, זה אולי יעבוד, לזמן מה. בכל מקרה, זה לא פתרון ראוי, כי:

  • ספריות לא משנות גרסה סתם כך. ה-API/ABI (ABI - הממשק הבינארי בין תוכנה לספרייה, ברמה נמוכה יותר מה-API) כנראה השתנה, ואולי חלקים אף הוסרו, והאם השינויים האלה ישפיעו על השימוש שלכם זה עניין של מזל בלבד.
  • מנהל החבילות לא יעקוב אחר הקישור הסמלי. מתחילים שמנסים מיד "לפרוץ" לקבצי ספריות מערכת נמצאים בסיכון הגבוה ביותר לעשות שינוי לא רצוי שהם לא יצליחו לאבחן או לתקן, וזה בדיוק מה שמנהל חבילות אמור למנוע.
  • חלופה קלה יותר, לזרוק את קובץ הספרייה הישן למערכת הקבצים בלי מעקב, עלולה פשוט להישכח, ובאגי אבטחה אפשריים בה לא יאותרו ולא יתוקנו.

במקום זאת, אפשר למשל להשתמש (או לכתוב) חבילת compat (חבילת תאימות), שמספקת את גרסת הספרייה הנדרשת.

64 ביט

איך יודעים אם המעבד שלי תומך ב-x86_64?

אם המעבד שלכם תומך ב-x86_64, יופיע הדגל lm (long mode) בקובץ /proc/cpuinfo. לדוגמה: 

$ grep -w lm /proc/cpuinfo

ב-Windows אפשר להשתמש בתוכנה החינמית CPU-Z כדי לברר אם המעבד תומך ב-64 ביט. מעבדים עם סט ההוראות "AMD64" של AMD או "EM64T" של Intel אמורים להיות תואמים לגרסאות x86_64 ולחבילות הבינאריות.

למה 64 ביט?

זה מהיר יותר ברוב המקרים, ומגיע כבונוס גם עם רמת אבטחה גבוהה יותר, הודות ל-ASLR (ערבוב אקראי של כתובות הזיכרון, כדי להקשות על תוקפים) בשילוב עם PIC (קוד שאינו תלוי במיקום קבוע בזיכרון) ו-NX Bit (סימון אזורי זיכרון כבלתי ניתנים להרצה), שאינו זמין בקרנל i686 הסטנדרטי בגלל PAE (הרחבת כתובות פיזיות) מבוטל. אם למחשב שלכם יש יותר מ-4 GiB RAM, רק מערכת הפעלה 64 ביט תוכל לנצל אותו במלואו.

גם מפתחי תוכנה נוטים יותר ויותר להתעלם מ-32 ביט ("ישן"), כי מעבדי x86 "חדשים" בדרך כלל תומכים בהרחבות 64 ביט.

יש עוד הרבה סיבות להימנע מ-32 ביט, אבל בין הקרנל, ה-userspace (תוכנות שרצות "מעל" הקרנל, ברמת המשתמש הרגיל) והתוכנות הבודדות, פשוט לא ניתן לרשום כאן את כל היתרונות של 64 ביט בימינו.