קטגוריה: טלפוניה

מציאת רשומה לפי התחלה מדוייקת ב PostgreSQL

הנה בעיה מעניינת – כיצד אני מביא רשומה המתאימה ביותר להתחלה כלשהי, כאשר ההתחלה משתנה באורך/תווים שלה?

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

כאשר אני יודע כי 2 תווים ראשונים מחזיקים תמיד בקידומת הבעיה מאוד פשוטה – אני חותך 2 תווים ראשונים ומחפש עליהם קידומות בצורה חד חד ערכית, ואם מדובר ב unique index חיפוש מהיר ביותר שאולי יעשה sequence scan במקום חיפוש באינדקס ויהיה מהיר מאוד.

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

למזלי יש כלים מאוד חזקים המסייעים בזה עם מסד נתונים PostgreSQL או PG בקיצור.

הדגמה של טבלת קידומות:

להמשיך לקרוא

צעדים ראשונים ב wireguard

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

כלומר נגיד ואני רוצה לגשת ל 10.0.0.12 ב HTTP כאשר אני נמצא באינטרנט, והשרת נמצא מאחורי 10.0.0.12, אין לי סיכוי ללא יכולת לעשות Port forwarding, הנגשת השרת כלפי חוץ או reverse proxy כלשהו.

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

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

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

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

הרעיון של Wireguard הוא שכל חיבור בין אם "שרת" ובין אם "לקוח" הוא בעצם Peer.
כאשר אני רוצה לתהחבר ל"שרת", אני אשים את הכתובת להתחבר אליו, ובמידה ואני רוצה למצוא שכנים אני אגדיר אותם במפורש בקובץ ההגדרות עבור אותו Peer.

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

ישנם מדריכים מדהימים ברשת, כולל באתר, הרשמי, כך שלא אכנס להגדרות כאן.

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

אחד הדברים המדהימים באמת של Wireguard זו הפשטות ליצור תעודות הצפנה.
פקודה קטנה ליצור מפתח פרטי ופקודה נוספת לקחת את המפתח הזה וליצור מפתח ציבורי.
בקובץ של המכשיר שמים את המפתח הפרטי, ובהגדרות של כל מי שצריך לדבר איתו שמים את המפתח הציבורי.
המפתחות שמורים כשורת base64 ואין התעסקות עם המון כלים כדוגמת easy-rsa של openvpn, ואין צורך להתעסק עם openssl.
קובץ ההגדרות יראה בצורה הזו ב"לקוח":

[Interface]
PrivateKey = 
Address = 10.1.0.2/24

[Peer]
PublicKey = 
PersistentKeepalive = 20
Endpoint = address:port
AllowedIPs = 0.0.0.0/0, ::/0

[Peer]
PublicKey = 
AllowedIPs = 10.1.0.3/32

[Peer]
PublicKey = 
AllowedIPs = 10.1.0.2/32

 

היצירה של ה QR התבצעה על ידי באמצעות לינוקס עם הפקודה qrencode בצורה הזו:

qrencode -t PNG -o qr_conf_for_phone.png --verbose < wg_conf_for_phone.conf

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

בשורה התחתונה, אני מאוד מרוצה מה vpn שלא רק קל להגדרה אלא נראה יציב יותר.

אופטימיזצית פרוייקט בזמן קורונה

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

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

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

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

התחלתי למדוד מה המקומות שלוקחים הכי הרבה זמן וגיליתי כי משהו שהוא מחוץ לשליטתי הוא הגורם לכך.

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

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

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

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

יצרתי סוג של טיימר הסופר עד כמות מסויימת של מילי שניות ובמידה והגיע אותו timeout לפני שהתוצר הסתיים, הייתי מדווח שגיאה חזרה.
במידה והסתיים, המידע המתאים נשלח כי הוא התקבל חזרה, ובטיימר לא היה באמת sleep כלשהו אלא תפיסה של "אירועים" על ידי שיחרור מיוטקסים או לחכות לmutex מסוים להשתחרר. הידע מתי לשחרר אותו התבצע על ידי שמירת ה payload שמגיע בstreaming pipe עד אשר תו מסויים מגיע, או אורך מסוים הגיע (הראשון מבניהם). במידה ועד שזה מתבצע הגיע הזמן לשחרר, אז mutex אחר שספר ticks פעל כאשר הבדיקה היתה על אחד משניהם.

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

לאחר השינוי הזה, המערכת התחילה לחזור אלי לרוב אחרי 10-200 מילי שניות, כאשר 500 מילי שניות היו לתוכן גדול בהרבה ממה שאותו משרד ממשלתי שולח אלי.

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

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

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

היה שלום פרל, ותודה על הסימנים

לפני מספר שנים כתבתי את המערכת האחרונה שלי בפרל.
היא תרגמה DSL לפעולות בפועל שמבוצעות.

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

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

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

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

על הדרך גיליתי שורות קוד שהזכירו לי גם מה לא אהבתי בפרל (אם כי במכלול הגדול של הדברים, אני מת על השפה). למשל 4 שורות קוד שלקח לי שעה להבין מה הן עושות (ואני כתבתי אותן) כי הן השתמשו במשתנים כדוגמת ‎$_‎ אשר מייצג למשל תוכן של scope ולא תמיד ברור של מה התוכן. בנוסף גם עוד מספר משתנים בסגנון.

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

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

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

זה סוג של סיום תקופה כזו. אז היה שלום ותודה על סמלים

מתכנת IT

הרבה שנים שאני מנסה להסביר לאנשים מה המקצוע שלי. אני מנסה להסביר כי המקצוע שלי הוא "מתכנת IT", אבל אנשים חושבים כי אני מדבר על DevOps.
התשובה היא לא, זה לא DevOps.

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

עכשיו אשאל אתכם שאלה: האם איש DBA שייך לקבוצה הזו? התשובה היא כן. האם הוא איש DevOps? התשובה היא לא.

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

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

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

איש DBA יודע למשל המון על IO ועל דיסקים, וזיכרון, אבל זה לא אומר שהוא יודע מספיק בשביל להחליף ציוד, או לבחור חומרה בצורה נכונה. הוא רק יודע מה מסוגל לתת ביצועים טובים, אבל האם לוח מסוים עדיף? האם שרת מסוג מסוים? האם בקר מסוים? האם מעבד מדגם אחד טוב יותר וכיוב', הם פחות מהמומחיות שלו. זה לא אומר שהוא אינו יודע, זה אומר שהוא פחות חי את זה. זה יותר סוג של by-product של העבודה, מאשר המומחיות.

להמשיך לקרוא

סיכום שנה – 2015

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

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

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

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

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

פרויקט של גוף ממשלתי שהשורשים שלו נטעו בסוף 2012, הגיע למצב של פיילוט ב2015, שעכשיו ב2016 כנראה שיכנס להיות בכל הארץ אצל אותו גוף ממשלתי.

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

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

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

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

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

אנדרואיד, mms ובעיית אבטחה עם פתרון ישים

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

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

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

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

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

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

כיצד עובד ה MMS? אני שולח הודעת SMS במבנה מסוים שאומר כי יש לי משהו כדוגמת תמונה בשרת שניתן להוריד באמצעות WAP.

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

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

הבעיות שיש לי עם תכנות ריספונסיבי

הקדמה

אנחנו חיים בעולם שיש בו המון מילות באזז, כדוגמת big data, responsive design, cloud computing, סייבר וכיוב' …
כל המילים האלו מגיעות מעולם השיווק, אבל לאדם טכני לא באמת אומרות הרבה.

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

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

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

מונחי יסוד

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

CSS – הם קבוצה של חוקים אשר יכולים לכסות אחד את השני (מכאן השם: Cascading Style Sheet) בצורה שתספק עיצוב למסמך.

הסבר

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

בטח תשאלו מה ההבדל בין הדברים.
ובכן, כאשר מדברים על עיצוב, אנחנו מדברים על איך המראה יהיה תחת רזולוציות שונות, אבל למשל תקשורת סלולרית (HSPA) כדוגמת 3G, 4G, LTE וכיוב', אינן נלקחות בחשבון, היות והן מדברות על תעבורה, לא על מראה.

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

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

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

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

האקינג לראוטר, או איך להפוך ראוטר לקוד פתוח

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

מאז לא היו לי אתגרים באמת מעניינים בנושא ההאקינג של מכשירים, עד שרכשתי את WDR4300 של TP-Link והחלטתי שאני לא אוהב את הרעיון שאין לי שליטה על הראוטר שלי.

גיליתי שאני מוגבל, היות ובמדינת ישראל יש הגבלת תדרים על ידי משרד הביטחון (ולא משרד התקשורת) – WTF ?!
אז בגלל זה אני למשל לא הייתי יכול לעדכן את הראוטר לגרסה חדשה יותר של TP-Link, כי אין להם הורדה של גרסה "ישראלית" המגבילה תדרים (מצטער אבל זה הזוי).

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

זה כיף להיכנס למכשיר דרך telnet ולהתחיל להגדיר את הפצת הלינוקס כפי שאתה רוצה. וזה עוד יותר כיף, כשמערכת החבילות זהה למוקו 🙂 .
אחרי שאתה מגדיר סיסמה ל root, ה telnet מתבטל, ואתה חייב לעבוד עם ssh, שגם עברה מספר שיפצורים על ידי.

אני קיבלתי את הראוטר עם חומרה v1.7, שזה השיפצור האחרון של tplink (נכון לכתיבת הפוסט הזה) בנושא החומרה, ונראה שהכל עובד מהקופסא, אחרי שאפשרתי מספר דברים 🙂

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

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

הראוטר של בזק מנתק את ה wifi כל כמה זמן לכמה שניות. כלומר את המכשירים המחוברים אליו.
מדפסת הרשת שלי, משום מה לא עובדת כמו שצריך עם הראוטר הזה, אבל הכי גרוע זה ה TR-069 שיש בראוטר ואני לא יכול לבטל אותו, הוא סוג של back-door  לכל הראוטרים האלו, המאפשרים לבזק לבצע provision מרחוק, אבל מסכנים את הראוטר לחלוטין.

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

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

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

בכל מקרה, אני מאוד נהנה 🙂

אריקסון ו webrtc

כבר כתבתי בעבר על webrtc, אך זה עולם שכל הזמן משתנה ולא רק טכנולוגית.

אחד הדברים שמאוד נחמדים בעולם ה webrtc, זה היענות של מרבית החברות הגדולות בשוק בשביל לאמץ אותו.

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

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

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

החברה פתחה אתר בנושא, ושמה את הקוד שלה ב github, וגם הוא ברישיון פתוח – BSD.
הכלים שהיא משתמשת גם הם פתוחים, כדוגמת Gstreamer .
הם גם משתמשים במימוש של סיסקו – מימוש קוד פתוח עבור H.264, למעשה זה משהו שהם מספקים שגוגל בכלל לא.

הם גם משחררים דפדפן עבור iOS בשם bowser אשר מאפשר בעצם לקבל תמיכה ב webrtc, ובכך הם הופכים להיות הדפדפן הראשון במערכת הפעלה זו שתומך בזה.
הדפדפן נועד לקדם דווקא את H.264, אבל בנתיים גם מאפשר להשתמש ב webrtc.

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

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

כרגע יש קרב גדול על בחירת קודקים לוידאו, כאשר הקרב הוא בין H.264 לבין VP8 ובעתיד גם VP9.

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

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

טלפון חכם, טלפון טיפש

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

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

התשובה המסובכת יותר: להמשיך לקרוא

webrtc ORTC

הקדמה

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

הרעיון הוא לקחת SDP ו RTP (שכמובן מכיל RTCP) ולאפשר להזרים אודיו ווידאו בצורה טבעית בדפדפן ללא שימוש בתוספים.
הטכנולוגיה גם מגיעה עם תמיכה ב STUN, ICE ו TURN.

היא תומכת ב OPUS, ו G711, ומחייבת אותנו לעבוד בצורה מאובטחת תחת DTLS,

עכשיו כל מה שנשאר זה לממש מערכת סיגנלים כדוגמת SIP או כל פתרון אחר – פשוט יותר עם web sockets,שגם הוא כיום (לפי התקן של webrtc) חייב כבר להיות מאובטח תחת TLS, ויש לנו פיתרון סטרימינג מלא.

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

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

הדגמה קלה (מה RFC):

v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=.
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000

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

הנה הסבר על מה שאתם רואים מול העיניים שלכם:
האות v, מייצגת version – גרסת הפרוטוקול, שלפחות כרגע היא תמיד 0.
האות o, מייצגת origin של הבקשה, ומכילה (לפי הסדר) – שם משתמש, session id, בנוסף session-version, סוג רשת (אינטרנט), סוג הכתובת, כתובת הרשת.
האות s מייצגת את session, כלומר השם שלו.
האות c מייצגת מידע על connection. זה אומר סוג הרשת, סוג כתובת הרשת, כתובת הרשת.
הכוונה היא לאן רוצים להתחבר בשביל המדיה.
האות t מייצגת זמנים.
האות m מייצגת מדיה, עם סוג מדיה, פורט דינאמי, פרוטוקול משלוח של המדיה, ומידע הקשור לפרוטוקול.
האות a מייצגת attribute, שזה תכונות שונות, למשל כאן, זה מייצג איזה קוקדים של אודיו ישלחו, כולל הקוד שלהם שמוגדר ב RFC עבור כל סוג קודק.

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

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

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

תוכן

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

לפני ORTC, תכננו פרוטוקול אחר לגמרי, אשר היה מאוד low level, ומאוד קשה להגנה, וסיפק יותר מידי כוח בצד המשתמש. הפרוטוקול קיבל את השם Open Peer. אז בגלל הסיבות האלו, החליטו לרדת ממנו.

ואז ישבו הרבה אנשים, אשר רובם יצרו את webrtc ואת Open Peer, והחליטו על גרסה 1.1 לwebrtc בכנס מסחרי מסוים, אם כי למרות ההכרזה על 1.1 ההכרזה מרגישה יותר כמו 2.0.
השם לפרוטוקול החדש באותו כנס, קיבל את השם ORTC או Object Real Time Communication, אשר ה draft הראשון (מבחינת יכולת מימוש) שלו שוחרר באוגוסט 2014.
היכולת לעקוב אחרי דברים, נעשת באתר ייעודי לכך בשם ortc.org.

הרעיון הוא לספק סוג של API, שמצד אחד קל לתכנות, ומצד שני קל לאבטח, אשר מאפשר לשלוט בצורה קלה ופשוטה יותר במידע על המדיה, כאשר יש API בצד ה javascript, אך גם עם תאימות לאחור, בשביל לא לשבור פתרונות קיימים.
אבל לא סתם API, אלא הדגש הוא על גישה של Object Oriented, כאשר בעבר דיברו על כך שהיא תכלול את היכולת להחזיק אובייקטים של סוקטים בשם RTCSocket אשר ניתנים לשימוש מחודש במידת הצורך, ובכך בעצם לעשות שימושיות ב RTC ללא צורך באתחול מחודש של הכל. אך אינני מוצא זאת בdraft האחרון (נכון לכתיבת פוסט זה).

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

הבעיה היא שORTC הוא סוג של API שבסוף משתמש ב SDP (אבל רק בהתחלה – תאימות לאחור) ואח"כ כנראה שיפרד מהגישה הזו. אבל הם עוד לא בטוחים בזה. כלומר הרעיון שלהם, הוא שבסופו של דבר לא יהיה SDP, אלא דיבור ישיר בין ה"ענן" (מערכת כלשהי שאתם תבנו בצד השרת) לבין הדפדפן, ואיכשהו יוחלט מה יורץ.

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

ואכן, זה מה שORTC מבצע. הם יצרו אובייקט בשם RTCRtpCapabilities, אשר התפקיד שלו לדבר על "מה אני צריך" עם הצד השני וניתן אפילו לעשות החלפה בזמן ריצה של המידע (ב SIP זה נקרא re-Invite).

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

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

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

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

קודקים למתחילים

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

ישנו מושג בעולם המולטימדיה אשר נקרא codecs. הפירוש הוא encoder ו decoder של מידע כדוגמת אודיו ווידאו.

ישנם הרבה מאוד סוגים מאלו, אבל מה זה בעצם אומר ?

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

ישנם 2 סוגי דחיסת נתונים בעולם הקודים:

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

Lossless מייצג צורת דחיסת נתונים עם יכולת שחזור מלא של המדיע ללא איבוד המידע. הדחיסה נמצאת בעיקר בדחיסת מידע מדוייק, כדוגמת טקסט, פורמטים כדוגמת ZIP וכיוב'.
ישנם גם תמונות (כדוגמת PNG) ואפילו קבצי קול (כדוגמת FLAC) המשתמשים בשיטה זו, אך אלו נדחסים פחות טוב בדרך כלל, ולכן גודל הקובץ גדול יותר, מאשר אם היו משתמש בים lossy.

G711

להמשיך לקרוא

יצאה גרסת 1.4.4 של FreeSwitch

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

המרכזייה בנויה מיחידת בסיס (core) ואוסף מודולים שונים, אשר מספקים לה תכונות שונות, בהתאם לצורת השימוש.
למשל, במידה ומעוניינים ליצור call centre, אז יש מודול לכך, ובמידה ורוצים ליצור ivr בצורה פשוטה, גם לכך יש מודול. אפילו חדרי ועידה מקבלים תכונות רבות יותר מאשר אלו של אסטריסק.
כל ההגדרות כולל ה diallplan נעשות באמצעות קבצי xml, אבל אפילו תוכניות החיוג זה למעשה מודול חיצוני. כאשר מעוניינים בכך, ניתן לצאת לשפות תכנות חיצוניות (גם כמודול), כדוגמת lua (שנתמכת הכי טוב), פרל (לא מתועדת מספיק), פיתון ואפילו ג'אווה סקריפט (יש תמיכה ב v8 ו SpiderMonkey, כאשר האחרון נמצא בשלב deprecated).
בנוסף, יש מימוש של event sockets – אחת הדרכים לשלוט במרכזיה, ולקבל אירועים ממנה, על ידי שימוש בפרוטוקולי תקשורת, כדוגמת TCP. ואלו מאפשרים חיבור של שפות נוספות, כדוגמת Go.
בנוסף, יש גם ספרייה שממשת את rayo – תת פרוטוקול xmpp אשר מאפשר גם שליטה דומה ל event sockets.

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

עץ 1.4 הביא איתו המון חידושים ושיפורי ביצועים, בהם בראש ובראשונה תמיכה מלאה בתקני webrtc ו websockets, אשר מניסיון שלי, טובים יותר מהתמיכה שיש באסטריסק. נכון לכתיבת שורות אלו, כרום ביטל את התמיכה ב SDES, דבר שמקשה על התמיכה ב webrtc של אסטריסק ללא בנייה אישית שלו, בעוד שFreeSwitch תומך ב dtls-srtp ללא בעיה מהקופסא.

בעוד שהפצת הלינוקס העיקרית של אסטריסק מבוססת red-hat (בדגש על centos), החל מגרסה 1.4, דביאן היא ההפצה הרשמית של Freeswitch.
במידה ואתם עדיין על centos5, אז יש סיכוי כי אולי תתקלו בבעיות בעת השדרוג.

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

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

העניין החשוב באמת הוא, ש FreeSwitch מספקת את האפשרות לקבל מרכזייה יציבה, שמשתמת יחסית במעט משאבים (תלוי באופן השימוש), עם המון יכולות.
היא יכולה להיות למעשה מרכזייה ברמת class 4 ולא רק class 5 בניגוד לאסטריסק למשל. ועץ 1.4 מבטיח כניסה לעולמות חדשים.

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

סיפ, מדוע זה לא פשוט כמו HTTP ?

אחד התסכולים הרבים שיש בעולם ה VoIP הוא התמודדות עם בעיות הקשורות לעולם הרשתות.

רוב העולם בטוח כי HTTP זו התקשורת המסובכת ביותר שיש בעולם הרשתות, ולכן אני שומע את השאלה: "אני לא מבין למה SIP לא פשוט כמו HTTP ?"

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

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

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

על זה נוסיף עוד בעיה "נחמדה" אשר נקראת NAT, כאשר ישנם 2 סוגי NAT: להמשיך לקרוא

מוזילה, לאן ? (2014)

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

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

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

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

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

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

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

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

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

אז השאלות המתבקשות הן:

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

או בריכוז לשאלה בודדת, מוזילה, לאן ?

תכנון מודלארי של מערכת

"If I had eight hours to chop down a tree, I'd spend six sharpening my ax." — Abragam Lincoln

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

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

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

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

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

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

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

למשל אפילו הגדרה של "עד שלא מאשרים משהו, אתה משמיע אפשרויות" לקח לי חצי דקה להוסיף למערכת.

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

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

הגדרת sip trunk עם freeswitch

freeswitch שונה מאוד מאסטריסק בתפיסה של איך דברים עובדים.
במידה ונרצה להוציא שיחות או להכניס שיחות, אין צורך בהגדרות מיוחדות, למעט הגדרות acl לכתובות ip. כלומר בברירת מחדל אין צורך ככה סתם להגדיר sip trunk בשביל שדברים יפעלו עבור ספק מסויים.

אך במידה ויש צורך להגדרות מיוחדות, או הגדרות של ביצוע פעולת register, אז אנחנו זקוקים להגדיר sip trunk, אך גם שם ישנם 2 גישות, אשר מוגדרות תחת sip_profiles:

  1. internal
  2. external

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

בברירת המחדל, internal מוגדר להשתמש עם sip בפורטים של 5060 ו 5061 (אם זה sip או sips). בעוד שרשת external מוגדר בברירת המחדל להשתמש בפורטים 5080 ו5081.

השאלה הנזרקת לאוויר, היא מה קורה כאשר הרשת החיצונית נכנסת דרך 5060, והתשובה היא שfreeswitch מכניס ל header בקשה לעבור ל5080, ובמידת האפשר מעביר את התקשורת לשם, ואם לא, אז נשארים על 5060, אבל היא לא נחשבת לרשת trusted.

העניין הוא, שזה לא נעצר בפורטים, או בהפרדה הזו, אלא זה ממש מסייע למפות מההתחלה עד הסוף מאיפה השיחה מגיעה. האם היא נכנסת מרשת internal או external (למשל), ובכך גם להתנהג לגמרי שונה ולהיכנס ל context לגמרי שונים (כפי שמוגדר בברירת המחדל).
כך למשל, אפשר להגדיר טלפונים (מכשירי טלפון, להבדיל משלוחות המוגדרות ב directory) ב internal בעוד ש sip trunk (או gateway כשם נוסף) לספקית חיצונית נגדיר ב external. להמשיך לקרוא

Telegram – מימוש קוד פתוח דמוי WhatApp

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

לאחר שfacebook רכשו את Whatsapp, התחלתי לקרוא כתבות על תחליפים עבור תוכנה זו, ותוכנה אחת משכה לי את העין – Telegram.

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

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

וכך מצאתי תחליף נחמד וטוב לתוכנה.

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

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

בכל מקרה, ממליץ לכולם לעבור לתוכנה ולעזוב את פייסבוק במנוחה 🙂

מרכזיה או פרוקסי, על רגל אחת

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

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

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

מרכזייה סוג 3 (class 3) שהיא בעצם מרכזייה איזורית. וכמובן שזה יורד ככה עד לclass 1.

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

  1. שרת אותות (signals)
  2. שרת מדיה (media)

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

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

שרתי פרוקסי יודעים לנתב ולנתח שיחה, לאפשר או לא לאפשר הרשאות שונות, וכן לבצע חיובים שונים על השיחה. אך הם אינם מצב קצה של השיחה, כי אם מצב אמצע, כדוגמת נתב בתקשורת רגילה. אין לה שלוחות, היא לא מנהלת פעולות קצה של משתמשים, אלא רק יודעת לנתח שיחה על מגוון הדברים שלה, ולהחליט אם להמשיך איתה הלאה, ואם כן לאן, או להפיל אותה לפי הצרכים של השרת (UAS – Userver Agent Server), וכן הצרכים של הלקוח (UAC – User Agent Client).
פרוקסי לרוב מקבל את התאור של B2BUA. כלומר לנתח תעבורה ולהחליט מה קורה איתה, כאילו היה UAS.

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

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

הבנה של bindaddr באסטריסק

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

Serious Network Trouble; __sip_xmit returns error for pkt data

בד"כ במצב כזה, החשד הוא שמשהו אחר תופס את הפורט, אז הרצתי בדיקה של netstat ואפילו lsof, וכלום, הפורט פנוי.
הרצתי netcat כשרת, והוא הצליח ללא בעיה לבצע bind על הפורט הזה.

הבעיה היא, שהלקוח עובד עם elastix שמבוססת על freepbx, וזו מתערבת בקבצי ההגדרות, ויוצרת עוד קבצי הגדרות חדשים עבורך להוספה, ולא ניתן לשנות קבצי הגדרות ידנית, כי היא דורסת אותם, אלא אם אלו קבצי "‎‎_custom.conf"
לאחר המון שעות מחקר, החלטתי לגשת לקבצים שנוצרים אוטומטית, וגיליתי כי bindaddr הצביע על כתובת IP שאומנם חוקית ברשת של המרכזיה, אבל היא לא שייכת למכונה.

כאן צריך להיכנס ולהבין בעצם את אסטריסק יותר לעומק.
במצב רגיל, כאשר פותחים socket ניתן להגיד לו להאזין לכתובת ip מסויימת, במקום להאזין להכל.
אבל באסטריסק ביצוע bind הוא מעט שונה בתפיסה שלו.
באסטריסק, הכתובת ip היא כתובת שקשורה לניתוב. היא אומרת לאסטריסק מאיפה התקשורת תגיע ולאן היא צריכה ללכת. לא ברמה של כתובת שרת, אלא ברמה של כרטיס רשת. כך שאם כתובת הip אינה שייכת לnetwork device, אסטריסק אינו יכול "להינעל" על אותה כתובת ip, שכן זו בעצם היכולת שלו לבצע bind על כרטיס רשת ולכן הוא אינו יכול להאזין לדברים.

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

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

רשומות DNS עבור SIP

לפני מספר שנים, למדתי הרבה (אך לא הכל 😦 ) על עולם ה DNS ובעיקר עבודה עם Bind, אך מצאתי שבד"כ יש רק מספר מצומצם של רשומות אשר משתמשים בהם: A, CNAME, TXT ו MX.
לאחרונה יצא לי ליעץ למספר חברות שונות אשר רצו לספק יותר משרת אחד לשירות SIP, ומצאתי את עצמי עושה להם קורס מזורז (לרוב דרך דוא"ל ושיחות טלפון) כיצד זה מתבצע, אז החלטתי להעביר את זה לכתב, ולנסות ולסייע יותר לאנשים באופן כללי.

A/AAAA

רשומת A מייצגת בעצם שם מתחם עבור כתובת IP. יש לו אח צעיר יותר בשם AAAA אשר מבצע אותו הדבר, רק עבור כתובות IPv6.

CNAME

רשומת CNAME, יודעת לקחת שם מתחם קיים, ולתת לו alias לשם אחר, כלומר foo.example.com יכול גם להצביע על bar.example.com ובכך שניהם מצביעים לאותו הדבר. הפירוש של CNAME הוא canonical name record והוא מעט "ממזר" באיך שקוראים ומשתמשים ברשומה.

TXT

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

MX

ויש את רשומת MX, אשר היא קיצור של mail exchanger record. התפקיד של הרשומה הוא לספק גישה למספר שרתי דואר תחת שם מתחם בודד, כאשר יש "משקל" לכל כתובת. המשקל אומר על קדימות של שימוש בשרת אחד על גבי השני. ככול שהמספר גבוהה יותר, כך כמות השימוש בו תהיה גבוהה יותר. כך שאם אשים משקל 60 לכתובת אחת ו10 לכתובת שניה, אז על כל 60 פניות לכתובת הראשונה, יהיו עשר פניות לכתובת השניה.

SOA

עוד רשומה מאוד נפוצה (למעשה הנפוצה ביותר) היא SOA שהיא Source of Authority. היא מחליטה בעצם על מי מנהל את ה DNS בפועל, או כמו שחבר כנסת חיפש פעם, הוא פחות או יותר האחראי על האינטרנט, לפחות בנושא של שמות מתחם.

כל זה נחמד למרבית השימוש כיום באינטרנט, אבל יש למעשה כמה עשרות סוגים של רשומות DNS, ועבור SIP אנחנו צריכים להשתמש בדרך כלל ברשומה מסוג SRV אשר משתמשת דרכה בכתובת שהיא A/CNAME . להמשיך לקרוא

FreeSwitch או אסטריסק ?

הקדמה

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

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

להמשיך לקרוא

בזיון השעון (או איך חברות סלולר דופקות את הלקוחות שלהן)

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

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

אם חברות הסלולר היו משחררות firmware מעודכן לטלפונים שברשותן רק עם שינוי של tzdata, מעולם לא היתה צריכה לעלות הבקשה להחליף מישראל לאתונה, היות והשעון היה מתחלף כמו שצריך בכוחות עצמו (אצלי בלינוקס):

$ zdump -v Asia/Jerusalem | grep 2013 | grep Oct
Asia/Jerusalem  Sat Oct 26 22:59:59 2013 UTC = Sun Oct 27 01:59:59 2013 IDT isdst=1 gmtoff=10800
Asia/Jerusalem  Sat Oct 26 23:00:00 2013 UTC = Sun Oct 27 01:00:00 2013 IST isdst=0 gmtoff=7200

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

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

מה צריך להבין בפיתוח אפליצקיות לסלולר

אתחיל בגילוי נאות: אינני מפתח אפליקציות לסלולר.

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

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

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

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

למשל, פיתוח מבוסס רשת – תקשורת סלולרית של data יקרה יותר מאשר תקשורת בwifi למשל, אם כי כל פעולת רדיו מאוד יקרה בסלולר – כן, גם bluetooth ו GPS.

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

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

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

גימגום השיחה בטלפון

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

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

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

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

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

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

ניוד צרות

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

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

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

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

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

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

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

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

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

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

דרושה חשיבה חדשה לחקיקת מזיקים

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

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

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

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

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

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

לזרוס, חדשות תקופתיות

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

הנה חלק קטן מהדברים אשר הוכרזו בשלושה חודשים האחרונים בנושא:

ביום שני האחרון (4/02/2013) שוחררה גרסה 1.0.6 של לזרוס אשר מכילה תיקוני באגים בלבד.

בינואר שוחרר הסבר כיצד ניתן לפתח עבור Raspberry Pi באמצעות לזרוס.

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

מנוע המשחק Castle שיחרר גרסה 4 שלו. המנוע מאפשר לספק API גבוהה לפיתוח משחקים, התחברות למודלים (כדוגמת אלו הנבנים עם blender), ועוד.

אנשים בקהילת הלזרוס של סין (תתפלאו אבל יש כזו קהילה), שיחררו את pascal4android בסוף שנה שעברה.

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

אחרון חביב לפוסט זה, הוא Community של FPC/Lazarus ב Google+‎ שאתם מוזמנים גם להצטרף לשם כמובן.

where have all the music gone ?

I used to be a Pandora user, but due to issues with the Music labelling cartel, it was forced to close it's service outside of the U.S. Australia and New-Zealand.
So I moved to Last.fm that offered me to pay a fee and listen to music. Until I got the following Email: להמשיך לקרוא

עתיד עולם התכנות לאן ?

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

למשל כאשר אדם שאל שאלה בwhatsup על ללמוד לפתח אפליקציות לאנדרואיד. אנשים התחילו להציע לו ללמוד את שפת C ואת שפת ++C, וכו' … ובסוף אחרי שהבין איך לתכנת בשפות האלו, לעבור לJava אשר איתה הוא סוף כל סוף יגיע "למנוחה ולנחלה".

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

ההבדל בהצעה שלי, הוא בכך שבאמצעות FPC, אני יכול לכתוב אפליקציות טבעיות לאנדרואיד (מהדר אותן לקבצי class של ג'אווה), ויותר מזה, אני יכול גם לבנות מערכות עבור iOS (יש בMarket של אפל, תוכנות שלמות אשר כתובות עם FPC ודלפי החדש עבור iOS), לספק את אותן המערכות לסביבות שולחנות העבודה, web ושרתים. כל זה ללא צורך להחליף שפה או טכנולוגיה, ועדיין לתת מענה רחב יותר מאשר פיתוח רק בשפת ג'אווה או Objective-C. להמשיך לקרוא

פרצת אבטחה חמורה בFreePBX 2.10.0 / Elastix 2.2.0

גרסת FreePBX 2.10.0 וגרסת Elastix 2.2.0‏ ואולי גם גרסאות ישנות יותר, מכילות בעיית אבטחה בה ניתן בצורה מרוחקת להריץ קוד על השרת כמשתמש root, ובכך לחדור למכונה.

הבעיה מתרחשת בעקבות בעיית Cross Site Scripting אשר כותבת ללא פילטר מסויים לקובץ את התוכן ששמים ב URL. חשוב מאוד לעדכן את המערכת לגרסה האחרונה ביותר אשר מתקנת את הבעיה.

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

בין מעריצי אפל למציאות

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

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

השיר הבא, הולך להישמע לכם מוכר מידי, בגלל שיש שיר בשם Hotel California אשר באורך פלא דומה לו מאוד, אבל השיר שאני שמתי כאן, הגיע קרוב לעשור לפני …

אתה יכול לקחת את הגמל עד לבאר, אתה לא יכול להכריח אותו לשתות …

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

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

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

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

heimdall גרסת ה rpm

בעקבות תקלה שמחקה לי באמצע שדרוג Arch Linux חלק ממערכת הקבצים הכי חשובה (באג בחבילה של libc), מצאתי את עצמי מתקין פדורה 17 בסוף.

אבל יש לי כמובן Samsung Galaxy S II אשר אני מתקין עליו רומים שונים מידי פעם, אבל לשם כך יש צורך לעדכן לפחות פעם אחת קרנל, או אפילו יותר מפעם אחת (אם בא לכם).

בשביל זה המציאו את התוכנה heimdall ללינוקס, אשר מאפשרת לעשות זאת ל Galaxy.

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

תוכלו למצוא את זה כאן בgithub .

האם אורקל מנסה להרוג כל טכנולוגיה מבוססת מחשב ?

הבהרה: אלע"ד (אני לא עוכר דין).

"אין לי בעיה עם בני אדם שהם גם עורכי דין, יש לי בעיה עם עורכי דין השייכים לקבוצת בני האדם." – איי קיי

אורקל תובעת את גוגל על כך כי אנדרואיד מבוססת Java (מעכשיו אכתוב את המילה בעברית), אבל זו לא שילמה להם כסף (והרבה) על כך שהם משתמשים בשפה. או במילות אורקל – גוגל לא שילמה להם על רישיון מתאים.

גוגל מצידה אומרת כי חברת סאן (אשר לצערי אורקל קנו אותה), שיחררה את מימוש ג'אווה "לחופשי" ברישיון אשר מאפשר לכל דורש לעבוד איתה. לפני כן, היו מספר מימושים שונים של JDK כדוגמת המימוש של חברת IBM, אשר נוצר כ clean room. אבל אז למעשה Sun שחררה ב2006 את OpenJDK, ואף התעוד נפתח לגמרי, וקיבלנו API לגמרי פתוח של ג'אווה. ואז חברת RedHat יצרה פרוייקט בשם IcedTea אשר מאגד בתוכו את תכונות ג'אווה ללא צורך בתמיכה של עוד כלים לשם כך, תוך שימוש בגרסת קוד הפתוח שSun פתחה.

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

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

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

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

שימוש ב wvdial עם sim של חברת פלאפון

לפני שנתיים כתבתי כיצד מתחברים למודם סלולרי של חברת פרטנר (Orange).

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

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

מה שעשיתי הוא כזה:


[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Stupid Mode = yes
Modem Type = USB Modem
ISDN = 0
New PPPD = yes
Baud = 9600

[Dialer pelephone1]
; Pelephone modem
Init2 = AT&F &D2 &C1
Init3 = ATS7=60 S30=0 S0=0
Init4 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init5 = AT+CGDCONT=1,"ip","internet.pelephone.net.il"
Modem Type = Analog Modem
Modem = /dev/serial/by-id/usb-ZTE_Incorporated_ZTE_WCDMA_Technologies_MSM_MF1900PLED010000-if02-port0
ISDN = 0
Phone = *99#
Password = pcl
Username = pcl@3g
Ask Password = off
Stupid Mode = off

ההרצה מאוד פשוטה:

$ sudo wvdial pelephone1

גלישה נעימה.

לבנות את FPC jvmbackend

רכשתי לפני שבוע Samsung Galaxy S2, והגיע הזמן באמת לבנות משהו לאנדרואיד.

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

אז ניגשתי לרענן את העץ של jvmbackend מהsvn, והחלטתי לבנות בעצמי את הגרסה החדשה.
לפני כן, יש לעשות patch קטן בעץ הקוד של jvmbackend לקובץ fpc.pp: להמשיך לקרוא

freeswitch

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

Asterisk היא מערכת סה"כ נחמדה, מבית היוצר של חברת Digium והיא משוחררת ברובה כקוד פתוח.

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

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

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

האם אתה מעוניין לשמוע הרצאה על כלי לפיתוח תוכנות לאנדרואיד ?

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

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

אז האם הייתם מעוניינים לשמוע על כך הרצאה ?

אפליקציית Android לניהול נסיעות ברכבת

train managmentSven Barth כתב לעצמו תכנה לניהול הנסיעות שלו ברכבת, ולשם כך השתמש בלזרוס ו FPC for JVM.

הגרסה משתמשת ב SQLite בנוסף בשביל לשמור ולשלוף מידע, ורצה בצורה טבעית על ה VM של אנדרואיד.

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

הגרסה הקודמת של התכנה נכתבה עבור מערכת מבוססת Windows CE. הגרסה שהוא יצר ל WinCE, השתמשה בקבצי ini, אותם הוא כאמור המיר לSQLite.

Sven פרסם גם את קוד המקור של האפליקציה שלו, במידה ואתם מעוניינים להשתמש בה כמובן 🙂

גרסה חדשה ל FPC JVM

ג'ונס שחרר הודעה לרשימת הדיוור של fpc-devel על כך שהוא שיחרר גרסה חדשה של FPC-JVM.

כזכור, הגישה הזו אומרת שFPC מאפשר לי ליצור קוד שJVM יכול להריץ בצורה טבעית.

בגרסה החדשה נוספה יכולת להדר קוד שיהיה ניתן להמרה נוחה לdalvik של אנדרואיד, ובעצם בנוסף ליכולת ליצור קוד טבעי (arm) לאנדרואיד, עכשיו יש גם יכולת בעצם לכתוב קוד שירוץ כאילו נכתב במקור בג'אווה.

בשביל לגרום לppcjvm להדר את הקוד לקבצי class ש dalvik אוהב יש להעביר את הפרמטר הבא:

ppcjvm -Tandroid ....

כמובן ש3 הנקודות הם המשך הפקודה שרוצים לספק.

עוד תוספות ושינויים שנכנסו לגרסה הזו הם:

  • המהדר עכשיו מנקה כמו שצריך את קבצי ה j אלא אם הועבר פרמטר של a-.
  • עכשיו קובץ ה Makefile יוצר את ה rtl כמו שצריך עבור גרסת הג'אווה וגרסת האנדרואיד
  • תוקן קוד המתייחס לפרמטרים עם var או out בתוך פונקציות/פרוצדורות מקוננות
  • תוקן באג של try/except מקונן
  • נוספת פקודה למהדר Ctcompactintarrayinit-

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

  • תוקן קוד של copy כאשר x שונה מ0.
  • הקוד של ה rtl נכנס לספרייה rtl/android/jvm כך שלא תהיה התנגשות במימוש קוד טבעי של android arm.

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

"The greatest challenge to any thinker is stating the problem in a way that will allow a solution" — Bertrand Russell

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

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

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

ללמוד erlang

יש לי רשימה מאוד ארוכה של שפות תכנות שאני רוצה ללמוד אותם. הידע שלי של קרוב ל24 שפות תכנות לא מספיק, והרעב עדיין גדול מאוד, אז אחרי הרבה התלבטויות מה השפה ללמוד, החלטתי ללכת בראש ובראשונה על erlang, וכרגע אני עושה את הצעדים הראשונים שלי בשפה. השם של השפה, כמו שפה אחרת שאני מאוד אוהב לתכנת בה, גם היא על שם מתמטיקאי (בשם Agner Krarup Erlang), והיא מבית Ericsson, וחלק אומרים שהשם של השפה בכלל לקוח ממשחק המילים Ericsson Language.

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

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