לינוס טורבאלדס: אריזת חבילות התוכנה בלינוקס זה "קוץ בתחת". אולי Valve תציל את המצב…

כתבתי בעבר כמה אני לא מרוצה מהדבר שבעבר כ"כ התגאנו בו: מנהלי החבילות. מסתבר שלינוס טורבאלדס הרבה יותר קיצוני ממני! הוא פשוט מתעב את דרך בניית חבילות התוכנה בהפצות השונות.

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

  • אחד הדברים שמונעים מגנו-לינוקס לעבוד מהקופסא (ולעבוד היטב גם אצל אדם לא טכני) הוא נושא אריזת החבילות. יש יותר מידי הפצות ויותר מידי פורמטים לחבילות הבינאריות. לינוס מעיד שאת אחד הפרוייקטים שהוא פיתח הוא ארז למקינטוש ולחלונות בלבד. ללינוקס הוא לא ארז! מדוע? מפני שתהליך יצירת חבילות בינריות בגנו-לינוקס הוא פשוט "קוץ בתחת" (06:50 בוידאו): אתה לא יוצר חבילות ללינוקס. אתה יוצר חבילה לפדורה 19, חבילה לפדורה 20, ואולי גם חבילה ל- 5 RHEL (מלפני 10 שנים). לדביאן היציב אתה לא אורז (כי הוא משתמש בספריות כ"כ ישנות ששום דבר שכתבת במאה האחרונה לא יעבוד שם…). לדביאן הלא יציב אולי תנסה לארוז חבילה, אבל גם כאן תתקל בעיה כואבת: לדביאן יש חוק שאומר שעליך להשתמש בספריות משותפות (shared libraries). אם לא תשתמש בספריות משותפות הדרך לאריזת התוכנה תהיה מייגעת. אבל אפילו אם תשתמש ב- "ספריות משותפות" תתקל בבעיה, מפני שאתה עובד בענף הלא יציב, ובספריה שאתה רוצה להשתמש בטח משתמשים עוד שני אנשים שאחד מהם משוגע… 🙂
  • כל מה שאתה רוצה ליצור זאת חבילה בינרית שתעבוד! כמובן שתרצה שתעבוד תמיד ובכל ההפצות (מבלי שמישהו ישבור את ה- ABI), ואני חושב שההפצות השונות עושות עבודה מאוד מאוד רעה. אחד הדברים שאני מקפיד עליהם בפיתוח הקרנל הוא שאף אחד לא ישבור את ה- ABI. אני נלחם בזה בכל שחרור של קרנל ואני חושב שזה עצוב. יש לנו כלל ברור בפיתוח הקרנל: אנו לא שוברים את ה- User Space. אני מאוד מאוד כועס כשאני מגלה שאנשים שוברים את ה- User Space (הרבה יותר מזה שהם כותבים שטויות). כמעט לפני כל שחרור של קרנל מגיע מפתח ואומר: "אני רוצה לשבור קצת את ה- ABI כדי לנקות דברים", ואני אומר לו: אתה לא תשבור את ה- ABI כי אני אמחץ אותך… 🙂
  • אני מסביר שוב ושוב למפתחים השונים כמה זה חשוב לשמור על ה- ABI ואז מגיעים ההפצות השונות ודופקות לזה את הצורה. הם שוברים את החבילות על ימין ועל שמאל… הם מעדכנים את glibc ואז הכל נשבר… מפתח מ- glibc אומר: יש באג בחבילה ולכן אני משחרר תיקון ואני אומר לו: זה לא באג זאת תכונה… אני לא אדבר על חבילות אחרות (יש הרבה דוגמאות), אבל זה ממש לא בסדר שלהפצות השונות לא איכפת לשבור, חדשות לבקרים, כל כך הרבה ספריות מרכזיות חשובות
  • וזה הדבר שרציתי שישתפר בלינוקס (אריזה אחודה לחבילות תוכנה), מפני שאתה לא יכול לצפות ממפתחי האפליקציות ליצור 50 מיליארד גרסאות לתוכנה שלהם (כך שיתאימו להפצות השונות).
  • אולי Valve תציל את המצב, ולא, זה לא בגלל שאני חושב שמשחקים זה דבר חשוב (לא איכפת לי, אני לא משחק משחקים). זה יקרה פשוט מפני ש- Valve לא תיצור 50 אריזות תוכנה שונות ל- Steam. היא תאלץ להשתמש בלינקים סטטיים וזה יצור קבצים בינאריים גדולים, וזה עצוב… מאחר שכל הפצה תרצה ש- Steam ירוץ אצלה, זה יאפשר ל- Valve לאלץ את הפצות הלינוקס לעבור לעבוד עם פורמט אחוד לחבילות התוכנה.

אז זאת דעתו של לינוקס ואני מסכים איתו. ההרצאה חשובה ומעניינת ולכן הזדרזתי לתקצר את החלקים החשובים שבה. עזבו תקציר: אין כמו לשמוע את המקור!

12 תגובות בנושא “לינוס טורבאלדס: אריזת חבילות התוכנה בלינוקס זה "קוץ בתחת". אולי Valve תציל את המצב…”

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

  2. צפריר: לא, הוא לא התכוון לזה… הוא מתייחס לאריזת חבילות תוכנה: מבחינתו אם פיתוח דפדפן מחייב לשבור תשתית בסיסית במכונה (נניח glibc), אז פשוט לא לעשות זאת! לעולם לא לשבור User Space. מבחינתו תתיחס לכל הבאגים שיש ב- glibc כ- features… אם התשתית הבסיסית לא תשתנה בכל ההפצות ניתן יהיה לארוז חבילות תוכנה שיעבדו בכל ההפצות

  3. לינוס לא הגון כאן.

    אמנם כלפי ה־user space יש שמירה על ה־ABI, אך מול הלקוחות המיידים שמשתמשים ב-api של הקרנל, הדרייברים, ה־ABI נשבר על ימין ועל שמאל.

    אם נשווה את זה ל-glibc ויישומים גרפיים לדוגמה, אז מול הלקוחות המיידים של glibc אמנם זה נשבר, אך אם ניקח לדוגמה toolkits, היישומים אשר עובדים מולם יכולים להמשיך לעבוד (בהנחה שהם לא מדברים ישירות מול ה-libc).

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

    בקיצור, האמת היא איפשהו שם באמצע.

  4. שלום מאיר
    חבל שלא היית בכנס (היית יכול להתקיל אותו והייתי שמח מאוד לשמוע את התגובה שלו…)

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

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

    לדעתי חייב שתהיה תשתית בסיסית יציבה איתה יעבדו כל ההפצות. לתשתית ניתן לבצע תיקוני באגים אבל מבלי שישברו את ה- ABI או את ה- User Space. ניתן להסכים שניתן לשבור זאת רק בין מחזורי LTS (שישוחררו נניח אחת ל- 3-4 שנים). במקרה זה מכסימום יארזו 2 חבילות (אחת לכל מהדורת LTS).

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

  5. מידע נוסף על השינוי האמור ב־glibc:
    http://lwn.net/Articles/416821/
    ראו קישורים משם (ורם תגובות) למידע נוסף.

    דף ההורדה של חבילת התוכנה שלינוס דיבר עליה:
    http://subsurface.hohndel.org/download/
    כמו שרואים שם, הוא לא צריך לתחזק את החבילה עבור כל ההפצות

    אני חוזר לעניין הדפדפן: נראה לך סביר שיהיה דפדפן שישמור על ממשק אחיד למשך 3-4 שנים ויתחייב לא לשבור אף אתר? כי זה מה שאתה מבקש מהפצות. יש לפיירפוקס גרסת LTS. שמתוחזקת למשך 9 חודשים. כשאובונטו קיצרו את משך התחזוקה של הגרסאות הרגילות שלהם לתשעה חודשים, כולם צחקו עליהם.

  6. צפריר:
    לגבי הדפדפן: לא כ"כ מבין את הדוגמא. הוא יכול לשנות את מראהו (מה מגביל אותו?), הוא לא אמור לשבור אף אתר אלא להיצמד לתקן ב- 100% (מבחינתי אם אתר לא עובד לפי התקן אז שהתצוגה שלו תישבר בדפדפן).

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

    לגבי התוכנה של לינוס (שמופיעה בקישור שסיפקת): יש קובץ בינארי (exe) אחד להורדה עבור חלונות, קובץ בינארי (dmg) אחד עבור מקינטוש, ועבור לינוקס בערך 1000 מילים איך להתקין בכל הפצה והפצה (כי לכל אחת מההפצות יש קובץ בינארי יעודי). לינוס כאמור לא ניסה לארוז בעצמו וההפצות עשו עבורו את העבודה, אבל אם היה רוצה לארוז בעצמו איזה טרחה גדולה זאת הייתה… (ועל כך הוא מתרעם)

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

    בכל מקרה, לינוס טוען בצדק: Valve לא תיצור "50,000" גרסאות לתוכנה שלהם. ההפצות יצטרכו להתיישר אם הם ירצו ש- Steam יעבוד בהפצה שלהם

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

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

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

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

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

  8. 1. בחלונות אני צריך ללכת לאתר, להוריד קובץ. לקוות שאין איתו בעיות (ממקור אמין), ועוד. בדביאן אני פשוט מתקין את התוכנה ממערכת ניהול החבילות. מעבר לכך, לינוס מקשר שם את החבילה עם QT. זה אומר שהוא חייב להתעדכן עם כל מה שקורה עם QT וכשיש שם עדכונים רלוונטיים, לבנות מחדש את החבילה. בהפצה סבירה זה לא התפקיד של מתחזק חבילת subsurface. החלף QT בכל ספריה נוספת שמקושרת סטאטית.

    2. במקרה של glibc התוכניות שנשברו לא נצמדו לתקן. בתקן כתוב במפורש ש־memcpy לא מעתיקה לשטח זכרון שחופף לשטח הממקור (כלומר: התוצאה במקרה כזה "לא מוגדרת").

    בפועל לפני השינוי זה במקרה עבד כל עוד ההעתקה הייתה "למעלה", כלומר: אם רציתי להזיז בלוק של 4096 בתים מהכתובת x לכתוב x+1024, השימוש ב:
    memcpy(ptr, ptr+1024, 4096)‎
    במקרה עבד. כמובן שמה שהייתי צריך לעשות (לפי התקן) הוא להשתמש ב־memmove.

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

  9. כמו שמאיר כתב, האמת היא איפשהו באמצע.
    אם ישברו את ה-ABI, הפצות לא יוכלו לשדרג לגרסא החדשה עד שכל התוכנות יתאימו את עצמם (למרות שהבאג בתוכנה – לא נכתבה לפי התקן) אם כל הספריות יקומפלו בצורה סטטית ויופצו עם התוכנה, באגים חמורים (אבטחה) עלולים להישאר לנצח.
    אני די מחבב את השיטה בלינוקס (לא להחזיק עותקים מיותרים), ואולי אפילו מסכים עם לינוס ש-make install הוא פשוט יותר מאשר apt-get/yum/pacman/yast.
     
    אני די בטוח שאם הבאג עלול לגרום ל"קרנל פאניק" ושאר מרעין בישין שגורמים לקריסה של מערכות, אז הכלל של "לא שוברים user space" היה נעלם…

  10. לצערי הרב, עדיין אין לי דעה רלוונטית בנושא 🙂
    אני עדיין לא מספיק בקיא במגנוני ניהול ואריזת חבילות 🙂
    (כמובן שלא בבניית חבילות)

    אבל אני ממש נהנתי לקרוא את הכתבה ואת הדיון שהתפתח
    😀

  11. mad_dr: לא כ"כ מסכים לגבי make_install. בדר"כ הרבה יותר קשה לקמפל ולהכין לבד קבצים בינריים של התוכנה (בעיקר בגלל נושא התלויות)

    צפריר: לגבי סעיף 1 שרשמת: זה ברור לחלוטין השימוש והצורך במנהל חבילות. לגבי שאר הנימוקים המקצועיים הרשמת: אינני מתווכח איתם, אבל בשורה התחתונה: האם לדעתך לא ניתן לפתח בהפצות מערכת אחודה להתקנת חבילות? (כזאת שתאפשר התקנה של נניח מס' גרסאות של אותה התוכנה) האם לדעתך מה שמיושם כרגע בלינוקס הוא הפתרון האולטימטיבי?

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *