شيء آخر: حزم تطبيقات Haiku؟

TL؛ DR: هل يمكن لشركة Haiku الحصول على الدعم المناسب لحزم التطبيقات، مثل أدلة التطبيقات (مثل .app على نظام Mac) و/أو صور التطبيق (Linux AppImage)؟ أعتقد أن هذه ستكون إضافة جديرة بالاهتمام وأسهل في التنفيذ بشكل صحيح من الأنظمة الأخرى نظرًا لأن معظم البنية التحتية موجودة بالفعل.

منذ أسبوع لقد اكتشفت هايكو، وهو نظام جيد بشكل غير متوقع. حسنًا، بما أنني كنت مهتمًا منذ فترة طويلة بالأدلة وصور التطبيقات (مستوحاة من بساطة نظام التشغيل Macintosh)، فليس من المستغرب أن تتبادر إلى ذهني فكرة...

للحصول على فهم كامل، أنا منشئ ومؤلف AppImage، وهو تنسيق لتوزيع تطبيقات Linux يهدف إلى بساطة نظام Mac ويمنح التحكم الكامل لمؤلفي التطبيقات والمستخدمين النهائيين (إذا كنت تريد معرفة المزيد، راجع: ويكي и الوثائق).

ماذا لو قمنا بإنشاء AppImage لـ Haiku؟

دعونا نفكر قليلاً، من الناحية النظرية البحتة: ما الذي يجب القيام به من أجل الحصول عليه AppImage، أو شيء من هذا القبيل، على هايكو؟ ليس من الضروري إنشاء شيء ما الآن، لأن النظام الموجود بالفعل في هايكو يعمل بشكل مذهل، لكن التجربة الخيالية ستكون لطيفة. كما يوضح أيضًا مدى تعقيد Haiku، مقارنةً ببيئات سطح المكتب Linux، حيث تكون مثل هذه الأشياء صعبة للغاية (يحق لي أن أقول ذلك: لقد كنت أعاني من تصحيح الأخطاء لمدة 10 سنوات).

في نظام Macintosh System 1، كان كل تطبيق عبارة عن ملف منفصل "مُدار" في Finder. باستخدام AppImage أحاول إعادة إنشاء تجربة المستخدم نفسها على Linux.

أولاً، ما هو AppImage؟ هذا نظام لإصدار تطبيقات الطرف الثالث (على سبيل المثال، علاج Ultimaker)، مما يسمح بإصدار التطبيقات متى وكيف يريدون: ليست هناك حاجة لمعرفة تفاصيل التوزيعات المختلفة، أو بناء السياسات أو بناء البنية التحتية، ولا حاجة إلى دعم المشرف، ولا يخبرون المستخدمين بما (لا) يمكنهم تثبيته على أجهزة الكمبيوتر الخاصة بهم. يجب أن يُفهم AppImage على أنه شيء مشابه لحزمة Mac في التنسيق .app داخل صورة القرص .dmg. والفرق الرئيسي هو أن التطبيقات لا يتم نسخها، ولكنها تظل داخل AppImage إلى الأبد، تمامًا مثل حزم Haiku .hpkg تم تركيبه، ولم يتم تثبيته أبدًا بالمعنى المعتاد.

على مدار أكثر من 10 سنوات من وجودها، اكتسبت AppImage بعض الجاذبية والشعبية: أيدها لينوس تورفالدس علنًا، وتبنتها المشاريع المشتركة (على سبيل المثال، LibreOffice، وKrita، وInkscape، وScribus، وImageMagick) باعتبارها الطريقة الرئيسية لتوزيع الإصدارات المستمرة أو الليلية، دون التدخل في تطبيقات المستخدم المثبتة أو غير المثبتة. ومع ذلك، لا تزال بيئات سطح المكتب والتوزيعات الخاصة بنظام التشغيل Linux تتشبث في أغلب الأحيان بنموذج التوزيع التقليدي القائم على الصيانة المركزية و/أو تروج لأعمالها التجارية و/أو برامجها الهندسية القائمة على Flatpak (ريدهات، فيدورا، جنوم) و لاذع (الكنسي، أوبونتو). يأتي يبعث على السخرية.

كيف يعمل

• تحتوي كل صورة AppImage على جزأين: نقرة مزدوجة صغيرة على ELF (ما يسمى. runtime.c)، متبوعة بصورة نظام الملفات SquashFS.

• يحتوي نظام ملفات 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. تقوم هذه الخدمة أيضًا بإجراء عملية التنظيف إذا تم حذف AppImage أو نقله. نظرا لحقيقة أن كل مدير سطح مكتب يتصرف بشكل مختلف قليلا، على سبيل المثال، في أي تنسيق يقبل الرموز، في أي أحجام أو أماكن، كل هذا مؤلم حقا.
• يتعطل التطبيق ببساطة عند التنفيذ في حالة حدوث أخطاء (على سبيل المثال، توجد مكتبة ليست جزءًا من النظام الأساسي ولا يتم توفيرها في AppImage)، ولا يوجد أحد يخبر المستخدم في واجهة المستخدم الرسومية بما يحدث بالضبط. لقد بدأنا في التغلب على هذا باستخدام уведомления على سطح المكتب، مما يعني أننا بحاجة إلى اكتشاف الأخطاء من سطر الأوامر، وتحويلها إلى رسائل يفهمها المستخدم، والتي يجب بعد ذلك عرضها على سطح المكتب. وبالطبع، تتعامل كل بيئة سطح مكتب معها بشكل مختلف قليلاً.
• في الوقت الحالي (سبتمبر 2019 - ملاحظة المترجم) لم أجد طريقة بسيطة لإخبار النظام بأن الملف 1.png يجب فتحه باستخدام Krita، و 2.png - استخدام برنامج جيمب.

موقع التخزين للمواصفات عبر سطح المكتب المستخدمة في GNOME, كيدي и إكسفس هو freedesktop.org

إن تحقيق مستوى الرقي المتأصل في بيئة عمل الهايكو أمر صعب، إن لم يكن مستحيلا، نظرا للمواصفات XDG من freedesktop.org لأجهزة سطح المكتب المشتركة، بالإضافة إلى تطبيقات مديري سطح المكتب بناءً على هذه المواصفات. كمثال، يمكننا الاستشهاد بأيقونة Firefox على مستوى النظام: على ما يبدو، لم يعتقد مؤلفو XDG حتى أنه يمكن للمستخدم تثبيت عدة إصدارات من نفس التطبيق.

أيقونات لإصدارات مختلفة من Firefox

كنت أتساءل ما الذي يمكن أن يتعلمه عالم Linux من نظام التشغيل Mac OS X لتجنب إفساد تكامل النظام. إذا كان لديك الوقت الكافي للقيام بذلك، فتأكد من قراءة ما قاله Arnaud Gurdol، أحد مهندسي Mac OS X الأوائل:

أردنا أن نجعل تثبيت التطبيق سهلاً مثل سحب رمز التطبيق من مكان ما (الخادم، محرك الأقراص الخارجي) إلى محرك الكمبيوتر الخاص بك. للقيام بذلك، تقوم حزمة التطبيق بتخزين جميع المعلومات، بما في ذلك الرموز والإصدار ونوع الملف الذي تتم معالجته ونوع أنظمة URL التي يحتاج النظام إلى معرفتها لمعالجة التطبيق. يتضمن هذا أيضًا معلومات عن "التخزين المركزي" في قاعدة بيانات Icon Services وLaunch Services. لدعم الأداء، يتم "اكتشاف" التطبيقات في عدة أماكن "معروفة": دلائل تطبيقات النظام والمستخدم، وبعض الأماكن الأخرى تلقائيًا إذا انتقل المستخدم إلى Finder في الدليل الذي يحتوي على التطبيق. في الممارسة العملية، نجح هذا بشكل جيد للغاية.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 session 144 - Mac OS X: تطبيقات التعبئة والتغليف وطباعة المستندات.

لا يوجد شيء مثل هذه البنية التحتية على أجهزة سطح المكتب Linux، لذلك نحن نبحث عن حلول بديلة للقيود الهيكلية في مشروع AppImage.

هل يأتي هايكو للإنقاذ؟

وشيء آخر: تميل منصات Linux كأساس لبيئات سطح المكتب إلى أن تكون غير محددة إلى حد كبير لدرجة أن العديد من الأشياء البسيطة جدًا في نظام متكامل ومتسق تكون مجزأة ومعقدة بشكل محبط في Linux. لقد خصصت تقريرًا كاملاً للمشكلات المتعلقة بمنصة Linux لبيئات سطح المكتب (أكد المطورون ذوو المعرفة أن كل شيء سيبقى على هذا النحو لفترة طويلة جدًا).

تقريري عن مشاكل بيئات سطح المكتب Linux في 2018

حتى لينوس تورفالدس اعترف بأن التجزئة هي سبب فشل فكرة مساحة العمل.

جميل أن نرى هايكو!

هايكو يجعل كل شيء بسيطًا بشكل مدهش

في حين أن النهج الساذج لـ "نقل" AppImage إلى Haiku هو ببساطة محاولة بناء (runtime.c والخدمة بشكل أساسي) مكوناته (وهو ما قد يكون ممكنًا!)، فإن هذا لن يقدم فائدة كبيرة لـ Haiku. لأنه في الواقع، يتم حل معظم هذه المشكلات في الهايكو وهي سليمة من الناحية المفاهيمية. يوفر Haiku اللبنات الأساسية للبنية التحتية للنظام التي كنت أبحث عنها في بيئات سطح مكتب Linux لفترة طويلة ولم أصدق أنها غير موجودة. يسمى:

صدق أو لا تصدق، هذا شيء لا يستطيع العديد من مستخدمي Linux التغلب عليه. في Haiku، كل شيء يتم تلقائيًا!

• تحصل ملفات ELF التي لا تحتوي على بت قابلية للتنفيذ على واحدة تلقائيًا عند النقر عليها نقرًا مزدوجًا في مدير الملفات.
• يمكن أن تحتوي التطبيقات على موارد مضمنة، مثل الرموز، التي يتم عرضها في مدير الملفات. ليست هناك حاجة لنسخ مجموعة من الصور إلى أدلة خاصة تحتوي على أيقونات، وبالتالي لا داعي لتنظيفها بعد حذف التطبيق أو نقله.
• توجد قاعدة بيانات لربط التطبيقات بالمستندات، فلا داعي لنسخ أي ملفات لهذا الغرض.
• في الدليل lib/ بجوار الملف القابل للتنفيذ، يتم البحث في المكتبات بشكل افتراضي.
• لا يوجد العديد من التوزيعات وبيئات سطح المكتب، مهما كان ما ينجح، فإنه يعمل في كل مكان.
• لا توجد وحدة منفصلة لتشغيلها تختلف عن دليل التطبيقات.
• لا تحتوي التطبيقات على مسارات مطلقة مدمجة لمواردها، بل لديها وظائف خاصة لتحديد الموقع في وقت التشغيل.
• لقد تم طرح فكرة صور نظام الملفات المضغوطة: هذه هي أي حزمة hpkg. يتم تثبيتها جميعًا بواسطة النواة.
• يتم فتح كل ملف بواسطة التطبيق الذي قام بإنشائه، ما لم تحدد خلاف ذلك صراحةً. كيف بارد هذا!

ملفين بصيغة png. لاحظ الرموز المختلفة التي تشير إلى أنه سيتم فتحها بواسطة تطبيقات مختلفة عند النقر عليها نقرًا مزدوجًا. لاحظ أيضًا القائمة المنسدلة "فتح باستخدام:" حيث يمكن للمستخدم تحديد تطبيق فردي. كم هو بسيط!

يبدو أن العديد من العكازات والحلول التي يتطلبها AppImage على Linux أصبحت غير ضرورية على Haiku، الذي يتميز بالبساطة والتطور في جوهره مما يجعله يتعامل مع معظم احتياجاتنا.

هل يحتاج Haiku إلى حزم التطبيقات بعد كل شيء؟

وهذا يؤدي إلى سؤال كبير. إذا كان إنشاء نظام مثل AppImage على Haiku أسهل بكثير من إنشاء نظام على Linux، فهل كان الأمر يستحق القيام به؟ أم أن شركة Haiku، بفضل نظام حزمة hpkg الخاص بها، قد قضت فعليًا على الحاجة إلى تطوير مثل هذه الفكرة؟ حسنًا، للإجابة علينا أن ننظر إلى الدافع وراء وجود AppImages.

وجهة نظر المستخدم

دعونا نلقي نظرة على المستخدم النهائي لدينا:

• أرغب في تثبيت تطبيق دون طلب كلمة مرور المسؤول (الجذر). لا يوجد مفهوم للمسؤول في هايكو، فالمستخدم لديه السيطرة الكاملة لأنه نظام شخصي! (من حيث المبدأ، يمكنك تخيل ذلك في وضع اللعب الجماعي، وآمل أن يبقيه المطورون بسيطًا)
• أريد الحصول على أحدث وأروع إصدارات التطبيقات، دون انتظار ظهورها في التوزيعة الخاصة بي (يعني هذا غالبًا "أبدًا"، على الأقل ما لم أقوم بتحديث نظام التشغيل بأكمله). في Haiku يتم "حل" هذه المشكلة من خلال الإصدارات العائمة. وهذا يعني أنه من الممكن الحصول على أحدث وأكبر إصدارات التطبيقات، ولكن للقيام بذلك تحتاج إلى تحديث بقية النظام باستمرار، وتحويله بشكل فعال إلى “هدف متحرك”.
• أريد عدة إصدارات من نفس التطبيق جنبًا إلى جنب، لأنه لا توجد طريقة لمعرفة ما تم تعطله في الإصدار الأخير، أو، على سبيل المثال، أنا، كمطور ويب، بحاجة إلى اختبار عملي ضمن إصدارات مختلفة من المتصفح. هايكو يحل المشكلة الأولى، ولكن ليس الثانية. يتم التراجع عن التحديثات، ولكن فقط للنظام بأكمله، ومن المستحيل (على حد علمي) تشغيل عدة إصدارات من WebPositive أو LibreOffice على سبيل المثال في نفس الوقت.

أحد المطورين يكتب:

الأساس المنطقي هو هذا: حالة الاستخدام نادرة جدًا بحيث لا يكون تحسينها منطقيًا؛ يبدو التعامل معها كحالة خاصة في HaikuPorts أكثر من مقبول.

• أحتاج إلى الاحتفاظ بالتطبيقات حيث أريدها، وليس على محرك أقراص بدء التشغيل الخاص بي. غالبًا ما تنفد مساحة القرص لدي، لذا أحتاج إلى توصيل محرك أقراص خارجي أو دليل شبكة لتخزين التطبيقات (جميع الإصدارات التي قمت بتنزيلها). إذا قمت بتوصيل محرك الأقراص هذا، فأنا بحاجة إلى تشغيل التطبيقات بالنقر المزدوج. يقوم Haiku بحفظ الإصدارات القديمة من الحزم، لكنني لا أعرف كيفية نقلها إلى محرك أقراص خارجي، أو كيفية تشغيل التطبيقات من هناك لاحقًا.

تعليق المطور:

من الناحية الفنية، هذا ممكن بالفعل باستخدام الأمر mount. وبطبيعة الحال، سوف نقوم بإنشاء واجهة المستخدم الرسومية لهذا بمجرد أن يكون لدينا عدد كاف من المستخدمين المهتمين.

• لا أحتاج إلى ملايين الملفات المنتشرة عبر نظام الملفات والتي لا أستطيع إدارتها يدويًا بنفسي. أريد ملفًا واحدًا لكل تطبيق يمكنني تنزيله ونقله وحذفه بسهولة. في Haiku، يتم حل هذه المشكلة باستخدام الحزم .hpkg، والتي تنقل، على سبيل المثال، لغة بايثون، من آلاف الملفات إلى ملف واحد. ولكن إذا كان هناك، على سبيل المثال، Scribus يستخدم python، فلا بد لي من التعامل مع ملفين على الأقل. ويجب أن أحرص على الاحتفاظ بنسخ منها تعمل مع بعضها البعض.

تعمل إصدارات متعددة من AppImages جنبًا إلى جنب على نفس نظام التشغيل Linux

وجهة نظر مطور التطبيق

دعونا ننظر من وجهة نظر مطور التطبيق:

• أريد التحكم في تجربة المستخدم بأكملها. لا أريد الاعتماد على نظام التشغيل ليخبرني متى وكيف يجب أن أقوم بإصدار التطبيقات. يسمح Haiku للمطورين بالعمل مع مستودعات hpkg الخاصة بهم، ولكن هذا يعني أنه سيتعين على المستخدمين إعدادها يدويًا، مما يجعل الفكرة "أقل جاذبية".
• لدي صفحة تنزيل على موقع الويب الخاص بي حيث أقوم بالتوزيع .exe للنوافذ، .dmg لنظام التشغيل Mac و .AppImage لنظام التشغيل Linux. أو ربما أريد تحقيق الدخل من الوصول إلى هذه الصفحة، كل شيء ممكن؟ ماذا يجب أن أضع هناك لهايكو؟ الملف كافي .hpkg مع التبعيات فقط من HaikuPorts
• يتطلب برنامجي إصدارات محددة من برامج أخرى. على سبيل المثال، من المعروف أن Krita تتطلب إصدارًا مصححًا من Qt، أو Qt يتم ضبطه بدقة على إصدار معين من Krita، على الأقل حتى يتم دفع التصحيحات مرة أخرى إلى Qt. يمكنك حزم Qt الخاص بك لتطبيقك في حزمة .hpkgولكن على الأرجح هذا غير مرحب به.

صفحة تنزيل التطبيقات العادية. ماذا يجب أن أنشر هنا لهايكو؟

سوف حزم (الموجودة كأدلة التطبيق مثل AppDir أو .app بأسلوب Apple) و/أو صور (في شكل صور AppImages أو .dmg من Apple) هل تعتبر التطبيقات إضافة مفيدة لبيئة سطح المكتب Haiku؟ أم أنها ستضعف الصورة بأكملها وتؤدي إلى تفتيتها، وبالتالي تزيد من تعقيدها؟ أنا ممزق: من ناحية، يعتمد جمال وتعقيد هايكو على حقيقة أن هناك عادةً طريقة واحدة للقيام بشيء ما، بدلاً من طرق عديدة. من ناحية أخرى، فإن معظم البنية التحتية للكتالوجات و/أو مجموعات التطبيقات موجودة بالفعل، لذا فإن النظام يصرخ من أجل وضع النسبة المئوية القليلة المتبقية في مكانها الصحيح.

وفقا للمطور السيد. com.waddlesplash

على لينكس هم (الكتالوجات ومجموعات التطبيقات - تقريبًا. مترجم) على الأرجح حل تقني للمشاكل النظامية. في Haiku نفضل حل مشاكل النظام ببساطة.

ماذا تعتقد؟

قبل أن تجيب...

انتظر، دعونا نجري فحصًا سريعًا للواقع: في الواقع أدلة التطبيق - بالفعل جزء من هايكو:

توجد أدلة التطبيقات بالفعل على Haiku، ولكنها غير مدعومة بعد في مدير الملفات

إنها ليست مدعومة بشكل جيد مثل Macintosh Finder، على سبيل المثال. كم سيكون رائعًا لو كان لدليل QtCreator اسم "QtCreator" وأيقونة في الزاوية العلوية اليسرى، بحيث يتم تشغيل التطبيق عند النقر عليه نقرًا مزدوجًا؟

وقبل ذلك بقليل أنا بالفعل طلبت:

هل أنت متأكد من أنه يمكنك تشغيل تطبيقاتك التي مضى عليها عقد من الزمن اليوم عندما نسيتها جميع متاجر التطبيقات ومستودعات التوزيع وتبعياتها؟ هل أنت واثق من أنك ستظل قادرًا على الوصول إلى وظيفتك الحالية في المستقبل؟

هل هناك بالفعل إجابة من Haiku، أو هل يمكن للكتالوجات وحزم التطبيقات المساعدة هنا؟ أعتقد أنهم يستطيعون ذلك.

وفقا للسيد. واد سبلاش:

نعم، لدينا الإجابة على السؤال: سندعم هذه التطبيقات ببساطة طالما كان ذلك ضروريًا حتى يتمكن شخص ما من قراءة تنسيقات الملفات الخاصة به بالطريقة الصحيحة أو توفير وظيفة فردية. إن التزامنا بدعم تطبيقات BeOS R5 على Haiku هو دليل على ذلك...

هذا صحيح!

ما هو مسار العمل الذي يجب أن يتخذه هايكو؟

أستطيع أن أتخيل التعايش السلمي بين hpkg والأدلة وصور التطبيق:

• استخدامات برامج النظام .hpkg
• بالنسبة للبرامج الأكثر استخدامًا (خاصة تلك التي تحتاج إلى جدولة الإصدارات المتداولة)، استخدم .hpkg (حوالي 80% من جميع الحالات)
• تم تثبيت بعض عبر .hpkg، ستستفيد التطبيقات من الانتقال إلى البنية التحتية لدليل التطبيقات (على سبيل المثال QtCreator): سيتم توزيعها على هيئة .hpkgكما كان من قبل.

السيد. كتب Waddlesplash:

إذا كان كل ما تحتاجه هو عرض التطبيقات في /system/apps، بدلاً من ذلك يجب أن نجعل الدلائل الموجودة في Deskbar أكثر قابلية للإدارة بالنسبة للمستخدمين، منذ ذلك الحين /system/apps ليس المقصود أن يتم فتحه وعرضه بانتظام من قبل المستخدمين (على عكس MacOS). في مثل هذه المواقف، لدى هايكو نموذج مختلف، لكن هذا الخيار مقبول من الناحية النظرية.

• تتلقى Haiku البنية التحتية لتشغيل صور التطبيقات، والبنيات الليلية والمستمرة والاختبارية للبرامج، وكذلك للحالات التي يريد فيها المستخدم "تجميدها في الوقت المناسب"، للبرامج الخاصة والداخلية، وحالات الاستخدام الخاصة الأخرى (حوالي 20٪ للجميع). تحتوي هذه الصور على الملفات اللازمة لتشغيل التطبيق .hpkg، مثبتًا بواسطة النظام، وبعد اكتمال التطبيق - غير مثبت. (ربما يستطيع مدير الملفات وضع الملفات .hpkg في صور التطبيق، تلقائيًا أو بناءً على طلب المستخدم - حسنًا، كما هو الحال عندما تقوم بسحب تطبيق إلى دليل شبكة أو محرك أقراص خارجي. انها مجرد أغنية! أو بالأحرى شعر - هايكو.) ومن ناحية أخرى قد يرغب المستخدم في تثبيت محتويات الصورة على شكل ملفات.hpkg، وبعد ذلك سيتم تحديثها ومعالجتها بنفس الطريقة كما لو تم تثبيتها من خلال HaikuDepot... نحن بحاجة إلى تبادل الأفكار).

نقلا عن السيد. واد سبلاش:

قد يكون تشغيل التطبيقات من محركات الأقراص الخارجية أو أدلة الشبكة مفيدًا. وستكون إضافة القدرة على تكوين المزيد من "المناطق" لـ pkgman ميزة رائعة بالتأكيد.

سيستفيد مثل هذا النظام من hpkg والأدلة وصور التطبيقات. إنهم جيدون بشكل فردي، لكنهم معًا سيصبحون لا يقهرون.

اختتام

لدى Haiku إطار عمل يوفر تجربة مستخدم بسيطة ومتطورة للكمبيوتر الشخصي، ويتجاوز بكثير ما يتم توفيره عادةً لأجهزة الكمبيوتر التي تعمل بنظام Linux. نظام الحزمة .hpkg هو أحد الأمثلة على ذلك، ولكن بقية النظام مشبع أيضًا بالتطور. ومع ذلك، قد تستفيد Haiku من الدليل المناسب ودعم صورة التطبيق. إن أفضل طريقة للقيام بذلك تستحق المناقشة مع الأشخاص الذين يعرفون هايكو وفلسفتها وهندستها المعمارية أفضل بكثير مني. بعد كل شيء، لقد تم استخدام هايكو لمدة تزيد قليلا عن أسبوع. ومع ذلك، أعتقد أن المصممين والمطورين والمهندسين المعماريين في هايكو سيستفيدون من هذا المنظور الجديد. على أقل تقدير، سأكون سعيدًا بأن أكون "شريكهم في السجال". لدي أكثر من 10 سنوات من الخبرة العملية في كتالوجات وحزم تطبيقات Linux، وأود أن أجد استخدامًا لها في Haiku، والتي أعتقد أنها مناسبة تمامًا لها. إن الحلول المحتملة التي اقترحتها ليست بأي حال من الأحوال هي الحلول الصحيحة الوحيدة للمشاكل التي وصفتها، وإذا قرر فريق هايكو العثور على حلول أخرى أكثر أناقة، فأنا أؤيد ذلك تمامًا. في الأساس، أفكر بالفعل في فكرة كيفية إنشاء نظام hpkg وأكثر روعة دون تغيير طريقة عمله. اتضح أن فريق Haiku كان يفكر في حزم التطبيقات لفترة طويلة عند تنفيذ نظام إدارة الحزم، ولكن لسوء الحظ (على ما أعتقد) أصبحت الفكرة "عفا عليها الزمن". ربما حان الوقت لإحيائه؟

جربها بنفسك! بعد كل شيء، يوفر مشروع Haiku صورًا للتمهيد من قرص DVD أو USB تم إنشاؤها يوميا.
هل لديك اسئلة؟ نحن ندعوك إلى الناطقين بالروسية قناة برقية.

نظرة عامة على الخطأ: كيف تطلق النار على قدمك في C و C++. مجموعة وصفات Haiku OS

من автора الترجمة: هذا هو المقال الثامن والأخير في سلسلة الهايكو.

قائمة المقالات: الأول الثاني ثالث رابع خامس سادس السابع

يمكن للمستخدمين المسجلين فقط المشاركة في الاستطلاع. تسجيل الدخول، من فضلك.

هل يعقل نقل نظام hpkg إلى Linux؟

• نعم

• لا

• تم تنفيذه بالفعل، سأكتب في التعليقات

صوت 20 مستخدمين. امتنع 5 مستخدما عن التصويت.

المصدر: www.habr.com