חודש: מאי 2005

הקטע, כרגיל בזמן האחרון, כאן.

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

שחר

הקטע עצמו בבלוגים. אני כמעט בטוח עובר.

פגשתי את שושנה ביום שישי ושכחתי לשאול אותה על הספאם.

שחר

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

והתפרסם שם עוד פוסט שלי.

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

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

ולגבי ההיסטוריה – נראה.

שחר

עבדתי עליכם – הפוסט לא פה בכלל.

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

אם המערכת תעמוד בציפיות, נעבור.

שחר

תוכנות מחשב מבצעות את מה שהן מבצעות באמצעות פניות למערכת ההפעלה. מערכת ההפעלה חושפת פעולות לביצוע באמצעות “API”, או “Application Program Interface”.

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

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

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

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

כדי להריץ תוכנה יש צורך לפתוח תהליך חדש לצורך התוכנה החדשה, לטעון את התוכנה אל תוכו ולהתחיל אותה. בלינוקס הדבר מבוצע באמצעות שתי פקודות. fork, אשר מפצל את התהליך הנוכחי לשני תהליכים, אב ובן, וממשיך לבצע את שניהם מהקוד הקיים, ו-exec, שמחליף את תוכן הביצוע של התהליך הנוכחי בתוכן שנטען מקובץ. קוד טיפוסי לביצוע הפעולה הנ”ל בלינוקס יבצע fork, ותהליך הבן יבצע exec. התוצאה – שני תהליכים, אחד בן של השני, ושהבן מריץ תוכנה חדשה.

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

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

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

בפרט, כחלק מהמרת rsyncrypto לעבודה על חלונות, אני צריך להריץ תוכנה אחרת, תוך שאני מפנה את היציאה של אותה תוכנה לתוכנה שלי. הדרך לעשות את זה היא באמצעות ייצירת pipe (צינור נתונים), וחיבורו ליציאה של התהליך לפני שהופכים אותו ל-gzip, התוכנה שאותה רוצים להריץ.

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

בחלונת אנחנו מגלים תופעה מדאיגה. אין אפשרות לבצע את הפעולה הזו באמצעות CreateProcess. זו פשוט לא אחת מהאופציות שניתנו. מכיוון שפעולת ייצור התהליך החדש ופעולת הרצת gzip קורות באותה הפקודה, אנחנו לא יכולים להשחיל את הטיפול ב-pipe בינהן. כתוצאה מכך, סדר הפעולות הינו הדבר הזוועתי הבא:
מייצרים צינור בעל קצה קורא וקצה כותב.
שומרים את מי שלא יהיה שמחובר ליציאה שלנו (תהליך האב)
מייצרים העתק של הקצה הכותב של הצינור, תוך שינוי תכונת ההעתק כך שיירש ע”י התהליך החדש (שעוד לא קיים).
מחברים את ההעתק החדש שייצרנו ליציאה של התהליך הנוכחי (תהליך האב!)
מייצרים תהליך חדש ומריצים בו את gzip
מחזירים את מי שלא יהיה שהיה מחובר ליציאה של תהליך האב לפני הריצה של gzip
סוגרים את שני ההעתקים של הקצה הכותב של הצינור

התהליך הזה:
– ארוך יותר
– פחות עמיד בהפרעות באמצע
– מבצע כמות גדולה של העתקות מיותרות
וכל זאת כי אין דרך להפריד בין ייצירת תהליך חדש לבין הרצת פקודה.

לדעתי, את מה שאנחנו רואים פה אפשר לראות בכל מקום שבו בוחרים באופציה של API עשיר פונקציונליות. הדברים שעליהם חשבו כותבי ה-API נהים קלים יותר. הבעיה היא שהדברים שעליהם לא חשבו כותבי ה-API נהים מאוד מאוד מאוד קשים. תופעה זו, בתורה, מעודדת אחידות פונקציונלית – אנשים לומדים רק את מה שה-API מאפשר להם, ומאבדים את היכולת לכתוב מחוץ לקופסה.

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

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

שחר

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

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

לא הייתי מעלה את זה בכלל, אם לא היתה עולה השאלה האמיתית – הקלטת נכשלה רק כאשר הגענו לשלב ה-Verify, שלב שרוב האנשים מוותרים עליו! שלב רישום הנתונים הסתיים, ללא כל דיווח על שגיאות או בעיות.

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

שחר

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

מי שמעוניין לשמוע אותי מסביר על מה זו מסיבת חתימת מפתחות של PGP, אבל, מוזמן להוריד:
http://wineconf.geldorp.nl/
החלק שבו אני מדבר הוא הקטן ביותר (וגם הכי פחות רלוונטי לכנס).

שחר

השבוע חזרתי מהכנס. היה ממש מוצלח.

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

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

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

ביום שלפני ההתחלה הרשמית של הכנס ישבנו בפאטיו של המלון, וטרידג’ דיבר על כמה מהדברים שבהם Wine ו-Samba יכולים לשתף פעולה. כמה פעמים אני ואחרים היינו צריכים להסביר לו את ההבדל המהותי בין הפרוייקטים: Wine הוא פרוייקט עצום, שעדיין לא הצליח להוציא גרסה יציבה ראשונה, Samba הוא פרוייקט יציב שבימים אלו עמלים על כתיבת הגרסה הרביעית שלו.

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

קבוצה אחת שלא הגיעה השנה היתה Cedega (לשעבר Transgaming). כנראה ש-Wine כבר לא כל כך מעניין אותם.

בכנסים כאלו זה השיחות הלא רשמיות שחשובות באמת. במסעדה יצא לי לדבר עם אלכסנדר על התמיכה בעברית בתוך CrossOver Office. הוא אמר שאם זה זז ל-DLL נפרד, הוא יהיה מוכן ש-Code Weavers יקמפלו את ה-DLL בעצמם. מה שמטריד אותו במיוחד בשימוש ב-ICU זה התלות של ICU בספריות של C++, תלות שהוא לא מוכן להכניס ל-CrossOver Office. אלו חדשות ממש טובות, מכיוון שאין לי את האמצעים להוציא את ICU מהמשוואה, אבל אני כן אנסה להעביר את התמיכה בעברית ל-DLL שנקרא “Uniscribe”, שם היא נמצאת בחלונות ממילא. זה יאפשר לכולם לקמפל את התמיכה בעברית ל-Wine הרגיל, אבל להפיץ אותה רק למי שמעוניין.

ועד כאן הדיווחים מהשטח. בחזרה לביצה.

שחר

אני נמצא בכנס Wineconf. כמה דיווחים מהירים:
בשיחה עם אלכסנדר, הדיקטטור הנאור של wine, הוא שאל אותי למה אני רוצה שיהיה לו מפתח PGP, והסברתי בגדול. השיחה משם התנהלה בערך כך:
אלכסנדר: “כך תדע שזה באמת אני שדוחה את התיקונים שלך ל-Wine”
שחר: “אבל אתה לא דוחה אותם, אתה שולח אותם ל-/dev/null”
א: כן, אבל כך אתה יודע שזה אני ששולח אותם לשם.
ש: למרבה הצער, לא היו הרבה תיקונים לדחות בזמן האחרון.
א: זה באמת חבל. אני אוהב לדחות את התיקונים שלך.

כמו כן, הכנס עצמו דיי מעניין. כרגע מדגימים את השיפורים ב-ReactOS, ואתמול היה הרבה דיון על איך סמבה ו-Wine יכולים לשתף פעולה.

עוד דיווחים בהמשך….

שחר