היסטוריית ה-Linux kernel: החלטות שעיצבו את המערכת

גרסה מקוצרת של היסטוריית ה-Linux kernel

ההיסטוריה של ה-Linux kernel מתחילה בגרסה 0.01 בספטמבר 1991 ומגיעה עד סדרת ה-7.x שרצה על שרתים כיום. רשימת הגרסאות היא החלק הפחות מעניין בה. מספר קטן של החלטות עיצב את אופי המערכת, ולכל אחת מהן עדיין יש השלכות על מכונה שתשכרו היום אחר הצהריים.

התאריכים ומספרי הגרסאות כאן מבוססים על kernel.org ועל היסטוריית הגרסאות שהוא מפרסם. המצב הנוכחי, נכון לאוגוסט 2026: גרסה 7.0 הגיעה ב-12 באפריל 2026, גרסה 7.1 ב-14 ביוני 2026, וגרסה 7.2 נמצאת בשלבי release candidates.

מדוע הבחירה ב-GPL בשנת 1992 עדיין רלוונטית

גרסה 0.01 פורסמה ב-17 בספטמבר 1991 תחת רישיון שטורבאלדס כתב בעצמו. הרישיון דרש הפצה של קוד המקור, והוסיף שורה בעלת משמעות רבה יותר: "אסור להפיץ זאת תמורת תשלום, אפילו לא עבור עלויות 'טיפול'". בשנת 1991 תוכנה הופצה על גבי תקליטונים, והעתקה ושליחה של תקליטונים כרוכות בעלויות. סעיף זה הפך הפצה מסחרית של Linux לבלתי אפשרית.

הוא שינה זאת. המעבר לרישיון GNU General Public License (GPL) הוכרז בהערות השחרור של גרסה 0.12 בינואר 1992 ונכנס לתוקף ב-1 בפברואר 1992. גרסה 0.95, במרץ 1992, הייתה הגרסה הראשונה שפורסמה תחתיו. כל עסק שנבנה מאוחר יותר על בסיס Linux נשען על שינוי זה.

הליבה (kernel) מופצת תחת GPL גרסה 2 בלבד, והיא מעולם לא עברה לגרסה 3. טורבאלדס סירב לכך בשנת 2007, בעיקר בשל הכלל נגד "tivoisation" ב-GPLv3, הדורש שמכשיר המפיץ קוד GPL יאפשר גם הרצה של עותק שעבר שינוי של אותו קוד. הוא התייחס לחומרה נעולה כעניינו הפרטי של היצרן. בשנת 2017 פרסמו מפתחי הליבה את ה-Kernel Enforcement Statement, המאמץ בכל זאת חלק אחד מ-GPLv3: מי שמתקן הפרה לאחר שקיבל על כך התראה שומר על הרישיון שלו, במקום לאבד אותו לצמיתות כבר בהפרה הראשונה.

לכך יש שתי השלכות על שרת. הקובץ הבינארי של הליבה שאתם מריצים נושא עמו זכות לקבל את קוד המקור התואם, כך שאף אחד לא יכול לספק לכם ליבת Linux שאינכם רשאים לבחון או לבנות מחדש. כמו כן, הודעת זכויות היוצרים על הליבה מציינת שהרישיון אינו חל על תוכניות משתמש המשתמשות בשירותי הליבה באמצעות קריאות מערכת (system calls) סטנדרטיות; זו הסיבה שמסדי נתונים קנייניים וסוכני ניטור מופצים עבור Linux מבלי להפר דבר. רישיון מתירני (permissive) יוצר לחץ הפוך, וכדאי להבין את ההבדל הזה לפני שבוחרים פלטפורמה: ראו Linux ו-FreeBSD כפלטפורמות שרתים.

מדוע הליבה המונוליטית ניצחה בפועל

ב־29 בינואר 1992, פרסם Andrew Tanenbaum הודעה שכותרתה "LINUX is obsolete" בקבוצת הדיון comp.os.minix. הוא העלה שתי טענות. ליבות מונוליטיות, שבהן מנהלי התקנים ומערכות קבצים רצים בתוך מרחב כתובות מורשה אחד, הן תכנון משנות ה־70, בעוד שמיקרו-ליבות (microkernels), שבהן רכיבים אלו רצים כתהליכים רגילים, הן העתיד. בנוסף, הוא טען כי Linux רתום ל־Intel 386 ולכן לעולם לא יהיה נייד.

הטענה לגבי הניידות נענתה באמצעות ביצוע פורטינג. גרסה 1.2 במרץ 1995 הוסיפה תמיכה ב־Alpha, ב־SPARC וב־MIPS. גרסה 2.0 ביוני 1996 הוסיפה פורט 64-ביט עבור Alpha.

הטענה לגבי התכנון נענתה באמצעות פשרה. Linux מעולם לא הפך למיקרו-ליבה. הוא קיבל מודולי ליבה הניתנים לטעינה (loadable kernel modules): קובצי אובייקט שניתן להזריק לתוך ליבה רצה ולהסירם שוב, כך שמנהל התקן מופץ בנפרד מהקובץ הבינארי של הליבה.

lsmod | head
modinfo virtio_net | head -5

lsmod מציג את מה שטעון כרגע. modinfo מדפיס את הקובץ שממנו הגיע המודול ואת הפרמטרים שהוא מקבל. בשרת וירטואלי, רוב נתיבי הדיסק והרשת הם מודולים, וזו הסיבה שאימג' ליבה אחד עולה על חומרה שהוא מעולם לא פגש.

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

העלות ש־Linux שמר עליה היא זו שיש לתכנן סביבה: מודול רץ עם הרשאות ליבה מלאות, כך שמודול פגום מפיל את המכונה כולה במקום רק תהליך אחד. כאן מורגשת הבעיה עם מודולים חיצוניים (out-of-tree). מנהל התקן של ספק שאינו נמצא ב-mainline חייב לעבור הידור מחדש מול כל ליבה חדשה, וזה מה ש־DKMS עושה במהלך שדרוג; כאשר הידור זה נכשל, ההתקן פשוט חסר לאחר ה-reboot.

מדוע נדרשו חמש-עשרה שנים להשלמת SMP

גרסת Linux 2.0 ביוני 1996 הייתה הליבה הראשונה שתמכה ב-symmetric multiprocessing (SMP), כלומר יותר מ-CPU אחד שמריץ ליבה אחת. המימוש הראשון השתמש בנעילה יחידה, ה-big kernel lock (BKL), כך שרק מעבד אחד יכול היה להימצא בתוך קוד הליבה בכל רגע נתון. לפיכך, מעבד שני סייע לעומס עבודה שמבצע חישובים ב-user space, אך כמעט ולא סייע לעומס עבודה של system calls, כיוון שאלו המתינו בתור מאחורי אותה נעילה.

הסרת הנעילה הזו ארכה חמש-עשרה שנים. המשתמשים הנותרים הועברו ל-fine-grained locking, בעיקר על ידי Arnd Bergmann, וה-BKL הוסר בגרסה 2.6.39, ששוחררה ב-18 במאי 2011. מתזמן המשימות (scheduler) התקדם באותו קצב איטי: מתזמן ה-O(1) ב-2.6.0, ה-Completely Fair Scheduler (CFS) מגרסה 2.6.23 בשנת 2007, ו-EEVDF, שהחליף את CFS בגרסה 6.6 באוקטובר 2023.

עבודה זו היא הסיבה לכך שתוכנית של 4 vCPU נחשבת כיום לעניין שבשגרה. היא גם מסמנת מגבלה שכדאי להכיר. בשרת וירטואלי משותף, הליבה שלכם מתזמנת את ה-threads שלכם, וה-hypervisor מתזמן את הליבה שלכם. הריצו את top וקראו את השדה %st. ה-steal time הוא זמן CPU שהליבה שלכם הייתה מוכנה להשתמש בו, אך המארח הקצה אותו לאורח אחר, לכן שום כוונון בתוך הליבה שלכם לא יחזיר אותו.

מדוע סדרת 2.6 שינתה את אופן בניית ה-kernel

לפני גרסה 2.6, מספרי הגרסאות הופיעו בזוגות. מספר שני זוגי ציין סדרה יציבה (2.4), ומספר אי-זוגי ציין סדרת פיתוח (2.5). גרסה 2.4 שוחררה ב-4 בינואר 2001 וגרסה 2.6 ב-17 בדצמבר 2003, כך שמשתמשים המתינו כמעט שלוש שנים לסדרה היציבה הבאה. הפצות לא יכלו להמתין, ולכן הן ביצעו backport. שני ספקים שסיפקו שניהם "2.4" הפיצו גרסאות kernel שהפרידו ביניהן אלפי תיקונים.

הפיצול בוטל לאחר 2.6. ה-mainline פותח כעת חלון מיזוג (merge window) של כשבועיים, מקבל עבודה חדשה, ולאחר מכן מריץ release candidates עד לרגיעה, ומשחרר גרסה כל 9 עד 10 שבועות; זהו הקצב ש-kernel.org עדיין מתעד. החצי השני של המודל הגיע ב-4 במרץ 2005 עם השחרור הראשון של ה-stable tree, עדכון תיקונים בלבד ל-2.6.11, שתוחזק על ידי Greg Kroah-Hartman ו-Chris Wright. ה-stable tree מקבל תיקונים ומסרב להוסיף פיצ'רים.

תופעת לוואי אחת: מספר הגרסה חדל מלהיות הבטחה. 3.0, 4.0, 5.0 ו-7.0 אינן כתיבה מחדש של הקוד. Torvalds מעלה את המספר הראשון כאשר השני גדל מספיק כדי להציק לו, וזו הסיבה ש-7.0 הגיעה אחרי 6.19 באפריל 2026. מה שחשוב עבור שרת הוא באיזה ענף ההפצה שלכם עוקבת, והאם ענף זה עדיין מקבל תיקונים.

כיצד השבר ב-BitKeeper הוליד את git באפריל 2005

החל מפברואר 2002 פותח ה-kernel באמצעות BitKeeper, מערכת בקרת גרסאות מבוזרת וקניינית מבית חברת BitMover של Larry McVoy, החל מסדרת 2.5. חברת BitMover העניקה למפתחי ה-kernel רישיון חינמי בתנאים מגבילים: אסור היה לעבוד על כלי מתחרה לבקרת גרסאות, ואסור היה לבצע הנדסה לאחור ל-BitKeeper. מפתחים רבים הסתייגו מבניית kernel חופשי באמצעות כלי שאין להם רשות לעיין בקוד המקור שלו.

הקשר נותק באפריל 2005, לאחר ש-Andrew Tridgell הציג תוכנית שמתקשרת עם מאגרי BitKeeper. ב-BitMover הגדירו זאת כהנדסה לאחור וביטלו את הרישיון החינמי. ה-kernel נותר ללא מערכת בקרת גרסאות באמצע מחזור פיתוח.

העבודה על git החלה ב-3 באפריל 2005. Torvalds הכריז עליו ב-6 באפריל. ב-7 באפריל git כבר היה בשימוש עצמי (self-hosting), כלומר ההיסטוריה של git עצמו נשמרה בתוך git. המיזוג הראשון של כמה ענפים (branches) בוצע ב-18 באפריל. ביוני 2005, git ניהל את ה-release של 2.6.12. זמן קצר לאחר מכן העביר Torvalds את התחזוקה ל-Junio Hamano וחזר לעבוד על ה-kernel.

התכנון נבע ישירות מהצורך: אלפי תורמים, ומתחזקים שמושכים קוד זה מזה דרך רשת שאף אחד לא סומך עליה. כל אובייקט מזוהה לפי ה-hash של תוכנו, כך ששינוי של בייט אחד בהיסטוריה הישנה משנה את השם של כל commit שבא אחריה. זו הסיבה ש-clone הוא עדות ולא רק טענה. כל pipeline של פריסה (deploy), כל מאגר תצורה, מארח הקוד שרוב הצוותים דוחפים אליו ו-שרת ה-git שניתן להריץ באופן עצמאי צמחו מתוך ויכוח רישוי על ה-kernel.

מה מודל ה-LTS מבטיח, ומה לא

גרסת ה-Mainline אינה הגרסה שאתם מריצים. גרסת Mainline מוחלפת בגרסה חדשה תוך 9 עד 10 שבועות. עץ ה-stable כולל תיקונים למשך מספר שבועות לאחר כל שחרור. ענפי ה-Longterm, הנכתבים בדרך כלל כ-LTS, כוללים תיקונים למשך שנים, ואלו הם הענפים שעליהם מתבססות הפצות.

גרסה 2.6.32, ששוחררה בדצמבר 2009, היא המקום שבו המודל הוכיח את עצמו. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 ו-Ubuntu 10.04 LTS כולן הפיצו אותה, והענף תוחזק עד פברואר 2016, יותר משש שנים לאחר הופעתו.

ההבטחה השתנתה יותר מפעם אחת. היא עמדה על שנתיים, ולאחר מכן על שש שנים עבור ענפים מסוימים. בשנת 2023 קיצצו מתחזקי ה-stable את ברירת המחדל חזרה לשנתיים, כיוון שביצוע backport לעצים ישנים גוזל זמן מהמתחזקים וענפים ישנים זוכים למעט בדיקות בפועל. ב-25 בפברואר 2026 פרסם Greg Kroah-Hartman תחזיות ארוכות יותר שוב, לאחר דיון עם החברות התלויות בענפים אלו, והמסגרת הנוכחית נעה בין שלוש לשש שנים.

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

אתר kernel.org מציג 6 ענפי longterm נכון לאוגוסט 2026. הענף הוותיק ביותר, 5.10, יכלול תיקונים במשך 6.0 שנים עד לסיומו ב-Dec 2026. הענף החדש ביותר, 6.18, צפוי לפעול עד Dec 2028, שהם 3.1 שנים של תיקונים.

התייחסו לתאריכים אלו כאל רף מינימום ולא כאל חוזה מחייב. התחזיות עבור 6.6 ו-6.12 שתיהן נדחו קדימה בפברואר 2026, וענף שאף אחד לא משתמש בו עלול להינטש במקום זאת. ההפצה שלכם בדרך כלל מבצעת את הבחירה עבורכם: Debian 13 מפיצה את 6.12, ו-Ubuntu 26.04 LTS מפיצה את 7.0. פער זה הוא התוכן המעשי של השאלה על LTS מול גרסאות ביניים בשרת, וזה מה שבאמת משתנה מתחת לפני השטח כאשר אתם משדרגים מ-Ubuntu 24.04 ל-26.04.

מלכודת אחת נובעת מכך. uname -r ב-Ubuntu 24.04 מדפיס משהו כמו 6.8.0-51-generic. זהו בסיס ה-upstream בתוספת ה-backports של ההפצה עצמה, לכן המספר מציין היכן הענף התחיל ולא אילו תיקונים כלולים בו. סורקים ששופטים kernel לפי מחרוזת הגרסה שלו מעלים התראות שווא נגד kernels של הפצות בדיוק מהסיבה הזו.

על מה הליבה (kernel) מתווכחת כרגע

שני ויכוחים מתנהלים כעת, ושניהם עוסקים בשאלה מי מבצע את העבודה.

Rust הוטמעה כתשתית בגרסה 6.1 בדצמבר 2022. בגרסה 7.0 הוסרה תווית הניסיוניות, כך ששפות הליבה של ה-kernel הן כעת C, assembly ו-Rust, והבנייה אינה דורשת עוד מהדר nightly. המחלוקת נוגעת לתחזוקה. מתחזק של קוד C שמשנה ממשק עלול לשבור bindings של Rust שאינו קורא, והוויכוח הוא על מי מוטלת האחריות לתקן אותם.

הוויכוח השני עוסק בתרומות של בינה מלאכותית (AI). Sasha Levin הציע מדיניות ביולי 2025, לאחר שנפח הולך וגדל של טלאים (patches) שנוצרו בסיוע מכונה הגיע לרשימות התפוצה. המסמך אושר ב-23 בדצמבר 2025 וכעת הוא מופיע בתיעוד התהליכים של ה-kernel בכתובת docs.kernel.org/process/coding-assistants.html. סוכן AI אינו רשאי להוסיף תגית Signed-off-by, כיוון ששורה זו מאשרת את ה-Developer Certificate of Origin (DCO) ורק אדם יכול לאשר זאת. סיוע מוצהר באמצעות תגית Assisted-by:, ששונתה מ-Co-developed-by: במהלך הבדיקה כיוון שכלי אינו נחשב למחבר. קוד שנוצר חייב להיות תואם ל-GPL-2.0-only. האדם ששולח את ה-patch בוחן אותו ונושא באחריות עליו.

הלחץ מאחורי המדיניות נובע מזמן הבדיקה. יצירת patch לוקחת שניות, בעוד בחינתו גוזלת ממתחזק אחר צהריים שלם. תגית אינה פותרת חוסר איזון זה. מה שהיא כן משמרת הוא המקור (provenance): ההיסטוריה ממשיכה לתעד מי חתם על כל שינוי, וזהו המאפיין שה-DCO נועד להגן עליו בשנת 2004.

מה המשמעות של היסטוריה זו עבור השרת ששכרת

• הרישיון הוא הסיבה לכך שבאפשרותך לקרוא ולבנות מחדש את ה-kernel שהספק שלך מפעיל, והסיבה לכך שתוכנה קניינית עדיין פועלת עליו.
• התכנון המונוליטי הוא הסיבה לכך שבאג בדרייבר אחד גורם לאתחול של כל המכונה, והסיבה לכך שמודול חיצוני (out-of-tree) חייב לעבור בנייה מחדש בכל שדרוג של ה-kernel.
• מודל השחרורים הוא הסיבה לכך שמספר הגרסה אינו מלמד אותך הרבה, בעוד שהענף (branch) ותאריך סוף החיים שלו מלמדים אותך כמעט הכל.
• סוג הווירטואליזציה קובע מה מותר לך לעשות: ב-KVM אתה מפעיל kernel משלך וטוען מודולים, בעוד שבווירטואליזציה מבוססת מכולות (containers) המשתפת את ה-kernel של המארח, uname -r מציג את גרסת המארח, modprobe נכשל, ומספר הגדרות sysctl הן לקריאה בלבד.

FAQ

מדוע ליבת Linux עדיין מופצת תחת GPLv2 ולא תחת GPLv3?

Torvalds החליט נגד מעבר ל-GPLv3 בשנת 2007, בעיקר בשל דרישת ה-anti-tivoisation שלה, המחייבת מכשיר שמשווק קוד GPL לאפשר הרצה של גרסה שעברה שינויים לאותו קוד. הוא רואה בחומרה נעולה עניין עסקי של היצרן. בנוסף, שינוי רישיון הוא כמעט בלתי אפשרי בפועל, כיוון שזכויות היוצרים בליבה מוחזקות על ידי אלפי תורמים ואין הסכם העברת זכויות שאפשר להסתמך עליו. הליבה מופצת תחת GPL-2.0-only בלבד, ולכן לא ניתן למזג קוד שמוצע תחת GPLv3 בלבד.

האם ליבת Linux היא ליבה מונוליטית או מיקרו-ליבה?

מונוליטית, עם מודולים הניתנים לטעינה. דרייברים ומערכות קבצים רצים בתוך מרחב הכתובות של הליבה, ו-lsmod מציג את אלו שטעונים כרגע. התוצאה היא מהירות מצד אחד וסיכון רחב מצד שני: מודול פגום עלול לגרום ל-panic בכל המכונה, בעוד שבמיקרו-ליבה היה אובד רק תהליך אחד. התמונה התרככה מאז 1992 באמצעות מערכות קבצים מסוג FUSE במרחב המשתמש ותוכניות eBPF שהליבה מאמתת לפני הרצתן.

מה ההבדל בין ליבות mainline, stable ו-longterm?

Mainline הוא העץ של Torvalds, שמשוחרר כל 9 עד 10 שבועות, ושם נוחתים הפיצ'רים החדשים לראשונה. Stable לוקח את גרסת ה-mainline העדכנית ביותר ומקבל תיקוני באגים למשך כמה שבועות. ענפי Longterm ממשיכים לקבל תיקונים במשך שנים, והם הבסיס שעליו מפיצות בונות את הליבות שלהן. אתר kernel.org מפרט את ענפי ה-longterm הנוכחיים עם תאריך סיום תמיכה משוער לכל אחד מהם.

האם ליבת Linux מקבלת קוד שנכתב על ידי בינה מלאכותית?

כן, תחת מדיניות שאומצה בדצמבר 2025. יש לציין את הכלי בתגית Assisted-by:, סוכן בינה מלאכותית אינו רשאי להוסיף שורת Signed-off-by, והקוד שנוצר חייב להיות תואם ל-GPL-2.0-only. המגיש האנושי חותם על הקוד, מה שאומר שהוא סקר את ה-patch ולוקח עליו אחריות תחת ה-Developer Certificate of Origin.

באיזו גרסת ליבה כדאי להשתמש בשרת?

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