הדברים שהכי מציקים לי בלינוקס

בלינוקס יש מבנה פעולה שונה ממה שאנשים מכירים מהעולם המסחרי של Windows או Mac.

בראש ובראשונה הוא מבוזר או מודולרי אם להשתמש במילה אחרת. מה שאומר שאפשר להרכיב את המערכת בצורה שאנחנו רוצים, כולל הגרעין. ככה אנחנו יכולים לקבל מערכת גרפית כמו שאנחנו רוצים מעורבבת בין Gnome, XFCE, WindowMaker ו Enlightenment. או להרכיב מערכת עם שרת HTTP ושרת ssh בלבד. המשחק, תאורטית, הוא אין סופי.

זו לפי הכרזות מיקרוסופט, גם תהיה הדרך של Windows בסופו של דבר.

בכל מקרה, הביזור הזה יכול לגרום גם לבעיות. למשל אני עובד בKDE אבל יש לי הרבה דברים שכתובים ב GTK או יועדו ל Gnome אשר אני משתמש בהם, מה שאומר שאני צריך להתקין ספריות של שתי הסביבות הגרפיות, במקום סביבה גרפית אחת שתשתלב (למרות שLazarus עוזר לנו לכתוב תוכנות שיתאימו לשני הסביבות -> הייתי חייב להכניס אותו גם לכאן ;)).

עוד דבר שמאוד מעצבן, זה הצורה שספריות משותפות נשמרות בשם. להבנה, ב Windows, הגרסה של ספרייה משותפת נשמרת בתוך הספרייה, באמצעות קובץ Resource אשר מותבע לאיזור מסויים, בעוד שביוניקס/לינוקס, הגרסה היא חלק מהשם של הספרייה, מה שאומר שספרייה בשם libc.so.6. כן 6 זו הגרסה, בעוד שהשם של הספרייה הוא libc.

אז איך פותרים את הבעיה של הגרסאות ? קישור סימבולי (Symbolic link אשר מוכר גם בתור symlink), אשר מצביע על קובץ אחר, ותופס את המקום רק של ההצבעה עצמה. ככה אנחנו נקבל גם ספריה בשם libc.so.

כמובן שלשיטה של מתן הגרסה כחלק מהשם יש יתרונות, כי אני יכול להחזיק במספר גרסאות לאותה ספרייה באותו מקום, בלי לגרום לבעיות, אבל זה אומר שאני חייב להשתמש או בכלי האלטרנטיבה, או לנהל בעצמי את הגרסה שאני רוצה שהתוכנה שלי תקושר אליה, כי אם אני אקשר לגרסה ספציפית (בתקווה ששאר הגרסאות לא שינו את ה API, ואז זה בכלל יהיה בעייתי), אז ברגע שהיא לא תתקיים יותר (שדרוג מערכת), אני אהיה חייב להדר מחדש את התוכנה שלי, דבר שרק יוצר בעיות וכאב ראש חדש. עוד בעיה שזה יוצר, הוא מציאת הספרייה הנכונה בעת הקישור. אני יודע: אני רואה את מאיר, צפריר וארתיום צועקים pkg-config, אבל למען האמת זה כלי שמאוד ספצפי לגישה של gcc והוא לא מתאים לצורות ששאר המהדרים עובדים בהן.

עוד דבר שמאוד מעצבן אותי בלינוקס הוא חוסר יכולת לקבל ABI אחיד בין מערכות, ובין אם זה בין כל גרסאות 2.6 של הקרנל או בין אם יש הבדל בין הפצות שונות, ולפעמים אפילו גרסאות libc שונות יכולות לגרום לחוסר תאימות ABI, בין הפצות דומות, אשר רק גרסאות שונות של ספרייה מבדילות בניהן. בWindows, יש תאימות לאחור מבחינת ABI  (למעט גרסאות קרנל גבוהות, כדוגמת Win 2000 מול XP מול Vista), גם בעדכוני קרנל קטנים, ע"י ביצוע אמולציה של פקודות ישנות יותר. מה שאומר שתוכנה שכתבתי ל Win95, למעט בעיות ספציפיות, תרוץ גם על Vista, למרות חוסר תאימות כביכול בין המערכות (למרות שיכולות להיות בעיות אחרות, הריצה עדיין תתבצע כמו שצריך), אף שהדבר מנפח את המערכת עצמה.

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

ונקנח (אף על פי שיש לי עוד כמה דברים) בכך שבלינוקס, הכל נבנה להיות C enabled, מה שאומר שכל הגישה והצורה של המערכת נבנתה לשפה אחת: C. לפני שאתם אומרים לי על פיתון, פרל וחבריהם, אני מזכיר לכם שיש לכם בתוך השפה שכבת תאימות ל C, כך שאתם אפילו לא צריכים להתאמץ בלעשות binding, אתם פשוט מכילים את ה"ראש" (header) בקובץ include/c שלכם, עם תוספות של השפה הדינאמית האהובה עליכם, ובעצם יוצרים hack שלמרות שעדיין מדובר בקוד C, אתם ניגשים אליו כאילו הוא טבעי בשפה שלכם. הגישה הזו שהכל זה C, היא בעייתית, ויוצרת מצבים מאוד אבסורדיים במערכת, שמאוד קשה להציג אותם לאלו שC שגורה ב"פיהם".

חג שמח 🙂

4 מחשבות על “הדברים שהכי מציקים לי בלינוקס

  1. ארתיום

    מס' הערות:
    בלינוקס יש תאימות של ABI לאחור — ABI של קרנל, אתה רוצה להריץ תוכנה לפני 20 שנה? אתה צריך גם ספריות libc וחבריה הישנות.

    אני נתקל בזה לא מעט. למשל, יש איזשהו רכיב שהייתי צריך להתקין על RHEL5 והוא התלונן על העדר ספריה… כשהתחלנו לחקור גילינו שהרכיב הזה מקומפל עם gcc 2.9x ולא אחר! לאחר מכן מצאנו במאגרים ספריית legacy המתאימה והתקננו.

    הבעיה, זה לא ABI או API אלא הבעיה, שאם אתה רוצה שהתכנה שלך תחייה אתה צריך אחד מאלו:
    1. לפתוח את הקוד שלה, שתיכנס למאגרי הפצה, אז יהיה מי שידאג לקמפל אותה לכל מקום
    2. לתחזוק את הגרסה ולהוציא גרסאות להפצות מודרניות.
    3. לקמפל הכל סטטית
    4. לתת למשתמש לשבור את הראש ולהשיג ספריות שכבר אף אדם שפוי לא משתמש בהם ולא מעדכן אותן ולא מתקן בהן בעיות אבטחה.

    הערה, שניה, אתה חושב ב־MS תומך בתאימות לאחור? אתה חי באשליות. בעבודה אנחנו נתקלים בבעיות האלו ביום־יום בכל מיני רכיבים ש־MS לדאגו לזרוק.

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

    הכל נבנה להיות C enabled, מה שאומר שכל הגישה והצורה של המערכת נבנתה לשפה אחת: C.

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

    חבר'ה מרדמונד ניסו לעקוף את הבעיה ויצרו COM… בואו נגיד ככה, גם מפתחי Windows כרישים שאוהבים לפתח עבורה לא סבלו את הטכנולוגיה… בקיצור זאת לא הייתה הצלחה רבה.

    רק בסיבוב השני הם הצליחו לעשות משהו טוב… וזה נקרא Dot.net…. אההה רק רגע, אבל זו בעצם לא שפה מקומפלת 😉

  2. ik_5 מאת

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

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

    ובקשר ל C enabled , אני לא מדבר על ה calling convention, אני מדבר על הצורה והגישה של המערכת עצמה, ולא רק מבחינה תכנותית. אבל אם ניקח את ה API השונים, אנחנו נראה שם לא לוקחים אף פעם בחשבון ששפות אחרות שהן לא C ו ++C ישתמשו בהן. אבל כמו שאמרתי, למי שמשתמש כל הזמן ב C, יהיה מאוד קשה להבין ולראות את מה שאני מדבר עליו.

  3. עודד

    הרעיון של ספריות פיתוח לפי גרסה הוא מצוין ועובד נהדר – אם אתה מוכן להשתמש בכל גרסה של libc אז תקרא ל-libc.so, אם אתה רוצה רק את גרסה 5 אז תקרא ל-libc.so.5 וכך הלאה (לגרסה ספציפית כרצונך). כמתחזק התוכנה אתה כמובן צריך לדאוג שאתה יודע איזו גרסה אתה צריך, ושאתה חושף את הידע הזה גם ל-linker (במידה וזה רלוונטי) וגם למנהל התלויות שלך – RPM, או dpkg או מה שזה לא יהיה. כל מערכות ההפעלה הרציניות היום מגיעות עם ספריות תאימות לכל הדברים החשובים ואתה רק צריך לדאוג שחבילת ההתקנה תדרוש אותם.

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

  4. ik_5 מאת

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

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

    למשל מה אם אני מתבסס על GTK 2.8, אבל מה לעשות שההפצה שלך באה רק עם GTK 2.11. וכל הפקודות שם של 2.8 בכלל היו deprecated עוד בגרסה 2.9.
    או מה קורה כאשר אני רוצה את gtk.so שאמור להיות בכלל היציאה האחרונה של gtk 2, אבל אז מסתבר לך שמשהו החליט להתקין בשם הזה דווקא את gtk 12.

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

כתיבת תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s