הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מאמרים בנושא לינוקס.
בניות ובדיקות ליליות ו־VirtualBox
כל מי שמפתח פרויקט מורכב שתומך במספר רב של פלטפורמות יודע עד כמה זה קשה להוציא גרסה בדוקה שתעבוד בכל אחת מהן.
נכון, כולנו ;) כותבים טסטים אוטומטיים ודואגים שהם יעברו בשלום לפני שחרור הגרסה, אבל... זה לא תמיד מספיק כי תמיד משהו איפשהו נשבר ולפי חוק מרפי משהו יישבר דווקא במקודם שלא עשית בו בדיקה נוספת.
כנ"ל CppCMS, אפילו שיש לי מערכת Unit-Tests שלמה, מידי פעם יש פספוסים בשחרור גרסה. וזה ברור: כשאתה מנסה לתמוך ב־GCC החל מ־3.4 עד 4.5, בקומפיילר של MSVC ושל Intel ב־Solaris, Linux, BSD, Mac OS X ו־Windows אז משהו בתוך כ־40 אלף שורות קוד חייב להישבר.
אז כבר הרבה זמן אני מחזיק מספר מערכות הפעלה על VirtualBox כדי לבצע בדיקות מידי פעם, רק שהפעם, הבנתי שהגיע זמן למכן את התהליך. ובכן, יצרתי מערכת Build לילית שבונה גרסה נקייה מ־trunk ומריצה טסטים. זה יחסית פשוט כאשר מדובר במכונה מקומית, ויש אפילו מערכות מוכנות לזה, אבל כשצריך לשלב מספר מערכות פעלה וסביבות וירטואליות, זה כבר קצת יותר מסובך.
בכל מקרה, בניתי סקריפט, שרץ מתוך crontab ומעלה מכונה וירטואלי, מתחבר אליה דרך ssh מריץ תסריט בניה וטסט ואז מוריד אותה באופן אוטומטי וכך לכל למכונה (למעשה Solaris ו־FreeBSD).
כאשר ניסיתי לעשות את אותו הטריק עם XP הסיפור הפך להיות מתסכל, בשרת FreeSSHD פשוט לא הצלחתי לבצע password-less login על־אף מאמצים רבים וקריאת התיעוד. בכל מקרה, המוצר הזה השאיר לי תחושה של מוצר "חצי־אפוי" כי הוא לא תמיד התנהג כמו שהוא אמור.
אחר־כך ניסיתי copssh, גם הוא היה כישלון טוטלי מכיוון שלא הצליח להעלות סרביס של ssh עם הודעות שגיאה על הרשאות ומשתמש ב־Even Log. החיפושים ברשת לא הניבו תוצאות. אז עברתי לגישה אחרת.
העתקתי את התסריט וכל הקבצים הנדרשים לשרת Samba והכנתי תסריט bat שרץ בחלונות וניגש תיקיה עם עליית המערכת. אם הקובץ נמצא, הוא בונה גרסה ומריץ טסטים, לאחר מכן שם את התוצאות באותו שרת ה־samba. עקום, אבל איכשהו עובד (כמו כל דבר אחר בחלונות...)
וכך נולדה מערכת בניה ובדיקות ליליות של CppCMS שמבצעת בדיקה על מספר פלטפורמות ומייצרת דו"ח יומי. בדיוק בגלל הדברים האלה אתה מבין עד כמה וירטואליזציה היא דבר אדיר.
CppCMS מול Java/JSP, C#/Asp.Net, PHP
פרסמתי השוואת ביצועים עדכנית בין CppCMS ושלוש טכנולוגיות web מובילות: PHP, Asp.Net/Mono ו־Java/JSP.
התוצאות וההסברים פורסמו כאן: http://art-blog.no-ip.info/cppcms/blog/post/67
התקנת תמיכה ב־LaTeX בעברית בהפצה מודרנית
אחת הבעיות להתחיל לעבוד עם LaTeX בעברית זה להתקין את התמיכה בו. לכן, רשמתי רשימת הערות להתקנה של תמיכה בעברית בהצפה מודרנית.
שימו לב, תתקינו בבקשה הפצת texlive ולא tetex, ההפצות המודרניות כמו Debian ו־Ubuntu באות כבר עם texlive.
שלבים בקצרה:
- הסירו ivritex אם מותקן
- התקינו texlive אם לא מותקן
- התקינו culmus-latex-0.7
- התקינו biditex
בפירוט
אם חבילת ivritex מותקנת במחשב שלכם, הסירו אותה ותמחקו ספרית .texmf בספריית הבית שלכם (שימו לב ל־"." שבתחילת שם הספריה).
התקינו LaTeX אם הוא לא מותקן, וודאי כי אתם משתמשים בחבילת texlive. בגדול tetex גם עובד אבל צפו בעיות.
וודאו כי יש לכם פקודות mktexlsr ו־updmap-sys (ניתן לבדוק אם פקודת which). אם לא התקינו את החבילות המתאימות.
הורידו את הגרסה האחרונה של culmus-latex (נכון לעכשיו 0.7) מפרויקט ivritex. להורדה כאן.
שימו לב, אתם לא צריכים חבילת src אלא culmus-latex-XX.tar.gz שמכילה את את הגופנים המוכנים מראש. פרוס אותה והרץ
make installבתור root או בעזרת sudo.
בדוק ש־LaTeX בעברית עובד ע"י הרצה קומפילציה של דוגמה בחבילת culmus-latex, בתיקיית examples בצורה הבאה:
latex culmus-ex.tex dvips culmus-ex.dvi ps2pdf culmus-ex.psובדיקת קובץ pdf שנוצר (בדקו שרואים עברית), כמו כן כדאי לבדוק כי pdflatex עובד ע"י הרצת
pdflatex culmus-ex.tex
BiDiTeX 0.0.9 - כש־ABI נשבר
שוחררה גרסת biditex החדש 0.0.9.
שינויים:
- התאמה לגרסה 0.19.x של FriBiDi
- תמיכה בנוסחאות המוגדרות ע"י
\[ו־\].
הסיבה: ספריית fribidi שברה את ה־ABI ואת ה־API שלה בלי לעדכן נכון את הגרסה ותיעוד, מה שגרם לי לא מעט כאב ראש ויצירת גרסת BiDiTeX חדשה.
שימו לב, אם biditex נשבר בצורה לא ברורה או לא מתפקד בצורה מוזרה, תורידו בבקשה חבילה עדכנית, או תקמפלו אותו מחדש מול גרסת fribidi עדכנית 0.19.x, הגרסאות שקומפלו עם fribidi הישן לא יעבדו לכם.
אז תעדכנו בבקשה את גרסת ה־biditex שלכם. שימו לב, החבילות שניתנות להורדה מ־sourceforge קומפלו בצורה סטטית ולא אמורות להישבר.
להורדה כרגיל, באותו מקום: http://sourceforge.net/projects/biditex/files/
יצירת מספרים אקראיים עם /dev/urandom וכמה קל ליפול בפח
רובינו מכירים את /dev/urandom הנפלא שמאפשר לייצר מספרים אקראיים בטוחים מבחינה קריפטוגרפית במהירות רבה.
למשל, אנחנו רוצים ליצור session-id חדש, מה קל יותר? פונים ל־/dev/urandom ומקבלים בשפע.
אבל כשבפועל השתמשתי בו ליצירת session-ids בגודל של 16 בתים, גיליתי... הוא מאוד אטי... הצלחתי לייצר משהו כמו 1,100 כאלה בשנייה, לא הרבה. התחלתי להתחכם, יצרתי מספר אחד להתחלה, הוספתי לו כמה שדות כמו זמן, מספר, לקחתי לו איזה md5 ואז זה עבד יפה וגם מהר (למרות שהמספרים האלה לא באים באותה איכות כמו שיכולתי לקבל אותם מ־/dev/urandom.
יום אחד בהיר הסתכלתי בקוד של Boost.UUID וראיתי שבקוד שלו, במקום להשתמש בפונקציות סטנדרטיות ופשוטות כמו std::ifstream או fopen פותחים את הקובץ ישירות עם open של מערכת ההפעלה וקוראים אותו עם read. מוזר, עשיתי בדיקה קצרה ו... זה קיבלתי 110,000 מפתחות של 16 בתים בשנייה במקום 1,100 - הבדל של שני סדרי גודל!
מה קורה פה?
אחרי מחקר קצר גיליתי ש:
FILE *f=fopen("/dev/urandom","r");
setbuf(f,0);
char buf[16];
fread(buf,1,16,f);
fclose(f);
עובד מהר מאוד, אבל אם מוחקים את השורה השנייה setbuf(f,0) מגלים שהוא הופך לאטי להחריד.
הסבר: ביטל של buffer פנימי בעזרת setbuf(), גורם לכך, שכל פניה לקריאה מהקובץ מתבצעת בדיוק במספר הבתים שביקשנו. אבל, כאשר buffer מוגדל, הספרייה הסטנדרטית מבצעת תחכום ומנסה לקרוא כמה שיותר (למעשה 4K) ובפועל במקום לקרוא מ־/dev/urandom 16 בתים, היא קוראת 4096...
מוסר השכל: אם אתה פותח /dev/urandom תמיד וודא שאתה לא משתמש ב־buffering בספריה שלך!
