בשעה טובה יש לקוח דוא"ל בקי-די-י שמאפשר לעבוד עם שירותי הדוא"ל של מייקרוסופט

לאחר שבמשך זמן מה ב kde לא הייה לקוח טבעי שאפשר לעבוד עם Office365 ( ולמעשה בדביאן מאז 2023) יש פתרון מלפני חודש, האנשים הטובים ב kde פתרו את הבעייה וב 24.08 האפשרות להשתמש בimap ו smtp של חברת מייקרוסופט שוב פעם נפתחה לפני משתמשי kde.

 

אני די אוהב להשתמש בkde , הוא נוח, הוא פשוט, וזה פשוט נעים לי בעיניים, כמה אני פאן בוי ? אפילו באורן שלי רציתי להריץ plasma-mobile.

 

את 24.08 אני קיבלתי בפדורה 41, למעשה לא השתמשתי בהפצות מבוססות rpm ברמה האישית מספר שנים רבות, בעבודה אומנם השתמשתי בסנטוס, אבל אצלי בבית אני תמיד השתמשתי בדביאן, בנתיים אני מטייל לי בפדורה במחשב המיועד לעבודה מול Office365. אם בדביאן זה יעבוד (כנראה רק בגרסת ה experimental ) זה יהיה נחמד.

 

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

 

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

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

ענני

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

המערכת בנוייה בצורה הבאה :

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

שירותי ה DNS שבתוך שרת ה openvpn ניתנים ע"י bind9, שירותי הדואל מסופקים ע"י dovecot ו exim4 היומן ואנשי הקשר מסופקים ע"י ownloud.

בשביל ה SSL יצרתי לעצמי CA אישי וחתמתי על האישורים ע"י ה CA הזה , לאחר מכן התקנתי את האישור בכל אחד מהמכשירים שצריכים להתחבר (הנה מדריך מצויין).

שירותי ההזדהות של exim משתמשים ב SASL (בחרתי ב SASL כי אני רוצה לחבר גם ejabbered לסביבה וזה יקל עלי את החיים לאחר מכאן) (מדריך כאן).

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

פעולה זו מתבצעת ע"י fetchmail + cron , יש ליצור הגדרה עבור כל משתמש שרוצה את העבודה בצורה הבאה :

usera@sinta:~$ cat .fetchmailrc

poll pop.gmail.com with proto POP3 and options no dns port 995 user gmailuser@gmail.com there with password gmailpassword is usera here options ssl

לאחר מכאן ביצוע crontab -e מתוך המשתמש בשביל להוסיף את fetchmail -vk.

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

להפתעתי גיליתי של firefox 35 שמסופק ע"י f-droid יש בעייה בעבודה עם שירות ה dns שנדחף ע"י openvpn בגלל באג פתוח עד 35 כולל, בגירסה 36 זה קורה פחות אבל זה היה פשוט מטמטם הבטיחו לתקן ב 37 נחייה ונראה.

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

לדוגמה ייבוא יומנים מ ICS  - הדרך לייבא היא העלאה של הקובץ ולאחר מכאן (דרך ממשק משתמש) ללחוץ עליו ורק אז תשאל לאן תרצה לייבא את היומן.

עיגון תיקיות ה webdav ככונן משותף עבד חלק בדביאן, בוינדוס 7 ובאנדרואיד השתמשתי באפליקציה (הצולעת לטעמי) owncloud.

השלב הבא בבנייה (שאותה לא עשיתי עדיין) הוא הרמה של slapd וכיוון של כלל המערכות לעבוד מולו, אני חושב שזה עדיף בשביל הזיהוי מאשר עבודה מול טבלאות בשרת דואל (כך גם אין לי vendor lock מעצבן כמו שיש ב KDE). בניית סביבת ejabbered ועוד.

אתם מוכנים להוציא את היד שלכם מהארנק שלי ?!

התחלתי לבדוק מנהלי הסיסמאות (key chains / password managers)  עבור הדפדפן שאני משתמש בו רוב הזמן (אני שומר חסד נעורים ל Firefox) נשמור את העבודה שאני לא מחזיק עוגיות (רגילות או פלאש) וקיבלנו מתכון שמצד אחד רוצה לשמור על פרטיות ומצד שני על קלות השימוש.

אני יחסית אוהב את kwallermanager שהוא די מותמע כחלק מהסביבת KDE, אז לקחתי את הפלאגין הבא לסיבוב (מקשר בין kwallet ל firefox / iceweasel).

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


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

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




מרוב בקשות פשוט נטרלתי את הפלאגין - כי כמעט אי אפשר לגשת לאתרי חדשות (פרט ל slashdot ו  boingboing שביקשו רק פעם אחת).


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

עוד צעד אחד לקרב את הנייד לנייח

התרגלתי יותר מדי לעבודה כשיש תקשורת ועם מחשב יחסית חזק - 

נגיד אני שיש לי כ 1000 אנשי קשר (תמונה , אתר , חברה קשרים ... ) יש לי כיום בעייה לעבוד עם הרשת נופלת:

חלק מהמידע מאוחסן ב Google.

חלק מהמידע מאוחסן ב Facebook.

חלק מהמידע מאוחסן ב Linkedin

יש המון מידע שיושב בCRMים הארגונים.

אהה ונכון יש גם מידע לוקאלי שאני כמעט לא מעדכן (* מחכה שיתקנו כבר באגים מטיריפים).

אילו היה לי פתרון שהיה מאפשר לשמור על המידע בצד שלי בלי לדאוג יותר מדי זה היה מצויין.

מה שאני עושה לפעמים כשאני יודע שאני יוצא לנסיעות ללא תקשורת זה פשוט לבצע export ו import שזה ממש לא תענוג גדול כשאתה עובד ב akonadi.

כשהיה לי מכשיר שתמך בדחיפת מידע משרת אם זה funambol (שאני לא ממש ממליץ ) ואם זה libsynthesis (שהשתמשתי בו בשביל ליצור שרת לעצמי) תמיד היתה לי בעייה עיקרית : 

אני צריך להשתמש גם ב backend לסנכרון (mysql/ ms sql / filestorage ) 

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

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

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

על מנת לפתור בעיות של מידע כפול יצרתי פנקס כתובות ע"ג ldap , שירות מיילים ע"ג currier וסינכרון יומנים ע"י davmail.

לאחרונה אני רואה שהמצב הזה השתפר - היום מערכות ה PIM מאפשרות שיחזור טוב יותר (פרט לאנשי הקשר ).

נניח ואני מחזיק את אנשי הקשר שלי ב מערכת הקבצים מספיק בשבילי לבצע export ל vcard3 ולדחוף את הקבצים לתיקייה המערכת תדע להתמודד עם זה.

אבל אנחנו משתמשים בakonadi והמצב שם יחסית שונה - 

אקונאדי היא הסביבה האחראית על ניהול המידע והיום המערכת לא ממש  יודעת לעבוד מול מספר מופעים : 

כל מחשב , מכשיר סלולר מתחבר לinstance שלו ועובד מולו.

הבעיה הזאת נתנה רעיון פיתוח לחברה של Kolab ולפי הפירסום הם הולכים לפתח שירות שיאפשר עבודה של מספר מכשירים כלפי סביבת PIM מסונכרנת - 

בצורה כזאת גם המחשב הנייד שלכם יעבוד מול ה ACS (Akonadi Control Server) וגם מכשירי הסלולר שלכם יסונכרנו מולו.

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

רגע זה נראה לכם מוכר ? נכון .. ראינו משהוא כזה כבר פעם זה לא בערך מה ש QMF ניסה לעשות פעם ?
אז אולי בנקודה כזאת אפליקציה שבנוייה  ב QMF תעבוד מול אקונאדי במקום מול השרת .. (כן בסדר.. ).

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

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

נ.ב.

לפי פירסומים זרים syncevolution יודע להתמודד עם מספר מערכות PIM ולדחוף את המידע .

(*) - מאז השידרוג ל QT4 לקוח הכתובות האהוב עלי עובד בצורה גרוע מevolution :

אם אתה צריך לבצע merge , find duplicate אתה חייב להשתמש באפליקציות חיצוניות.

הרבה מאוד מידע הוסר והלך לאיבוד - הסכמה של kaddressbook ב kde4 שונה מkde3.

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

להבין שאתה באמת צריך זה עוד מימוש של סיפריה

 זוכרים את הwsdl של אחת ממערכות ה CRM שנלחמתי בה לאחרונה ?
נו זאת אם ה WSDL שלא מתאים לצד השרת.

מאוד התלהבתי מהעובדה שעכשיו זה עובד והגעתי לנקודה שהבנתי שאני יכול לממש pim plugin שיעבוד עם thunderbird + lightining + provider/ kontact

התחלתי לממש את ה library שאוכל להכניס ואז ירד לי האסימון - אני ממציא מחדש את libgcal רק עבור CRM אחר. כמה שעות של טיול בקוד ואני מבין ש:

• צריך ספרייה שתוכל לתת מידע מהקישור בין המכונה המריצה לבין מערכת ה CRM.
• צריך להשתמש בספריות כמה שיותר גנריות וכמה שפחות תפורות למערכת (היה שלום MSXML).
• צריך קוד ב C טהור - צריך להבין איך לעשות נכון את ניהול ועיבוד המידע  (pthread לא בא בחשבון)
• צריך פתרון פשוט בשביל לא לגמור עם עוד רעיון שלא יהיה אפשרי לכתיבה (ראה ערך אקונדי ב thunderbird).

לא אמרתי נואש קפצתי לחבר שהוא כותב למערכות PIM כעבודה והוא שימח אותי בכלל : 
כמו שחשבתי עדיף לבצע הפרדה בין סיפריה שתבצע ניהול חיבור ויצרת איש קשר / יומן מאשר לקחת את הקוד ולהשתמש בהתאמה של כל אחד ממנגנוני הPIM.
צריך להזהר מלהשתמש בהתקני האיחסון היפים למידע (המחלקות של KDE , Evolution )  ולהשתמש במחלקות של vcard  , vcal / vcalendar וכן מעטות הסיפריות שמתנהגות בצורה זהה גם בויינדוס וגם בדביאן.

בנושאי vcard צריך להזהר כי הרבה מאוד חברות מגדירות שדות נוספים שיש צורך לזהות (רמז עבה לסקייפ ו KDE).

לבנתיים אני יושב על ה design אם כי gdata נראה ממש טוב. 

 

הצרות שלי עם SOAP

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

ישנם היום הרבה דרכים להשתמש ב RPC על גבי רשת (ידוע גם כ webservices) זה יכול REST הישן והטוב (פשוט תממשו url לכל בקשה).
זה יכול להיות XML-RPC המצויין לדעתי.
אבל לצערי המון פעמים רואים שימוש ב SOAP בלבד , ותמיכה בסוג אחד של סביבה נתמכת.

הסיבה לפחות בארץ היא שליטת אחת מסביבות הפיתוח בשוק (מישהוא אמר .NET ?) ושם כברירת מחדל מופיע בשימוש ב SOAP (אם מישהוא רוצה להעביר מידע הדרך הפשוטה בשבילו ביותר היא SOAP) , אם לפני שנים אנשים למדו והבינו עם מה עובדים היום יש כמות אדירה של פקידים שלא זזים מילמיטר מהמקום הבטוח שלהם שפשוט מושכים תפריטים.

לא פעם שמעתי תגובות מה איך אתה משתמש ב webservices מתוך C++ ואיך בכלל אתה משתמש ב telnet - זה בטח האקינג... 

והחלק הנורא ביותר - הwsdl שלך אי אפשר לעבוד איתו.

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

אתם חושבים שזה הכול ? 

מתברר שהרבה צועקים שאי אפשר להשתמש ב soap ולהחזיר תשובה כאשר זו לא נמצאת בתוך  בקונטיינר (יש אלמנט תשובה ובתוכו עוד כלל התשובות שלכם).

משום מה ברירת המחדל של יצרת complex type אומרת שכולם צריכים לעבוד לפי החליל של MS (מי שעובד ב Java מקלל במיוחד את יצור הwsdl ).

לאלה מאיתנו שכותבים קוד ב C++ קל יותר יש לנו מספר חבילות שדואגות לנושא (הממ .. gsoap + libxml) , ברגע שיש דרישה אנחנו פשוט משנים את הפורמט בלי יותר מדי כאב ראש.

על כן יש לי (ולהרבה אחרים) כלל - 

במהלך ההכנה לחוזה אנו כותבים כי כלל הממשקים חייבים להציג את כי פעולת התקשורת אפשרית באמצעות אפליקציה צד שלישי מוכרת (soapui/telnet).

זה נשמע לכם כמשהוא מוזר אבל לפעמים מגלים שצריך איזשהוא dll בשביל לבצע עוד תקשורת ועיבוד של המידע (הממ... crms המממ...). כן כן אבל ה webserivce שלי דורש NTLMv2 יגיד המתכנת (לדוגמה בdynamics) - למצב כזה אנחנו יכולים להתמודד שלauthntication נדאג אחרי זה (כי gsoap לדוגמה מאפשר זאת ) וחוץ מזה שכבר זונחים את NTLM ועוברים לkerberos.
בגלל זה עדיף לחלק את העבודה בין עבודה עם רק webservices לעובדה עם מכלול אפליקציות אחרות שצריך לתקשר איתם.

הרי בשביל מה יש ממשק וובי / webservices אם צריך עוד אפליקציה בשביל לעבוד זה (ראה ערך dynamics crm / owa בלי outlook שמותקן על המחשב המקומי).

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

(עדיין תקוע עם webservice בשביל לגרום לCRM לעבוד עם akonadi :-( )

Kontact on an exchange 2007 SP2

איזה אושר אפשר לגשת ולקבל גישה מלאה לאלמנטים של שרת exchange מתוך kde (בלי davmail) :

• את שירותי ה email קיבלנו כבר מזמן (פשוט הגדירו את שירותי ה imap/pop3 בתוך kmail)
• פעם הגישה היחידה לאנשי הקשר היתה שימוש בldap , אבל עכשיו יש פתרון נוסף כפלאגין של אקונדי.
• גישה ליומן הארגוני באמצעות אותו הפלאגין.

על מנת להשתמש בזה יש ליצור חשבון באמצעות mapiprofile.
להוריד ולהתקין את הפלאגין : 

svn co svn://anonsvn.kde.org/home/kde/trunk/playground/pim/akonadi/exchange

cmake exchange

make && make install

להוסיף את החשבון בתוך kmail וזהוא יש לכם גישה למידע האירגוני של החברה.


חשוב לזכור שמוצרי dynamics לא מסונכרנים כברירת מחדל כך שחברה שמתשמשת ב dynamic crm לא תוכלו לגשת אליה באמצעות הפלאגין הזה.

האם אקונדי היא התשובה שאנחנו מחכים לה בנושאי CRM?

 היום כל חברה מייצרת ומשתמשת באיזה שהיא מערכת CRM.
בין עם זה Microsoft Dynamic Crm  / Sugar Crm / HighLearn / Rashim systems או כל מוצר אחר, לרוב המערכות היתה תמיד את אותה הבעיה :
הם מותאים מאוד לממשק וובי (ובמקרה הטוב יפתחו ויצגו במשהוא שונה מ IE על גבי וינדוס).
בשנים האחרונות אפשר לראות פתיחה לעוד אפשרויות גישה בצורת webservices או ממשקי REST.

הבעיה אף אחד לא שומר על תבנית של אחרים כל אחד יש לו התנהגות שונה.

לכן framework שיכול לתפקד כרכיב ביניים הוא חיוני (אתה משאיר את הלוגיקה במקום אחד ומוריד כפילות קוד).

דוגמה מצויינת שאני משתמש בה רבות הינה אקונאדי (Akonadi) , אמנם היא נועדה לשמש כפתרון pimי מוצהר היא מתפקדת טוב גם כלפי נתונים אחרים. הדבר החשוב בה זה ההתממשקות שלה כלפי סביבת העבודה:
אמנם היום היא רק תומכת ב KDE (במוזילה עדיין מחכים לאביר על המקלדת הלבנה ) אבל בגלל שהיא כבר עובדת בwindows וההפצות החביבות עליכם היא יכולה לשמש כפלטפורמה יחודית.


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

באקונדאי אני פשוט יורש את את המחלקות הנדרשות ומבצע קריאות לספרייה שלי שמתקשרת ל YetAnotherCrm.
העובדה יורדת מימים לשעות בודדות (כאשר יודעים איזה קריאות צריך לעשות ).
 

לזכור להתקשר בשביל מזל טוב

לאחר השידרוג האחרון שעשיתי ל kde (ל 4.6) גיליתי שימי ההולדת והחתונות הפסיקו להופיע ב korgnizer.
הלכתי למקור וגיליתי שאני עושה בדיוק מה שתומס ממליץ רק שאצלו הכל עובד מהקופסה ואצלי איך להגיד ... כלום.

לאחר חיפוש והגדרות ונפילת בסיס הנתונים של akonadi (למה לא הגדרתי לו לעבוד מול בסיס הנתונים שלי במקום לשמור הכל בקובץ ?!) גיליתי את הפתרון.

מתברר שakonadi חי בעולם משלו ויומנים אחרים פשוט לא רואים מה שקורא:
אם פעם היה מספיק ליצור יומן ימי הולדת אחד בודד המצב ב 4.6 השתנה , בשביל להשתמש בתזכורות צריך ליצור מופע (instance) של יומן ימי ההולדת כאלמנט בתוך האוגר של akonadi:

לאחר שהוספת מספר יומנים / ספרי אנשי קשר (kfacebook , google ו אולי kwhatsup ברגע שחזור היומן) יש להוסיף לאותו האוגדן anniversary  & birthday.

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

 BEGIN:VCARD
ADR;TYPE=home:;;חוות אינטרנט של בזק לאומי;;;;Israel
BDAY:2002-02-23T00:00:00
FN:Whatsup
N:Whatsup;;;;
UID:1UGx1gnzEp
URL:www.whatsup.co.il
VERSION:3.0
X-KADDRESSBOOK-X-SpousesName:linux-il
END:VCARD

החלק היפה מתחיל לאחר שהוספת את כל אנשי החיבורים לשירותי הציבוריות (משתמשי google, facebook וכו').

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

ופתאום היומן שלי מתמלא בימי ההולדת של אנשי הקשר שלי.

באג מעצבן באקנודי

בשידרוג האחרון של אקנודי  בדביאן (4.6.4) שמתי לב שהמערכת הופכת ללא שמישה:
kmail לא עובד , אין תגובה מממשק המשתמש (תנודות עכבר לא מרונדרות) בקיצור המערכת תקועה.

אחרי קפיצה לtty0 אני מגלה שהתהליך akonadi_maildir טופס 100% מעבד וחוסם את akonadi_server , אם זה לא מספיק כמעט כל resource שהיה בעל יכולות קאשינג תקוע.

חיפוש גיגול והפתרונות :
להעיף resourceים שאתם לא משתמשים בהם: maildir , mbox , maildispatcher
אם זה לא עובד לאתחל את תיקיית הconfig

דיון בנושא לוגים

בימים האחרונים מתחולל דיון די מעניין ברשימת התפוצה של kde-pim מהיא צורת הלוגים שצריכה להרשם. לדעתי הדיון נותן מבט מעניין למתכנתים בכל תחום שהוא לכמות החומר והאיפיון שלו ברגע שהוא מגיע ללוג. כן אני יודע שתשובת RTFM או STFW היא תשובה מקובלת אבל האם זה מספיק טוב ?

אבל האם יש אפשרות ללוגים ברורים יותר ? האם לא יותר טוב לקבל בלוג את השורה המדוייקת בקוד ואת הנושא של הבעיה יותר מאשר akondai לא עובד ? בנינו כמה פעמים יצא שישר איך שרואים משהוא בלוג אוטומטית עוברים לחיפוש בגוגל על השגיאה. לא יותר טוב שהשגיאה תסביר מה בדיוק הבעיה ? במילים אחרות מה שאנחנו אומרים לאנשי הQA כשהם פותחים ticket אבל האם אנחנו עובדים לפי אותם חוקים ?
כמה פעמים היית רוצה לקבל שגיאה :

file , line : Value is K when should to be N , problem is in P

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

וכרגיל kde4win עושה לי צרות

מרפי , או מרפי מדוע אתה מציק לי ?! (ולמה אני עדיין ער ?!)

לפני שבוע כמה אנשים ראו אצלי בטויוטר סטטוס משעשע בנושא של KDE. הסיבה אני כרגיל מנסה לדחוף את kde4win בסביבת עבודה עיסקית כי אוהב להשתמש בKDE גם על וינדוס. הבעיה ? ב4.4 בשונה מ4.3 יש דרישה שaknodi ירוץ .
התוצאה ? 85% ניצול מעבד תקיעה של כל המערכת ביטול והפלת על מה שקשור לkde. וזה בדיוק כשהבוס מגיע.

בקיצור אני לא הולך להריץ את kontact על המכונה (מהסיבה הפשוטה שאין לי יום שלם להשקיע). אני מאוד מופתע כי עד עכשיו שימוש ב4.3 היה גם מהר וגם ללא תקלות מיותרות חוץ מהעובדה שהחליטו להוציא את השימוש ב ldap - כלומר חסל סדר רשימות כתובות של AD בשימוש מkmail בוינדוס.

אני מאוד מקווה שיהיו תיקונים (במיוחד בנושא של aknodi) בkde4win כי אני די אוהב להשתמש בזה (כשאין באגים).
אני צריך להראות את ה"פתרון מהקופסא" לשימוש של כל הנושא המשרדי :
אימייל
IM
פנקס כתובות
יומן

שני המתמודדים שלי תמיד הם thunderbird+firefox+pidgin לעומת kontact רק שהפעם kontact הפסיד טכני.
מה הופתעתי לגלות שowa sync עדיין לא מוכנס לעבודה בkontact הייתי מצפה שפתרון שהוא לא פארסינג לאתר יהיה כבר קיים בחבילת תוכנה מתקדמת. לדעתי הפיתצר הזה יחסית חסר אבל בגלל כל הנושא של akonadi אני אפילו לא ניכניס לנסות לפתוח את הפיטצר הדרוש (יש המון מה ללמוד ואין לי כרגע את הזמן הדרוש לכך). אני אישית מצפה לקבל תפריט בחירה להגדרה של כל מה שקשור ל owa בהגדרה. אני יודע שאפשר להגדיר ידנית את תיבת המייל , את חיפוש הכתובות (LDAP) אבל זה סיפור לחפש כל פעם את ההגדרה המדוייקת (וזה עוד לפני הסיפור של לקבל גישה דו כיוונית לshared folder שמוגדר בשרת). כן אני יודע שזה בניגוד לתקן IMAP4 אבל מה לעשות אני מצפה מתוכנה שפשוט תעבוד. כן כן אתה אמור למצוא את התסריט שעושה עבורך את העבודה