הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
מאמרים בנושא תכנה ומחשבים.
שוחררה גרסת בטא הראשונה של CppCMS.
אחרי כחצי שנה של פיתוח שוחררה גרסת בטא הראשונה של CppCMS תחת רישיון LGPL v2.1.
מה זה CppCMS?
זאת תשתית לפיתוח יישומי Web ב־C++ המספקת ביצועים יוצאים מן הכלל שלא ניתן להשיג בשימוש בטכנולגויות מקובלות.
מה המרכיבים של CppCMS?
הגרסת בטא כוללת:
- תשתית לכתיבת יישום web ב־C++: cppcms.
- ספרית תבניות tmpl המאפשרת הפרדה נוחה בין הקוד לבין תוכן HTML.
- ספרית גישה לבסיסי נתונים שונים dbixx -- למעשה מעטפת C++ נוחה עבור libdbi.
- רשימת דוגמאות, בהן "מיני־פורום" המדגים את העבודה עם התשתית.
מה ייתווסף לגרסה יציבה ראשונה שלא קיים בבטא?
הרבה תיעוד שעדיין לא נכתב.
זה נורא מעניין איך אני מתחיל?
- להורדת CppCMS מ־SourceForge.
- כותבים "שלום עולם" בעזרת CppCMS.
- כותבים "שלום עולם" עם שימוש בתבניות בעזרת CppCMS.
- כותבים "מיקרו־פורום" בעזרת CppCMS.
רוצים עוד?
יש מידע רחב בנושא בבלוג הפיתוח של CppCMS. כמו כן, תמיד אפשר ללמוד מקוד קיים, למשל, הקוד של הבלוג הזה הזמין דרך svn.
דו"ח התקדמות 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.
מצד, שני, מי שיכול לקחת את הקוד הוא לאו דווקא אדם שישחרר את הקוד אחר כך, וזה כבר פחות מוצא חן בעיניי.
שאלה קשה... דעתכם?
