🥇עוד משהו: חבילות אפליקציות הייקו?

TL; DRהאם Haiku יכול לקבל תמיכה מתאימה עבור חבילות יישומים, כגון ספריות יישומים (כגון .app ב-Mac) ו/או תמונות יישומים (Linux AppImage)? אני חושב שזו תהיה תוספת ראויה, וכזו שתהיה קלה יותר ליישום נכון מאשר במערכות אחרות, מכיוון שרוב התשתית כבר קיימת.

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

למען הסר ספק, אני היוצר והמחבר של AppImage, פורמט להפצת יישומים. Linux, שמטרתו להפוך את ה-Mac לפשוט יותר ומעבירה שליטה מלאה לידי מפתחי האפליקציות ומשתמשי הקצה (ראה עוד בהמשך). ויקי и תיעוד).

מה אם ניצור AppImage עבור הייקו?

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

במחשב Macintosh System 1, כל יישום היה קובץ נפרד, "מנוהל" ב-Finder. באמצעות AppImage, אני מנסה לשחזר את אותה חוויית משתמש ב- Linux.

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

במשך יותר מ-10 שנות קיומה, AppImage צברה תאוצה ופופולריות מסוימת: לינוס טורוואלדס עצמו תמך בה בפומבי, ופרויקטים פופולריים (למשל, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) אימצו אותה כשיטה העיקרית להפצת גרסאות רציפות או ליליות שאינן מפריעות ליישומים המותקנים או הוסרו על ידי משתמשים. עם זאת, סביבות שולחן עבודה והפצות... Linux לרוב עדיין נצמדים למודל ההפצה המסורתי והמרכזי המבוסס על מתחזקים ו/או מקדמים את העסק התאגידי שלהם ו/או תוכניות הנדסה המבוססות על פלאטפק (רד-האט, פדורה, גנום) ו נמרץ (קנוני, Ubuntuזה מתקרב. באופן מגוחך.

איך הכל עובד

כל AppImage מכיל 2 חלקים: קובץ ELF קטן שניתן להריץ (מה שנקרא runtime.c), ואחריו תמונה של מערכת הקבצים סקוושFS.

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

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

נראה שהכל פשוט.

והדברים האלה מסבכים את העניינים עוד יותר:

עם מגוון כה גדול של תפוצות Linux שום דבר, בדעתו הישרה, לא יכול להיקרא עוד "חלק מההתקנה המוגדרת כברירת מחדל עבור כל מערכת יעד חדשה". אנו עוקפים את הבעיה הזו על ידי בניית רשימת אי הכללות, מה שמאפשר לנו לקבוע מה יארוז לתוך AppImage ומה יצטרך להגיע ממקור אחר. עם זאת, לפעמים אנו מפספסים את המטרה, למרות שבדרך כלל הכל עובד כשורה. מסיבה זו, אנו ממליצים ליוצרי חבילות לבדוק את AppImages בכל מערכות היעד (הפצות).
יישומים כמטענים חייבים להיות ניתנים להזזה על פני מערכת הקבצים. למרבה הצער, ליישומים רבים יש נתיבים מוחלטים מקודדים קשיחים, למשל, למשאבים ב /usr/shareצריך לתקן את זה איכשהו. חוץ מזה, צריך לייצא את זה LD_LIBRARY_PATH, או נכון rpath כך שהמטעין יוכל למצוא את הספריות המקושרות. לשיטה הראשונה יש חסרונות (שניתנים להתגבר עליהם באמצעות שיטות מורכבות), והשנייה פשוט מסורבלת.
מלכודת ה-UX הגדולה ביותר עבור משתמשים היא שאתם חייבים הגדר את הסיבית הניתנת להפעלה קובץ AppImage לאחר ההורדה. תאמינו או לא, זהו מכשול אמיתי עבור חלק מהמשתמשים. הגדרת קובץ ההפעלה מסורבלת אפילו עבור משתמשים מנוסים. כפתרון עוקף, הצענו להתקין שירות קטן שמנטר קבצי AppImage ומגדיר את קובץ ההפעלה שלהם. בצורתו הטהורה, זה לא הפתרון הטוב ביותר, מכיוון שהוא לא יעבוד מיד עם ההורדה. הפצות Linux הם לא מספקים את השירות הזה, כך שהמשתמשים חווים חוויה רעה מיד עם השימוש.
חברים Linux הם מצפים שלאפליקציה חדשה יהיה סמל במפעיל. אי אפשר פשוט לומר למערכת, "תראה, יש אפליקציה חדשה, בואו נתחיל." במקום זאת, לפי מפרט XDG, צריך להעתיק את הקובץ. .desktop למקום הנכון ב /usr עבור התקנה כלל-מערכתית, או ב $HOME עבור אדם פרטי. סמלים בגדלים מסוימים, בהתאם למפרט XDG, צריכים להיות ממוקמים במקומות מסוימים ב usr או $HOME, ולאחר מכן להריץ פקודות בסביבת העבודה כדי לעדכן את מטמון הסמלים, או לקוות שמנהל סביבת העבודה יבין זאת ויזהה הכל באופן אוטומטי. אותו הדבר חל על סוגי MIME. כפתרון עוקף, מומלץ להשתמש באותו שירות, אשר בנוסף להגדרת דגל ההפעלה, אם סמלים וכו' נמצאים ב-AppImage, יעתיק אותם מה-AppImage למיקומים הנכונים בהתאם ל-XDG. בעת מחיקה או הזזה של סמלים, השירות אמור לנקות הכל. כמובן, לכל סביבת עבודה יש התנהגויות שונות, כולל פורמטים של קבצים גרפיים, גדלים, מיקומי אחסון ושיטות עדכון מטמון, וזה מה שיוצר את הבעיה. בקיצור, שיטה זו היא פתרון עוקף.
אם זה לא מספיק, עדיין אין סמל AppImage במנהל הקבצים. Linux עדיין לא קיבלתי החלטה לגבי יישום elficon (למרות את הדיון и יישום), כך שאי אפשר להטמיע סמל ישירות ביישום. משמעות הדבר היא שליישומים במנהל הקבצים אין סמלים משלהם (בין אם AppImage או משהו אחר), רק בתפריט המשגר. כפתרון עוקף, אנו משתמשים בתמונות ממוזערות - מנגנון שתוכנן במקור כדי לאפשר למנהלי שולחן עבודה להציג תמונות ממוזערות של קבצים גרפיים כסמלים שלהם. כתוצאה מכך, השירות להגדרת סיבית ההפעלה פועל גם כ"מזעור", ויוצר וכותב תמונות ממוזערות של סמלים למיקומים המתאימים. /usr и $HOMEשירות זה גם מנקה קבצי AppImages אם הם נמחקים או מועברים. מכיוון שכל מנהל שולחן עבודה מתנהג מעט אחרת, למשל, באילו פורמטים, גדלים ומיקומים הוא מקבל סמלים, זה יכול להיות די מעצבן.
האפליקציה פשוט קורסת במהלך הביצוע אם מתרחשות שגיאות (לדוגמה, יש ספרייה שאינה חלק ממערכת הבסיס ואינה כלולה ב-AppImage), ואף אחד לא אומר למשתמש בממשק המשתמש הגרפי מה בדיוק קורה. התחלנו לעקוף את זה באמצעות התראות בשולחן העבודה, מה שאומר שעלינו לאתר שגיאות משורת הפקודה, להמיר אותן להודעות קריאות על ידי המשתמש, ולאחר מכן להציג אותן בשולחן העבודה. וכמובן, כל סביבת שולחן עבודה מטפלת בהן בצורה מעט שונה.
כרגע (ספטמבר 2019, - הערת המתרגם) לא מצאתי דרך קלה לומר למערכת שהקובץ 1.png אתה צריך לפתוח את זה עם קריטה, ו 2.png — באמצעות GIMP.

מיקום האחסון עבור מפרטי שולחן עבודה מרובי משתמשים בו ב גנומה, KDE и Xfce הוא freedesktop.org

השגת רמת התחכום השזורה עמוק בסביבת שולחן העבודה של Haiku קשה, אם לא בלתי אפשרית, עקב המפרטים. XDG מאתר freedesktop.org עבור יישומים בין-שולחניים, כמו גם של מנהלי שולחן עבודה המבוססים על מפרטים אלה. סמל יחיד של Firefox בכל המערכת הוא דוגמה: ככל הנראה, מחברי XDG מעולם לא שקלו שמשתמש עשוי להיות מותקן עם מספר גרסאות של אותה אפליקציה.

סמלים עבור גרסאות שונות של פיירפוקס

תהיתי מה העולם Linux אני יכול ללמוד מ-Mac OS X כדי להימנע מפשלות באינטגרציה של המערכת. אם יש לכם זמן ואתם מעורבים בזה, הקפידו לקרוא את מה שאמר ארנו גורדולד, אחד מהמהנדסים הראשונים של Mac OS X:

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

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 מושב 144 - Mac OS X: אריזת יישומים והדפסת מסמכים.

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

האם הייקו בא להציל?

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

הדו"ח שלי על בעיות סביבת העבודה Linux ב- 2018

אפילו לינוס טורוואלדס הודה שפיצול היה הסיבה לכישלון רעיון סביבות שולחן העבודה.

כיף לראות את הייקו!

עם הייקו, הכל הופך לפשוט בצורה מדהימה.

בעוד שגישה נאיבית ל"נייד" של AppImage ל-Haiku תהיה פשוט לנסות לקמפל את הרכיבים שלה (בעיקר runtime.c והשירות) (מה שאולי אפילו אפשרי!), זה לא יביא תועלת רבה ל-Haiku. מכיוון שלמעשה, רוב הבעיות הללו נפתרות ב-Haiku והן מבוססות מבחינה רעיונית. Haiku מספקת בדיוק את אבני הבניין לתשתית המערכת שחיפשתי בסביבות שולחן עבודה במשך כל כך הרבה זמן. Linux ולא יכלו להאמין שהם לא היו שם. כלומר:

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

קבצי ELF שאין להם את סיבית ההפעלה מקבלים אותה אוטומטית בעת לחיצה כפולה במנהל הקבצים.
אפליקציות יכולות לכלול משאבים מובנים, כגון סמלים המופיעים במנהל הקבצים. זה מבטל את הצורך להעתיק חבורה של תמונות לספריות סמלים מיוחדות, מה שאומר שאין צורך לנקות אותן לאחר מחיקה או העברה של האפליקציה.
יש מסד נתונים לקישור יישומים למסמכים, אין צורך להעתיק קבצים לשם כך.
כברירת מחדל, חיפוש ספריות מתבצע בספרייה lib/ שליד קובץ ההפעלה.
אין הפצות מרובות וסביבות שולחן עבודה; מה שעובד, עובד בכל מקום.
אין מודול משגר נפרד השונה מספריית היישומים.
ליישומים אין נתיבים מוחלטים מובנים למשאבים שלהם; ישנן פונקציות מיוחדות לקביעת המיקום במהלך הביצוע.
הרעיון של תמונות מערכת קבצים דחוסות יושם: כל חבילת hpkg. כולן מורכבות על ידי הליבה.
כל קובץ נפתח עם היישום שיצר אותו אלא אם כן תציין אחרת במפורש. איזה מגניב זה!

שני קבצי PNG. שימו לב לסמלים השונים, המציינים שהם ייפתחו ביישומים שונים בעת לחיצה כפולה. שימו לב גם לתפריט הנפתח "פתח באמצעות:", שבו המשתמש יכול לבחור יישום ספציפי. כמה פשוט!

נראה שהרבה מהפריצות והפתרונות לעקיפת הבעיה הדרושים ל-AppImage ב- Linux, הופכים למיותרים בהייקו, שבליבתו פשטות ותחכום שהופכים אותו מתאים לרוב צרכינו.

האם בכלל צריך חבילות אפליקציה?

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

נקודת מבט של משתמש

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

אני רוצה להתקין את האפליקציה מבלי לבקש את סיסמת המנהל (root). בהייקו אין מושג של מנהל, למשתמש יש שליטה מלאה כי זו מערכת אישית! (בעיקרון, אפשר לדמיין את זה במצב מרובה משתתפים, אני מקווה שהמפתחים ישמרו על זה פשוט)
אני רוצה לקבל את הגרסאות העדכניות והטובות ביותר של אפליקציות, לא לחכות שהן יופיעו בהפצה שלי (שמשמעותה בדרך כלל "לעולם לא", לפחות אלא אם כן אני משדרג את כל מערכת ההפעלה). הייקו "פותרת" את זה עם מהדורות מתגלגלות. משמעות הדבר היא שניתן לקבל את הגרסאות העדכניות והטובות ביותר של יישומים, אך לשם כך עליכם לעדכן כל הזמן את שאר המערכת, ולהפוך אותה למעשה ל"מטרה נעה"..
אני רוצה שיהיו לי מספר גרסאות של אותה אפליקציה זו לצד זו, כי אני לא יכול לדעת מה היה שבור בגרסה האחרונה, או, נניח, כמפתח אתרים, אני צריך לבדוק את העבודה שלי בגרסאות דפדפן שונות. הייקו פותר את הבעיה הראשונה, אבל לא את השנייה. ניתן לבטל עדכונים, אבל רק עבור המערכת כולה; אי אפשר (ככל הידוע לי) להריץ, למשל, מספר גרסאות של WebPositive או LibreOffice בו זמנית.

אחד המפתחים כותב:

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

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

הערת מפתח:

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

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

מספר גרסאות של AppImages הפועלות זו לצד זו על גבי אחד Linux

נקודת מבטו של מפתח אפליקציות

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

אני רוצה לשלוט בכל חוויית המשתמש. אני לא רוצה להיות תלוי במערכת ההפעלה שתגיד לי מתי ואיך לשחרר אפליקציות. Haiku מאפשר למפתחים לעבוד עם מאגרי hpkg משלהם, אך משמעות הדבר היא שמשתמשים צריכים להגדיר אותם באופן ידני, מה שהופך את הרעיון ל"פחות אטרקטיבי".
יש לי דף הורדה באתר שלי שבו אני מפיץ .exe עבור Windows, .dmg עבור מק ו .AppImage עבור Linuxאו שאולי אני רוצה להרוויח כסף מהגישה לדף הזה? הכל אפשרי? מה כדאי לי לשים שם בשביל הייקו? קובץ אחד מספיק .hpkg עם תלויות רק ב-HaikuPorts
התוכנה שלי דורשת גרסאות ספציפיות של תוכנות אחרות. לדוגמה, ידוע ש-Krita דורשת גרסה מתוקנת של Qt, או Qt שמכוונן היטב לגרסה ספציפית של Krita, לפחות עד שהתיקונים יוחזרו ל-Qt. ניתן לארוז Qt משלך עבור יישום בחבילה .hpkg, אבל סביר להניח שזה לא יתקבל בברכה.

דף הורדה טיפוסי של אפליקציה. מה צריך להציב כאן בהייקו?

האם הערכות (הקיימות כספריות יישומים כמו AppDir או .app בסגנון אפל) ו/או תמונות (בצורת AppImages שעברו שינוי משמעותי או .dmg האם הוספת אפליקציות (מאפל) היא תוספת מועילה לשולחן העבודה של Haiku? או שזה ידלל את התמונה הכוללת ותוביל לפיצול, ולכן יוסיף מורכבות? אני קרוע: מצד אחד, היופי והתחכום של Haiku נובעים מהעובדה שבדרך כלל יש דרך אחת לעשות משהו, לא רבות. מצד שני, רוב התשתית לקטלוגים ו/או חבילות אפליקציות כבר קיימת, כך שהמערכת זועקת שהאחוזים הנותרים יתאימו.

לדברי היזם אדון. waddlesplash

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

מה אתה חושב?

לפני שאתה עונה…

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

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

הם פשוט לא נתמכים כמו, נניח, תוכנת ה-Macintosh Finder. כמה מגניב היה אם לספריית QtCreator היה שם וסמל של "QtCreator" בפינה השמאלית העליונה, שיפעילו את היישום בלחיצה כפולה?

קצת קודם אני כבר שאל:

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

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

לדברי מר. waddlesplash:

כן, יש לנו תשובה לשאלה הזו: פשוט נתמוך ביישומים אלה כל עוד יידרש, עד שמישהו יוכל לקרוא כראוי את פורמטי הקבצים שלהם או לספק פונקציונליות 1:1. המחויבות שלנו לתמוך ביישומי BeOS R5 ב-Haiku היא עדות ברורה לכך...

זה בטוח!

איזו דרך פעולה צריכה להייקו לנקוט?

אני יכול לדמיין דו-קיום שליו של hpkg, ספריות ותמונות יישומים:

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

מר וואדלספלאש כותב:

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

Haiku מקבל תשתית להרצת תמונות אפליקציה, ליליות, רציפות ובניית ניסוי של תוכנה, כמו גם למקרים בהם המשתמש מעוניין "להקפיא" אותה בזמן, עבור תוכנה פרטית ופנימית, ומקרי שימוש מיוחדים אחרים (כ-20% מכלל). תמונות אלו מכילות את הקבצים הדרושים להרצת האפליקציה. .hpkg, מותקן על ידי המערכת, ולאחר סיום היישום, מותקן. (אולי מנהל הקבצים יוכל למקם את הקבצים .hpkg לתמונות אפליקציה, באופן אוטומטי או לפי דרישת המשתמש - כמו כשגוררים אפליקציה לשיתוף רשת או לכונן חיצוני. זה רק שיר! או ליתר דיוק, שירה - הייקו.) מצד שני, המשתמש עשוי לרצות להתקין את תוכן התמונה כקבצים..hpkg, ולאחר מכן הם יעודכנו ויעובדו בדיוק כאילו הותקנו דרך HaikuDepot... אנחנו צריכים לעשות קצת סיעור מוחות).

ציטוט מאת מר וודלספלאש:

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

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

מסקנה

להייקו יש תשתית המספקת ממשק משתמש פשוט ומתוחכם למחשבים אישיים, והיא הולכת הרבה מעבר למה שמסופק בדרך כלל למחשבים אישיים ב... Linuxמערכת חבילות .hpkg — היא דוגמה כזו, אך גם חלקים אחרים של המערכת חדורים בתחכום. עם זאת, Haiku תרוויח מתמיכה נאותה בקטלוגי יישומים ותמונות. כיצד לעשות זאת בצורה הטובה ביותר כדאי לדון עם אנשים שמכירים את Haiku, את הפילוסופיה והארכיטקטורה שלה הרבה יותר טוב ממני. אחרי הכל, אני משתמש ב-Haiku רק קצת יותר משבוע. אף על פי כן, אני מאמין שנקודת מבט רעננה זו תהיה שימושית למעצבים, למפתחים ולאדריכלים של Haiku. לכל הפחות, אשמח להיות "שותף לניהול" עבורם. יש לי למעלה מ-10 שנות ניסיון מעשי בעבודה עם קטלוגי יישומים וחבילות תמונות עבור Linux, ואני רוצה למצוא להם שימוש בהייקו, ואני מאמין שהם מתאימים בצורה מושלמת. הפתרונות הפוטנציאליים שהצעתי אינם היחידים לבעיות שתיארתי, ואם צוות ההייקו יחליט למצוא פתרונות אחרים, אלגנטיים יותר, אני לגמרי בעד. באופן עקרוני, אני כבר חושב על רעיון איך לבנות את המערכת. hpkg מפתיע עוד יותר, מבלי לשנות את אופן פעולתו. מסתבר שצוות Haiku חשב זמן רב על חבילות יישומים בעת יישום מערכת ניהול החבילות, אך למרבה הצער (אני חושב) הרעיון נדחק לקטגוריה "מיושנת". אולי הגיע הזמן להחיות אותו?

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

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

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

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

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.