מיקרוסופט תנתק את צינור החמצן של XP ב 8 לאפריל 2014

21 ביוני 2012

6 תגובות

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

XP

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

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

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

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

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

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

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

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

6 תגובות

  1. אופק22 ביוני 2012 ב 23:27

    VisualStudio2010 מפורסם כנתמך עד 2015. אז מפורסם. בפועל, עשרות באגים מדווחים (+10 על ידי אישית) מתוקנים רק ב2012RC או 2012RTM. עדכוני אבטחה כנראה שיוציאו, אם יעלו, אבל תמיכה מלאה – על הנייר בלבד.

    ל, WINDOWS, OFFICE או מוצרים אחרים אני לא מדווח על באגים ישירות, אבל ממה שאני קורא אני מתרשם שהחוויה דומה.

    הגב
  2. GadiM23 ביוני 2012 ב 10:03

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

    הגב
  3. אופק23 ביוני 2012 ב 13:48

    הי מאיר

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

    הסרת BREAKPOINTS עם F9 אינה עובדת בתנאים מסוימים:

    connect.microsoft.com/…/commenting-a-c-code-section-with-breakpoints-can-make-them-un-deletable-with-f9

    שגיאה רצינית בקבצי הTARGETS של MSBUILD, שבמוצהר לא תתוקן בVC2010:

    connect.microsoft.com/…/c-static-lib-references-are-sometimes-not-transitive

    (זה מרגיז במיוחד, כי (א) מפריע מאד בעבודה יומיומית, (ב) סומן כFIXED כי בRC2012 זה הסתדר…)

    הגב
  4. אופק23 ביוני 2012 ב 13:51

    הנה דוגמאות ישנות יותר:

    connect.microsoft.com/…/-targetdir-computes-wrong-for-outdir-starting-with

    connect.microsoft.com/…/internal-cps-error-when-re-adding-project-reference

    יש עוד הרבה, שלי ושל אחרים.

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

    הגב
  5. GadiM23 ביוני 2012 ב 16:22

    הי אופק,
    קודם כל השם הוא גדי. מאיר, זה שם המשפחה, והוא שמור למפגשים עם שגרירים וכיוצא בזה. כן, אני יודע שזה מבלבל, אבל זה לא אני אלא ההורים שלי.
    לנושא הבגים שלא מטופלים. אני לא חושב שהתפקיד שלי זה להגן על מיקרוסופט, זה הג'ב שלהם, ואני לא חושב לרגע לקחת אותו מהם. אבל אני כן חושב, שצריך להיות הוגנים, ולצעוק עליהם על מה שמגיע להם, ולא על מה שלא מגיע להם.
    מיקרוסופט לא שונה בטיפול שלה בבאגים, מאף גוף תכנה אחר. ולמעשה, מתוך הכרות עם הרבה גופי תכנה אחרים, אני יכול להעיד, שהיחס שלה לנושא הבגים הוא הרבה יותר רציני. וזו הסיבה שלא מגיע להם, לדעתי, היחס שאתה נותן להם.
    כל Issue שמדווח ב Connect, נכנס ישר לרשימת הבגים של מערכת ניהול הבגים של המוצר. ולא רק זאת, חובה להתיחס אליהם (Address) ולעשות להם Triage תוך 2 ימי עבודה.
    אבל מצד שני, מנהל הפרויקט יכול להחליט, בזמן שהוא קובע חלוקת עבודה וסדרי עדיפויות, שהוא מעדיף לטפל בבאגים שנראים לו יותר רלונטיים וחשובים, לפני שהוא מטפל בבאג שלך. בעיקר אם הוא מתרשם, ששהבעיה נקודתית ולעומתה יש צעקות חזקות על באגים אחרים. מנהל הפרויקט גם יכול להחליט, וזה חוקי לחלוטין, שהוא יטפל בזה בגירסא הבאה.
    כמו לכל גוף תכנה, גם למיקרוסופט יש כמות מוגבלת של מפתחים בכל פרויקט, ויש לה את רוחב הפס שלה, שאותו מנהל הפרויקט אמור לנצל ביעילות, כנגד הדרישות והאילוצים.
    כך שמה שיש לנו כאן, זה חילוקי דעות בינך לבין מנהל הפרויקט, לגבי העדיפות וסדר הקדימויות של הבאג שלך יחסית לבאגים אחרים.
    זה רחוק מאד מהגישה שאתה מתאר, כאילו אין טעם לדווח להם באגים כי ממילא לא מתייחסים אליהם, ואתה עושה את זה רק למען הקהילה.
    חשוב שאתה, וכל האחרים שמדווחים על תקלות באתר Connect, ימשיכו לדווח על באגים. זה נכול לכל מוצרי מיקרוסופט שאופציית המשוב באתר Connect פתוחה להם.זה אחד מצנורות המשוב היעילים ביותר שאני מכיר, וזה גם עובד.
    אם הבאג שלך, נראה לך מספיק חשוב, ואתה רוצה שהוא יטופל בעדיפות. תכתוב עליו בבלוג שלך, צרף את הקישור לדיווח שלך ב Connect. ובקש מכל מי שחושב כמוך, שיצביע עליו כחשוב. זה יגרום לכך שהבאג שלך יעלה בסולם העדיפויות של מנהל הפרויקט. כי זה יהפוך אותו מבעיה פרטית של מפתח אחד, לבעיה כלל מערכתית.
    ואני לא מדבר על זה באופן תיאורטי, זה גם עובד בפועל. חפש בבלוגוספירה את הסיפור של ה Edit and Continue ב #C.

    הגב
  6. אופק24 ביוני 2012 ב 13:07

    הי גדי (אלף סליחות על ה'מאיר'!  לקח לעצמי: לא לכתוב תגובות עם עיניים נעצמות מעייפות)

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

    במאמר מוסגר, הייתי שמח אם הם היו פותחים את מאגר הבאגים *הפנימי* שלהם לציבור, ולא מכריחים את המשתמשים לגלות אותם שוב ושוב מחדש. בזאת הם בהחלט נבדלים לרעה מהרבה חברות תוכנה אחרות.  הנה הצעה שלי אליהם בעניין – visualstudio.uservoice.com/…/2665441-publish-internally-known-non-security-bugs

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

    הגב