מאמרים בנושא ‏לינוקס‏.

מועמד לשחרור ראשון של הדור הבא של CppCMS זמין להורדה

ב־יום רביעי, 18 בינואר 2012, מאת ארתיום; פורסם תחת: תכנה חופשית, לינוקס, פיתוח, תכנה ומחשבים, CppCMS; ‏0 תגובות

אחרי פיתוח אינטנסיבי של כשנתיים וחצי, המועמד לשחרור של הדור הבא של CppCMS זמין להורדה.

איפשהו באפריל 2009 היה לי ברור שהארכיטקטורה של הדור הראשון של CppCMS לא הייתה מוצלחת:

  • ה־API היה בנוי בצורה שלא אפשר הרחבה קלה
  • הארכיטקטורה לא אפשרה פיתוח מונחה אירועים: Comet
  • הישענות על ספריות צג ג' כמו CgiCC ו־libfastcgi שהיו להן הבעיות API עמוקות, לא אפשרה לפרויקט להתקדם.
  • המערכת הייתה קשורה בצורה מאוד מובהקת ל־POSIX API ולא אפשרה תמיכה טבעית במערכת הפעלה Windows.

אחרי הרבה חשיבה, הבנתי שכדי לעשות קפיצת מדרגה משמעותית, צריך להתחיל לארגן את הקוד מחדש והתחלתי לעבוד.

העבודה הניבה פֵרות וביוני 2010 שחררתי גרסת בטא ראשונה. היא תפסה תאוצה באופן מידי. תוך חודשים ספורים כמות ההורדות קפצה מכ־100 הורדות בחודש לכ־300.

מהר מאוד, גרסת בטא הפכה לפופולרית. רוב משתמשי ה־CppCMS החלו לעבוד אתה או אפילו עם גרסת הפיתוח הזמינות דרך ה־svn. היום, רוב משתמשי CppCMS (אם לא כולם) עובדים עם גרסת פיתוח בטא. כל האתרים הפומביים שידוע לי עליהם, רצים על תשתית CppCMS החדשה.

למרות שבאופן רשמי, הדור הבא של CppCMS נחשב בטא, הוא היה יציב, מתוחזק היטב ובדוק הרבה יותר מהגרסה "היציבה", הסיבה היחידה שהוא היה נקרא "בטא" היא שאפשרתי לעצמי לשנות את ה־API בצורה לא תואמת, אחור, לזרוק API שהיה בנוי בצורה גרועה, לשנות סמנטיקה, לשפר ועוד.

היום, שנתיים וחצי אחרי שנוצר ענף "refactoring" ב־svn ה־API התייצב ומועמד לשחרור הראשון זמין להורדה.

מפתח בארץ ה־IDE

ב־יום חמישי, 29 בדצמבר 2011, מאת ארתיום; פורסם תחת: תכנה חופשית, לינוקס, פיתוח, תכנה ומחשבים, C++‎‏; ‏8 תגובות

לאחרונה, הייתי צריך לבחון סביבת פיתוח משולבת (IDE) בלינוקס, ולעשות להן השוואה: איזו סביבה היא יותר מתקדמת ונוחה בהקשר של פיתוח ב־C++‎. למרות שאני כותב הרבה קוד, ויצא לי בעבר להשתמש בלא מעט IDE, ביניהם גם Visual Studio וגם KDevelop 3, אני מעדיף לעבוד עם vim, סביבת הפיתוח האולטימטיבית. אבל vim בתור "סביבת פיתוח משולבת" זה לא בדיוק מוכר. יש אנשים שאוהבים IDE... כך שפשטתי שרוולים והתחלתי לבדוק.

על הפרק עמדו מספר אופציות:

  • KDevelop שהיה לי ניסיון איתו בגסראות 3
  • Eclipse שרבים עובדים איתו
  • Netbeans שרבים ממליצים עליו

ומספר IDE נוספים: Anjuta, CodeBlocks ו־CodeLite.

התחלתי מ־KDevelop 4:

בעבר היה לי ניסיון לא רע עם KDevelop 3 והחלטתי לתת לסביבה הזו הזדמנות נוספת. לפני שאני מתחיל את הסיפור, אומר, אחרי כ־20 דקות עבודה התחלתי להרגיש שאני יותר פרודוקטיבי עם KDevelop מאשר עם vim!

הסביבה עשתה צעד עצום מאז גרסה 3. השלמה אוטומטית כמעט מושלמת ומהירה, highlighting מעולה וגם tooltips מאוד נוחים שמאפשרים לגשת לכל מקום. שילוב נוח עם CMake, הגדרות פשוטות, התנהגות ברורה, אינטגרציה עם קובצי man ועוד.

התחלתי לממש פיצ'ר מסוים עבור cppdb‏ ולראשונה הרגשתי שאני מצליח לכתוב קוד מהר יותר ומדויק יותר בהשוואה ל־vim.

הסביבה מאוד מהירה ומגיבה בצורה כמעט מידית.

מבחינת יכולת הדיבוג, הדבר היחיד שלא הצלחתי למצוא זה כיצד אני מגדיד למשל catch throw - לעצור על זריקת החריגה, בסוף, הפעלתי את זה ישירות דרך מסוף ה־gdb.

יחד עם כל היתרונות האלה, היא באה עם חסרון אחד גדול ובלתי נסלח: היא קורסת מידי פעם. תוך כדי העבודה היא עפה לי מספר פעמים. אומנם, לא איבדתי שום דבר, פתחתי אותה מחדש ותוך מספר שניות חזרתי לעבוד בדיוק מאותו מקום, עדיין, בעיניי זה משהו שלא אמור לקרות, נקודה. סימן קריאה!

המשכתי ל־Eclipse

אחרי מעט הגדרות הצלחתי לגרום לו לעבוד עם קובץ Makefile הנוצר ע"י CMake, הגדרתי פרויקט והתחלתי לעבוד.

הסביבה עבדה בצורה יפה, לא הרגשתי אטיות מיוחדת, יחד עם זאת, היא לא הגיבה בצורה מספיק מהירה בעיניי. כשהקלדתי foo.‎ - אחרי הקלדת הנקודה יש השהיה קטנה עד שהתפריט מופיע. אומנם היא מאוד קצרה, היא עושה הבדל מהותי במהירות הכתיבה שלי.

בנוסף, בניגוד ל־KDevelop הוא לא ידע להשלים ערכים תוך כדי הקלדה בצורה לגמרי אוטומטית, למשל אני מתחיל לכתוב my_variable הוא לא מציע לי השלמה אחרי שכתבתי my_va - צריך ללחוץ ctrl-space, אבל בסה"כ הסביבה בהחלט לא רעה ופרודוקטיבית.

התרשמתי לטובה מסימון השגיאות בקוד תוך כדי כתיבה, הוא הרגיש לי קצת יותר ברור בהשוואה ל־KDevelop, מבחינת הדיבוג המצב היה דומה לזה של KDevelop.

בכל אופן, הרגשתי שזאת סביבה ברמה מאוד גבוהה, אבל קצת אטית.

ניסיתי סביבות "קלות" יותר

אז פתחתי CodeBlocks שרבים ממליצים עליו. ויתרתי עליו די מהר - מבחינתי חוסר אינטגרציה עם כלי בניה חיצוניים הוא "deal-breaker" ובכלל לא התרשמתי ממנה יותר מידי. ניסיתי קצת codelite - גם הוא היה יותר מידי lite לטעמי.

לאחר מכן ניסיתי Anjuta, שגם אתה עבדתי בעבר. לא התרשמתי יותר מידי. בפרט, למשל חסרה אפשרות להשלמת הפונקציות של מצביעים חכמים ועוד.

גם היא ירדה מהפרק די מהר.

נותרה לי סביבת Netbeans

שמעתי עליה הרבה דברים טובים והמלצות רבות. בעבר יצא לי לנסות אותה אבל ויתרתי עליה כמעט באופן מידי, אחרי שיא המשיכה "ליצור אינדקס" של הפרויקט במשך דקות ארוכות. אבל החלטתי לתת לה סיכוי במחשב החדש.

בניגוד לסביבות אחרות שזמינות ישירות ומהמאגרים של Ubuntu, ‏Netbeans לא מופיעה שם, צריך להתקין אותה בנפרד. הורדתי את הגרסה היציבה האחרונה המותאמת לפיתוח C++‎ והתקנתי.

פה הייתה לי הפתעה ממש טובה:

  • אפילו שהיא צרכת הרבה יותר זיכרון מ־eclipse ו־KDevelop הסביבה עבדה מאוד מהר, השלמה אוטומטית כמעט מושלמת ומהירה.
  • אינטגרציה מעולה עם subversion, למשל הצגת diff מאוד נוחה עם אפשרות עריכה ישירה.
  • הגדרות פשוטות
  • אינטגרציה עם CMake (שחסרה ל־eclipse)
  • תפריטים נוחים והגיוניים (ב־eclipse הן היו ממש קטסטרופה)

ועוד

ובכלל, הרגשתי שזאת סביבה מאוד פרודוקטיבית, בנויה היטב ויעילה. מה שכן, היא ללא ספק בנויה למחשבים חזקים עם כמויות זיכרון גדולות.

סיכום

אחרי הרבה שנים של עבודה עם vim אני חושב שאתחיל לבחון את הגישה שלי ל־IDE מחדש. כרגע Netbeans היא הבחירה המובילה. הייתי מאוד רוצה לעבוד עם KDevelop אבל אני לא חושב שאוכל לעבוד אתו כל עוד הוא קורס.

מבחינתי יציבות ואמינות יותר חשובה מכל פיצ'ר אחר, וכרגע KDevelop לא עונה על הדרישה הבסיסית הזו וחבל.

מי הרס את שולחן העבודה שלי?

ב־יום חמישי, 1 בדצמבר 2011, מאת ארתיום; פורסם תחת: תכנה חופשית, לינוקס, תכנה ומחשבים; ‏15 תגובות

פעם הייתי משתמש מרוצה של KDE 3. יצא KDE 4 הזדעזעתי, לא התרגלתי, לא הצלחתי להתאים אותה לדרישות שלי. עברתי ל־Gnome 2 שאז כבר התקדם בצורה משמעותית. ואז יצאה Unity הבלתי נסבלת ומיד עברתי ל-Gnome 3. אומנם הזדעזעתי קצת פחות ואפילו הצלחתי להגיע למשהו סביר, אבל בכל זאת לא הייתי מרוצה. אז ניסיתי XFCE בגרסה האחרונה. אני חושב שאשאר שם.

מדוע זה קרה? איך מתוך כל הסביבות הקיימות, בחרתי דווקא את ה"נחותה ביותר"? האם זאת השמרנות שלי? האם זה הרצון לעבוד עם משהו שאני רגיל אליו - סביבה שהתרגלתי שלא צריך ללמוד, סביבה בה אני יודע איפה כל כפתור נמצא? או אולי, הכל החידושים האלה פגעו בחוויית המשתמש - פגעו ביכולת שלי לעבוד?

ניסיתי לאחרונה 3 סביבות שנחשבות ה"מתקדמות ביותר" היום: KDE 4,‏ Unity וגם Gnome 3 - בשלושתן מצאתי מספר בעיות שהפריעו לי:

בחירת הצבעים: מדוע לעזאזל בכל שולחן עבודה מודרני, כל פאנל חייב להיות שחור או מאוד כהה? מה רע בצבעים בהירים וחמים? מה רע בכחול? מה רע בצבעים הבהירים והחמים של אובונטו של פעם?

כולם נותנים תחושה לא נעימה, כאילו אנחנו בסרט Tron: Legacy‏ - זה נחמד בשביל אפקטים אבל לא נעים לעין.

בנוסף לבחירת הצבעים הכהים גם רמת הניגודיות בין רגע לגופן היא מאוד נמוכה. למשל, תסתכלו בתמונה באה כיצד אפשר לקרוא את הטקסט על הכלים שנמצאים בפינה ימנית תחתונה?

אז בואו נחליף ערכת הנושא... למשל ב-Gnome מצאתי ערכה נעימה ובהירה, אבל... בצבעים של גופן אפור כהה על רקע בהיר כהה, ניגודיות איומה! או שערכה מכוערת או שפשוט לא נעימה לעבודה ומעייפת עיניים.

תפריטים חדשים: זה מאוד אפנתי לעשות תפריט קטן ומרובע ש... מסתיר חלק מהאפשרויות. פעם כשבחרתי תפריט, היית רואה את הכל או כמעט הכל. היום? צריך לדפדף עם גלגל העכבר כדי להגיע למקום מסוים. אסטטי? יותר. שימושי? פחות.

הגדרות והתאמה אישית: חוץ מ־KDE 4 שמכיל תפריט הגדרות עשיר במקום ברור (כמו תמיד) כולם מאוד צמצמו את יכולת ההגדרה של הסביבה. קשה יותר להתמצא, יש פחות אופציות פחות ערכות נושא.

אחד הדברים הראשונים שאהבתי כשהתחלתי לעבוד בלינוקס זאת גמישות הסביבה: איפה אני שם שעות, סרגל משימות, תפריט, רכיבים של שולחנות עובדה וכד'.

הכל היה מאוד גמיש והיה קל לשנות את ההגדרות. למשל, כשעבדתי עם KDE3 הגדרתי מיקום הפנלים דומה לזה של Gnome עם שינויים והתאמות שונות.

היום, סביבות העבודה החדשות באות עם "ראיה משלהם" איך הדברים אמורים להיראות... אם אתה רוצה לשנות את זה. אתה יכול אבל לעתים זה כבר לא גמיש כמו פעם.

גם הרבה אפשרויות שהיו לי נעלמו: לא הצלחתי למצוא דרך הגדיר "מקש חם" למסוף ב-KDE. אין תחליף ל-kkbswitch שמאפשר עבודה נוחה עם יותר משתי שפות. כל סביבת עבודה ממציאה דרך יצירתית ולא ברורה משלה לבצע הגדרות. לדוגמה, ב-Gnome 3 צריך לעשות alt-click כדי להגיע להגדרות פנלים. ב-KDE-4 זה סיוט לנסות להוסיף או לסדר כלים על הפנל וכן הלה.

מחשב נועד לעבודה: השינויים לא צפויים ורכיבים שנעלמים פוגעים באופן ישיר ביכולת העבודה שלי. למשל Gnome 3 לא ייבא את הסרגל עם לחצני התכנה שלי מ-Gnome 2. דברים שאתה משתמש בהם ביום יום נעלמו.

אני, שמחשיב את עצמי רגיל להפתעות סביבות העבודה, לא מצליח למצוא ידיים ורגליים. מה משתמש פשוט, לא טכני היה עושה? מה אימא שלי הייתה אומרת, אם הייתי מתקין לה Unity? פתאום היא הייתה צריכה ללמוד איך להשתמש במחשב מחדש!

אני חושב שמפתחים התחילו לשכוח ש-Gnome/KDE/Unity הם בסה"כ קליפה - "Shell". הם צריכים לעזור לנו לעבוד - לא להפריע. הם לא הרכיב המרכזי אלא רכיב חשובה אבל משני.

היום, סביבות העבודה במקום להפוך לאינטואיטיביות יותר, צפויות יותר, נוחות יותר, מהירות יותר הן הפכו למסובכות, מצועצעות, לפעמים לוקות בחסר עם הרבה אפקטים אסטטים חסרי תועלת.

נשברתי והתקנתי XFCE. מיד מצאתי דרך להגדיר כמעט כל מה שאני צריך, בצורה פשוטה וישירה. הסביבה מהירה בטירוף - וממש לא מדובר במחשב חלש. היא נוחה כמו ש-Gnome 2 היה. היום היא בהחלט חזקה ועונה על דרישות המשתמש מצד אחד. מצד שני, היא לא מביאה את הגישה המצועצעת של הסביבות המודרניות - היא עושה רק את מה שצריך לעשות ותו לא.

עדכונים

מסתבר שלינוס עבר ל־XFCE‏.

ציטוט:

I'm using Xfce. I think it's a step down from gnome2, but it's a huge step up from gnome3. Really.‎

מספר ימים עם Unity

ב־יום חמישי, 1 בדצמבר 2011, מאת ארתיום; פורסם תחת: תכנה חופשית, לינוקס, תכנה ומחשבים; ‏6 תגובות

כבר הרבה זמן עבדתי עם Ubuntu 10.10 ויצא כבר 11.10 אז החלטתי שאחרי שנה שלא שדרגתי את האובנטו שלי הגיע הזמן לשדרג. כיוון שלא ניתן לקפוץ בין שתי גרסאות שונות אז נאלצתי לשדרג קודם ל־10.04. כיוון שהייתי צריך לעבוד על המחשב על איזושהי עבודה דחופה, החלטתי לדחות את השדרוג הבא ולא להתעסק יותר מידי עם הגדרות (כי לא היה לי זמן לזה).

אז החתחלתי לעבוד עם Unity. דבר ראשון שקפץ לי: הם ניסו להעתיק את הממשק של Mac OS X. העתיקו את התפריט שמופיע למעלה העתיקו את ה־Dock. האמת שלא אהבתי את זה, אבל החלטתי לתת לזה ניסוי.

ברגע שהתחלתי לעבוד גיליתי תכונה מאוד חשובה שלמען האמת, בגללה פותח Unity במקור: התאמה טובה למסך רחב ונמוך - המסך של מחשבים ניידים. באמת יש אופטימיזציה טובה וניצול מאוד יעיל של מסך - בעיקר בגלל התפריט שמופיע למעלה ומצב full-screen בו הוא עובד.

אבל פה פחות או יותר נגמרו התכונות הטובות וכאן התחילו בעיות שימושיות שלי איתו:

  1. אין appletים... זה אחד הדברים החשובים מבחינתי, תמיד מופיע לי מד העומס, מד צריכת הזיכרון. איפה אפלט של שולחן עבודה וירטואלי שאפשר להזיז חלון פעולת עכבר אחת?
  2. התאמה אישית... איפה אני עושה התאמה אישית של ממשק? איך למשל אני מגדיר 6 שולחנות עבודה ויראואליים או 4 שיושבים בשורה אחת. קשה למצוא ולמשל אפילו חיפוש בתפריט הציג לי שתי תוכנות של הגדרות (אחד של Gnome והשניה של KDE)
  3. איך אני מגיע להגדרות המערכת וכד', למשל כיצד מגדיר מדפסת. פעם היה תפריט ברור System->Printing ומה עכשיו?

לסיכום, רעיון יפה, במיוחד למחשבים ניידים, אבל זה רחוק מלהיות שמיש.

טוב, אחרי שאשדרג ל־11.10 אחזיר את ה־Gnome הרגיל (או שגם הוא ייהרס כי זה היה Gnome 3?)

אני כבר מחכה ש־12.04 תשוחרר - LTS אז אני לפחות אדע שיש לי שקט בלי מהפכות למשך שנתיים.

כשהקצאות הזיכרון משנות

ב־יום רביעי, 10 באוגוסט 2011, מאת ארתיום; פורסם תחת: תכנה חופשית, לינוקס, תכנה ומחשבים, CppCMS, C++‎‏; ‏16 תגובות

יש הרבה צווארי בקבוק ביישומי רשת. רבים מהם נובעים מארכיטקטורת היישום, קריאות מערכת הפעלה ועוד.

אבל בשלב מסוים יישום רשת יעיל מגיע לנקודה בה הקצאות זיכרון מתחילות להשפיע בצורה משמעותית, בפרט זה נוגע לכל הקשור לעבודה עם מחרוזות.

ב־C++‎ יש מחרוזת הטובה הישנה: std::string. אבל יש לה מגבלה אחת: היא דורשת הקצאה של חתיכת זיכרון. זה נכון לכל מחרוזות בכל השפות ובכל הכלים גם אם הם immutable ומשתמשות ב-reference counting - עדין יש צורך להקצות זיכרון לאותה החתיכה.

בואו ניקח לדוגמה יישום פשוט שמאתר מקום כלשהו בעץ המשתמש במפתחות std::string המבוסס על std::map. הוא מקבל כפרמטר מחרוזת כמו ‎/foo/bar/124‎ ומחלץ ממנה את המפתחות foo ו־bar כחלקים במסלול, יישום בסגנון xpath.‏

אז עבור פונקציה:

void find_path(std::string const &str);

הקריאה

find_path("/foo/bar/123");

תצטרך ליצור שלוש מחרוזות:

  • ‎/foo/bar/123‎
  • foo
  • bar

כך או אחרת עבור שולש מחרוזות האלה נצטרך להקצות שלוש חתיכות זיכרון, גם אם המחרוזות שלנו משתמשות ב-reference counting או הן immutable.

אז כיצד CppCMS מתמודד עם הבעיה הזו:

  1. קיימת מחלקה מיוחדת cppcms::string_key שמחזיקה מתוכה את ה־std::string הישן והטוב. אבל בנוסף, ניתן ליצור את אותה המחלקה באופן מפורש מזוג מצביעים מטיפוס char const *‎, כך שהיא שומרת רק הצבעה לטקסט ולא מעתיקה אותו.

    כמובן, שבמקרה הזה, המשתמש הוא האחראי לכך שהמצביעים יישארו תקפים כל עוד משתמשים באובייקט הזה.

  2. עכשיו נשנה את הפונקציה find_path קלות ונוסיף לה עוד גרסה:

    void find_path(char const *str);
void find_path(std::string const &str);

    עכשיו, נשתמש רק במחרוזות שלא "מחזיקות בעלות על התוכן" ובכך נוכל ליצור מחרוזת מקורית ותת־מחרוזות foo ו־bar בלי להקצות זיכרון בכלל.

כמובן, זה הקו הכללי, אבל יש עוד הרבה טריקים מעניינים נוספים שמאפשרים למנוע או להוריד את כמות ההקצאות זיכרון כמו שימוש ב־pool שמוקצה פעם אחת ומשוחרר בסוף בבת אחת, שימוש במחסנית עבור קטעים קטנים ועוד.

CppCMS החל מגרסה 0.99.9 ששוחררה היום, אימץ את הטכניקה הזו בצורה רחבה ואפשר, במקרים מסוימים, להכפיל את ביצועים המערכת כולה.

כמובן, כשמשתמשים בטריקים האלה צריך להיות זהיר במיוחד גבי ניהול זיכרון ידני. אלא אם, קטע קוד רץ הרבה פעמים או כבר זיהיתם קטע מסוים כצוואר בקבוק, תשתמשו במחרוזת הרגילה. בסופו של דבר, הקצאה של זיכרון היום זה תהליך יחסית מהיר, אם לא מנצלים אותו לרעה.

העמוד הבא

העמוד הבא

דפים

נושאים