ההיסטוריה של הפצות Linux: עץ המשפחה המלא

מהי למעשה הפצת Linux

ההיסטוריה של הפצות Linux מתחילה בפער: הליבה (kernel) של Linux כשלעצמה אינה עושה דבר שמשתמש יכול להפיק ממנו תועלת. היא עולה (boots) ומזהה חומרה, ואז עוצרת. מישהו חייב להוסיף סביבת משתמש (userland), לבחור כיצד תוכנה מותקנת ומעודכנת, ולהתחייב להמשיך לתחזק אותה במשך שנים. הפצה היא אוסף הבחירות הזה, בתוספת קבוצת האנשים שנשארת לתחזק אותו לאחר מכן.

היא מורכבת מחמישה חלקים. שינוי של כל אחד מהם יוצר הפצה שונה, גם כאשר רוב הקבצים הבינאריים זהים:

• ליבה (kernel), בגרסה שנבחרה על ידי הפרויקט, עם התיקונים (patches) והדרייברים שנוספו לה.
• סביבת משתמש (userland): ספריית ה-C, ה-shell, מערכת ה-init, והפקודות הסטנדרטיות.
• פורמט חבילות, והכלי שמתקין אותן.
• מדיניות שחרור גרסאות (release policy): מה מותר לשנות, באיזו תדירות, וכמה זמן כל גרסה נתמכת.
• אנשים: מתחזקי חבילות, צוות אבטחה, ומישהו שנותן מענה כאשר חבילה נשברת.

הליבה היא החלק המשותף, ולכן שתי הפצות Linux קרובות זו לזו הרבה יותר מאשר כל אחת מהן קרובה למערכת Unix אחרת. כדאי לזכור זאת כאשר משווים בין Linux ו-FreeBSD כפלטפורמות שרת, שם הליבה וסביבת המשתמש הבסיסית נבנות על ידי פרויקט אחד ומשוחררות יחד. ב-Linux, הרכיבים הללו מגיעים ממקורות (upstreams) נפרדים, וההפצה היא הגורם שגורם להם לעבוד יחד בהרמוניה.

היסטוריה של הפצות Linux בשלוש משפחות

שלושה פרויקטים שהחלו ב-1993 וב-1994 הפכו למשפחות: Slackware, Debian ו-Red Hat. כמעט כל image בלוח בקרה של VPS כיום הוא אחת מהן או צאצאית שלהן. צאצאית יורשת את פורמט החבילות, את מבנה הקבצים ובדרך כלל את הרגלי ה-release, וזו הסיבה שנגזרת של Debian עדיין מרגישה כמו Debian גם לאחר הסרת המיתוג.

העצמאיות ראויות לשורה משלהן, כיוון שהן לא פוצלו מאף אחת אחרת. Arch, Gentoo, Alpine, NixOS ו-Void כתבו כל אחת מנהל חבילות משלה וחוקים משלה. שתיים מהן, Arch ו-Alpine, הגיעו בכל מקרה לרשימת ה-images של ספק השרתים שלכם, מסיבות שלא היו קשורות כלל לשולחן העבודה.

1992: ההפצות לפני המשפחות

MCC Interim Linux הופיעה בפברואר 1992, והורכבה על ידי Owen Le Blanc במרכז המחשוב של מנצ'סטר (Manchester Computing Centre). היא ריכזה את ה-kernel ואת כלי ה-GNU (ראשי תיבות של GNU's not Unix) על גבי זוג תמונות תקליטון (floppy images) עם מתקין מונחה תפריטים. היא נוצרה כיוון שביצוע פעולות אלו באופן ידני גזל יום עבודה שלם.

SLS (Softlanding Linux System), ששוחררה על ידי Peter MacDonald בשנת 1992, הרחיקה לכת והוסיפה את X (מערכת החלונות X Window System) ואת רשתות ה-TCP/IP. SLS היא הסיבה לכך שהמונח הפצה (distribution) קיבל את משמעותו הנוכחית. היא הייתה גם רצופה בבאגים ומתוחזקת באיטיות, ובשנת 1993 החליטו שני אנשים בנפרד לתקן זאת. האחד בנה אותה מחדש. השני התחיל מחדש עם כללים כתובים.

Slackware, 1993: המשפחה הוותיקה ביותר שעדיין מופצת

Patrick Volkerding הפיץ את Slackware 1.00 ב־16 ביולי 1993, לאחר שנבנתה על בסיס SLS תוך תיקון באגים. היא מתוחזקת עד היום, מה שהופך אותה להפצת ה-Linux הוותיקה ביותר ששרדה.

חבילת Slackware היא ארכיון tar דחוס המכיל בתוכו סקריפט התקנה. אין בה פתרון תלויות: שום רכיב לא בודק אם הספרייה שהחבילה החדשה שלכם דורשת כבר קיימת על הדיסק. החלטה בודדת זו עיצבה את כל השאר. אם הכלי אינו פותר תלויות, הסט המופץ חייב להיות עקבי מעצם בנייתו, ולכן המהדורות נדירות ושמרניות. Slackware 15.0 הגיעה בפברואר 2022, שש שנים לאחר 14.2.

המשפחה קטנה. המהדורות המוקדמות ביותר של SUSE באמצע שנות ה-90 נבנו על בסיס Slackware, לפני שהפרויקט פנה לדרכו העצמאית עם YaST ומאוחר יותר עם פורמט החבילות RPM. החלק האחרון מבלבל אנשים. SUSE ו-openSUSE משתמשות בחבילות RPM, והן אינן נגזרות של Red Hat. הפורמט נדד, אך השושלת לא.

Debian, 1993: חוזה חברתי וצינור הפצה בעל שלוש סוויטות

איאן מרדוק הכריז על Debian ב-16 באוגוסט 1993, שלושה שבועות לאחר Slackware ומאותה סיבה. השם משלב את שם בת זוגו דברה עם שמו שלו. המניפסט של Debian פורסם בינואר 1994 וקבע את התנאים: ההפצה תתוחזק באופן פתוח על ידי מתנדבים, ולא על ידי חברה.

לאחר מכן ניסחה Debian את התנאים בכתב. ה-Debian Social Contract וה-DFSG (הנחיות התוכנה החופשית של Debian) אומצו ביולי 1997, וה-DFSG הפכו לבסיס של ה-Open Source Definition בשנת 1998. מסמך שנכתב כדי להכריע מה שייך להפצה אחת, סיים בהגדרת קטגוריית רישוי עבור התעשייה כולה. זו גם הסיבה לכך של-sources.list שלך יש רכיבים: main מכיל תוכנה שעומדת בהנחיות, contrib ו-non-free מכילים את מה שלא, ו-Debian 12 הוסיפה את non-free-firmware כדי שמחשב נייד עם כרטיס אלחוטי יוכל לבצע התקנה ללא צורך בחיפוש ידני אחר דרייברים.

הכלים הם הירושה הנוספת. dpkg מתקין חבילה אחת ומסרב לפעול כאשר משהו חסר, תוך הדפסת dpkg: dependency problems prevent configuration of. APT (כלי חבילות מתקדם), שהפך לברירת המחדל עם Debian 2.1 בשנת 1999, הוא השכבה שמחשבת מה עוד יש להוריד ובאיזה סדר. כל פקודת apt בכל נגזרת של Debian נובעת מעבודה זו.

מכונת השחרור כוללת שלוש סוויטות וכלל אחד. מתחזק מעלה חבילה ל-unstable, ששם הקוד הקבוע שלה הוא sid. סקריפט מעביר את החבילה ל-testing לאחר כ-5 עד 10 ימים, אם היא נבנתה בהצלחה בארכיטקטורות השחרור ולא צברה באגים קריטיים חדשים. לאחר מכן ה-testing עובר הקפאה (freeze), צוות השחרור מנקה את מה שנותר, ו-stable משתחרר כאשר רשימת הבאגים קצרה מספיק. לא לפי תאריך. זו הסיבה ש-Debian stable נראית ישנה ומתנהגת היטב: מספרי הגרסאות נעצרים בזמן ההקפאה, בעוד תיקוני אבטחה ממשיכים לעבור backport לתוכם.

גם הממשל מעוגן בכתב, עם ראש פרויקט נבחר והחלטות כלליות מחייבות. בשנת 2014 המנגנון הזה בחר ב-systemd כמערכת ה-init המוגדרת כברירת מחדל, והאנשים שלא הסכימו לכך פיצלו את הפרויקט ל-Devuan, שהוציאה את השחרור הראשון שלה ב-2017. Debian לא הייתה ההפצה הראשונה שביצעה את המעבר הזה וגם לא האחרונה, והסיבות לכך שזה המשיך לקרות, לצד ההתנגדויות שהתבררו כנכונות, מתועדות ב-תיאור האופן שבו systemd החליפה את SysV init. הנגזרות הגדולות יותר הן Ubuntu, Raspberry Pi OS, Proxmox VE, Kali ו-Linux Mint.

Red Hat, 1994: RPM, והפיצול ל-Fedora ו-RHEL

Marc Ewing הפיץ את הגרסה הראשונה של Red Hat Linux סביב ליל כל הקדושים של 1994. החברה של Bob Young רכשה אותה ב-1995, ושניהם בנו את העסק הראשון בתחום ה-Linux שמכר תמיכה במקום תוכנה. Red Hat הונפקה בבורסה ב-11 באוגוסט 1999. IBM השלימה את רכישת החברה ביולי 2019 תמורת כ-34 מיליארד דולר, ומאז ההפצה שעליה מאושרת רוב תוכנות הארגונים נמצאת בבעלות IBM.

התרומה הטכנית המתמשכת היא RPM (ראשי תיבות של Red Hat package manager), שנכתב על ידי Erik Troan ו-Marc Ewing עבור Red Hat Linux 2.0 בשנת 1995. חבילת RPM מצהירה על התלויות שלה, והיא מיוצרת מתוך קובץ spec, שהוא מתכון בנייה שכל אחד יכול להריץ. התכונה השנייה הזו היא שאפשרה מאוחר יותר בנייה מחדש (rebuild) עצמאית של המוצר הארגוני של Red Hat.

Red Hat Linux 9 משנת 2003 הייתה האחרונה בשושלת המקורית. החברה פיצלה אותה לשניים: Fedora Core 1 בנובמבר 2003 כגרסת הקהילה המהירה, ו-RHEL (ראשי תיבות של Red Hat Enterprise Linux), שהחלה כ-Advanced Server 2.1 בשנת 2002, כגרסה האיטית בתשלום. הסיבה ברורה. מוצר אחד לא יכול להיות גם המקום שבו מנסים גרסאות חדשות וגם הפלטפורמה שעליה בנק מריץ מערכות ללא שינוי במשך עשר שנים. שני החצאים מקושרים: גרסה ראשית של RHEL מתפצלת מגרסת Fedora, עוברת ייצוב, ואז מוקפאת. כלי ניהול החבילות עבר באותו לוח זמנים, מ-yum בשנות ה-2000 ל-dnf כברירת המחדל של Fedora בשנת 2015, עם rpm מתחת לשניהם.

מדוע CentOS חדלה מלהיות גרסה חינמית של RHEL

פרויקט CentOS החל בשנת 2004 עם מטרה פשוטה: לקחת את חבילות המקור שפרסמה Red Hat, להסיר מהן את סימני המסחר, לקמפל אותן מחדש ולהפיץ את התוצר בחינם. במשך עשור היא הפכה להפצת השרתים החינמית הסטנדרטית, ובשנת 2014 Red Hat הטמיעה את הפרויקט בתוך החברה.

ב־8 בדצמבר 2020 הודיעה Red Hat כי התמיכה ב־CentOS Linux 8 תסתיים ב־31 בדצמבר 2021, שמונה שנים מוקדם מהתאריך שפורסם במקור, וכי השם ימשיך להתקיים תחת המותג CentOS Stream. גרסת Stream אינה גרסה שנבנתה מחדש (rebuild). זהו ענף הפיתוח שממנו נגזרות מהדורות ה־minor של RHEL, ולכן היא מתקדמת בזמן לעומת RHEL במקום לעקוב אחריה. עבור מכונה שאתם מתכננים להחזיק במשך שנים, עבודה עם גרסה מתקדמת היא בחירה שגויה, כיוון שאתם מקבלים שינויים לפני הלקוחות המשלמים של Red Hat.

בשנת 2021 הופיעו שתי גרסאות שנבנו מחדש. Rocky Linux הוקמה על ידי Gregory Kurtzer, ממייסדי CentOS. AlmaLinux מומנה על ידי חברת CloudLinux. ביוני 2023 הפסיקה Red Hat לפרסם את קוד המקור של RHEL בכל מקום מלבד ב־CentOS Stream ובפורטל הלקוחות שלה. Rocky המשיכה לשאוף ליצירת גרסאות זהות לחלוטין. AlmaLinux שינתה את מטרתה לתאימות ABI (ממשק בינארי של יישומים), מה שאומר שתוכנה שנבנתה עבור RHEL תרוץ עליה, ללא הבטחה שרשימת הבאגים תהיה זהה לחלוטין. מאוחר יותר באותה שנה הקימו Oracle, SUSE ו־CIQ את OpenELA כדי לפרסם קוד מקור משותף. כל הרצף הזה, מהפיצול ב־2003 ועד לשינוי בפרסום המקור ב־2023 וההבטחות של כל גרסה כיום, מתואר בפירוט ב־סקירה המורחבת על Red Hat, CentOS, Rocky ו־AlmaLinux.

אם רשימת התמונות (images) של ספק הענן שלכם עדיין מציינת CentOS, בררו למה הכוונה לפני שתתבססו עליה.

cat /etc/os-release

NAME="CentOS Stream" הוא ענף פיתוח מתגלגל (rolling) שקודם ל־RHEL. NAME="AlmaLinux" או NAME="Rocky Linux" הן גרסאות שנבנו מחדש ועוקבות אחריה, עם חלון תמיכה של עשר שנים.

Ubuntu, 2004: תמונת מצב של Debian unstable, על פי לוח שנה

Ubuntu 4.10 שוחררה ב־20 באוקטובר 2004, במימונו של Mark Shuttleworth. הקשר שלה ל־Debian הוא טכני ולא סנטימנטלי. כל מחזור פיתוח נפתח בייבוא חבילות מ־Debian unstable למהדורה החדשה של Ubuntu. הייבוא נמשך עד שלב ה־Debian Import Freeze במהלך המחזור, ולאחריו Ubuntu מנהלת את השינויים שלה בעצמה. חבילות רבות ב־Ubuntu הן חבילות Debian בתוספת דלתא (delta), וה־changelog מציין זאת.

החצי השני הוא לוח השנה. Debian משוחררת כשהיא מוכנה. Ubuntu משוחררת באפריל ובאוקטובר, ומספר הגרסה הוא התאריך: 24.04 יצאה באפריל 2024. כל מהדורת אפריל שנייה היא LTS (תמיכה לטווח ארוך), וזה מה שספק שירות מתכוון אליו כשהוא מציע Ubuntu ללא סיווג נוסף. איזו מהשתיים מתאימה לשרת היא הנושא המלא של בחירה בין Ubuntu LTS למהדורות ביניים, ומעבר מ־LTS אחת לבאה אחריה כולל הליך משלו, המכוסה ב-שדרוג מ־24.04 ל־26.04.

פרט אחד מפיל מנהלי שרתים מדי שנה. הארכיון של Ubuntu מחולק לרכיבים. main מתוחזק על ידי Canonical לאורך כל תקופת התמיכה המלאה. universe מתוחזק על ידי הקהילה, והבטחת האבטחה שלו שונה. apt install לא מציג מידע על ההבדל. פקודה אחת מציגה זאת:

apt-cache policy nginx

שורת מאגר (repository) שמסתיימת ב־/main משמעותה שצוות האבטחה של Canonical אחראי על אותה חבילה. שורה שמסתיימת ב־/universe משמעותה שהקהילה אחראית עליה. בדקו זאת עבור כל רכיב החשוף לאינטרנט.

Arch, 2002: הפצות מתגלגלות והמחיר של שדרוג חלקי

Judd Vinet שחרר את Arch 0.1 ב-11 במרץ 2002, עם מנהל חבילות שהוא כתב בעצמו, pacman, ומתכוני בנייה שהם סקריפטים פשוטים של shell. ל-Arch אין גרסאות הפצה כלל. מדיה ההתקנה היא תמונת מצב מתוארכת של אותם מאגרים מתגלגלים, כך שמכונה שהותקנה ב-2019 ועודכנה מדי שבוע מריצה את אותה Arch כמו מכונה שהותקנה היום. ה-AUR (מאגר המשתמשים של Arch) מכיל מתכוני בנייה שנתרמו על ידי משתמשים. אלו הם מתכונים, לא חבילות שעברו בדיקה, לכן קריאת ה-PKGBUILD לפני הרצתו היא חלק מהעבודה.

למודל המתגלגל יש מצב כשל אחד, והוא נגרם בכל פעם באשמת המשתמש. התקנה של חבילה בודדת באמצעות pacman -Sy foo מרעננת את מסד נתוני החבילות ולאחר מכן מתקינה קובץ בינארי חדש המקושר לספריות חדשות יותר מאלו הקיימות על הדיסק. תוכניות קורסות אז כך:

error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

הפעולה הנתמכת היא pacman -Syu, שמעדכנת את הכל יחד. הפרויקט גם מפרסם הודעות חדשות המציינות כי נדרשת התערבות ידנית לפני שדרוגים מסוימים, והרצת השדרוג ללא קריאתן עלולה להשאיר מכונה שאינה עולה.

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

Alpine: הפצה קטנה שהתפרסמה בזכות מכולות

Alpine החלה בסביבות שנת 2005 כפיצול (fork) של LEAF (ראשי תיבות של Linux embedded appliance framework), שבעצמו נגזר מ-Linux Router Project. נתנאל קופה בנה אותה עבור מכשירי קצה (appliances) ולא עבור שולחנות עבודה. היא מחליפה את רוב רכיבי ה-userland המקובלים: musl במקום ספריית ה-C של GNU,‏ BusyBox במקום כלי ה-core utilities של GNU,‏ OpenRC במקום systemd, ו-apk כמנהל החבילות. גרסה 3.0 של Alpine משנת 2014 הייתה השחרור שעבר לשימוש ב-musl.

מכולות הפכו אותה לפופולרית. שכבת בסיס של Alpine היא שבריר מהגודל של בסיס Debian או Ubuntu, ולכן החל משנת 2016 היא הפכה לתמונת בסיס נפוצה, ואנשים רבים שמעולם לא התקינו Alpine הריצו אותה מדי יום.

המחיר הוא ש-musl אינה glibc, והפער מתבטא בבאגים שנראים לא קשורים. קובץ בינארי המקושר ל-glibc נכשל ב-Alpine עם הודעה ששולחת אנשים לחפש קובץ שכבר קיים:

sh: ./myapp: not found

התוכנית קיימת. מפרש ה-ELF שלה לא, כיוון שהטוען (loader) של glibc חסר. Python היא הפתעה נפוצה נוספת: חבילות wheel מוכנות שנבנו עבור manylinux לא יותקנו על musl, ולכן pip חוזרת להידור ממקור (compiling from source) ועוצרת כאשר לא מותקן מהדר. תקן ה-wheel מסוג musllinux משנת 2021 פתר זאת עבור פרויקטים שמפרסמים חבילות כאלו, ועבור אף אחד אחר.

כמערכת הפעלה מארחת על גבי VPS, ההתקנה של Alpine קטנה והעדכונים מהירים, אך היא מוציאה אתכם מהמסלול שרוב התיעוד מניח. כל מדריך שמורה לכם להריץ systemctl enable דורש תרגום ל-rc-update add.

הדור הבלתי-משתנה: עדכונים אטומיים ושרתים מבוססי Image

הענף החדש ביותר משנה את מודל העדכון במקום את רשימת החבילות. מערכת מבוססת ostree שומרת על /usr במצב לקריאה בלבד (read-only). עדכון הוא עץ מערכת קבצים חדש ומלא, אשר יורד, מוכן להפעלה, ומוחלף ב־reboot הבא. העץ הקודם נשאר כרשומת אתחול, כך שעדכון כושל מבוטל על ידי אתחול מחדש לתוך הגרסה הישנה.

Fedora Silverblue הביאה גישה זו לשולחן העבודה ב-2018, ו-Fedora CoreOS הביאה אותה לשרתים ב-2019, לאחר ש-Red Hat רכשה את CoreOS ב-2018. הפצת Flatcar Container Linux המשיכה את דרכה של Container Linux המקורית לאחר שזו הופסקה ב-2020. מערכת openSUSE MicroOS מגיעה לאותה תוצאה באמצעות snapshots של btrfs ו-transactional-update. בשנת 2024 הוסיפה Red Hat מצב מבוסס Image ל-RHEL, הבנוי על bootc, שבו מערכת ההפעלה מופצת כ-container image והמכונה מתעדכנת על ידי הפנייה לתג (tag) חדש. Talos Linux מרחיקה לכת ומסירה את ה-shell ואת ה-SSH לחלוטין: המכונה מוגדרת דרך API, כך שאין למה להתחבר. NixOS, ששוחררה לראשונה ב-2007, מגיעה מכיוון אחר. המערכת כולה נבנית מקובץ הגדרות דקלרטיבי אחד, וגרסאות קודמות נשארות זמינות לאתחול.

ספק השרתים שלכם כנראה לא מציע אף אחת מאלו כ-image בלחיצת כפתור, כיוון שהם מצפים שההגדרה תתבצע באתחול הראשון על ידי Ignition או cloud-init, ולא על ידי מנהל מערכת שעורך קבצים דרך SSH. פתרונות אלו משתלמים בניהול מכונות רבות וזהות, מצב שבו תמצאו את עצמכם ברגע שתתחילו לנהל כמה שרתי Linux בו-זמנית ותזדקקו לכך שכל אחד מהם יהיה זהה לאחרים באופן שניתן להוכחה.

כמה זמן נתמכת גרסה?

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

[
  {
    "distro": "Alpine 3.x",
    "standard_years": 2,
    "extended_total_years": 2
  },
  {
    "distro": "Debian 13",
    "standard_years": 3,
    "extended_total_years": 5
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "standard_years": 5,
    "extended_total_years": 10
  },
  {
    "distro": "AlmaLinux 10",
    "standard_years": 10,
    "extended_total_years": 10
  },
  {
    "distro": "RHEL 10",
    "standard_years": 10,
    "extended_total_years": 13
  }
]

Alpine תומכת בכל ענף 3.x למשך 2 שנים; זו הסיבה שהיא מתאימה יותר לתמונת מכולה (container image) שאתם בונים מחדש לעיתים קרובות, מאשר למערכת הפעלה מארחת שאתם מותירים ללא שינוי. צוות האבטחה של Debian מכסה גרסה יציבה למשך כ-3 שנים, ולאחר מכן צוות ה-LTS ממשיך לתמוך בארכיטקטורות הנפוצות עד ל-5 שנים בסך הכל. גרסת Ubuntu LTS מעניקה לכם 5 שנים עבור חבילות ב-main, ומנוי Ubuntu Pro מרחיב זאת ל-10 שנים, בחינם לשימוש אישי על מספר קטן של מכונות. RHEL 10 מפרסמת 10 שנים, אשר תוספת ה-extended life cycle support בתשלום מאריכה ל-13. AlmaLinux 10 תואמת לחלון הזמן של RHEL העומד על 10 שנים ללא צורך במנוי כלל, וזו הסיבה המלאה לקיומן של הפצות ה-rebuild.

ל-Arch אין שורה כאן, כיוון שהפצה מתגלגלת (rolling distribution) אינה כוללת גרסאות לתמיכה. המספר שקובע עבור Arch הוא כמה זמן ניתן להשאיר מכונה ללא מגע, וזה נמדד בשבועות.

מדוע רשימת הדימויים (images) של ה-VPS שלכם נראית כך

ספק שירות מפיץ את הדימויים שהלקוחות מבקשים לפי שם, ואלו מותקנים באופן אוטומטי על ה-hypervisor שלו. זו הסיבה שכמעט כל רשימה נפתחת ב-Ubuntu LTS וב-Debian stable, מוסיפה AlmaLinux או Rocky עבור משתמשים שהתוכנה שלהם מאושרת לעבודה מול RHEL, ושומרת את Alpine, Arch ו-Fedora להמשך הרשימה. ברגע שתבינו מהו VPS וכיצד הדימוי מגיע לדיסק, התבנית תהיה ברורה: הספק בוחר מערכות הפעלה שעומדות בהתקנה ללא השגחה ונשארות נתמכות לזמן רב יותר מהזמן הממוצע שבו לקוח מחזיק בשרת.

הבחירה הזו מחייבת אתכם ליותר מאשר רק מנהל חבילות. היא קובעת את תהליך השדרוג שתבצעו בעוד שלוש שנים, ואלו שונים לחלוטין בין משפחות הפצה. Debian ו-Ubuntu תומכות בשדרוגי גרסה מרכזיים במקום (in-place). משפחת Red Hat מבצעת אותם באמצעות leapp. ל-Arch אין שדרוג מכיוון שאין לה גרסאות. השדרוג ב-Alpine מתבצע על ידי עריכת /etc/apk/repositories והרצת apk upgrade --available. הבחירה גם קובעת אילו תוכנות תוכלו להתקין ללא הוספת מאגר צד-שלישי, מי מפיץ את התיקון כאשר מופיע ערך CVE (פגיעויות וחשיפות נפוצות) עבור רכיב שאתם מריצים, ואיזו מערכת init וספריית C התוכנות העתידיות שלכם יניחו שקיימות.

ישנה השפעה נוספת שקל לזלזל בה. רוב התשובות שנכתבות באינטרנט מניחות נתיב של משפחת Debian או משפחת Red Hat, לכן בחירה מחוץ לשתי אלו משמעותה תרגום הוראות לאורך כל חיי המכונה. בחרו את המשפחה שמדיניות השחרורים שלה תואמת את התדירות שבה אתם מוכנים לגעת בשרת, ואז היצמדו אליה. החלפת החבילות שמותקנות מעל היא קלה. החלפת ההפצה שמתחתן משמעותה בנייה מחדש של השרת.

FAQ

לאיזו משפחת הפצות Linux שייך השרת שלי?

הריצו את cat /etc/os-release. השדה ID מציין את שם ההפצה והשדה ID_LIKE את המשפחה שלה; כך למשל, מכונת Ubuntu תדווח על ID_LIKE=debian ומכונת AlmaLinux תדווח על ID_LIKE="rhel centos fedora". מנהל החבילות הוא סימן מזהה נוסף. apt ו-dpkg מעידים על משפחת Debian, dnf ו-rpm על משפחת Red Hat, apk על Alpine, ו-pacman על Arch.

האם CentOS היא עדיין גרסה חינמית של RHEL?

לא. CentOS Linux 8, ה-rebuild האחרון תחת שם זה, הגיע לסוף דרכו ב-31 בדצמבר 2021, ו-CentOS Linux 7 הגיע לסוף חייו ב-30 ביוני 2024. הפרויקט שנותר, CentOS Stream, הוא הענף שממנו נבנות גרסאות ה-minor של RHEL, ולכן השינויים מגיעים אליו לפני שהם מגיעים ל-RHEL ולא אחריו. ה-rebuilds החינמיים שתפסו את התפקיד הישן הם AlmaLinux ו-Rocky Linux, שניהם עם חלון תמיכה של עשר שנים.

מדוע Debian stable מפיצה גרסאות ישנות כל כך?

מכיוון שמספר הגרסה קופא בעוד התיקונים ממשיכים להגיע. Debian מבצעת backport לתיקוני אבטחה לתוך הגרסה שהפיצה במקום לייבא גרסה חדשה מה-upstream, כך שחבילה שמציגה 2.4.57-2+deb13u1 יכולה להכיל תיקון שפורסם בשבוע שעבר. הסיומת שאחרי גרסת ה-upstream היא ה-revision של Debian, והפקודה apt changelog <package> מפרטת מה נכלל בה. הערכת רמת האבטחה של שרת Debian לפי מספרי הגרסאות מובילה תמיד למסקנה שגויה.

האם כדאי להריץ הפצה מתגלגלת (rolling release) כמו Arch על שרת VPS?

רק אם אתם מתכננים לעדכן אותה באופן קבוע. הפצה מתגלגלת מניחה שכל מכונה שואפת להגיע לסט החבילות העדכני ביותר, לכן עדכון חבילה אחת בלבד באמצעות pacman -Sy foo יוצר אי-התאמה בספריות ושגיאות כגון cannot open shared object file. הריצו את pacman -Syu באופן סדיר, קראו את דף החדשות של הפרויקט לפני כל הרצה, והמערכת תישאר יציבה. אם תזניחו את המערכת למשך שנה, השדרוג הראשון יהיה מסוכן.

מה משנה בפועל הפצה בלתי-ניתנת לשינוי (immutable) או אטומית?

היא משנה את מועד החלת העדכונים ואת הדרך שבה מבטלים אותם. ה-/usr מותקן במצב קריאה בלבד (read-only), עדכון מוכן כעץ מערכת חדש ומלא, והמעבר מתבצע בעת אתחול (reboot), כאשר העץ הקודם נשמר כרשומת אתחול לצורך חזרה לאחור (rollback). אתם מקבלים מכונה שהיא או מעודכנת לחלוטין או שלא, ללא מצב ביניים של עדכון חלקי. אתם מוותרים על התקנת תוכנה באמצעות עריכת קבצים במקום, ולכן היישומים עוברים למכולות (containers) או לחבילות שכבות (layered packages).