ההיסטוריה של הפצות 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) על גבי זוג תקליטונים עם תוכנית התקנה מבוססת תפריטים. היא נוצרה כיוון שביצוע פעולות אלו באופן ידני גזל יום עבודה שלם.

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 דחוס המכיל בתוכו סקריפט התקנה. אין בה פתרון תלויות (dependency resolution): שום רכיב לא בודק אם הספרייה שהחבילה החדשה שלך דורשת כבר קיימת על הדיסק. החלטה בודדת זו עיצבה את כל השאר. אם הכלי לא פותר תלויות, הסט המופץ חייב להיות עקבי מעצם בנייתו, ולכן הגרסאות נשארות נדירות ושמרניות. Slackware 15.0 הגיעה בפברואר 2022, שש שנים לאחר 14.2.

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

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

Ian Murdock הכריז על Debian ב-16 באוגוסט 1993, שלושה שבועות לאחר Slackware ומאותה סיבה. השם משלב את שם בת זוגו Debra עם שמו שלו. ה-Debian Manifesto פורסם בינואר 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 (Advanced Package Tool), שהפך לברירת המחדל עם Debian 2.1 בשנת 1999, הוא השכבה שמחשבת מה עוד יש להוריד ובאיזה סדר. כל פקודת apt בכל נגזרת של Debian היא צאצא של עבודה זו.

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

הממשל רשום גם הוא, עם מנהל פרויקט נבחר והחלטות כלליות מחייבות. בשנת 2014 המנגנון הזה בחר ב-systemd כמערכת ה-init המוגדרת כברירת מחדל, והאנשים שלא הסכימו לכך יצרו את ה-fork שנקרא Devuan, שביצע את ההפצה הראשונה שלו ב-2017. הצאצאים הגדולים יותר הם 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 כדי לפרסם קוד מקור משותף.

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

cat /etc/os-release

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

Ubuntu 20.04: תמונת מצב של 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 user repository) מכיל מתכוני בנייה שנתרמו על ידי משתמשים. אלו מתכונים, לא חבילות שעברו בדיקה, לכן קריאת ה-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 כפיצול של LEAF (Linux embedded appliance framework), שבעצמו נגזר מ-Linux Router Project. נתנאל קופה (Natanael Copa) בנה אותה עבור התקני קצה (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 interpreter שלה אינו קיים, כיוון שה-loader של glibc חסר. Python היא הפתעה נפוצה נוספת: חבילות wheel מוכנות שנבנו עבור manylinux לא יותקנו על musl, ולכן pip חוזרת להידור ממקור (compiling from source) ונעצרת כאשר לא מותקן מהדר. תקן ה-musllinux wheel משנת 2021 פתר זאת עבור פרויקטים שמפרסמים חבילות כאלו, אך לא עבור אף אחד אחר.

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

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

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

Fedora Silverblue הביאה גישה זו לשולחן העבודה ב-2018, ו-Fedora CoreOS הביאה אותה לשרתים ב-2019, לאחר ש-Red Hat רכשה את CoreOS ב-2018. הפצת Flatcar Container Linux המשיכה את Container Linux המקורית לאחר שזו הופסקה ב-2020. הפצת openSUSE MicroOS מגיעה לאותה תוצאה באמצעות btrfs snapshots ו-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) שאתם בונים מחדש לעיתים קרובות, מאשר למארח (host) שאתם מותירים ללא שינוי. צוות האבטחה של Debian מכסה גרסה יציבה (stable) למשך כ-3 שנים, ולאחר מכן צוות ה-LTS ממשיך לתמוך בארכיטקטורות הנפוצות עד לסך כולל של כ-5 שנים. גרסת Ubuntu LTS מעניקה לכם 5 שנים עבור חבילות ב-main, ומנוי Ubuntu Pro מרחיב זאת ל-10 שנים, בחינם לשימוש אישי על מספר קטן של מכונות. RHEL 10 מפרסמת 10 שנים, אשר תוספת התמיכה בתשלום למחזור חיים מורחב מאריכה ל-13. AlmaLinux 10 תואמת לטווח הזמן של RHEL העומד על 10 שנים ללא צורך במנוי כלל, וזו הסיבה היחידה לקיומן של הפצות ה-rebuild הללו.

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

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

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

הבחירה הזו מחייבת אתכם ליותר מאשר מנהל חבילות בלבד. היא קובעת את תהליך השדרוג שתריצו בעוד שלוש שנים, ואלו שונים לחלוטין בין משפחות הפצה. Debian ו-Ubuntu תומכות בשדרוגי גרסה מרכזיים במקום. משפחת Red Hat מנהלת אותם דרך leapp. ל-Arch אין שדרוג גרסה כי אין לה גרסאות. ב-Alpine התהליך כולל עריכת /etc/apk/repositories והרצת apk upgrade --available. הבחירה גם קובעת אילו תוכנות תוכלו להתקין מבלי להוסיף מאגר צד-שלישי, מי מפיץ את ה-patch כאשר מתפרסם ערך 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, שניהם עם תמיכה מובטחת ל-10 שנים.

מדוע 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).