הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מאמרים בנושא תכנה חופשית.
דו"ח התקדמות CppCMS והשאלת שם הפרויקט.
שם חדש לפרויקט
לאחרונה אני מתחיל להבין ששם הפרויקט הוא מאוד לא מוצלח. רבים חושבים שמדובר ב־Content Managment System כמו Drupal ולא ב־Web Developmen Framefork כמו Django ואחרים.
לכן אני מתלבט: האם לשנות את שם הפרויקט ואם כן היא איזה שם לבחור?
דו"ח התקדמות
לאחרונה הוכנסו שינויים גדולים ועקרוניים שהופכים את ה־framework להרבה יותר גמיש וניתן להרחבה בקלות יחסית.
שינויי API הפנימי השונים
- API של שרת אינטרנט הופרד למודולים נפרדים. כיום CppCMS תומך ב: cgi, fastcgi ו־scgi . שינוי הממשק נעשה ע"י שינוי קטן בקובץ הגדרות הרצה.
- הופרד API של cache כך שכל מודול נטען בנפרד. כיום יש תמיכה בשלושה סוגי ה־cache: thread share, dummy ו־fork שעליו אספר בהמשך.
- הפרדה של מודי העבודה השונים: mod-thread-pool, single-worker-thread ומוד חדש ומבטיח mod-prefork.
הוספת mod-prefork
השינויים הגדולים האחרונים הם בעיקר לצורך התמיכה במוד עבודה בטוח -- prefork כאשר כל פעילות מופרדת לתהליכים נפרדים המפוקחים ע"י תהליך האב, כך שנפילה של תהליך, או זליגת זיכרון לא תגרום לבעיה בכל היישום. כמו כן, התווסף מוד עבודה של cache חדש: מוד בו כל הנתונים נמצאים בזכרון משותף.
למעשה mod-prefork אמור להפוך לברירת מחדל בגלל שהוא הרבה יותר בטוח וסלחני לטעויות המפתחים שאמור למנוע השבתה של מערכת במקרה של באג.
הסיפור המעניין בפיתוח של המוד הוא למעשה המימוש של cache. המימוש התבסס על קוד ה־cache הקיים שמבוסס על STL, רק... שיניתי allocators כך שהקצאת זכרון תתבצע מקטע זכרון משותף המנוהל ע"י libmm. למעשה, העובדה שכל התהליכים הם "כפילים" של אותו האב המשתפים את כל הכתובות, מאפשרת לדחוף לזכרון משותף כל מחלקה שהיא ואפילו ייצורים מוזרים כמו STL. הדבר אינו אפשרי במערכות הפעלה שלא תומכות ב־fork.
מוד העבודה הזה יודע ליצור תהליך חדש בצורה אוטומטית אם אחד התהליכי העבודה נפל, ובנוסף מאפשר להגביר את מספר האיטרציות שכל אחד מתהליכי העבודה מבצע עד להחלפתו בתהליך רענן. זה מאפשר לא לדאוג לזליגות זכרון בכלל, אם כי במחיר קטן של ביצועים הנדרשים ליצירת תהליך חדש פעם בה כמה זמן.
מאמר מקביל בבלוג פיתוח (אנגלית)
Autotools - קשה איתם, אבל אי אפשר בלעדיהם.
אחד הכלים השנואים ביותר ע"י המפתחים בעולם Unix זה autotools. מצד שני, זה גם הכלי הנוח ביותר עבור משתמשים שהתקנת תוכנה כלשהי מסתכמת בהרצת שלוש בפקודות
./configure
make
make install
במה מדובר? מדובר בכלי שמאפשר: בנייה, הפצה, בדיקה, התקנה, הסרה, קונפיגורציה של תכנה, ספריות, תיעוד בפלטרפורמות מרובות בצורה אוטומטית. נשמע מפוצץ? וזה אכן הדבר. נכון להיום זה אחד הכלים החזקים שקיימים בתחום *nix.
אבל, אם זה כלי כל־כך חזק, למה כל־כך רבים שונאים אותו?
המשך...לירות לעצמך ברגל... או לא כל הרישיונות שווים
אחד היתרונות הגדולים של תוכנה חופשית היא העובדה שאתה כמעט ולא צריך להמציא גלגל מחדש, תמיד תוכל למצוא ספריית צד ג' שעושה את הדבר.
למשל, אתה רוצה לחשב md5sum? מה בעיה? מוצאים קטע קוד ומכניסים, רוצים ספריה אקזוטית אחרת, מחפשים ומוצאים. בשלב מסוים אתה מגלה, שהקוד שלך, למעשה, מכיל כמה עשרות קטעי קוד צד ג'.
פה מתחילה הבעיה... לכל קטע קוד יש רישיון אקזוטי משלו, למשל, עבור הבלוג הזה והתשתית שלו הייתי צריך להשתמש בקטעי הקוד תחת הרישיונות הבאים:
- רישיון MIT עבור ספריה קטנה לקריאת קובצי־mo.
- רישיון zlib עבור ספריה קטנה שמחשבת md5sum.
- רישיון BSD עבור ספריה שהופכת Markdown ל־HTML.
- קוד ב־Public Domain לחישוב hash (בקרוב ישולב).
- קוד תחת רישיון MIT שכמעט הוכנס למערכת (מימוש של rb-tree).
- קוד תחת LGPL, שמשום מה לא היה חלק מספריה, אלא הופיע ב"דוגמאות".
אני כבר לא מדבר על ספריות שאני עושה איתן link: תחת רישיונות LGPL, boost ועוד רישיון מוזר חופשי אבל לא מוכר במיוחד.
הכל טוב ויפה? כל הרישיונות מאפשרים לשלב את הקוד בכל מיני פרויקטים שונים, כולל סגורים. כך שהכל נראה ורוד ביותר. עכשיו נראה שלא כל־כך.
המשך...BSD או LGPL?
עם התקדמות הפרויקט שלי אני מתחיל להתלבט: האם בחירת רישיון BSD הייתה נכונה.
מה אני רוצה:
- שרישיון לא ימנע מפרויקטים לקחת את התשתית ולהשתמש בה, אפילו לצורך שימוש מסחרי.
- אני כן רוצה לאפשר static linking בגלל שזה פשוט מקל על תהליך deploy בצורה משמעותית.
- אני לא רוצה לתת את הספרייה לכל אחד לעשות את מה שחפץ לו: קרי לשנות אותה לפתח על בסיסה משהו אחר ולא לפתוח את הקוד.
מצד אחד, LGPL הוא טוב למטרה ראשונה והאחרונה, אבל עם השנייה יש בעיה: הוא לא מאפשר לבצע static link עם תוכנה בעלת רישיון אחר (אפילו מסחרי). וזה מאוד חשוב, כי קשה לעשות deploy לשרת מרוחק אם יש הרבה תלויות. (אפילו אני כשעושה deploy לשרת וירטואלי מקמפל עם גרסה סטטית של התשתית).
מצד, שני, רישיון BSD לא מסוגל לתת לי את מה שאני רוצה מבחינת הגנה על חופשיות הקוד. אבל במחשבה אחרת, האם זה מפריע לעשרות פרויקטים מוצלחים להישאר פתוחים כמו sqlilte, lighttpd ואחרים? האם אני באמת זקוק להגנה ש־LGPL נותן לי?
מה לעשות?.. שאלה קשה. עדיין לא החלטתי, אבל בינתיים אני נוטה להחליף רישיון ה־BSD ב־LGPL.
בכל אופן, אני לא רוצה רישיון בסגנון GPL או אחר בעל מגבלות דומות.
אז מה עדיף רישיון copyleft או non-copyleft?
בשימושים שלי אני די מעדיף להשתמש ברישיון שהוא non-copyleft כי אני יכול לקחת את הקוד כפישהו, לשנות ולשלב בתוכנה בלי ליצור ספריות נפרדות אלא ע"י static link למספר קובצי C (כמובן כשאני רוצה להכניס שינויים). אני לא יכול עשות את זה בצורה טריביאלית במקרה של LGPL. וזה תמיד מרתיע אותי ברישיונות כאלה. אני אפילו צריך לשכתב קטע קוד קטן ש"השאלתי" מ־contrib של CgiCC, בגלל שהוא LGPL ואז תוכנה שלא לא תהיה תואמת BSD.
מצד, שני, מי שיכול לקחת את הקוד הוא לאו דווקא אדם שישחרר את הקוד אחר כך, וזה כבר פחות מוצא חן בעיניי.
שאלה קשה... דעתכם?
רגע האמת... האם C++ באמת נתן יתרון בתחום Web?
אחרי כמעט חצי שנה של פיתוח תשתית C++ לפיתוח מערכות התוכן, אני מתקדם לגרסת בטא הראשונה. למעשה כל הרכיבים שתכננתי עבורה מוכנים והדבר היחיד שעוצר אותי בפני הכרזה על גרסת הבטא הראשונה זה חוסר תיעוד שעדיין אני צריך להכין.
המטרה של הפרויקט הייתה ליצור תשתית לפיתוח יעיל ומהיר ל־Web ב־C++ -- שפה שלא נפוצה בתחום זה, על מנת לקבל ביצועים יוצאים מן הכלל. בדרך גם למדתי הרבה על תשתיות דומות אחרות ועכשיו הכנתי השוואה ביצועים בין שתי מערכות:
- מערכת בלוגים פופולרית WordPress בעברית
- הבלוג שכתוב על בסיס CppCMS -- למעשה הבלוג הזה.
WordPress נבחרה בגלל ההכרות המצוינת שלי אתה ויכול להוציא ממנה את מירב הביצועים האפשריים שניתן לקבל בעזרת שפות תכנות דינמיות טיפוסיות כמו PHP.
המערכות הוגדרו ככה:
- שרת אינטרנט lighttpd 1.4.13
- ממשק שרת FastCGI
- PHP גרסה 5.2.
- Opcode Cache של PHP נעשה ע"י XCache 1.2.1
- בסיס הנתונים MySQL 5.0.
- תוסף caching עבור WordPress: WP-Cache-2 עם הטלאי שלי שמשפר את הביצועים שלו בעוד כ־60%.
- מערכת CppCMS עם ניהול ה־cache בזיכרון.
- חומרה: AMD Athlon XP 3000+ 64bit, 1G RAM
- מערכת הפעלה: Debian Etch 64 bit.
