על חרדת הנטישה של מיקרוסופט: הכירו את WSL 2

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

‍
מיקרוסופט בשנים האחרונות ביצעה כמה שינויים על מנת לכלול תאימות למערכות אחרות. כך לדוגמא, ה-command prompt הישן קיבל מתיחת פנים, הן ב-Power Shell ומאוחר יותר גם בתאימות להצגת טרמינלים מרחוק (בחיבור SSH או Telnet). זה לא היה מושלם, אבל זה היה צעד חשוב - במיוחד כשמיקרוסופט החלו לשלב גם SSH Client בתוך Windows 10 לגרסאותיו השונות.

‍
בכנס Build האחרון, מיקרוסופט הציגה את ה-Windows Terminal שלה: שיפור משמעותי לעומת ה-CMD הישן והקונסולה של PowerShell. הפעם יש טאבים, תמיכה ב-Emoji, קוסטומיזציה ועוד. בקצרה, זה נראה כך:

‍

‍

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

‍
ועכשיו לנושא המאמר: WSL 2

‍
למי שאינו מכיר, WSL (ראשי תיבות Windows Subsystem for Linux) זו מערכת שמיקרוסופט פיתחה שמשתלבת עם ה-NT Kernel (כן, Windows 10 מבוסס על NT, כמו רוב גרסאות ה-Windows בשנות ה-2000). המערכת הזו משמשת כ"מתרגם" מה-API של ה-Linux Kernel (גרסה 4.4 של ה-Linux Kernel) ל-NT API. בנוסף, המערכת גם דאגה להרשאות מיוחדות של קבצים ותיקיות, כך שלא היה צורך ליצור Partition של לינוקס מצד אחד, ומצד שני קבצים בינאריים של לינוקס לא יכלו לרוץ על Windows שלא מותקנת בה WSL. כל הקונסטרוקציה הזו נועדה לתת מספר דברים:

‍
• לאפשר לבנות הפצות לינוקס ידועות שירוצו ישירות עם ה-WSL, ללא צורך במערכת לינוקס ב-VM
• לאפשר להריץ אפליקציות לינוקס בהתאם להעדפות שלכם
• אין צורך בלשלב קוד GPL כמו ה-Kernel לתוך המערכת

‍
הדבר הזה עבד לא רע, אלא אם הייתם רוצים להתחיל להשתמש בזה ברצינות עם המערכת, כמו לקמפל קוד, להתקין NPM וכל דבר שהיה קשור לקבצים – שם ה-WSL היה גרוע. כמה גרוע? אם נניח פעולה של פתיחת קובץ דחוס הייתה לוקחת דקה במערכת לינוקס טבעית, עם WSL זה היה תהליך איטי מאוד (אתם מוזמנים להסתכל במבחני השוואה כאן), כך שכל מי שרצה להשתמש ברצינות ב-WSL היה יורד מזה מהר מאוד לאחר שהיה חווה את הביצועים האיטיים. מי שחשב להשתמש בקונטיינרים עם WSL או עם דרייברים של לינוקס, היה מגיע למסקנה המרה ש-WSL לא יכול להריץ דברים כאלו. מצד שני – זה היה אחלה דבר בשביל להריץ דברים מרחוק כמו Ansible, התחברות למערכות מרוחקות עם מפתחות וכו'.

‍
מיקרוסופט היו בהחלט מודעים לעניין, והם הבינו שהטריקים של המרה ל-NT-API לא ממש יעזרו. דרוש פתרון אחר, ועדיף אחד "טבעי".

‍
התוצאה: WSL 2

‍
השינוי המהותי עם WSL 2 היה שהפעם, יש מעין "מיני VM" קטן שעושה Boot ומטעין גרסה מאוד מקוצרת של ה-Kernel, אך ללא 1,001 הדרייברים שמגיעים עם ה-Linux Kernel וכל הדרייברים הנחוצים שלינוקס צריך – הוא מקבל אותם דרך דרייברים Paravirtualized (קצת מזכיר את ה-VMWare Tools שמתקינים). כך, מצד אחד ה-Kernel רץ בצורה מבודדת כ-VM קטנטן, ומצד שני מיקרוסופט לא צריכה להסתבך עם ה-GPL: הם ישחררו את שינויי הקוד שהם צריכים לשחרר, ואין נגיעה ישירה לקוד של Windows.

‍

בשיטה הזו, ה-WSL 2 מקבל מספר דברים:

‍
• אפשרות להשתמש בגרסת Kernel מודרנית (אני מאמין שמיקרוסופט תוציא מסמך איך לקמפל קרנלים משלכם לשימוש ב-WSL 2)
• אפשר להשתמש בדברים כמו cgroups ולהריץ קונטיינרים (docker, cri-o וכו')
• כל גישת ה-File/Directory תעבור דרך דרייבר שמיקרוסופט תשחרר ש"ידבר" עם NTFS, ומיקרוסופט טוענים כי בדיקות שלהם מראות כי הביצועים משתפרים פי 20 בהשוואה ל-WSL 1
• יותר אפליקציות יוכלו לרוץ

‍
עדיין קיימות מספר שאלות מהותיות: האם נוכל להשתמש בציודי USB? מה לגבי שימוש בלינוקס וכרטיסים פיזיים במערכת (כמו שימוש ב-CUDA מתוך ה-WSL 2), שימוש בדסקטופ גרפי (Wayland) ועוד – אבל אני מניח שבחודשים הקרובים נקבל על כך תשובות.

‍
לסיכום

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

‍

‍

מאת: חץ בן חמו, יועץ ומומחה בנושאי ענן, וירטואליזציה, לינוקס, אחסון ועוד

‍

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