משהו אחר: חבילות אפליקציות של Haiku?

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

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

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

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

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

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

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

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

איך זה עובד

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הדו"ח שלי על הבעיות של סביבות שולחן העבודה של לינוקס בשנת 2018

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

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

הייקו עושה הכל פשוט להפליא

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

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

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

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

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

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

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

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

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

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

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

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

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

הערת מפתח:

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

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

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

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

בואו נסתכל מנקודת מבטו של מפתח יישומים:

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

דף הורדת יישומים רגיל. מה עלי לפרסם כאן עבור הייקו?

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

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

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

מה אתה חושב?

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

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

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

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

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

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

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

לדברי מר. waddlesplash:

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

זה בטוח!

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

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

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

אדון. waddlesplash כותב:

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

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

ציטוט מאת מר. waddlesplash:

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

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

מסקנה

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

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

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

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

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

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

האם זה הגיוני להעביר את מערכת hpkg ללינוקס?

• כן

• לא

• כבר מיושם, אכתוב בתגובות

20 משתמשים הצביעו. 5 משתמשים נמנעו.

מקור: www.habr.com