למרות הסלידה שלי מהממשק הלא ברור של גימייל (בפעמים האחרונות אני פשוט עובר לממשק הפשוט), זה באמת הפיתרון הטוב ביותר כאשר אתה צריך גישה לדואל מכל מקום, אז עד עכשיו עבדתי בגישה די מטופשת בה אם ידעתי שאני אהיה רחוק לזמן ממושך מהמחשב שלי, הייתי שולח את מה שאני צריך לגימייל, אבל כרגע היתה לי הארה אחרי שתוך 30 דקות הצלחתי להגדיר את כל מה שנדרש בשביל להפעיל google apps על שם מתחם מסוים (בעצם רק שינוי הגדרות DNS) והתרשמתי מזה שממש יש שם יכולת לנהל חשבונות דואל בצורה יותר חכמה מסתם מתן שם נרדף לחשבון גימייל. נראה לי שזה ממש פיתרון מצוין לעסק קטן שצריך מספר קטן של תיבות דואל (הענין חינמי עד 50 משתמשים).
עד כמה קשה להקים אתר עם שם מתחם בעברית? לא הכי קל שבעולם
אני לא יודע אם מה שעברתי משקף, אבל יש לי תחושה שהבעיתיות של שמות מתחם בעברית לא בהכרח הוסברה לאנשים שקנו אותם. אקספלורר 6+ 7 לא באמת תומכים וזה כבר 30% מהשוק, ומהדפדפנים היותר מודרניים שבדקתי (ולא בדקתי את כולם) רק אקספלורר 9 יודע גם לשלוח נכון וגם לפענח ולהציג נכון את הכתובות החוזרות כאשר היתר מציגים מה שיראה לכל אדם סביר כגיבריש.
במקרה שלי, פאנל הניהול בחברה האחראית על השרת שלי ומספקת לו שירותי DNS לא ידע לקבל כתובות בעברית, וגם כאשר הוכנס שם המתחם עם הקידוד המתאים דבר לא עבדו 100% בצורה חלקה. התומך שדיברתי איתו בכלל לא ידע האם המערכת שלהם תומכת בשמות מתחם בינלאומיים, וחשב שלא בצדק שהקידוד שלי לא נכון.
והוורדפרס, בהתקנה הלוקחת לא יותר מ5 דקות, לא יודע שכתובת הגיבריש שממנה הוא מוצא את כתובת האתר דורשת התיחסות מיוחדת ומחליט להציג את כתובת הגיבריש בכל מקום אפשרי….
בארכיטקטורת הרשת הנוכחית שירותים המזרימים תוכן בקצב גבוה גורמים להאטה(!) בקצב הקבלה
מאמר (וההמשכים שלו) מאוד טכני המצריך קצת ידע על פרוטוקול הTCP מציף בעיה חדשה ברשת הנובעת מהעובדה שמחירים של זכרונות הם כל כך נמוכים שאין צורך ממשי לחסוך בשימוש בהם ולכן מוקצים היום באפרים* גדולים יותר מבעבר.
הבעיה עם זה היא שככל שהבאפר גדול, אם קצב ההוצאה ממנו נשאר קבוע, הlatency** של המידע העובר דרך הבאפר נהיה גבוה יותר ופרוטוקולים כמו TCP שיודעים לווסת אוטומטית מקבלים את המידע הנחוץ להם באיחור ולכן התוצאה היא שכולם מנסים לקבל את הכל בקצב הגבוהה ביותר, כמו נהגים הנדחפים בכח לצומת בה הרמזור מקולקל, ורק מחמירים את הפקק.
לדוגמא אם מוגדר באפר בגודל מגה ביט בחיבור שלכם ואתם מורידים מאתר הורדות (חוקי כמובן) קובץ בגודל מגה, כאשר קצב ההורדה שלכם הוא מגה בשניה, כלומר הבאפר שלכם מתמלה כמעט מיידית בגלל שהקצב ברשת הגלובלית גבוה יותר, ואז אתם מנסים לגלוש לאתר עם הדפדפן שלכם. במצב הזה יקח לדפדפן שניה לפני שיוכל להתחיל לתאם את הקצב עם רוחב הפס הפנוי בפועל, וכנ"ל לתוכנה בה אתם משתמשים להורדה. התוצאה היא שהאינרטנט מרגיש איטי, למרות שאין כל סיבה טכנית אמיתית לכך.
ניסוי שערך הכותב מעלה על נס דוקא את מערכת ההפעלה חלונות כמערכת ההפעלה שמתמודדת בצורה הטובה ביותר עם הבעיה כאשר לינוקס היא הגרועה ביותר "מהקופסה" למרות שניתן לקנפג אותה כך שתהיה טיפה טובה יותר מהמק.
כמובן שהבעיה יותר חמורה מאחר שכל ציוד ברשת עשוי ליצור אותה, ובעוד שלפחות באופן תיאורתי יש לנו שליטה על מערכת ההפעלה במחשב שלנו, הרי שעל ציודים כמו נתבים אלחוטיים ומודמים שמספקים ספקי התשתית אין לנו בדרך כלל שליטה (וכמובן שאותה הבעיה עשויה לקרות גם בציודים של ספקי התשתית והISP עצמם).
*באפר (buffer) הוא זיכרון העוזר לתאם בין שני צדדים הניגשים למידע (אחד מעלה והאחר מוריד) בקצבים שונים. המטרה של הבאפר היא שלמוריד תמיד יהיה משהו זמין להורדה כאשר הוא מבקש ובכך לגרום שהמידע יועבר בערך בקצב אחיד (ענין חשוב לשיחות ווידאו)
**latency הוא הזמן שעובר בין שליחת בקשה למידע וקבלת התשובה. כאשר הlatency גבוה בשיחת "טלפון" נדמה כאילו שהצד השני כל הזמן צריך לחשוב קצת לפני שהוא עונה לנו.