Systemd 260: TPM2, ארגז חול ויכולות חדשות בלינוקס

מדריך חומרה » מדריכי קנייה » Systemd 260: TPM2, ארגז חול ויכולות חדשות בלינוקס

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

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

פרידה סופית ממערכת V ותלות מוחלטת בכוננים מקוריים

אחד השינויים הבולטים ביותר ב-systemd 260 הוא ההסרה המוחלטת של התמיכה בסקריפטים של System V. תהליך האתחול הקלאסי המבוסס על /etc/init.d הוצא בהדרגה במשך שנים, אך כעת הוא נעלם למעשה מקוד systemd.

משמעות הדבר היא שהרכיבים האחראים לגישור בין סקריפטי SysV ליחידות מקוריות הוסרו: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator, ו-systemd-sysv-install אינם קיימים עוד. כתוצאה מכך, כל שירות שעדיין תלוי במנגנונים מדור קודם אלה פשוט לא יופעל במערכות המאמצות systemd 260.

במהלך תהליך הניקוי, מספר אפשרויות בנייה של Meson סומנו גם כמיושנות או הוסרו. הדגלים -Drc-local=, -Dsysvinit-path= ו- -Dsysvrcnd-path= הועברו לארכיון, בעוד שאחרים כמו -Dintegration-tests= ו- -Dcryptolib= הוסרו לחלוטין. זה שולח מסר ברור: כעת הכל חייב להיות מטופל על ידי יחידות מקוריות ותשתית systemd המודרנית.

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

דרישות ליבה גבוהות יותר ומיקוד בסביבות הנוכחיות

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

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

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

TPM2, שלמות אתחול ותמיכה מתקדמת ב-SRK

אחד התחומים שבהם systemd מתפתח הכי הרבה הוא האינטגרציה שלו עם TPM2 (Trusted Platform Module 2.0) . שבב זה, שנפוץ יותר ויותר בלוחות אם מודרניים של UEFI ובחומרה בינונית-מתקדמת, מאפשר עיגון סודות למצב המערכת, מדידת שלבי אתחול ופתיחה אוטומטית של אמצעי אחסון מוצפנים כאשר הסביבה היא כצפוי.

Systemd 260 משפר עוד יותר את האינטגרציה הזו על ידי הוספת כלים ושירותים המכסים שלבים שונים של תהליך האתחול. רכיב מפתח הוא systemd-tpm2-setup , האחראי על הכנת התשתית סביב מפתח שורש האחסון (SRK) של ה-TPM . מפתח שורש זה משמש כבסיס קריפטוגרפי לאבטחת התקשורת עם השבב ולאחסון מאובטח של סודות אחרים.

במהלך האתחול, מבחינים בין שני שלבים: שלבים מוקדמים מאוד במערכת initrd ושלב אחד במערכת השורש. בראשון, שירות בשם "Early TPM SRK Setup" בודק אם ל-TPM כבר יש SRK מאוחסן, ואם הוא אינו קיים, יוצר אותו והופך אותו לזמין באופן זמני תחת /run/systemd/tpm2-srk-public-key.* . מאוחר יותר, לאחר שמערכת הקבצים האמיתית תורכב, השירות יאגד את ה-SRK ויאמת שהמפתח המאוחסן ב- /var/lib/systemd/tpm2-srk- public-key.pem תואם לזה שב-TPM.

בתרחישים שתצורתם מוגדרת היטב, יוצגו רשומות יומן כגון "SRK כבר מאוחסן ב-TPM" והודעות המציינות שטביעת הרגל של SRK תואמת למצופה. עם זאת, אם הסביבה אינה מוגדרת כראוי (לדוגמה, בהגדרות המשתמשות ב-Yocto או בלוחות כמו Raspberry Pi עם TPM מבוסס SPI ושיטות אתחול מותאמות אישית כגון U-Boot ואתחול מדוד), עלולים להיווצר מצבים שבהם systemd לא מצליח ליצור קבצים אלה תחת /var/lib/systemd, מה שמעלה ספקות לגבי תצורת ה-SRK כהלכה.

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

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

האינטגרציה עם תשתית מדידת האתחול מתחזקת עוד יותר על ידי יחידות ספציפיות כמו systemd-pcrextend , אשר רושמות אירועים כגון "enter-initrd", "leave-initrd", "sysinit" ו-"ready" ב-PCRs שונים (למשל, PCR 11). רצף הרחבות זה מאפשר ל-TPM לצבור רשומה מאומתת קריפטוגרפית של זרימת האתחול, אשר לאחר מכן ניתן להשתמש בה עבור מדיניות אתחול מהימנה או עבור UKI (Unified Kernel Images) כדי לאמת את מצב המכונה לפני שחרור מפתחות.

אמצעי אבטחה ואחסון שירותים עם systemd

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

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

במקום לערוך את היחידה המקורית - אשר תאבד בעדכוני חבילה עתידיים - מומלץ ליצור לעקוף en /etc/systemd/system/mi-servicio.service.d/ עם קובץ, למשל, sandbox.confלאחר שינויו, פשוט טען מחדש את התצורה עם מערכת ולהפעיל מחדש את השירות כך שההגבלות החדשות ייכנסו לתוקף.

ברמת מערכת הקבצים, אחת האפשרויות החשובות ביותר היא מערכת הגנה=ערכים כגון strict, full o true הם מרכיבים חלקים שונים של העץ במצב קריאה בלבד. הנוהג הרגיל, כאשר הדבר אפשרי, הוא להשתמש מערכת הגנה=קפדניתזה הופך את /usr, /boot, /efi ו- /etc לקריאה בלבד עבור השירות. אם יישום צריך לכתוב לתיקיות ספציפיות, הוא רשאי לעשות זאת באמצעות נתיבי קריאה וכתיבה =/נתיב באחדות.

כדי לשפר עוד יותר את הפרטיות, מומלץ גם להגביל את הגישה לתיקיות משתמשים באמצעות `ProtectHome=true` , אשר מונע מהשירות לקרוא `/home`, `/root` או `/run/user`. בנוסף, `PrivateTmp=true` יוצר רווחים מבודדים של `/tmp` ו-`/var/tmp`, ומונע חשיפה צולבת של קבצים זמניים בין תהליכים.

במכשירים, `PrivateDevices=true` מסתיר את עץ `/dev` בפועל ומחליף אותו בקבוצה מינימלית של פסאודו-מכשירים בטוחים (null, zero, recognition וכו'). אם כונן זקוק להתקן ספציפי (לדוגמה, יציאה טורית או בלוק דיסק), ניתן להעניק לו אישור באמצעות `DeviceAllow=/dev/xxx rw` או במצב קריאה בלבד.

הרשת היא גם וקטור מפתח. עם רשת פרטית=אמת נוצר מרחב שמות רשת מבודד, ומשאיר רק את הלולאה החוזרת; השירות לא יראה ממשקים פיזיים ולא יוכל לתקשר עם העולם החיצון. לחלופין, ניתן להגביל את משפחות הכתובות בהן הוא יכול להשתמש על ידי משפחות כתובת מוגבלות =מאפשר רק AF_INET ו-AF_INET6 עבור IPv4/IPv6, AF_UNIX עבור שקעים מקומיים או אפילו none ליפניזציה מלאה של יכולות הרשת.

בנוגע להרשאות, הפקודה `NoNewPrivileges=true` היא אחת החזקות ביותר: היא מונעת מהתהליך לרכוש הרשאות חדשות באמצעות קבצים בינאריים של setuid או שינויי יכולות. בקיצור, גם אם השירות מבצע קוד פגיע, הוא לא אמור להיות מסוגל לעבור ל-root באמצעות מנגנונים מסורתיים. בשילוב עם `CapabilityBoundingSet=` , המגדיר את הרשימה המדויקת של היכולות המותרות (לדוגמה, רק `CAP_NET_BIND_SERVICE` יאזין בפורטים נמוכים), משטח התקיפה ממוזער.

כדי ללכת רחוק יותר, systemd מאפשר סינון קריאות מערכת עם מסנן קריאות מערכת=במקום לתחזק רשימה ידנית של syscalls, נעשה שימוש בקבוצות מוגדרות מראש, כגון @system-service, @network-io, @basic-io או להכחיש קבוצות כמו ~@privileged. עם systemd-ניתוח syscall-filter ניתן לבדוק אילו קריאות ספציפיות שייכות לכל קבוצה. זה מאפשר בנייה של פרופיל ביצוע מוגבל מאוד, בדומה למה שיציע ארגז חול ייעודי.

הגדרות רלוונטיות נוספות כוללות `ProtectKernelTunables=true` , החוסם שינוי של פרמטרי ליבה ב-`/proc/sys` וב-`/sys`; `ProtectKernelModules=true` , המונע טעינה או פריקה של מודולים; `ProtectKernelLogs=true` , המונע קריאת יומני ליבה; ו -`ProtectControlGroups=true` , החוסם כתיבות להיררכיה של cgroups. כל זה עובד בצורה חלקה עם יכולות בידוד משתמשים חדשות כגון ` PrivateUsers=full` , אשר בגרסה 260 עודכן כדי למפות את מלוא טווח מזהי המשתמש, ובכך מבטל את הדרכים הקודמות לעקיפת הבעיה שנדרשו עבור סביבות systemd מקוננות.

PrivateUsers, xaccess, ובקרות גישה חדשות למכשירים

מנגנון PrivateUsers , שנועד לאפשר לשירותים לפעול במרחב מזהה משתמש מבודד, מאוחד ב-systemd 260. האפשרות PrivateUsers=full ממפה כעת את מלוא טווח המזהים, ומפשטת את הדברים במכולות ובמערכות עם מופעי systemd מקוננים המבוססים על גרסאות ישנות יותר (לפני 257). שיפור זה ביטל פריצות ששימשו בעבר לזיהוי מופעים ישנים יותר אלה.

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

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

mstack, systemd-mstack וכלי קונטיינר חדשים

בתחום קונטיינריזציה, systemd 260 מציג את הפונקציונליות אסטאק ופקודה קשורה, systemd-mstackהרעיון מאחורי mstack הוא לאפשר הגדרה של OverlayFS מבוסס על מבנה של ספרייה מיוחדת בשם .mstack/, אשר פועל לפי מפרט ספציפי לארגון השכבות שלו.

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

רשת: אינטגרציה עם ModemManager ואפשרויות ביצועים חדשות

בשכבת הרשת, systemd-networkd ממשיך לצבור חשיבות. אחת התכונות החדשות הבולטות היא האינטגרציה שלו עם ModemManager דרך פרוטוקול "simple connect" , המאפשר ניהול מודמים וחיבורים ניידים ישירות מ-networkd מבלי להסתמך על כלים חיצוניים.

כדי לתמוך בזרימה זו, נוסף סעיף חדש. לקבצי התצורה, עם פרמטרים כגון APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=זה מקל על פריסות ב אזורים או סביבות כפריות עם קישוריות המבוססת על רשתות סלולריות, נוכח מאוד באזורים מסוימים באירופה שבהם לא תמיד יש סיבים או קווי טלפון קוויים איכותיים.

מבחינת ביצועים, קבצי ה- . link של systemd-networkd כוללים אפשרויות חדשות ספציפיות עבור התקני Ethernet. אלו כוללות את ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList ו-GenericReceiveOffloadUDPForwarding . אפשרויות אלו מאפשרות כוונון עדין של העברת העבודה לחומרה ולמנהלי התקנים, דבר חיוני עבור רשתות ארגוניות, מרכזי נתונים וספקי שירותים שצריכים למזער כל אלפית שנייה של השהייה.

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

ניידות שירות, מכונות וירטואליות זמניות ושירותים לא מורשיים

רכיב systemd-portabled , האחראי על ניהול שירותים "ניידים" ארוזים בתמונות, מקבל יכולת מעניינת מאוד: כעת הוא יכול לפעול כשירות ברמת המשתמש . משמעות הדבר היא שמשתמשים ללא הרשאות, בסשן הרגיל שלהם, יכולים להפעיל ולנהל שירותים ניידים בתוך המרחב שלהם מבלי להזדקק ל-sudo או הרשאות מוגברות.

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

מצד שני, systemd-vmspawn - הכלי שנועד להפעיל מכונות וירטואליות באופן משולב עם systemd - מרחיב את יכולותיו להירשם עם systemd-machined בתוך סשן המשתמש . הוא גם מציג אפשרות `-ephemeral` ליצירת מכונות ארעיות שנהרסות עם סיום השימוש בהן. זוהי התאמה מושלמת עבור צינורות CI/CD, כיתות וירטואליות או פלטפורמות חינוך אירופאיות הדורשות יצירה והשמדה מהירות ומבוקרות של מכונות וירטואליות.

שליטה מכוונת במעבד, זיכרון ותזמון עם SCHED_EXT ו-THP

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

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

פקודות חדשות ב-systemctl והרחבת השימוש ב-Varlink

פקודת systemctl המוכרת מקבלת פקודת חדשה: enqueue-marked . פעולה זו מפעילה באופן פנימי את מתודת D-Bus EnqueueMarkedJobs() ומאפשרת עבודה עם תורים של משימות ושירותים מסומנים מראש. למרות שזה אולי נראה כמו פרט שולי, עבור צוותי תפעול המנהלים חוות שרתים בקנה מידה גדול, זהו כלי נוסף לשיפור זרימות עבודה של פריסה ואוטומציה.

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

שדות זיהוי מערכת וחוויית משתמש

תכונה חדשה ומסקרנת אך שימושית עבור חלק מההפצות היא הצגת השדה שם_מפואר= בארכיון /etc/os-releaseשדה זה דומה ל-PRETTY_NAME, אך מאפשר רצפי ANSI ותווי יוניקוד מורכבים יותרהודות לכך, ניתן להציג הפצות ומהדורות ספציפיות עם שמות מושכים או ייחודיים יותר.

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

תיעוד ספציפי עבור סוכני בינה מלאכותית וזרימת עבודה של סקירה בסיוע

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

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

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

בנוסף, כלול קובץ תצורה. claude-review.ymlשם מוגדר כיצד יש לסקור את תהליך ניתוח בקשות השינוי (pull requests), בעזרת קוד קלוד. בהקשר זה, נדרשים תרומות שהשתמשו בבינה מלאכותית לשלב תוויות גילוי נאות כמו Co-developed-by בתיקונים, ומשאירים ראיות לכך שכלי אוטומטי השתתף ביצירת הקוד.

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