היום השישי שלי עם הייקו: מתחת למכסה המנוע של המשאבים, האייקונים והחבילות

TL; DR: Haiku היא מערכת הפעלה שתוכננה במיוחד עבור מחשבים אישיים, ולכן יש לה כמה טריקים שהופכים את סביבת שולחן העבודה שלה להרבה יותר טובה מאחרות. אבל איך זה עובד?

לאחרונה גיליתי את הייקו, מערכת טובה באופן בלתי צפוי. אני עדיין נדהם עד כמה זה פועל בצורה חלקה, במיוחד בהשוואה לסביבות שולחן העבודה של לינוקס. היום אני אסתכל מתחת למכסה המנוע. במידת הצורך להבנה מעמיקה, אעשה השוואות עם סביבות שולחן העבודה המקוריות של Macintosh, Mac OS X ו-Linux (תקן XDG מ-freedesktop.org).

משאבים בקבצי ELF

אתמול למדתי ש-IconOMatic יכולה לשמור אייקונים במשאבי rdef בקובצי הפעלה של ELF. היום אני רוצה לראות איך זה באמת עובד.

אֶמְצָעִי? לצטט מ ברוס הורן, המחבר המקורי של Macintosh Finder וה"אבא" של Macintosh Resource Manager:

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

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

ב-Mac זה משמש ערוך מחדש, תוכנית גרפית לעריכת משאבים פתאום.

ResEdit במקינטוש המקורי

כתוצאה מכך, ניתן היה לערוך אייקונים, פריטי תפריט, תרגומים וכו'. קל מספיק, אבל הם עדיין "נוסעים" עם האפליקציות.
בכל מקרה, לגישה הזו היה חסרון גדול: היא עבדה רק על מערכות קבצים של אפל, וזו הייתה אחת הסיבות לכך שאפל נטשה את "קטע המשאבים" בעת המעבר ל-Mac OS X.
ב-Mac OS X, אפל רצתה פתרון עצמאי של מערכת קבצים, אז הם אימצו את הרעיון של חבילות (מ-NeXT), ספריות שמנהל הקבצים מתייחס אליהן כאל "אובייקטים אטומים", כמו קבצים ולא ספריות. כל חבילה עם אפליקציה בפורמט .app יש, בין היתר, קובץ Info.plist (באיזושהי המקבילה של אפל ל-JSON או YAML) המכילה מטא נתונים של אפליקציות.

מקשים לקובץ Info.plist מחבילת היישום של Mac OS X.

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

Mathematica.app ב-NeXTSTEP 1.0 בשנת 1989: מופיע כספריית קבצים בטרמינל, אך כאובייקט בודד במנהל הקבצים הגרפי.

בואו נחזור ל-BeOS, המושגים שעליהם מבוסס Haiku. המפתחים שלה, בעת המעבר מ-PEF (PowerPC) ל-ELF (x86) (זהה לשימוש ב-Linux), החליטו להוסיף קטע משאבים לסוף קבצי ה-ELF. הוא לא השתמש בסעיף ה-ELF המתאים לו, הוא פשוט צורף לסוף קובץ ה-ELF. כתוצאה מהתוכנית strip ואחרים מ-binutils, שלא מודעים לכך, פשוט ניתקו אותו. לכן, בעת הוספת משאבים לקובץ ELF ב-BeOS, עדיף לא לתפעל אותו עם כלי לינוקס.

מה קורה עם הייקו עכשיו? בעיקרון, פחות או יותר אותו דבר.

בתיאוריה, ניתן יהיה למקם משאבים בחלק הרצוי של ה-ELF. לפי המפתחים בערוץ #haiku ב-irc.freenode.net:

עם ELF הסעיף יהיה הגיוני יותר... הסיבה היחידה שאנחנו לא עושים את זה ככה היא כי זה מה שעשינו ב-BeOS."
ואין טעם לשנות את זה עכשיו.

ניהול משאבים

משאבים נכתבים בפורמט "משאב" מובנה: בעצם רשימה של משאבים עם גדלים ולאחר מכן התוכן שלהם. נזכרתי פורמט ar.
כיצד לבדוק משאבים בהייקו? יש משהו כמו ResEdit?
על פי תיעוד:

כדי להציג את המשאבים הניתנים בחבילת היישום, אתה יכול לגרור את קובץ ההפעלה לתוכנית כמו משאבים. אתה יכול גם ללכת למסוף ולהפעיל את הפקודה listres имя_файла.

Resourcer זמין ב- HaikuDepot, אבל הוא פשוט קורס עבורי.

כיצד לנהל משאבים בקבצי ELF? באמצעות rsrc и rdef. rdef קבצים נאספים ב rsrc. קוֹבֶץ rdef מאוחסן בפורמט טקסט רגיל, כך שהרבה יותר קל לעבוד איתו. פורמט קובץ rsrc מצורף לסוף קובץ ה-ELF. בואו ננסה לשחק:

~> rc -h
Haiku Resource Compiler 1.1To compile an rdef script into a resource file:
    rc [options] [-o <file>] <file>...To convert a resource file back into an rdef script:
    rc [options] [-o <file>] -d <file>...Options:
    -d --decompile       create an rdef script from a resource file
       --auto-names      construct resource names from ID symbols
    -h --help            show this message
    -I --include <dir>   add <dir> to the list of include paths
    -m --merge           do not erase existing contents of output file
    -o --output          specify output file name, default is out.xxx
    -q --quiet           do not display any error messages
    -V --version         show software version and license

אתה יכול להשתמש בתוכנית xres לבדיקה ובקרה:

/> xres
Usage: xres ( -h | --help )
       xres -l <file> ...
       xres <command> ...The first form prints this help text and exits.The second form lists the resources of all given files.The third form manipulates the resources of one or more files according to
the given commands.
(...)

בסדר, בוא ננסה?

/> xres -l /Haiku/system/apps/WebPositive/Haiku/system/apps/WebPositive resources:type           ID        size  name
------ ----------- -----------  --------------------
'MIMS'           1          36  BEOS:APP_SIG
'APPF'           1           4  BEOS:APP_FLAGS
'MSGG'           1         421  BEOS:FILE_TYPES
'VICN'         101        7025  BEOS:ICON
'VICN'         201          91  kActionBack
'VICN'         202          91  kActionForward
'VICN'         203         300  kActionForward2
'VICN'         204         101  kActionStop
'VICN'         206         243  kActionGoStart
'MSGG'         205        1342  kActionGo
'APPV'           1         680  BEOS:APP_VERSION

עוד על משאבים ופורמט rdef אתה יכול לקרוא כאן.

סוגי משאבים סטנדרטיים

למרות שאתה יכול להכניס כל דבר למשאבים, ישנם כמה סוגים סטנדרטיים מוגדרים:

• app_signature: סוג יישום MIME, למיפוי פתיחת קבצים, השקה, IPC וכו'.
• app_name_catalog_entry: מכיוון ששם האפליקציה הוא בדרך כלל באנגלית, ניתן לציין את המקומות שבהם נמצאים השמות המתורגמים, כך שמשתמשים בשפות שונות יראו את שם האפליקציה המתורגמת אם תרצו.
• app_version: בדיוק מה שחשבת
• app_flags: מציין registrar כיצד לטפל בבקשה. אני חושב שיש בזה יותר ממה שנראה לעין. למשל, יש B_SINGLE_LAUNCH, מה שמאלץ את המערכת להשיק תהליך יישום חדש בכל פעם שהמשתמש מבקש זאת (אותו עיקרון משמש לרוב האפליקציות בלינוקס). לאכול B_MULTIPLE_LAUNCH, מה שגורם לתהליך לפעול כל קובץ. סוף סוף יש B_EXCLUSIVE_LAUNCH, מה שמאלץ את המערכת להפעיל רק תהליך אחד בכל פעם, לא משנה באיזו תדירות משתמשים מפעילים אותו (לדוגמה, כך פיירפוקס פועל על לינוקס; ניתן להשיג אותה תוצאה ביישומי Qt באמצעות הפונקציה QtSingleApplication). יישומים עם B_EXCLUSIVE_LAUNCH מקבלים הודעה כאשר המשתמש מנסה להפעיל אותם שוב: למשל, הם מקבלים את הנתיב של הקובץ שהמשתמש רוצה לפתוח בעזרתו.
• vector_icon: סמל יישום וקטור (ב-BeOS לא היו אייקונים וקטורים, לרוב היישומים היו שני אייקוני רסטר בקבצי ההפעלה שלהם).

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

אייקונים וקטוריים בסגנון הייקו

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

me@host:~$ ls /usr/share/icons/hicolor/
128x128  256x256  512x512           index.theme
160x160  28x28    64x64             scalable
16x16    32x32    72x72             symbolic
192x192  36x36    8x8
22x22    42x42    96x96
24x24    48x48    icon-theme.cache

כשמסתכלים על זה כבר אפשר להרגיש באיזו יצירה מדובר.

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

me@host:~$ find /usr/share/icons/ -name 'firefox.*'
/usr/share/icons/HighContrast/16x16/apps/firefox.png
/usr/share/icons/HighContrast/22x22/apps/firefox.png
/usr/share/icons/HighContrast/24x24/apps/firefox.png
/usr/share/icons/HighContrast/256x256/apps/firefox.png
/usr/share/icons/HighContrast/32x32/apps/firefox.png
/usr/share/icons/HighContrast/48x48/apps/firefox.png
/usr/share/icons/elementary-xfce/apps/128/firefox.png
/usr/share/icons/elementary-xfce/apps/16/firefox.png
/usr/share/icons/elementary-xfce/apps/22/firefox.png
/usr/share/icons/elementary-xfce/apps/24/firefox.png
/usr/share/icons/elementary-xfce/apps/32/firefox.png
/usr/share/icons/elementary-xfce/apps/48/firefox.png
/usr/share/icons/elementary-xfce/apps/64/firefox.png
/usr/share/icons/elementary-xfce/apps/96/firefox.png
/usr/share/icons/hicolor/128x128/apps/firefox.png

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

סמלים שונים של Firefox בגרסאות שונות. כרגע אי אפשר לטפל בזה בלינוקס בלי קביים שונים.

Mac OS X מטפל בזה קצת יותר בעדינות:

Mac:~ me$ find /Applications/Firefox.app | grep icns
/Applications/Firefox.app/Contents/MacOS/crashreporter.app
/Contents/Resources/crashreporter.icns
/Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns
/Applications/Firefox.app/Contents/Resources/document.icns
/Applications/Firefox.app/Contents/Resources/firefox.icns

ניתן לראות שיש קובץ אחד firefox.icns בחבילה Firefox.app, המכיל את כל הגדלים כך שלגרסאות שונות של אותה אפליקציה יש אייקונים שונים.
הרבה יותר טוב! אייקונים נוסעים עם האפליקציה, כל המשאבים נמצאים בקובץ אחד.

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

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

והם עדיין מותאמים:

גדלי אייקונים ב-HVIF בהשוואה לפורמטים אחרים.

ההבדל הוא בסדר גודל!

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

רמות שונות של פירוט (LOD) בהתאם לגודל הרינדור

עכשיו לגבי החסרונות: אתה לא יכול לקחת SVG, לזרוק אותו לתוך ImageMagick ולקרוא לזה יום; אתה צריך לעבור מספר מחזורים כדי ליצור אייקון בפורמט HVIF. כאן הסברים. עם זאת, IconOMatic יכול לייבא SVG בצורה לא מושלמת; כ-90% מפרטי SVG מיובאים בהסתברות מסוימת, את ה-10% הנותרים יהיה צורך להגדיר ולשנות באופן ידני. קרא עוד על איך HVIF עושה את הקסם שלו אחד יכול בבלוג לאה גנסון

הוספת אייקון לאפליקציה

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

/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt Creator  -o /Haiku/home/QtQuickApp/QtQuickApp  -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt Creator

בוא נבדוק שהסמל הועתק:

/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type           ID        size  name
------ ----------- -----------  --------------------
'VICN'         101      152238  BEOS:ICON

נראה טוב, אבל למה זה שכאשר הסמל החדש מועתק הוא לא מופיע?

ה-VICN:101:BEOS:ICONs המועתקים עדיין לא משמש כסמל יישום במנהל הקבצים

מה פספסתי?

הערת מפתח:

אנחנו צריכים ליצור קובץ rdef עם כל המשאבים, ולאחר מכן בצע את הפקודה rc имя.rdef, פעולה זו תיצור את הקובץ .rsrc. אז אתה צריך להפעיל את הפקודה resattr -o имя_бинарника имя.rsrc. לכל הפחות, אני משתמש בפקודות כאלה כדי להוסיף סמלים לסקריפטים שלי.

ובכן, רציתי ליצור משאב, לא תכונה. אני מאוד מבולבל.

אחסון חכם במטמון באמצעות מערכת הקבצים

פתיחה וקריאה של תכונות ELF היא איטית. כפי שכתבתי למעלה, האייקון נכתב כמשאב בקובץ עצמו. שיטה זו אמינה יותר ומאפשרת לך לשרוד העתקה למערכת קבצים אחרת. עם זאת, הוא מועתק גם לתכונת מערכת הקבצים, למשל BEOS:ICON. זה עובד רק במערכות קבצים מסוימות, כמו BFS. הסמלים שמוצגים על ידי המערכת (ב-Tracker ו-Deskbar) נקראים מהתכונה המורחבת הזו, מכיוון שהפתרון הזה עובד במהירות. במקומות מסוימים (בהם המהירות אינה חשובה, למשל, חלון "אודות" טיפוסי), המערכת מקבלת את הסמל ישירות מהמשאב בקובץ. אבל זה לא הסוף. זכור, ב-Mac, משתמשים יכולים להחליף אייקונים של יישומים, ספריות, מסמכים בעצמם, מכיוון שב-Mac אפשר לעשות את הדברים ה"חשובים" האלה, למשל החלפת סמל Slack חדש בקודם. ב-Haiku, עליך לחשוב על המשאב (בקובץ) כסמל המקורי שמגיע עם האפליקציה, ועל התכונה (במערכת הקבצים BFS) כעל משהו שמאפשר למשתמש לבצע שינויים כרצונו (אם כי, רמז, ה-GUI להוספת סמל מותאם אישית על גבי הסמל הוא אופציונלי). עדיין לא מיושם כברירת מחדל).

בדיקת תכונות מערכת הקבצים

עם resaddr אפשר לבדוק ולהגדיר תכונות של מערכת הקבצים.

/> resattr
Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ]

Reads resources from zero or more input files and adds them as attributes
to the specified output file, or (in reverse mode) reads attributes from
zero or more input files and adds them as resources to the specified output
file. If not existent the output file is created as an empty file.
(...)

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

הקסם של חבילות hpkg

נכון לעכשיו (לרוב) נעשה שימוש בחבילות להשגת תוכניות ב- Haiku .hpkg. אל תתפתו מהשם הפשוט: פורמט ה-.hpkg עובד אחרת לגמרי מפורמטים אחרים עם שמות דומים שנתקלתם בהם, יש לו כוחות על של ממש.

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

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

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

KERN: package_daemon [16042853:   924] active package: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023:   924] active package: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232:   924] active package: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405:   924] active package: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611:   924] active package: "llvm_libs-5.0.0-3-x86_64.hpkg"

מגניב, כן? תחזיק מעמד, זה יהיה אפילו יותר מגניב!

יש חבילה מאוד מיוחדת:

KERN: package_daemon [16040020:   924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"

הוא מכיל מערכת הפעלה מינימליסטית מאוד, כולל הקרנל. תאמינו או לא, אפילו הקרנל עצמו לא מוסר מנפח האתחול (מחיצת שורש), אלא נטען בקפידה למקומו מהחבילה .hpkg. וואו! כבר ציינתי שלדעתי חלק מהתחכום והעקביות הכוללים של Haiku נובע מהעובדה שהמערכת כולה, מהקרנל ומרחב המשתמש הליבה ועד לניהול חבילות ותשתית זמן ריצה, מפותחת בשיתוף פעולה על ידי צוות אחד. תארו לעצמכם כמה קבוצות וצוותים שונים יידרש כדי להריץ משהו כזה בלינוקס [אני מדמיין את פרויקט PuppyLinux - בערך. מְתוּרגְמָן]. אז תארו לעצמכם כמה זמן ייקח עד שהגישה הזו תאומץ בהפצות. אומרים: קחו בעיה פשוטה, חלקו אותה בין מבצעים שונים, והיא תסתבך עד כדי כך שכבר אי אפשר יהיה לפתור אותה. הייקו במקרה הזה פקח את עיניי. אני חושב שזה בדיוק מה שקורה בלינוקס עכשיו (לינוקס במקרה זה הוא מונח קיבוצי ל-Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).

החזרת מערכת באמצעות hpkg

באיזו תדירות מתרחש המצב הבא: העדכון הצליח, ואז מתברר שמשהו לא עובד כמו שצריך? אם אתה משתמש במנהלי חבילות קונבנציונליים, קשה להחזיר את מצב המערכת לנקודת זמן לפני התקנת חבילות חדשות (לדוגמה, במקרה שמשהו השתבש). מערכות מסוימות מציעות דרכים לעקיפת הבעיה בצורה של תמונות מצב של מערכת הקבצים, אך הן די מסורבלות ואינן נמצאות בשימוש בכל המערכות. הייקו פותר את זה באמצעות חבילות .hpkg. בכל פעם שחבילות משתנות במערכת, החבילות הישנות אינן נמחקות, אלא מאוחסנות במערכת בספריות משנה כמו /Haiku/system/packages/administrative/state-<...>/ תָמִיד. פעולות שלא הסתיימו מאחסנות את הנתונים שלהן בספריות משנה /Haiku/system/packages/administrative/transaction-<...>/.

תוֹכֶן /Haiku/system/packages/administrative. ספריות "מצב..." מכילות קבצי טקסט עם שמות של חבילות פעילות, וספריות "טרנסקשן..." מכילות את החבילות עצמן.

"מצב פעיל ישן", כלומר. רשימה .hpkg חבילות פעילות לפני שינויים מתועדות לאחר כל פעולה במנהל הקבצים בקובץ טקסט /Haiku/system/packages/administrative/state-<...>/activated-packages. באופן דומה, "מצב פעיל" חדש נכתב בקובץ טקסט /Haiku/system/packages/administrative/activated-packages.

מדריך /Haiku/system/packages/administrative/state-<...>/ מכיל רק קובץ טקסט עם רשימה של חבילות פעילות של מצב זה (במקרה של התקנה של חבילות ללא הסרה), ואם חבילות הוסרו או עודכנו - ספריית המצב מכילה גרסאות ישנות של חבילות.

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

הורדת הייקו. כל נקודת כניסה מציגה "מצב פעיל" תואם

אני אוהב את הגישה של קבצי טקסט פשוטים בתור רשימת "מצב פעיל", עם שמות שקל להבין .hpkg. זה עומד בניגוד מוחלט להיות בנוי למכונות-לא-לאנשים. צְרוֹר מ-OSTree או Flatpak במערכת הקבצים (באותה רמה כמו Microsoft GUID).

רשימת חבילות פעילות עבור כל נקודת זמן

נתוני תצורה

כנראה, בקטלוג /Haiku/system/packages/administrative/writable-files מכיל קובצי תצורה עבור חבילות, אך הם ניתנים לכתיבה. אחרי הכל, כזכור, .hpkg מותקן לקריאה בלבד. אז יש להעתיק את הקבצים האלה מהחבילות לפני הכתיבה. יש את המשמעות.

שילוב GUI עבור מערכת hpkg

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

התרחישים הבאים עולים בראש:

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

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

בדיקת תכולת החבילה

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

על הייקו אני לוחץ לחיצה ימנית על החבילה, ואז לוחץ על "תוכן" כדי לראות מה יש בפנים. אבל הנה רק רשימה של קבצים ללא יכולת לפתוח אותם על ידי לחיצה כפולה.
זה יהיה הרבה יותר טוב אם הייתה דרך להרכיב את החבילה (זמנית). .hpkg לצפייה דרך מנהל קבצים, והמשתמש לא יצטרך לדאוג לגבי פרטי היישום. (אגב, אתה יכול לפתוח .hpkg חבילה פנימה Expander, שיכול לפרוק אותו כמו כל ארכיון אחר).

הממשק של HaikuDepot מאפשר להציג רשימה של קבצי חבילה, אך אין דרך להציג את התוכן על ידי, למשל, לחיצה כפולה על README.md

ה-Mac מנצח בקטגוריה זו, אבל הוספת הפונקציונליות של HaikuDepot שאתה רוצה לא אמורה להיות קשה מדי.

התקנת חבילה באמצעות GUI

ב-Mac, רוב תמונות הדיסק .dmg מכילים חבילות .app. לחץ פעמיים על תמונת הדיסק ולאחר מכן העתק את החבילה, למשל, על ידי גרירתה לתוך /Applications ב-Finder. זה מובן מאליו מבחינתי, אבל שמעתי שייתכן שחלק מהמתחילים לא יוכלו להתמודד עם זה. כברירת מחדל, אפל "מציעה" ספרייה כלל מערכת /Applications (ב-NeXT זה היה מחובר לרשת וגם בודד), אבל אתה יכול בקלות לשים את האפליקציות שלך בשרת קבצים או בספריית משנה $HOME/Applications, אם אתה אוהב את זה ככה.

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

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

דרך נוספת היא להשתמש במנהל קבצים, פשוט גרור ושחרר .hpkg חבילה או בתוך /Haiku/system/packages (עבור התקנה כלל מערכת, כברירת מחדל), או ב /Haiku/home/config/packages (להתקנה בודדת; לא זמין בלחיצה כפולה - אני עדיין מתעצבנת מהמילה "config" במקום הזה, שבשבילי במקרה זה היא שם נרדף ל"הגדרות"). והקונספט של ריבוי משתמשים עדיין לא זמין אפילו עבור Haiku (כנראה בגלל זה זה כל כך פשוט – אני לא יודע, אולי יכולות ריבוי משתמשים יסבכו שלא לצורך בסביבת שולחן עבודה שולחנית).

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

הסרת חבילה מה-GUI

ב-Mac, עליך לגרור את סמל היישום לפח האשפה, וזה הכל. בְּקַלוּת!

על הייקו, ראשית, אתה צריך למצוא היכן החבילה ממוקמת במערכת, כי לעתים רחוקות אתה מתקין אותה במקום הנכון (המערכת עושה הכל). בדרך כלל אתה צריך להסתכל פנימה /Haiku/system/packages (עם התקנת ברירת מחדל כלל המערכת), או ב /Haiku/home/config/packages (הזכרתי ש"config" הוא כינוי שגוי?). ואז האפליקציה פשוט נגררת לפח האשפה, וזהו.
בְּקַלוּת! עם זאת, לא הייתי אומר את זה. הנה מה שבאמת קורה:

זה מה שקורה אם תגרור אפליקציה לפח האשפה /Haiku/system/packages

רק ניסיתי להעביר את האפליקציה שלי מאתמול "Hello World" ב-QtQuickApp לפח. לא ניסיתי להעביר את ספריית המערכת, ומכיוון שכל החבילות מותקנות בספריית המערכת, אי אפשר להסיר את החבילה .hpkg ללא שינוי "התוכן שלו". משתמש רגיל יפחד וילחץ על כפתור "ביטול" שהוקצה כברירת מחדל.

מסביר אדון. waddlesplash:

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

אוקיי, אולי עלי לעשות זאת באמצעות HaikuDepot? אני לוחץ פעמיים על החבילה ב /Haiku/system/packages, ממתין להופעת כפתור "הסר התקנה". לא, יש (רק) "התקן". "הסר התקנה", איפה אתה?

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

זה קורה אם אתה מנסה להתקין חבילה שכבר מותקנת.

הבא מופיע:

אם תלחץ על "החל שינויים" בחלון הקודם, זה ייראה כך

אני מניח שזו שגיאת תוכנה; הקישור לאפליקציה כבר שם. [הכותב לא סיפק קישור - בערך. מְתוּרגְמָן]

פתרון מהיר: הוסף כפתור "הסר התקנה" אם החבילה כבר נמצאת /Haiku/system/packages, או ב /Haiku/home/config/packages.

כשאני צופה ברשימת החבילות המותקנות ב- HaikuDepot, אני רואה את החבילה שלי ברשימה ויכול להסיר אותה.

המק מנצח בקטגוריה זו. אבל אני יכול לדמיין שעם הגדרה נכונה, חווית המשתמש ב-Haiku תהיה טובה יותר מאשר ב-Mac. (אחד המפתחים דירג את זה כך: "פחות משעה להוסיף את הפונקציונליות שצוינה ל- HaikuDepot, אם אתה יודע קצת C++", יש מתנדבים?)

הסרת משהו מחבילה

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

ב-Mac, המשתמש למעשה עובד בדרך כלל עם הקובץ .dmgמאיפה מגיעה חבילת האפליקציה .app. בדרך כלל תמונות .dmg מצטברים בספריית ההורדות, והחבילות מועתקות על ידי המשתמש אל /Applications. הוא האמין שמשתמשים רבים עצמם אינם יודעים מה הם עושים, השערה זו מאושרת על ידי עובד לשעבר של אפל. (אחד הדברים שאני לא אוהב ב-Mac. ולמשל, עם AppImage אין הבדל בין האפליקציה לחבילה שבה היא הייתה. גרור את הסמל לפח = זהו. קל!)

על הייקו, יש גם חלוקה בין apps/ и packages/, אז אני בספק אם זה עשה את זה ברור יותר למשתמשים. אבל מה קורה אם תגרור אפליקציה מ apps/ הוסף לעגלה:

זה מה שקורה כשאתה מנסה להסיר יישום שנלקח מקובץ .hpkg

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

פתרון מהיר: מציע להשתמש ב-GUI כדי למחוק במקום זאת .hpkg

סתם בשביל הכיף, ניסיתי לשכפל את האפליקציה על ידי לחיצה על Alt+D. קיבלתי את ההודעה "לא ניתן להזיז או להעתיק אובייקטים באמצעי אחסון לקריאה בלבד." והכל בגלל /system (חוץ מזה /system/packages и /system/settings) היא נקודת ההרכבה של packagefs (זכור כיצד היא מופיעה בפלט df?). למרבה הצער, הפלט של הפקודה mount אינו מבהיר את המצב (כפי שנאמר באחד המאמרים הקודמים), mountvolume לא מראה את מה שאתה מחפש (כנראה חבילות מותקנות באמצעות לולאה .hpkg לא נחשבים ל"כרכים"), ושכחתי גם את הפקודות החלופיות.

אף אחד לא זכה בקטגוריה זו מלבד AppImage (אבל זו, למען האמת, דעה מוטה). עם זאת, אפשר לדמיין שאחרי הכוונון, חווית המשתמש ב-Haiku תהיה טובה יותר מאשר ב-Mac.

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

העתקת תוכן חבילה למערכת אחרת

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

על הייקו, אני גורר את היישום, אבל התלות לא מעובדות בכלל.

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

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

הורד חבילה עם כל התלות שלה

לא כל מכונה מחוברת לרשת כל הזמן. להיפך, יש מכונות (כן, אני מסתכל עליך, חלונות, מק ולינוקס מודרניים) שוכחים מזה. חשוב לי שאוכל ללכת, למשל, לבית קפה אינטרנט, להוריד תוכנה לכונן נשלף, להכניס את הכונן הזה למחשב הביתי שלי ולהיות בטוח שהכל יעבוד [בחור מסוכן, עושה את זה בווינדוס... - משוער. מְתוּרגְמָן].

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

ב-Mac זה בדרך כלל קובץ אחד, כל מה שאתה צריך לעשות הוא להוריד .dmg. לרוב, אין לו תלות מלבד אלו ש-MacOS עצמה מספקת כברירת מחדל. חריג הוא יישומים מורכבים הדורשים סביבת ביצוע מתאימה, למשל java.

על הייקו הורדת חבילה .hpkg שכן, נניח, אותו יישום ב-java, עשוי שלא להספיק, מכיוון ש-java יכול להיות או לא קיים במחשב היעד. האם יש דרך להוריד את כל התלות לחבילה נתונה .hpkg, מלבד אלו שמותקנות כברירת מחדל בהייקו ולכן צריכים להיות בכל מערכת הייקו?

המק מנצח בקטגוריה זו בהפרש קטן.

הערות מר. waddlesplash:

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

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

העברת חבילות למקום נפרד

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

ב-Mac אני רק מעביר חבילות .app לכונן נשלף או ספריית רשת ב-Finder, וזהו. אני עדיין יכול ללחוץ פעמיים כדי לפתוח את היישום כפי שהייתי עושה בדרך כלל מאמצעי האחסון האתחול. רַק!

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

המק מנצח בקטגוריה זו.

לדברי מר. waddlesplash:

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

נדבר על זה במאמר הבא.

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

דוח סופי על שילוב מערכת hpkg עם ה-GUI

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

עוד משהו: Kernel Debug Land

זה יהיה נהדר להיות מסוגל להזין פקודות במהלך פאניקת ליבה, למשל syslog | grep usb. ובכן, בהייקו זה אפשרי בזכות Kernel Debug Land. איך אתה יכול לראות את הקסם הזה בפעולה אם הכל עובד כמו שצריך מבלי להיכנס לפאניקת גרעין? קל על ידי לחיצה על Alt+PrintScn+D (Debug Mnemonic). אני מיד נזכר מפתח מתכנת, מה שאפשר למפתחי המקינטוש המקוריים להיכנס ל-debugger (אם הותקן, כמובן).

מסקנה

אני מתחיל להבין שהתחכום של מערכת הייקו נובע מכך שהעבודה מתבצעת על ידי צוות אחד קטן עם התמקדות ברורה בסביבת העבודה, כאשר כל שכבות המערכת נגישות.
ניגוד חד לעולם של Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, שבו הכל מפורק לחתיכות קטנות עד כדי כך שההפשטה יושבת על הפשטה ומניעה עם קביים.
הייתה גם הבנה של איך המערכת .hpkg משלב את השיטות המומלצות של מנהלי החבילות המסורתיים, Snappy, Flatpak, AppImage, אפילו btrfs, ומשלב אותם עם גישת ה"פשוט עובד" של ה-Mac.

זה היה כאילו משהו "התחלף" לי בראש, והבנתי איך המערכת .hpkg יודעת להתגלגל, רק מלהסתכל עליה. אבל זה לא אני, אלא היופי והפשטות של המערכת. הרבה מזה הוא בהשראת הרוח של ה-Mac המקורי.

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

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

בעיות אקראיות

אולי יש כבר בקשות, או שצריך לפתוח אותן?

• BeScreenCapture אמור להיות מסוגל לייצא ל-GIF כמו Peek. ניתן לעשות זאת באמצעות ffmpeg, שכבר זמין עבור Haiku. יישום.
• תוכנת צילום מסך לא מצליחה ללכוד חלון מודאלי, במקום זאת לוכדת את כל המסך
• לא ניתן לחתוך צילומי מסך באמצעות כלי החיתוך של WonderBrush ולאחר מכן לשמור את התוצאה בקובץ
• אני לא אוהב במיוחד את סמן היד בהייקו, אבל אני חושב שזה קשור לתחושה הנוסטלגית החמה. זה מעצבן במיוחד בעת שימוש בכלי החיתוך ב-Krita, מכיוון שהוא גורם לחיתוך לא מדויק (ראה צילומי מסך של דיאלוגים מודאליים במאמר זה). סמן כוונת יהיה נפלא. יישום.

נסה זאת בעצמך! אחרי הכל, פרויקט Haiku מספק תמונות לאתחול מ-DVD או USB, שנוצרו יומי. כדי להתקין, פשוט הורד את התמונה וכתוב אותה לכונן הבזק באמצעות חָרָט

יש לך שאלות? אנו מזמינים אותך לדוברי רוסית ערוץ מברק.

סקירת שגיאות: איך לירות לעצמך ברגל ב-C ו-C++. אוסף מתכונים של Haiku OS

מן המחבר תרגום: זהו המאמר השישי בסדרה על הייקו.

רשימת מאמרים: Первая ב Третья רביעית החמישי

מקור: www.habr.com