הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מאמרים בנושא לינוקס.
יצירת מספרים אקראיים עם /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 בספריה שלך!
שוחררה גרסה מקדימה של Boost.Locale 3.
שלום,
שוחררה גרסה מקדימה של Boost.Locale
- מדריך: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html
- תיעוד מפורט: http://cppcms.sourceforge.net/boost_locale/html/index.html
- הורדה: https://sourceforge.net/projects/cppcms/files/boost_locale/
חדש בגרסה:
- התווספה תמיכה במנגנוני לוקליזציה מרובים:
- ספריית ICU - ברירת מחדל
- תמיכה בסיסית של הספריית הסטנדרטית של C++ עם שיפורים.
- POSIX 2008 API (כמו strftime_l)
- Windows API.
התמיכה הזו מאפשרת להשתמש בכלי לוקליזציה בסיסיים גם ללא ספריית ICU הכבדה.
- שיפורים משמעותיים בממשק וניהול לוקלים
- תיקוני ביצועים עובר ICU
- שיפורים בעבודה עם UTF-8
- תיקונים בתמיכה ב־UTF-16
ועוד.
קיימת תמיכה ב:
- מערכות הפעלה: Linux, FreeBSD, OpenSolaris, Windows, Cygwin, (בקרוב גם Mac OS X).
- מהדרים (קומפיילרים) gcc (גרסאות 3.4 עד 4.5), Intel 11, MSVC9, SunCC 5.10/stlport
שוחררה גרסת בטא שניה של CppCMS
שוחררה גרסת בטא שניה של CppCMS. השינויים כוללים בין השאר:
- שיפורי ביצועים משמעותיים, בפרט בעבודה עם FastCGI, כך שהביצועים שלו לא נופלים מאלו של SCGI.
תיקוני באגים חשובים, ביניהם:
- תיקוני באגים בהעלאת קבצים
- בעיות שליחת תגובת HTTP במערכות אסינכרוניות.
- בעיות בייצוג מספרים ב־JSON.
התווספו דוגמאות נוספות, בפרט עבודה עם JSON ו־Comet.
אבל, אחד הדברים החשובים בעיניי בגרסה הזו, הוא לאו דווקא עצם שחרור הגרסה הנוספת, אלא מעבר הקהילה ישירות לגרסה 1.x.x של CppCMS בזכות שיפורים רבים שהוכנסו לתוכה, למעשה, רוב המשתמשים הפעילים ברשימת התפוצה של CppCMS משתמשים בגרסה החדשה, למרות שהיא עדיין נחשבת לגרסת בטא.
ואללה Vala!
כבר לא מזמן שמתי לב על פרויקט Vala של Gnome... אבל רק עכשיו יצא לי לנסות את הגרסה העדכנית שלו לעומק (גרסה 9.2).
כשקראתי בפעם הראשונה על Vala התגובה הייתה: "It is too good to be true".
- שפה מקומפלת ורצה בצורה טבעית (ללא זבל של VM ו־JIT) שזה אומר שהיא לא צורכת הרבה משאבי CPU.
- שפה שמשתמשת ב־GC פשוט (שימוש ב־reference counting במקום GC אמתי). מדוע זה טוב? כי יש לך דטרמיניסטיות ו־destructors - שזה אומר שהיא לא צורכת הרבה זיכרון.
- תמיכה ב־RAII שכל־כך חסר לי שפות כמו Java או C#.
ובנוסף לכל:
- הם הרוויחו ישירות SDK מאוד עשיר של Gnome. כי כל מה שמבוסס על GObject בא בצורה טבעית ל־Vala.
- הם הרוויחו תמיכה בפלטפורמות רבות בכלל שהם בחרו כשפת ביניים את C, כך שרוב העבודה הקשה הם משאירים למהדרי C (שיש בשפע החל מהדרים חזקים כמו gcc עד מהירים וקלילים כמו tcc).
לטעמי, שפה כמעט מושלמת לפיתוח יישומיים יומיומיים.
למעשה, היום ל־C++ יש מספר חלופות מצומצם שנותנות יכולות דומות עם פישוט של השפה עצמה: D, Vala, ו־FPC. (אני לא מדבר על Java או C#/Mono כי הם בכלל בליגה אחרת)
שפת D היא בעלת פוטנציאל גבוהה ביותר מכולם, אבל אני אישית חושב שעבודה עם Garbage Collection מקשה על הרבה דברים. היא מפרידה בין שני סוגי המשאבים: זיכרון וכל השאר (שהם הרבה יותר יקרים) כמו קבצים, נעילות, קשרי רשת פתוחים ועוד, שכן דורשים ניהול דטרמיניסטי. כך שאני חושב שעובדה עם Reference Counting נותנת מענה ל־95% מהמקרים, והשאר, נפתרים בקלות עם מעט תחכום.
Pascal בעייתית מהרבה בחינות, כולל ניהול משאבים ידני, העדר RAII וגם GC ועוד הרבה דברים שהופכים אותה מזדנבת מאחורי הטכנולוגיות המודרנית (עידו, זאת דעתי, אתה יכול להסכים או לא להסכים אתה).
עכשיו, על הנייר, נראה ש־Vala לקחה את הטוב ביותר מהרבה שפות
- מ־C היא לקחה ה־ABI הפשוט וקלות חיבור עם שפות אחרות, בסה"כ מדובר ב־C!
- מ־C++ היא לקחה את RAII, לקחה את ה־Destructors.
- מ־C# היא לקחה את OOP ואת הקלות של הכתיבה כך אפשר מהר ובקלות להיכנס לפיתוח.
אז החלטתי להסתכל לעומק
ציפו לי מספר אכזבות:
- Vala לא תומכת ב־Overloading בדיוק כמו ש־C לא תומך. ההיגיון מאחורי הוא די פשוט: הם רוצים שקוד C שנוצר יהיה שימושי גם מחוץ ל־Vala, קרי יישום של GTK יוכל להשתמש במחלקות שבמקור כתובות ב־Vala וזאת טענה מאוד חזקה שאני מוכן לקבל.
החריגות (Exceptions) ב־Vala הן ממש לא חריגות כפי שאנחנו מכירים אותם ב־C++ או ב־Java - הן לא מחלקות. אי אפשר ליצור היררכיה של חריגות, למשל DiskError שיורש מ־IOException והוא בתורו יכול יורש מ־Exception הבסיסי.
החריגות הן למעשה צירוף של תחום (domain) קוד ומחרוזת המייצגת את השגיאה, כך למשל כדי להציג חריגה שדיברנו עליה אנחנו מייצרים errordomain IOError בתוכו אנחנו בוחרים סוגים כמו
DISK_ERRORשהוא פרמטר של החריגה, וכמובן גם טקסט. מבחינה זו, היה יותר נכון לקרוא להן Error Code מאשר חריגה במובן הקלסי.נכון שזה מכסה 95% מכל המקרים, אבל זה כן מייצר בעיה כשאתה רוצה להעביר מידה יותר מורכב (אם כי זה נדיר).
התיעוד עדיין לוקה בחסר הן מבחינת השפה עצמה והן מבחינת הספריות (אני צריך לפנות כל פעם לתיעוד GTK של C כדי להבין מה מתודה מסוימת עושה).
לפחות בשלב זה, אתה חייב לדעת C, כי לפעמים, כן קוראות שגיאות קומפילציה ברמת C, במיוחד עם ספריות חסרות או גרסאות לא תואמות.
אבל בגדול: שפה מהירה מאוד, פשוטה, בעלת SDK מאוד עשיר ואני צופה לה עתיד מעניין.
סיכום
היום Vala היא עדיין לא שפה מוכנה ל־Prime Time, אלא אם אתם מוכנים להיות בודקי הבטא שלה, מצד שני אם אתה יודע C ומכיר Gtk מספיק טוב, אתה תוכל להסתדר בקלות אתה.
היום מספר שפות יחסית מהירות ומתאימות לפיתוח יישומי Destkop: C, C++, D, C#, Java, Pascal ו־Vala. אני בהחלט רואה ב־Vala פוטנציאל גבוהה (כמובן לצידה של C++).
נפלאות התמיכה בחלונות או מדוע CMake לא בדיוק מערכת הבניה איכותית.
פרסמתי מאמר Why CMake sucks... (once more) בבלוג שלי באנגלית.
מומלץ לקריאה לכל אלו שאוהבים CMake ושונאים auto*.
קצת רקע לאנשים שלא רגילים לעולם חלונות: בחלונות לא עושים linking ישירות מול dll אלא תמיד מול import-library מיוחדת שיודעת לעשות טעינה ל־dll. כך שאם בלינוקס בד"כ כל ספריה באה בגרסאות: דינאמית וסטטית, בחלונות (כולל mingw ו־cygwin) כל ספריה באה בגרסאות: דינאמית, ספריית import לספריה דינאמית וגרסה סטטית.
עכשיו תקראו את המאמר ותיהנו ;-).
לטובת מפתחי CMake ייאמר: אחרי שדיווחתי על הבאג הם עדכנו את הויקי שלהם כדי להמנע מהבעיה הזו.
