http://artyom.cppcms.com/ בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא! http://artyom.cppcms.com/post/308 http://artyom.cppcms.com/post/308 <div style="direction:rtl"> <p>הסיפורו של הניסיון להדפיס "שלום" במספר שפות במסוף של חלונות.</p> <p><a href="http://blog.cppcms.com/post/105">http://blog.cppcms.com/post/105</a></p> </div> http://artyom.cppcms.com/post/306 http://artyom.cppcms.com/post/306 <div style="direction:rtl"> <p>כשאתה מפתח הפרויקט קוד־פתוח, קל מאוד להפיץ קוד מקור, אבל כשזה מגיע לקבצים בינאריים, זה הופך לבעיה הרבה יותר משמעותית. יש עשרות הפצות, כל אחת מגיע במספר גרסאות שונות ומביא אתה חבילות טיפה שונות. לכן, לאדם אחד זה כמעט ובלתי אפשרי לבנות חבילות לכל הפצה אפשרית.</p> <p>בזכות debootstrap היה לי יחסית קל לבנות חבילות deb ל־Debian ו־Ubuntu, אבל המצב הרבה יותר מורכב כשמדובר ב־rpm כי אין דרך קלה לשים את הפצת rpm בספריה ולעשות לתוכה chroot.</p> <p>בהמלצת שגיא בן־עקיבא התחלתי להשתמש ב־<a href="https://build.opensuse.org/">Open Build Service</a> של OpenSuse.</p> <p>האמת, אני מאוד מרוצה! כל מה שצריך זה להעלות Source RPM או קובץ spec, כל השאר ייעשה בצורה אוטומטית: בניה למספר הפצות ופלטפורמות, הכנת מקורות מסודרים ואפילו אתה מקבל repository מסודר.</p> <p>בצורה כזו הכנתי rpmים ל־3 הפצות (Fedora, Suse, CentOS) כולל מספר גרסאות וגם הכל עבור שתי ארכיטקטורות: x86 ו־x86_64.</p> <p><a href="http://download.opensuse.org/repositories/home:/artyom-beilis/">http://download.opensuse.org/repositories/home:/artyom-beilis/</a></p> <p>מה שנותר... להבין כיצד משתמשים בשירות עבור debים</p> </div> http://artyom.cppcms.com/post/305 http://artyom.cppcms.com/post/305 <div style="direction:rtl"> <p>היום, אחרי מספר שנות פיתוח, שוחררה גרסה יציבה של CppCMS 1.0.0, אחרי תקופה ארוכה של גרסאות בטא. הגרסה הזו מהווה אבן דרך משמעותית בהתפתחות של CppCMS, הן מבחינה טכנולוגיות והן מבחינה עסקית.</p> <p>החל מגרסה 1.0.0, ספריית CppCMS תהיה זמינה תחת רישיון חופשי LGPLv3 ותחת רישיון מסחרי שיאפשר פיתוח יישומים קנייניים תוך שמירה על שלמות המוצר והגנה על הסודות המסחריים שלו.</p> <p>למידע נוסף על הרישוי החלופי והמחירים אנא כנסו לאתר שלנו:<br/> <a href="http://commercial.cppcms.com">http://commercial.cppcms.com</a></p> <p>גרסה זו, עברה שכתוב יסודי ושינויים ארכיטקטוניים עמוקים שהזניקו את הפופולריות שלה מיד עם שחרור גרסאות בטא ראשונות. מבין החידושים הטכנולוגיים:</p> <ul> <li>הכנסה של API ו־ABI יציבים</li> <li>תמיכה מובנית ב־Ajax ו־Comet</li> <li>שיפורים מהותיים בלוקליזציה</li> <li>תמיכה מובנית ב־Windows</li> <li>שיפורים משמעותיים באבטחה: מסנני XSS וכלים למניעת CSRF ועוד.</li> <li>שרת HTTP מובנה לפיתוח ומערכות משובצות</li> </ul> <p>הענף הישן יציב CppCMS 0.0.x לא נתמך יותר. כל משתמשיי הענף הישן מתבקשים לעבור לגרסה החדשה. יש לציין, לא ידוע לי על משתמש אחד שנשאר עם הגרסה הישנה.</p> </div> http://artyom.cppcms.com/post/304 http://artyom.cppcms.com/post/304 <div style="direction:rtl"> <p>בעקבות <a href="http://oc666.net/2012/01/31/nginx-htaccess-replacement/">הכתבה</a> של <a href="http://oc666.net">עופר כהן</a> הגעתי ל<a href="http://wiki.nginx.org/LikeApache-htaccess">טבלת השוואה</a> מעניינת בין Apache לבין nginx. מה שהפתיע אותי זה שכדי להעביר קובץ <code>http://example.com/site/files/images/layout/header.png</code> השרת nginx מבצע קריאת stat בודדת. הטבלה עשתה השוואה עם apache שעשה O(n)‎ קריאות עבור תיקיה בעומק n לעומת O(1)‎ עבור nginx...</p> <p>ברגע שראיתי את זה נדלקה לי נורת אזהרה! מה עם symbolic links?</p> <p>הסבר: נניח אני איצור קישור סימבולי בשם mypicture.png שיפנה ל־‎/etc/passwd או לקובץ רגיש אחר, אז ע"י גישה לקובץ תמים אני אוכל לקרוא כל קובץ שיש לשרת web הרשאות לקרוא.</p> <p>לכל השרתי web יש אופציה לא לעקוב אחרי קישורים כאלה מטעמי אבטחה וזאת גם אופציה מומלצת לעבודה. מה חשוב, זה שבלתי אפשרי לעשות בדיקה כזו ב־O(1)‎ קריאות מערכת ההפעלה (לפי עומק התיקיה).</p> <p>אז החלטתי לבדוק בעזרת strace, כמה קריאות stats בפועל מבצעים apache,‏ lighttpd ו־nginx כשהאופציה כזו מופעלת וגיליתי... ש־nginx <em>בכלל לא תומך באופציה כזו</em>! קרי הגדרת אבטחה בסיסית ש<strong>כל</strong> שרת אינטרנט החל מ־apache ועד ל־thttpd תומכים בו (אגב גם השרת הפנימי של cppcms) בכלל לא מופיעה בו!</p> <p><a href="http://forum.nginx.org/read.php?21,218970,219019">התשובה</a> (רוסית) של מפתח nginx היא להשתמש ב־<code>mount -o nosymfollow</code> עבור מערכת הקבצים כדי לעקוף את הבעיה.</p> <p>חבל...</p> </div> http://artyom.cppcms.com/post/303 http://artyom.cppcms.com/post/303 <div style="direction:rtl"> <p>לאחרונה יש יותר ויותר כתבות על Nginx ועד כמה השרת הזה מעולה. נתח השוק של Nginx לפי הסקירות האחרונות של Netcraft עומד על כ־10%. אז כנראה יש סיבה לכך!</p> <p>עכשיו, דברים שלא מספרים:</p> <ul> <li>רוב שרתי ה־Nginx המופיעים ב־Netcraft עובדים כ־Reverse Proxy או מטפלים בעיקר בקבצים הסטטיים. בהרבה מאוד המקרים Nginx הוא מתפקד כ־Load Balancing Frontend לפי שרתי Apache.</li> <li>התמיכה של Nginx בתוכן דינאמי היא בין מועטה עד לוקה בחסר: <ul> <li>אין תמיכה ב־CGI כלל.</li> <li>אין תמיכה בניהול של שרתי FastCGI, כך שהשירות התוכן הדינאמי שלך חייב לרוץ התהליך נפרד ואתה צריך לדאוג לו (למשל להעלות אם הוא נפל מסיבר כלשהי)</li> <li>הגדרות FastCGI לא תואמות תקן - <code>PATH_INFO</code> לא מוגדר כברירת מחדל. צריך לעבוד קשה כדי שהוא יעבוד נכון. מה שגורם לא מעט בעיות לאלה שמגלים שהיישום שלהם שבור בצורה לא ברור ולא מבינים למה.</li> <li>תמיכה ב־SCGI שבורה לחלוטין. הוא לא מטפל ב־Status כמו שצריך, שזה אומר שרוב ההפניות תהינה שבורות אלא אם היישום שלך ישלח את התשובה כ־HTTP נקי.</li> </ul> </li> </ul> <p>להמשיך?</p> <p>כן, אם אתם צריכים Reverse Proxy או לטפל בתוכן סטטי זהו שרת מעולה. אחרת, תחשבו פעמיים.</p> <p>אני ממליץ בחום על Lighttpd: מהיר כמו Nginx ובנוי על אותם העקרונות, מתועד היטב, מטפל תוכן סטטי ודינאמי בצורה יוצאת מן הכלל. קל לקינפוג ועוד.</p> <p>לפני שאנשים יקפצו ויגידו:</p> <blockquote><p>Lighttpd זולג!</p></blockquote> <p>אז התשובה היא, לא הוא, לא זולג.</p> <p>ציטוט:</p> <blockquote><p>there are no memory leaks just stupid ways to use lighttpd.‎</p> <p>e.g. it is really stupid to stream large files via a fastcgi app, when x-lighttpd-send-file could do a much more efficient job‎</p></blockquote> <p>תקראו עוד:</p> <ul> <li>‏<a href="http://redmine.lighttpd.net/issues/758">http://redmine.lighttpd.net/issues/758</a></li> <li>‏<a href="http://redmine.lighttpd.net/boards/2/topics/4009">http://redmine.lighttpd.net/boards/2/topics/4009</a></li> </ul> </div> http://artyom.cppcms.com/post/302 http://artyom.cppcms.com/post/302 <div style="direction:rtl"> <p>אחרי חמש שנים שהחזקתי את הבלוג שלי ואת כל האתרים שלי על <a href="http://artyom.cppcms.com/post/15">המחשב הביתי</a>, הגיע הזמן להעביר את התפקיד לשרת וירטואלי אי־שם בענן.</p> <p>הסיבה העיקריות למעבר הן:</p> <ul> <li>Uptime נמוך, בעיקר אודות חברת החשמל וגם מידי פעם תקלות חומרה.</li> <li>חיבור לא אמין במיוחד מחו"ל שגרם לי להחזיק אתר המראה סטטי לפרויקט שלי.</li> </ul> <p>אז הגיע הזמן לשדרג. כיוון שהאתרים שלי רצים על טהרת CppCMS זה לא היה דבר טריביאלי,</p> <ul> <li>מצד אחד, אני צריך שרת וירטואלי עם שליטה מלאה על יכולת התקנת התכנה, כולל התקנה של קובצי הריצה משלי, לכן, שירותי אירוח משותפים לא באו בחשבון, כי רובם לא מותאמים לטכנולוגיות כאלה.</li> <li>מצד שני, ממש אין לי צורך בשרת חזק, בעיקר בגלל שהטכנולוגית CppCMS היא חסכונית להפליא.</li> </ul> <p>אחרי הרבה השוואות של מחירים (לא זולים) של שרתי VPS החלטתי ללכת על Amazon EC2, כיוון שאני משלם על מה שאני משתמש... וחוץ מרוחב הפס אני לא ממש הולך להשתמש בהרבה <code>:-)</code>. לכן, החלטתי ש־Amazon EC2 יהיה אידאלי לטכנולוגיה שאני מציע.</p> <p>ובכן, רכשתי שם המתחם, סידרתי שרת ב־EC2 ותוך זמן קצר עברתי ל־VPS משלי בענן.</p> <p>כרגע יש לי שרת שמריץ lighttpd ומאחוריו שלוש יישומי FastCGI: עבור האתרים:</p> <ul> <li><a href="http://cppcms.com">http://cppcms.com</a> - הויקי של CppCMS‏</li> <li><a href="http://blog.cppcms.com">http://blog.cppcms.com</a> - בלוג הפרויקט</li> <li><a href="http://artyom.cppcms.com">http://artyom.cppcms.com</a> - הבלוג הזה.</li> </ul> <p>השרת מהיר וקל כנוצה עם ערכי uptime:load average שווים ל־0.</p> </div> http://artyom.cppcms.com/post/301 http://artyom.cppcms.com/post/301 <div style="direction:rtl"> <p>בשעה טובה, עברתי שרת.</p> <p>אנא עדכנו את ה־rss שלכם לשרת החדש:</p> <p><a href="http://artyom.cppcms.com">http://artyom.cppcms.com</a></p> <p>העברה אוטומטית מהכתובת הישנה (art-blog.no-ip.info) לחדשה מתבצעת בצורה אוטומטית אבל היא תיעלם בקרוב.</p> </div> http://artyom.cppcms.com/post/300 http://artyom.cppcms.com/post/300 <div style="direction:rtl"> <p>מאז שהמציאו שפת תכנות ראשונה ממשיכים למצוא את השפה האולטימטיבית שתפתור לנו את כל הבעיות:</p> <ul> <li>תהיה מהירה</li> <li>תהיה פשוטה</li> <li>תהיה חזקה</li> <li>תהיה ברורה</li> <li>תהיה נוחה</li> <li>תכין לנו קפה לארוחת הבוקר...</li> </ul> <p>אז נגיד מחר אני אצליח ליצור שפה חדשה:</p> <ul> <li>מהירה כמו C או C++‎</li> <li>קלה להבנה כמו Java או Pascal</li> <li>גמישה כמו Python או JavaScript</li> <li>ועוד כמה תכונות נוספות שתרצו לפרט</li> </ul> <p>ואז כשיהיה לי מהדר (או משערך) אולטימטיבי שיעבוד על כל מערכת הפעלה ובכל סביבה החל ממערכות משובצות עד מחשבי על, החל מ־ARM עד ל־Itanium ואפתח IDE אולטימטיבי יהפוך אותי לפרודוקטיבי־על, אני אתחיל לעבוד...</p> <p>מה יקרה?</p> <p>רוב המפתחים היום לא כותבים אלגוריתמים הם כותב אפליקציות. רוב המפתחים היום צריכים לדעת את הספריות שלהם יותר טוב מהשפה, למתכנת GUI ממוצא יותר חשוב להבין אין עובד Qt מאשר לדעת כיצד לעשות partial template specialization. למתכנת יישומי עיבוד תמונה ב־Matlab יותר חשוב לזכור את הפונקציות שמבצעות convolution על מטריצה, מאפשר לזכור כיצד להגדיר מחלקות. למפתח Web יהיה יותר חשוב לדעת כיצד לייצר טופס, מאשר כיצד להשתמש בפונקציות למבדה.</p> <p>בסופו של דבר גם אם פיתחת שפת־על אתה צריך כלים. ואם אין לך כלים השפה תמות.</p> <p>זאת הסיבה רוב השפות שנולדות לאחרונה הן רצות על JVM או על ‎.Net או כמו Vala משתמשות באוסף הספריות העשיר של Gnome כדי להיות פרודוקטיבי.</p> <p>ומה עם "שפות־העל" שפותחו והמון מחשבה הושקעה בהן כמו, למשל, D? הן לא התרוממו.</p> <p>למעומת זאת, שפות "עתיקות" כמו C ממשיכות להתקיים והמונים כותבים בהן. Vala בזכות האימוץ המלבב של GTK ו־GObject תופסת תאוצה. Go? כנראה לא תתרומם בקרוב בלי השקעה אדירה.</p> <p>במילים אחרות.</p> <p>זה נחמד אם תהיה שפה חדשה שתפתור לנו את כל הבעיות האפשריות, אבל אם היא לא "תירש" בצורה אוטומטית או חצי אוטומטית SDK עשיר, היא לא תחיה הרבה.</p> </div> http://artyom.cppcms.com/post/299 http://artyom.cppcms.com/post/299 <div style="direction:rtl"> <p>נתקלתי בכתבה מעניינת</p> <p dir="ltr"><a href="http://ib-krajewski.blogspot.com/2012/01/static-vs-dynamic-debate-decided.html">Static vs Dynamic Debate Decided</a></p> <p>כל כך נכון. ככל שהפרויקט גדל ככה יותר קשה לעבוד עם שפות דינאמיות ובמיוחד לעשות refactoring אפילו פשוט לקוד.</p> </div> http://artyom.cppcms.com/post/297 http://artyom.cppcms.com/post/297 <div style="direction:rtl"> <p>אחרי פיתוח אינטנסיבי של כשנתיים וחצי, המועמד לשחרור של הדור הבא של CppCMS זמין להורדה.</p> <p>איפשהו באפריל 2009 היה לי ברור שהארכיטקטורה של הדור הראשון של CppCMS לא הייתה מוצלחת:</p> <ul> <li>ה־API היה בנוי בצורה שלא אפשר הרחבה קלה</li> <li>הארכיטקטורה לא אפשרה פיתוח מונחה אירועים: Comet</li> <li>הישענות על ספריות צג ג' כמו CgiCC ו־libfastcgi שהיו להן הבעיות API עמוקות, לא אפשרה לפרויקט להתקדם.</li> <li>המערכת הייתה קשורה בצורה מאוד מובהקת ל־POSIX API ולא אפשרה תמיכה טבעית במערכת הפעלה Windows.</li> </ul> <p>אחרי הרבה חשיבה, הבנתי שכדי לעשות קפיצת מדרגה משמעותית, צריך להתחיל לארגן את הקוד מחדש והתחלתי לעבוד.</p> <p>העבודה הניבה פֵרות וביוני 2010 שחררתי גרסת בטא ראשונה. היא תפסה תאוצה באופן מידי. תוך חודשים ספורים כמות ההורדות קפצה מכ־100 הורדות בחודש לכ־300.</p> <p>מהר מאוד, גרסת בטא הפכה לפופולרית. רוב משתמשי ה־CppCMS החלו לעבוד אתה או אפילו עם גרסת הפיתוח הזמינות דרך ה־svn. היום, רוב משתמשי CppCMS (אם לא כולם) עובדים עם גרסת פיתוח בטא. <a href="http://art-blog.no-ip.info/wikipp/en/page/who_uses">כל האתרים הפומביים</a> שידוע לי עליהם, רצים על תשתית CppCMS החדשה.</p> <p>למרות שבאופן רשמי, הדור הבא של CppCMS נחשב בטא, הוא היה יציב, מתוחזק היטב ובדוק הרבה יותר מהגרסה "היציבה", הסיבה היחידה שהוא היה נקרא "בטא" היא שאפשרתי לעצמי לשנות את ה־API בצורה לא תואמת, אחור, לזרוק API שהיה בנוי בצורה גרועה, לשנות סמנטיקה, לשפר ועוד.</p> <p>היום, שנתיים וחצי אחרי שנוצר ענף "refactoring" ב־svn ה־API התייצב ומועמד לשחרור הראשון זמין להורדה.</p> </div>