מחשבות, מחשבים, ושאר דברי בלע

לפני כמה פוסטים שאלתי את השאלה הבאה:

נתון מערך בגודל NxN של פיקסלים כאשר כל הפיקסלים שחורים חוץ מאחוז מסויים מהם שאינו שחור ומפוזר באופן אקראי,
בהינתן קואורדינטה (x,y) מסויימת בתמונה, מצא במהירות את כל הנקודות שנמצאות בתוך חלון בגודל K על K (כאשר K קבוע בבעיה) שמרכזו (x,y), משהו כזה:

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

אז הנה הפתרון שלי:
נחלק את התמונה למשבצות בגודל KxK, ונשמור רשימה של כל הנקודות בכל משבצת.
כאשר מבקשים מאיתנו לתת את רשימת הנקודות בחלון מסויים, נסתכל בארבעת החלונות שהחלון הזה חותך ונסנן את כל הנקודות בארבעת החלונות שלא נמצאות בתוך החלון המבוקש.
זה הכל בעצם.
הביצועים של הפתרון הזה מעולים, כדי להכין את הגריד (Grid) נעבור על כל הפיקסלים בתמונה, ולכל נקודה נמצא בזמן קבוע את המשבצת שאליה היא שייכת.
כשממש מחפשים את הנקודות בחלון מסויים, נבדוק במקרה הגרוע 2K*2K פיקסלים (אם כל הנקודות לבנות) אבל במקרה הרגיל נבדוק הרבה פחות (ואם החלון לא מכיל נקודות כלל נדע את זה מהר מאוד).
זה הקוד של העיבוד המקדים:

הקוד הבא סופר את המספר הנקודות בתוך החלון שמרכזו (x,y)’ שימו לב שהלולאות עוברות על ארבעה ריבועים בגריד בלבד:

יתכן שאפשר לשפר את הביצועים אם נחלק את הגריד לריבועים יותר קטנים ונכלול ריבועים שלמים שנופלים בתוך החלון בלי לבדוק כל נקודה באופן פרטני, אבל לא ניסיתי.
הביצועים של הפתרון הזה די מטורפים. על Q6600 במהירות 2.4GHZ, עם תמונה בגודל 500X500 פיקסלים וחלון של 20X20, בדיקה של כמה זמן לוקח לספור את הפיקסלים בכל 250,000 החלונות האפשריים לקחה כ160 מילישניות, מה שנותן מהירות בדיקה של מעל 1500 חלונות במילישניה (או יותר ממליון וחצי חלונות בשניה), בלי תלות בגודל התמונה שנבדקת (על תמונה של 1000X1000 המהירות היתה דומה).

האפלט הבאה מדגימה את האלגוריתם. אפשר להוריד אותה מפה. הקוד כלול בתוך הJAR (אפשר לפתוח את הJAR עם תוכנה לפתיחת קבצי ZIP).
בנוסף, האפלט יכולה לרוץ כתוכנית רגילה : java -jar fast_window.jar
אפשר ללחוץ בתוך האפלט כדי לסמן את הנקודות בחלון.

הדפדפן שלך לא תומך בג’אווה, ככה האפלט ניראית (רק שהיא אינטראקטיבית) :

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

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

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

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

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

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

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

JNotify התעורר.

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

• jps : מראה תהליכי ג’אווה
• jstack : מציג את רשימת הת’רדים בתהליך ג’אווה, ומה כל אחד מהם עושה.
• jmap: מאפשר שמירה לקובץ של תמונת הזכרון (heap dump) של תהליך ג’אווה. אפשר לבחון את הקובץ עם jhat או עם VisualVM.
• jhat : מאפשר ניתוח קבצי heap dump שנוצרו בעזרת jmap.
• jconsole : ממשק פשוט שמאפשר בחינה של שימוש הזכרון, שימוש בזמן מעבד ועוד.
• visualvm: כלי חזק יותר מjconsole, שהחל מעדכון 18 של JDK 1.6.0 מגיע עם הJDK. ויז’ואל VM מאפשר גם ניתוח ביצועים פשוט (cpu and memory profiling).

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

VisualVM

אז איך בכל זאת אפשר להתחבר לתהליך ג’אווה מרוחק עם VisualVM?
התהליך קצת מורכב, ולכן אני אתעד אותו כאן:

על המחשב המרוחק:

1. צרו קובץ permissions.txt שיכיל את זה:

2. הריצו את jstatd (שמאפשר לתהליכים מרוחקים לקבל רשימה של מכונות ג’אווה שרצות על המכונה ולהתחבר אליהן) :

3. הריצו את התוכנית שלהם עם הפרמטר הבא:

על המחשב המקומי:

1. צרו תעלות SSH לשרת כך:

שימו לב שיש פה שתי ‘תעלות’:

• תעלת TCP מ1101 אל 1099 בשרת המרוחק. זו תעלה שמאפשרת להתחבר אל הjstatd ישירות.
• פרוקסי SOCKS5 שמאזין על פורט 9696

2. הפעילו את visualvm עם הפרמטרים הבאים :

שאומרים לו להשתמש בפרוקסי SOCKS5 שהקמנו.

3. מתוך VisualVM, הוסיפו לחיבור המקומי חיבור לjstatd בפורט 1101.

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

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

שרת חדש

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

למעשה הייתי מרוצה מספיק מeSecureData (אליהם עברתי מHCOOP לפני פחות משנה וחצי).
מהירות התקשורת היתה קצת מאכזבת אבל לא היו יותר מדי תקלות.
אז למה עברתי?
במסגרת העבודה שלי בface.com (כן, אני עובד בface.com, לא חושב שיצא לי להזכיר את זה פה עד עכשיו) אני עובד מול חברת אכסון בשם CentralHost בסן דייגו, ומחזיק אצלם מספר לא מבוטל של שרתים. בשנה וחצי בשנה חצי שאני עובד שם, הייתי מאוד מרוצה מהם ומרמת התמיכה שלהם – אם כי המחיר שלהם הוא גבוה משמעותית מזה של eSecureData, לפחות למכונות החזקות שאני מחזיק שם במסגרת העבודה.
בכל אופן, יש לי יחסים מצויינים עם בעל החברה, וכששאלתי אם יש לו הצעה אלטרנטיבית שתאפשר לי להעביר את השרת שלי אליו הוא הסכים לתת לי מחשב באותו מחיר שאני מקבל בeSecureData – שזה $79 לחודש, עם יותר זכרון (4 ג’יגה במקום 2 ג’יגה), ושני הרדיסקים של 500 בתצורת רייד 1 (ראי, אם הרדיסק אחד מת לא קורה כלום ופשוט מחליפים אותו) לעומת הרדיסק אחד בלבד בשרת הישן.
העברתי בעזרתו את השרת למכונה החדשה, ולמעט שינויי הגדרות קטנים בשרת הDNS שאני מריץ, ובהגדרות הDNS ברשת הדומיינים שלי הכל פשוט עובד.
אני בטוח שיהיו עוד חבלי לידה, אבל אם אתם קוראים את זה, אתם עובדים מול השרת החדש.
אז כמו תמיד, יש לי מקום לאורחים. מי שחושב לעבור שרת למשהו יותר רציני מאיכסון משותף בגודדי שיצור קשר. (רק לאנשים שמרגישים בנוח עם SSH).

BoneCP

השתמשתי בProxool בתור Connection pool לבסיס הנתונים במשך די הרבה זמן, ועם הזמן גיליתי בעיות – שאומנם די נדירות אבל מספיק חמורות כדי שאני אחפש פתרון.
חשבתי לפתור אותן בעצמי, וגיליתי שהוא לא מתקמפל על JDK מודרני. שלחתי מייל לרשימת התפוצה שלו לגבי העניין, וחודשים עברו בלי שום תגובה ובלי הודעות נוספות.
היה ריח של פרוייקט מת באוויר, וכשנתקלתי בבעיה נוספת (100% CPU בקוד של פרוקסול לעיתים נדירות), החלטתי לחפש Connection pool אחד.
בסוף הגעתי לBoneCP שאומנם מוגדר כבטא, אבל עובד היטב – וחשוב יותר – המפתח שלו עונה לאימיילים ומתקן באגים.

טיפוסי אישיות

מי שלמד פסיכולוגיה (לא אני) מכיר את העניין הזה לעומק כנראה, אבל אני מניח שרוב הקוראים פה לא למדו פסיכולוגיה אני אכנס לעניין:
במהלך שיטוטי באינטרנט בחיפוש אחרי ספרייה לDecoding של תמונות בC או C++ (יש מילה בעברית לDecoding? פענוח? פרישה?) נתקלתי בCxImage, וראיתי בדף האודות של המפתח שהוא טוען שהאישיות שלו היא מסוג INTJ.
אני די בטוח שנתקלתי בסוג הקטלוג הזה למחלקות אישיות בעבר, אבל הפעם הסתקרנתי, אם הוא INTJ אז מה אני? וכמה הדבר הזה בכלל עובד?

התחלתי לחקור, מסתבר שמדובר במבחן פסיכומטרי שמבוסס על העבודה של קארל יאנג מ1920 ופותח על ידי קתרין קוק בריגס וביתה איזבל בריגס מיירס, והמבחן קרוי על שמן: Myers-Briggs Type Indicator או MTBI.
בגדול, הרעיון הוא שהאישיות של בני אדם נקבעת על ידי ארבעה תכונות, כאשר לכל תכונה יש שני צדדים (מוחצן – מופנם, חושב – מרגיש) וכו’, ואצל כל אחד תכונה אחת מכל זוג היא יותר דומיננטית מהשניה.

הזוגות הם:

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

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

סך הכל יש ארבע ‘ביטים’ כשלכל ביט יש שתי אפשרויות, מה שיוצר 16 קומבינציות.

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

בעיית החלוקה

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

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

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

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

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

לפני קצת יותר משנה גוגל שחררו ברשיון קוד פתוח פרוייקט בשם Protocol Buffers, ובקיצור protobuf.
protobuf מגדיר שפה להגדרת מבני נתונים (IDL), ויודע לייצר קוד יעיל שקורא וכותב את אותם מבני נתונים בC++, JAVA או פייתון.
יש תמיכה חיצונית לפורמט בשפות נוספות, C#, D, רובי PHP* ועוד.
הדוגמאות שאני אתן יהיו בג’אווה, אבל השתמשתי בו גם עם C++ והוא עובד היטב גם שם.
כל מפתח מגיע מתי שהוא לשלב שבו תוכנית שהוא כותב צריכה להעביר נתונים לתוכנית אחרת (או למופע אחר של עצמה) דרך הרשת, או לשמור נתונים לקובץ כדי לקרוא אותם אחר כך.
מקובל לקודד את הנתונים בתוך הודעות, כשיש הרבה מאוד דרכים לכתוב את ההודעות, ובדרך כלל מדובר בקוד די סיזיפי שחוזר על עצמו וכתיבתו היא די משעממת (בפעם העשירית שעושים משהו כזה).
נניח שאנחנו רוצים להעביר אובייקט שמייצג אימייל על גבי הרשת (ונתעלם רגע מהפרוטוקולים המקובלים להעברת אימיילים).
לאובייקט אימייל שלנו יש שדה של שולח, אחד או יותר שדות של מקבלים, נושא, טקסט, ואפס או יותר קבצים נלווים ואפילו עדיפות.
אפשר לייצג אותו במבנה הלוגי הזה:

מה שיש לנו פה זה הגדרת הודעה תקינה בשפת הIDL של protobuf.
השפה תומכת בהגדרת חבילה (שמתורגמת לpackage בג’אווה ולnamespace בC++), וכן בהגדרות מקוננות של הודעות.
המספרים אחרי כל שורה נקראים טאגים ומשמשים לזיהוי של השדות בפרוטוקול הבינארי, ולכן אחרי שהם נקבעים אי אפשר לשנות אותם.
אפשר לראות שהשפה תומכת בהגדרה של enum, וכן ברשימות של אובייקטים (שיכולים בעצמם להכיל אובייקטים וכן הלאה).
חוץ מטיפוסים שאתם מגדירים, השפה תומכת גם בטיפוסים פנימיים למשל מחרוזת, משתנה בוליאני, מספר ברוחב קבוע (למשל ארבעה בתים), מספר ברוחב משתנה ועוד.
המספרים ברוחב משתנה מקודדים בצורה דומה קצת לקידוד של UTF8, אבל בצורה קצת יותר פשוטה:

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

חלק מהטיפוסים הנתמכים בשפה הם ברוחב קבוע, למשל מספרים בנקודה צפה (Floating point) ושלמים שמוגדרים כFIXED, למשל FIXED64 יהיה תמיד 64 ביטים או 8 בתים.
עוד על השפה אפשר לקרוא פה.

את הקובץ שמכיל את הגדרת ההודעות “מקמפלים” עם protoc, שמייצר ממנו קוד בג’אווה C++ או פייתון:

הנה דוגמא לקוד ג’אווה שמייצר הודעה, כותב אותה לקובץ, קורא אותה ומדפיס אותה בפורמט טקסטואלי:

נקמפל ונריץ:

אפשר לראות שבמפתיע הפלט הטקסטואלי הוא כמעט קובץ Swush תקני, אני נשבע שלא הסתכלתי עליו כשהגדרתי את Swush
זו דוגמא לשימוש בprotobuf בג’אווה, השימוש בC++ בשפות אחרות פשוט בצורה דומה.
כל העניין מאוד קל לשימוש, ואני ממליץ מאוד לכל מי שצריך לכתוב אובייקטים לקובץ או לרשת לבדוק את protobu.
אגב, הקוד המחולל נראה טוב מאוד, כמעט כאילו כתבתם אותו בעצמכם.

* PHP : הספריה לתמיכה בPHP היא pb4php, והיא לא מאוד מוצלחת. למרות שיתכן שבקרוב הפרוייקט יקבל PATCH משמעותי שהופך את הספריה ליותר שמישה (לפחות לצרכים שלי).

אחד המשחקים המצופים של השנה – Dragon age: Origins - יצא לפני אתמול, ואחרי שראיתי את הציונים והביקורות שהוא קיבל החלטתי לקנות אותו.

חיש מהר קניתי אותו בSteam, חנות המשחקים שלValve.
בזמן שקניתי אותו היה נראה כאילו אני מבצע הזמנה לפני שהמשחק יצא (Pre order), אבל מה שקורה בדרך כלל זה שאפשר להוריד את המשחק מראש, וברגע שהוא משתחרר (מה שהיה אמור להיות אתמול) קבצי המשחק המוצפנים עוברים תהליך של פענוח ואז אפשר לשחק.
אבל מה? מסתבר שבארצנו הקטנטונת – וגם באירופה, המשחק ישוחרר רק ביום שישי או שבת.
סתם כדי להתעצבן, בדקתי באתר הטורנטים הקרוב לביתי, ואכן – המשחק כבר שם.
שלחתי אימייל לתמיכה של Valve, בו מחיתי על כך שהם מסרו מידע שגוי שגרם לי ולאחרים לקנות את המשחק ולהצטער.
אז המשחק כבר אצלי, מוצפן – ושילמתי עליו, אבל מסיבות עלומות ומציקות אני לא מורשה לשחק בו למרות ששחקנים אחרים בעולם כן.
מעצבן מספיק כדי לפעול.
משתמשים בפורום של Steam כתבו שהם הצליחו לשחק אחרי שהתחברו לSteam תוך שימוש בVPN שמחובר לארצות הברית.
חיפשתי קצת, ולא מצאתי משהו שלא ביקש ממני כרטיס אשראי בשביל לנסות, אז חשבתי לעצמי:
השרת שמריץ את הבלוג נמצא בקנדה, רוב הסיכויים שהמשחק שוחרר בקנדה באותו תאריך כמו בארצות הברית.
החלטתי להרים שרת VPN על השרת בעזרת ההוראות פה.
ההוראות פשוטות למדי, אבל במקום לאתחל את השרת כמו שהם הציעו אחרי ההגדרות הפעלתי מחדש את pptpd:

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

פתחתי חור TCP בפיירוואל בשרת בפורט 1723, שהוא הפורט הסטנדרטי של העניין הזה, וכמובן בחרתי סיסמא חזקה עם gpw שמייצר סיסמאות שאפשר להגות (Generate pronounceable passwords), ניסיתי להתחבר דרך מכונת המשחקים שלי שמריצה חלונות 7 (מערכת מומלצת), והעסק התחבר בלי בעיה.
בדקתי את כתובת הIP שלי בwhatismyip.com ולשמחתי ראיתי שהיא הכתובת של השרת.
הפעלתי מחדש את Steam, נכנסתי מקנדה – והפלא ופלא, בתור קנדי הצלחתי להפעיל את המשחק.

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

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

אגב, הלוגו החביב בחסות creatr.

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

שני הפרוייקטים הנ”ל מתבססים על Swush כשפת הקונפיגורציה שלהם.
הAPI של Swush כבר מספיק עשיר ויציב, וממש כיף לי להשתמש בו.

מכונת האיכסון שלי, להלן איירון, כבר די מוכנה.

תצורת דיסקים ומערכת הקבצים

זו התצורה הנוכחית של הZFS באיירון:

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

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

שיתוף קבצים בין מחשבים

יש לי עוד שני מחשבים, אחד מריץ רק לינוקס, ואחד מריץ לינוקס וחלונות (במכונה וירטואלית בשביל iTunes ימח שמו), ובדואל בוט בשביל משחקים.
כדי לשתף קבצים עם הלינוקסים, הגדרתי שיתוף בNFS.
את NFS פיתחו בסאן, והמימוש שלהם הוא המימוש הטוב ביותר של NFS, הבעיה היא שהמימוש של לינוקס הוא לא ממש לפי התקן, לפחות אם נאמין לשמועה הרווחת.
בזמן העברת קבצים מלינוקס לאופן-סולריס על גבי NFS נתקלתי בבעיות, ההעתקה הופסקה מעצמה בהעתקת קבצים גדולים עם שגיאה קלט/פלט סטנדרטית : די מטריד.
אחרי שווידאתי שהבעיה היא בNFS (העתקתי את הקובץ הגדול באמצעות SCP ווידאתי שהוא תקין עם md5sum) התחלתי לשחק בפרמטרים של NFS בצד הלינוקס, באיזה פרוטוקול הוא מתחבר (NFS4? NFS3? אולי אפילו NFS2 השם ישמור?), באיזה תעבורה? UDP או TCP.
בסוף גיליתי את התצורה שעובדת וגם נותנת ביצועים טובים:
NFS3 עם TCP, ועם חוצצי קבלה ושליחה בגודל 32K (בשביל הביצועים, לא היה להם השפעה על השגיאה).
השורה הרלוונטית /etc/fstab בלינוקס נראית ככה:

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

גיבוייים של מכונות לינוקס

אין ספק שאיירון היא המכונה הכי עמידה שיש לי בכל מה שקשור לאכסון קבצים ועמידות לקריסת דיסקים (דיסקים קורסים, זו עובדת חיים).
מכיוון שכך, זה רק טבעי שאני ארצה לגבות של מכונות הלינוקס שלי אל איירון.
בעבר תיארתי את אסטרגיית הגיבוי שלי של מכונות לינוקס.
בגדול הרעיון הוא לבצע rsync של הקבצים הרלוונטיים, ולשלב את זה עם רוטציה של ספריות סנאפשוט בזמנים שונים. כדי למנוע בזבוז מיותר של מקום – משתמשים בhard links כך שקובץ שלא שונה מהגיבוי האחרון תופס מקום פעם אחת בלבד.
זה נחמד, אבל די מסורבל : צריך להעתיק את העץ מחדש כל פעם, ולמחוק עצים מיותרים, ובנוסף השיטה של החיסכון במקום לא מושלמת – כי קובץ ששונה רק בביט אחד יתפוס את כל המקום של הקובץ מחדש.
עם הסנאפשוטים של ZFS אפשר לעשות משהו הרבה יותר פשוט ואלגנטי, שגם יותר חסכוני במקום והרבה יותר מהיר.
הרעיון הוא פשוט לסנכרן את הספריה או הספריות הרלוונטיות מהשרת (או השרתים) אל ספריית היעד, ולקחת סנטפשוט של ZFS. כדי למנוע התפוצצות סנטפשוטים, אפשר פשוט למחוק סנאפשוטים ישנים.
כתבתי תוכנה פשוטה בשם zync שמממשת את הרעיון הזה.
כתובה בג’אווה, וקובץ ההגדרות שלה כתוב בswush, אז הוא קריא ונחמד.
הנה קובץ הגדרות לדוגמא:

zync כבר די מוכנה לדעתי, ואני מתחיל לגבות איתה את מכונות הלינוקס שלי, כולל את השרת שמריץ את הבלוג.

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

כזכור לקוראים הוותיקים, אני משדרג די סדרתי.
לפני כשלוש שנים שדרגתי את מחשבי למפלצת זוללת ביטים שהתיישנה קשות מאז, פנטיום D, עם 2 ג’יגה זכרון, לוח אם פיצוצי של אסוס וכל זה.
הזמן עבר, ובשדרוג סיבובי טיפוסי שדרגתי את המחשב לפנטיום קור-דואו, והעברתי את הפנטיום D לסלון, וראיתי כי טוב.
עוד זמן עבר, והפנטיום D התחיל לגמגם בטיפול בוידאו ברזולוציה של 1080p, בהתחלה נסיתי להוציא ממנו עוד קצת חיים בשימוש בקודקים מתוחכמים, אבל בשלב מסויים ירדתי מהעניין וקניתי פנטיום i7 לחדר, ואת הקור-דואו שמתי בסלון. הפעם כבר לא היה לי שימוש למפלצת שזללה ביטים בימיה הטובים, ושמתי את לוח האם, המעבד והזכרון שעדיין עבד בקופסא, בתקווה למצוא לחומרה שימוש מתישהו.

פסט-פורוורד להיום.
יצא לי להתעסק עם אופן סולאריס, ופשוט התאהבתי בZFS.
ZFS היא ה-מערכת קבצים הכי טובה שראיתי, יש לה פיצ’רים שאין לאף מערכת קבצים אחרת.
מה למשל, שואל הקורא הסקרן?
טוב, אז ככה:
checksum של הנתונים עצמם, כולל ריפוי אוטומטי במקרה של נזק לנתונים (!) במקום נזק שקט כמו במערכת קבצים אחרות.
סנאפ-שוטים של מערכת הקבצים, שלא תופסים מקום ולוקחים זמן קצר במיוחד.
איך לא תופסים מקום? די פשוט, ברגע שמבצעים את הסנאפ-שוט (מעתה – צילום), מערכת הקבצים מסמנת שיש עליה סנאפ שוט וממתי הוא.
זה הכל.
ברגע שבלוק חדש נכתב, הוא לא נכתב במקום הבלוק הישום של אותו קובץ, אלא בצד. הבלוק הישן ממשיך להיות זמין דרך הצילום הישן, ומי שעובר כרגיל ניגש לבלוק החדש.
אפשר לשמור צילומים כאלו בכמויות, והמקום שהם תופסים הוא רק ההבדל בין צילום לצילום שקדם לו (או בין המצב הנוכחי של מערכת הקבצים אם הצילום הוא האחרון).
מגניב בשביל גיבויים, אפילו אוטומטיים. אפשר להגדיר בקלות רבה את אופן-סולאריס לקחת צילומים כאלו כל רבע שעה. חשבו כמה שזה מגניב לדעת שתמיד יש גיבוי של מה שעשיתם.

מה עוד?
לא צריך להסתבכך עם מחיצות, מערכות קבצים, פירמוטים, RAID וכל העניינים האלו.
ZFS תומכת בהכל, עם שתי פקודות אינטואיטיביות – zpool וzfs. היא תומכת גם בNFS (שיתוף קבצים פשוט ברשת).
אני לא אכנס לעובי הקורה בפוסט הזה, אולי בפוסט אחר, אבל מספיק שאומר שמערכת הקבצים הזו לבדה היא סיבה מספיק טובה לעבור מלינוקס לאופן-סולאריס (למרבה הצער, הרשיון בה משוחררת ZFS לא תואם את GPL, ולכן אין ZFS בלינוקס – ולא, אני לא מחשיב פתרון ZFS מבוסס FUSE כפתרון אמיתי).

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

אז איך נהנים משני העולמות?
תוכנות לינוקס, איכסון באופן סולאריס?
האופציה המתבקשת היא לארגן מכונה נוספת שתריץ אופן סולאריס, ותשמש כמכונת אחסון בלבד.
הגישה תתבצע דרך NFS או דרך CIFS למחשבי חלונות (אני עדיין משחק על חלונות!).
וזה מתקשר לאגדה המקדימה על המכונה זוללת הביטים, שהיום זוללת בעיקר אבק.
התוכנית היא לקנות לה עוד קצת זכרון (ג’יגה אחד התקלקל וארבע ג’יגה היום עולה כל כך זול שזה פשע לקנות שני ג’יגה), לקחת איזה הרדיסק או שניים או שלוש מהמחשב בסלון, לקנות עוד איזה הרדיסק או שניים, ולקנפג שם אופן סולאריס עם ZFS בתצורת RAIDZ (תצורה יותר טובה מתצורת RAID5 שנותנת עמידות נתונים זהה אבל גם עם דיסקים זולים ובביצועים יותר טובים ברוב המקרים).
ככה המכונה תזכה לעדנה מחודשת, ולי יצא להנות מהתכונות של ZFS. אולי אני אפילו אשים את ספריית הבית שלי על המכונה הזו. עם חיבור ג’יגה ביט, זה כנראה יהיה יותר מהיר מעבודה מקומית על דיסק בודד כי אני אקבל את הביצועים של עבודה על כמה דיסקים במקביל.

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

קיבלתי את האימייל הבא מהצוות שמנהל את אתר ההרחבות של ג’ומלה, שאומר בקצרה שמ 1.7.2009 רק חבילות ברשיון GPL יכללו במאגר ההרחבות של ג’ומלה.
הוספתי את פיירסטטס למאגר ההרחבות לפני שנתיים וחצי, והמערכת קיבלה יופי של תגובות ממשתמשי ג’ומלה.
מכיוון שפיירסטטס לא משוחררת תחת GPL, היא כבר לא מופיעה במאגר.
בבדיקה מול גוגל-קש, מספר ההרחבות במאגר ירד מ4554 ל2990, ירידה של 33%.
לדעתי זו חוצפה ובריונות של של ג’ומלה לדרוש ממפתחי ההרחבות לשנות את הרשיון, וויתרתי על שרותי אתר ההרחבות של ג’ומלה (שזה די חבל, כי הוא הכיל 21 ביקורות על פיירסטטס, רובן המכריע מאוד חיוביות).

האימייל, תגובתי למטה:

תגובתי: