חור אבטחה בגוגל קבוצות

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

גוגל, פישלתם.
ככה זה נראה (גרסא מצונזרת קלות):
google-mess1.png

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

Thank you for contacting us. We've made some changes recently that should
have resolved the problem you reported in our discussion group. Please let
us know if this issue persists.

Regards,
The Google Team

שרת Jabber

פתחתי שרת jabber על yadan.net (המחשב בסלון, לשעבר firefang.net, שגם מתפקד כשרת דואר).
jabber הוא שרת בפרוטוקול XMMP, שהוא פרוטוקל מסרים מיידיים נחמד ופתוח, מה שיפה זה שהוא גם מבוזר:
משתמשי ג'אבר בשרת אחד יכולים לדבר בצורה שקופה עם משתמשי ג'אבר בשרתים האחרים, למשל עם משתמשי Google talk.
עוד דבר נחמד זה שעם ג'אבר, לא צריך חשבונות שונים כדי להכנס מהעבודה ומהבית בו זמנית:
כל כניסה יכולה להשתמש במשאב שונה (בלינגו הג'אברי – Resource), למשל – מהבית אני נכנס תחת omry at yadan.net/Home ובעבודה דרך omry at yadan.net/Work. אם היה לי ג'אבר בסלולארי הייתי נכנס שם דרך omry@yadan.net/mobile או משהו. מה שנחמד זה שג'אבר יודע לנתב את ההודעות למקום הנכון (המשאב בעל העדיפות הגבוהה היותר שבו אני פעיל).
אז מי שרוצה לצ'וטט, אני omry at yadan.net בג'אבר. (@ במקום at).

ג'אבר מאפשר לכל אחד לשלוח מסרים למשתמשי Google talk (ולכל שרת ג'אבר אחר), פשוט יוצרים משתמש בשרת ג'אבר לבחירתכם ושולחים למשתמשי גוגל טוק. לא צריך כתובת ג'ימייל.
שרת מתבקש הוא כמובן jabber.org, כל מי שרוצה יכול להרשם שם ישירות דרך תוכנת הג'אבר הקרובה לביתו (שאינה Google talk, שכצפוי לא מאפשרת לבחור שרת).
אפשר להשתמש בPidgin, ואז ההרשמה נראית כך (כמובן שצריך להחליף את someone בשם הרצוי).
pidgin jabber

במקרה הזה, ברגע שנרשמתם, משתמש הג'אבר שלכם הוא user@jabber.org, ותוכלו לשלוח דרכו הודעות לכל משתמש ג'אבר בכל שרת ציבורי.

מד מהירות

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

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

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

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

עלויות:
1. עלויות חומרה ראשונית: להערכתי כ6000-7000 שקלים.
2. עלויות תקשורת, תלוי במספק הספקים שיבדקו ובחבילה שתבדק. אם נניח בדיקה של החבילה הסטנדרטית במהירות 1.5 מגהביט על גבי תשתית ADSL, מדובר בסדר גודל של לא יותר מ150 שקל לחודש לכל ספק אינטרנט (כולל התשתית). אם נבדוק את שלושת ספקיות האינטרנט הגדולות נגיע לכ450 שקל בחודש עבור תקשורת לצרכי בדיקה.
אפשר להוזיל על ידי שימוש באותו חיבור ADSL לכל הספקים, אבל אז לא יהיה אפשר לבצע בדיקות תקשורת בין הספקים עצמם.
בנוסף, יהיה צורך באירוח של השרת (לא משנה אצל איזה ספק, כי הבדיקה תתבצע דרך הADSL ולא דרך הקו המהיר), להערכתי מדובר בעוד כ500-400 שקל בחודש. אפשר להוזיל את העלות הזו משמעותית על ידי שימוש בשרת Shared hosting שיכול לשבת אפילו בחו"ל ושיקבל נתונים מהשרת הבודק שישב בארץ).

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

JWebcam נולד מחדש

לפני יותר משלוש שנים פתחתי פרוייקט בשם JWebcam בסורס-פורג'.
הפרוייקט היה הנסיון הראשון שלי לכתוב פרוייקט קוד פתוח, והיה מערכת שרת/לקוח להזרמת וידאו ממצלמת רשת.
התחלתי לפתח אותו אחרי שלא הייתי מרוצה מהאלטרנטיבות שהיו בזמנו.
הפרייקט היה נחמד, וכלל פונקציות נחמדות כמו זיהוי תנועה, הזרמת וידאו על גבי HTTP ויכולת לתמוך בכמה מצלמות שמשדרות לאותו שרת.
וברגע שעברתי לעבודה על לינוקס הפסקתי סופית את הפיתוח שלו, כי לא היה לי מספיק זמן לברר מה השינויים שאני צריך לעשות כדי לשאוב נתונים מהמצלמה תחת לינוקס.
לפני כשבוע פנה אלי schwarzer_peter שרצה להחיות את הפרוייקט; הוא התחיל לפתח משהו דומה וכשהוא ניסה לרשום אותו בסורס-פורג' – כנראה תחת אותו שם, הוא גילה שתפסתי את השם.
אחרי קצת אימייל-פונג החלטנו שהוא יקבל הרשאות מנהל ומנדט לעשות ככל העולה על רוחו, ושאני אייעץ ואעזור לו להתממשק אל הקוד שכבר כתבתי.
הוא פתח בלוג וורדפרס חביב לפרוייקט, ונראה שהוא עובד די במרץ.
כיף לראות שאחרי שלוש שנים מישהו מוצא שימוש לקוד שכתבתי ושהפרוייקט מתעורר.

כביש רחב, גשר צר

עידן מאנקדוטות כותב שאולי הגיע הזמן לתמחר אחרת את הגישה לרשת, בטענה שרוב פס הוא משאב מוגבל, ושלא יתכן שכמות קטנה של משתמשים שמנצלים את רוחב הפס שלהם ב100% יפגעו בכל שאר המשתמשים.
זה נשמע הגיוני, אבל למעשה רוחב פס הוא לא משאב מוגבל.
רוב פס אפשר לייצר, יש מאין.
זה לא מים או קרקע שלא משנה מה תעשה, הכמות שלהם סופית.
הטכנולוגיה של העברת נתונים במהירות גבוהה מתקדמת כל הזמן. חיפוש זריז העלה את זה.
ברגע שרוב הפס של המייל האחרון קפץ מ33.6 קילוביט ל1500 קילוביט (או הרבה יותר), אין ברירה אלה לשדרג את שאר התשתית בהתאם.
מאז ומעולם ספקי שירות האינטרנט עובדים על שיטת הoverbooking, מתוך הנחה מוצדקת – שרוב המשתמשים לא ישתמשו בכל רוחב הפס כל הזמן.
יש איזה שהוא מקדם, נקרא לו U, שלפיו אפשר להעריך מה תהיה צריכת רוחב הפס של משתמשים שמנויים לסך הכל של Y ג'יגה בייטים לשניה.
(זה לא כל כך פשוט, כי משתמשים שמנויים על החבילות המהירות נוטים לנצל את רוחב הפס בצורה יותר מלאה, וכמובן שיש שעות יותר עמוסות מאחרות).
הפריחה של שיתוף הקבצים משנה את התמונה, ואותו U משתנה איתה.
חברות אינטרנט שמתמהמהות בקניית עוד רוחב פס כך שיעמדו בU הנוכחי גורמות לפגיעה בכל המשתמשים שלהן.
אבל האשמים בפגיעה באיכות השירות הם לא אותם משתמשים "אגרסיביים" שבסך הכל משתמשים במשאב עליו הם שילמו, אלא ספקי שירות האינטרנט שלא דאגו למספיק רוחב פס שיוכל לשרת את המשתמשים שלהם ברמות הצריכה הנוכחיות.

סרטון IPhone חדש

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

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

אנקדוטה:
חלונות ניסתה למנוע ממני לקחת את התצלומסך, לא הצליח לה.

iphone1.png

כתבות חדשות, עיתונאים מיושנים

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

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

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

עכשיו לכיף האמיתי, רשימת המטלות שדבורק מקצה לליבות המובטלות:

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

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

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

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