कुछ और: हाइकु ऐप बंडल?

TL, डॉ: क्या हाइकु को एप्लिकेशन पैकेजों के लिए उचित समर्थन मिल सकता है, जैसे एप्लिकेशन निर्देशिकाएं (जैसे .app मैक पर) और/या एप्लिकेशन छवियां (लिनक्स AppImage)? मुझे लगता है कि यह एक योग्य अतिरिक्त होगा जिसे अन्य प्रणालियों की तुलना में सही ढंग से लागू करना आसान है क्योंकि अधिकांश बुनियादी ढांचा पहले से ही मौजूद है।

एक सप्ताह पहले मैंने हाइकु की खोज की, जो एक अप्रत्याशित रूप से अच्छी प्रणाली है। खैर, चूंकि मुझे लंबे समय से निर्देशिकाओं और एप्लिकेशन छवियों (मैकिंटोश की सादगी से प्रेरित) में रुचि रही है, इसलिए यह आश्चर्य की बात नहीं है कि मेरे दिमाग में एक विचार आया...

पूरी समझ के लिए, मैं ऐपइमेज का निर्माता और लेखक हूं, एक लिनक्स एप्लिकेशन वितरण प्रारूप जिसका लक्ष्य मैक को सरल बनाना है और एप्लिकेशन लेखकों और अंतिम उपयोगकर्ताओं को पूर्ण नियंत्रण देता है (यदि आप अधिक जानना चाहते हैं, तो देखें) विकि и प्रलेखन).

यदि हम हाइकु के लिए एक AppImage बनाएं तो क्या होगा?

आइए थोड़ा सोचें, विशुद्ध रूप से सैद्धांतिक रूप से: पाने के लिए क्या करने की आवश्यकता है AppImage, या हाइकु पर ऐसा ही कुछ? अभी कुछ बनाना आवश्यक नहीं है, क्योंकि हाइकु में पहले से मौजूद प्रणाली आश्चर्यजनक रूप से काम करती है, लेकिन एक काल्पनिक प्रयोग अच्छा होगा। यह लिनक्स डेस्कटॉप वातावरण की तुलना में हाइकु के परिष्कार को भी प्रदर्शित करता है, जहां ऐसी चीजें बहुत कठिन होती हैं (मुझे ऐसा कहने का अधिकार है: मैं 10 वर्षों से डिबगिंग के साथ संघर्ष कर रहा हूं)।

मैकिंटोश सिस्टम 1 पर, प्रत्येक एप्लिकेशन फाइंडर में एक अलग फ़ाइल "प्रबंधित" थी। AppImage का उपयोग करके मैं Linux पर उसी उपयोगकर्ता अनुभव को फिर से बनाने का प्रयास कर रहा हूँ।

सबसे पहले, AppImage क्या है? यह तृतीय-पक्ष एप्लिकेशन जारी करने की एक प्रणाली है (उदाहरण के लिए, अल्टिमेकर कुरा), अनुप्रयोगों को जब और जैसे वे चाहें जारी करने की अनुमति देते हैं: विभिन्न वितरणों की विशिष्टताओं को जानने, नीतियों का निर्माण करने या बुनियादी ढांचे का निर्माण करने की कोई आवश्यकता नहीं है, किसी अनुरक्षक समर्थन की आवश्यकता नहीं है, और वे उपयोगकर्ताओं को यह नहीं बताते हैं कि वे क्या (नहीं) स्थापित कर सकते हैं उनके कंप्यूटर पर. AppImage को प्रारूप में Mac पैकेज के समान समझा जाना चाहिए .app डिस्क छवि के अंदर .dmg. मुख्य अंतर यह है कि एप्लिकेशन कॉपी नहीं किए जाते हैं, बल्कि AppImage के अंदर हमेशा के लिए रहते हैं, हाइकु पैकेज के समान ही .hpkg स्थापित, और सामान्य अर्थों में कभी भी स्थापित नहीं किया गया।

अस्तित्व के 10 से अधिक वर्षों के दौरान, AppImage ने कुछ अपील और लोकप्रियता हासिल की है: लिनस टोरवाल्ड्स ने स्वयं सार्वजनिक रूप से इसका समर्थन किया है, और सामान्य परियोजनाओं (उदाहरण के लिए, लिब्रे ऑफिस, क्रिटा, इंकस्केप, स्क्रिबस, इमेजमैजिक) ने इसे मुख्य तरीके के रूप में अपनाया है। स्थापित या अनइंस्टॉल किए गए उपयोगकर्ता अनुप्रयोगों में हस्तक्षेप किए बिना, निरंतर या रात्रिकालीन बिल्ड वितरित करना। हालाँकि, लिनक्स डेस्कटॉप वातावरण और वितरण अभी भी पारंपरिक, केंद्रीकृत अनुरक्षक-आधारित वितरण मॉडल से चिपके हुए हैं और/या अपने स्वयं के उद्यम व्यवसाय और/या इंजीनियरिंग कार्यक्रमों को बढ़ावा देते हैं। Flatpak (रेडहैट, फेडोरा, गनोम) और तेज़ (कैनोनिकल, उबंटू)। यह आता है हास्यास्पद.

यह सब कैसे काम करता है

• प्रत्येक AppImage में 2 भाग होते हैं: एक छोटा डबल-क्लिक ELF (तथाकथित)। runtime.c), उसके बाद एक फ़ाइल सिस्टम छवि स्क्वैशएफएस.

• स्क्वैशएफएस फाइल सिस्टम में एप्लिकेशन का पेलोड और इसे चलाने के लिए आवश्यक सभी चीजें शामिल हैं, जिसे सही दिमाग में हर हाल के लक्ष्य सिस्टम (लिनक्स वितरण) के लिए डिफ़ॉल्ट इंस्टॉलेशन का हिस्सा नहीं माना जा सकता है। इसमें मेटाडेटा भी शामिल है, जैसे एप्लिकेशन का नाम, आइकन, MIME प्रकार, आदि।

• जब उपयोगकर्ता द्वारा चलाया जाता है, तो रनटाइम फ़ाइल सिस्टम को माउंट करने के लिए FUSE और स्क्वैशफ्यूज़ का उपयोग करता है, और फिर माउंटेड AppImage के अंदर कुछ एंट्री पॉइंट (उर्फ AppRun) को चलाने का प्रबंधन करता है।
  प्रक्रिया पूरी होने के बाद फ़ाइल सिस्टम अनमाउंट हो जाता है।

सब कुछ सरल प्रतीत होता है.

और ये चीज़ें हर चीज़ को जटिल बनाती हैं:

• लिनक्स वितरण की इतनी विविधता के साथ, "सही दिमाग में" कुछ भी "हर नए लक्ष्य सिस्टम के लिए डिफ़ॉल्ट इंस्टॉलेशन का हिस्सा" नहीं कहा जा सकता है। हम निर्माण द्वारा इस मुद्दे पर काम करते हैं बहिष्करण सूची, आपको यह निर्धारित करने की अनुमति देता है कि AppImage में क्या पैक किया जाएगा और क्या कहीं और ले जाने की आवश्यकता होगी। साथ ही, हम कभी-कभी चूक जाते हैं, इस तथ्य के बावजूद कि, सामान्य तौर पर, सब कुछ बढ़िया काम करता है। इस कारण से, हम अनुशंसा करते हैं कि पैकेज निर्माता सभी लक्ष्य प्रणालियों (वितरणों) पर AppImages का परीक्षण करें।
• एप्लिकेशन पेलोड फ़ाइल सिस्टम में स्थानांतरित होने योग्य होना चाहिए। दुर्भाग्य से, कई अनुप्रयोगों में, उदाहरण के लिए, संसाधनों के लिए हार्ड-कोडित निरपेक्ष पथ होते हैं /usr/share. इसे किसी तरह ठीक करने की जरूरत है. इसके अलावा, आपको या तो निर्यात करना होगा LD_LIBRARY_PATH, या ठीक करें rpath ताकि लोडर संबंधित लाइब्रेरी ढूंढ सके। पहली विधि की अपनी कमियाँ हैं (जिन्हें जटिल तरीकों से दूर किया जाता है), और दूसरी विधि बस बोझिल है।
• उपयोगकर्ताओं के लिए सबसे बड़ा UX ख़तरा यही है निष्पादन योग्य बिट सेट करें डाउनलोड करने के बाद AppImage फ़ाइल। मानो या न मानो, यह कुछ लोगों के लिए एक वास्तविक बाधा है। निष्पादन योग्यता बिट सेट करने की आवश्यकता अनुभवी उपयोगकर्ताओं के लिए भी बोझिल है। समाधान के रूप में, हमने एक छोटी सेवा स्थापित करने का सुझाव दिया जो AppImage फ़ाइलों की निगरानी करती है और उनकी निष्पादन क्षमता बिट सेट करती है। अपने शुद्ध रूप में, यह सबसे अच्छा समाधान नहीं है, क्योंकि यह बॉक्स से बाहर काम नहीं करेगा। लिनक्स वितरण यह सेवा प्रदान नहीं करता है, इसलिए, उपयोगकर्ताओं को बॉक्स के बाहर एक बुरा अनुभव होता है।
• लिनक्स उपयोगकर्ता उम्मीद करते हैं कि नए एप्लिकेशन में स्टार्टअप मेनू में एक आइकन हो। आप सिस्टम को यह नहीं बता सकते: "देखो, एक नया एप्लिकेशन है, चलो काम करें।" इसके बजाय, XDG विनिर्देश के अनुसार, आपको फ़ाइल की प्रतिलिपि बनाने की आवश्यकता है .desktop सही जगह पर /usr सिस्टम-व्यापी स्थापना के लिए, या में $HOME व्यक्तिगत के लिए. XDG विनिर्देश के अनुसार, कुछ आकारों के चिह्नों को कुछ निश्चित स्थानों पर रखने की आवश्यकता होती है usr या $HOME, और फिर आइकन कैश को अपडेट करने के लिए कार्य परिवेश में कमांड चलाएँ, या आशा करें कि कार्य परिवेश प्रबंधक इसका पता लगा लेगा और स्वचालित रूप से सब कुछ का पता लगा लेगा। MIME प्रकारों के साथ भी ऐसा ही है। वर्कअराउंड के रूप में, उसी सेवा का उपयोग करने का प्रस्ताव है, जो निष्पादन योग्यता ध्वज को सेट करने के अलावा, आइकन आदि होने पर भी करेगा। AppImage में, उन्हें XDG के अनुसार AppImage से सही स्थानों पर कॉपी करें। हटाए जाने या स्थानांतरित किए जाने पर, सेवा से सब कुछ साफ़ होने की उम्मीद की जाती है। बेशक, प्रत्येक कार्य परिवेश के व्यवहार, ग्राफिक फ़ाइल स्वरूपों, उनके आकार, भंडारण स्थानों और कैश को अपडेट करने के तरीकों में अंतर होता है, जो एक समस्या पैदा करता है। संक्षेप में, यह विधि एक बैसाखी है।
• यदि उपरोक्त पर्याप्त नहीं है, तो फ़ाइल प्रबंधक में अभी भी कोई AppImage आइकन नहीं है। लिनक्स जगत ने अभी तक एल्फिकॉन को लागू करने का निर्णय नहीं लिया है (इसके बावजूद)। विचार-विमर्श и कार्यान्वयन), इसलिए आइकन को सीधे एप्लिकेशन में एम्बेड करना असंभव है। तो यह पता चला है कि फ़ाइल प्रबंधक में एप्लिकेशन के पास अपने स्वयं के आइकन नहीं हैं (कोई अंतर नहीं, ऐपइमेज या कुछ और), वे केवल स्टार्ट मेनू में हैं। वर्कअराउंड के रूप में, हम थंबनेल का उपयोग कर रहे हैं, एक तंत्र जिसे मूल रूप से डेस्कटॉप प्रबंधकों को ग्राफिक फ़ाइलों की थंबनेल पूर्वावलोकन छवियों को उनके आइकन के रूप में दिखाने की अनुमति देने के लिए डिज़ाइन किया गया था। नतीजतन, निष्पादन योग्यता बिट सेट करने की सेवा एक "मिनीएटराइज़र" के रूप में भी काम करती है, जो उपयुक्त स्थानों पर आइकन थंबनेल बनाती और लिखती है। /usr и $HOME. यदि AppImage हटा दिया जाता है या स्थानांतरित कर दिया जाता है तो यह सेवा सफाई भी करती है। इस तथ्य के कारण कि प्रत्येक डेस्कटॉप प्रबंधक थोड़ा अलग व्यवहार करता है, उदाहरण के लिए, यह किस प्रारूप में आइकन स्वीकार करता है, किस आकार या स्थान में, यह सब वास्तव में दर्दनाक है।
• यदि त्रुटियाँ होती हैं तो एप्लिकेशन निष्पादन पर क्रैश हो जाता है (उदाहरण के लिए, एक लाइब्रेरी है जो बेस सिस्टम का हिस्सा नहीं है और AppImage में आपूर्ति नहीं की गई है), और GUI में उपयोगकर्ता को यह बताने वाला कोई नहीं है कि वास्तव में क्या हो रहा है। हमने इसका उपयोग करके इससे निजात पाना शुरू किया नोटिस डेस्कटॉप पर, जिसका अर्थ है कि हमें कमांड लाइन से त्रुटियों को पकड़ने, उन्हें उपयोगकर्ता द्वारा समझे जाने वाले संदेशों में परिवर्तित करने की आवश्यकता है, जिन्हें डेस्कटॉप पर प्रदर्शित करने की आवश्यकता है। और निश्चित रूप से, प्रत्येक डेस्कटॉप वातावरण उन्हें थोड़ा अलग तरीके से संभालता है।
• फिलहाल (सितंबर 2019 - अनुवादक का नोट) मुझे सिस्टम को यह बताने का कोई आसान तरीका नहीं मिला है कि फ़ाइल 1.png क्रिटा का उपयोग करके खोला जाना चाहिए, और 2.png - GIMP का उपयोग करना।

उपयोग किए गए क्रॉस-डेस्कटॉप विनिर्देशों के लिए भंडारण स्थान सूक्ति, केडीई и XFCE freedesktop.org है

विशिष्टताओं के कारण, हाइकु कार्य वातावरण में गहराई से अंतर्निहित परिष्कार के स्तर को प्राप्त करना असंभव नहीं तो कठिन अवश्य है। freedesktop.org से XDG क्रॉस-डेस्कटॉप के लिए, साथ ही इन विशिष्टताओं के आधार पर डेस्कटॉप प्रबंधकों के कार्यान्वयन के लिए। उदाहरण के तौर पर, हम एक सिस्टम-वाइड फ़ायरफ़ॉक्स आइकन का हवाला दे सकते हैं: जाहिर है, एक्सडीजी के लेखकों ने यह भी नहीं सोचा था कि एक उपयोगकर्ता के पास एक ही एप्लिकेशन के कई संस्करण इंस्टॉल हो सकते हैं।

फ़ायरफ़ॉक्स के विभिन्न संस्करणों के लिए प्रतीक

मैं सोच रहा था कि सिस्टम एकीकरण को खराब होने से बचाने के लिए लिनक्स दुनिया मैक ओएस एक्स से क्या सीख सकती है। यदि आपके पास समय है और आप इसमें रुचि रखते हैं, तो पहले Mac OS

हम एप्लिकेशन को इंस्टॉल करना उतना आसान बनाना चाहते थे जितना कि एप्लिकेशन आइकन को कहीं (सर्वर, बाहरी ड्राइव) से आपके कंप्यूटर ड्राइव पर खींचना। ऐसा करने के लिए, एप्लिकेशन पैकेज आइकन, संस्करण, संसाधित होने वाली फ़ाइल प्रकार, यूआरएल योजनाओं के प्रकार सहित सभी जानकारी संग्रहीत करता है, जिसे सिस्टम को एप्लिकेशन को संसाधित करने के लिए जानना आवश्यक है। इसमें आइकन सर्विसेज और लॉन्च सर्विसेज डेटाबेस में 'सेंट्रल स्टोरेज' की जानकारी भी शामिल है। प्रदर्शन का समर्थन करने के लिए, एप्लिकेशन को कई 'प्रसिद्ध' स्थानों में 'खोजा' जाता है: सिस्टम और उपयोगकर्ता एप्लिकेशन निर्देशिकाएं, और कुछ अन्य स्वचालित रूप से यदि उपयोगकर्ता एप्लिकेशन वाली निर्देशिका में फाइंडर पर नेविगेट करता है। व्यवहार में इसने बहुत अच्छा काम किया।

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 सत्र 144 - मैक ओएस एक्स: पैकेजिंग एप्लिकेशन और प्रिंटिंग दस्तावेज़।

लिनक्स डेस्कटॉप पर इस बुनियादी ढांचे जैसा कुछ भी नहीं है, इसलिए हम AppImage प्रोजेक्ट में संरचनात्मक सीमाओं के आसपास समाधान ढूंढ रहे हैं।

क्या हाइकु बचाव में आ रहा है?

और एक और बात: डेस्कटॉप वातावरण के आधार के रूप में लिनक्स प्लेटफ़ॉर्म इतने कम निर्दिष्ट होते हैं कि कई चीजें जो एक सुसंगत पूर्ण-स्टैक सिस्टम में काफी सरल होती हैं, लिनक्स में निराशाजनक रूप से खंडित और जटिल होती हैं। मैंने डेस्कटॉप वातावरण के लिए लिनक्स प्लेटफ़ॉर्म से संबंधित मुद्दों पर एक पूरी रिपोर्ट समर्पित की (जानकार डेवलपर्स ने पुष्टि की कि सब कुछ बहुत लंबे समय तक इसी तरह रहेगा)।

2018 में लिनक्स डेस्कटॉप वातावरण की समस्याओं पर मेरी रिपोर्ट

यहां तक ​​कि लिनस टोरवाल्ड्स ने भी स्वीकार किया कि विखंडन के कारण ही कार्यक्षेत्र का विचार विफल हुआ।

हाइकु देखकर अच्छा लगा!

हाइकु हर चीज़ को आश्चर्यजनक रूप से सरल बना देता है

जबकि AppImage को Haiku में "पोर्ट" करने का सरल तरीका केवल इसके घटकों (मुख्य रूप से runtime.c और service) को बनाने का प्रयास करना है (जो संभव भी हो सकता है!), इससे Haiku को अधिक लाभ नहीं मिलेगा। क्योंकि वास्तव में, इनमें से अधिकांश समस्याएं हाइकु में हल हो गई हैं और वैचारिक रूप से सुदृढ़ हैं। हाइकु बिल्कुल सिस्टम इंफ्रास्ट्रक्चर बिल्डिंग ब्लॉक प्रदान करता है जिसे मैं लंबे समय से लिनक्स डेस्कटॉप वातावरण में ढूंढ रहा था और विश्वास नहीं कर सका कि वे वहां नहीं थे। अर्थात्:

विश्वास करें या न करें, यह एक ऐसी चीज़ है जिसे कई लिनक्स उपयोगकर्ता दूर नहीं कर सकते हैं। हाइकु पर सब कुछ स्वचालित रूप से होता है!

• ईएलएफ फ़ाइलें जिनमें निष्पादन योग्यता बिट नहीं है, फ़ाइल प्रबंधक में डबल-क्लिक करने पर स्वचालित रूप से एक प्राप्त हो जाती है।
• एप्लिकेशन में अंतर्निहित संसाधन हो सकते हैं, जैसे आइकन, जो फ़ाइल प्रबंधक में प्रदर्शित होते हैं। छवियों के एक समूह को आइकनों के साथ विशेष निर्देशिकाओं में कॉपी करने की कोई आवश्यकता नहीं है, और इसलिए एप्लिकेशन को हटाने या स्थानांतरित करने के बाद उन्हें साफ़ करने की कोई आवश्यकता नहीं है।
• एप्लिकेशन को दस्तावेज़ों से जोड़ने के लिए एक डेटाबेस है, इसके लिए किसी फ़ाइल को कॉपी करने की आवश्यकता नहीं है।
• निष्पादन योग्य फ़ाइल के बगल में lib/ निर्देशिका में, पुस्तकालयों को डिफ़ॉल्ट रूप से खोजा जाता है।
• बहुत सारे वितरण और डेस्कटॉप वातावरण नहीं हैं; जो भी काम करता है, वह हर जगह काम करता है।
• चलाने के लिए कोई अलग मॉड्यूल नहीं है जो एप्लिकेशन निर्देशिका से अलग हो।
• एप्लिकेशन में अपने संसाधनों के लिए अंतर्निहित पूर्ण पथ नहीं होते हैं; रनटाइम पर स्थान निर्धारित करने के लिए उनके पास विशेष कार्य होते हैं।
• संपीड़ित फ़ाइल सिस्टम छवियों का विचार पेश किया गया है: यह कोई भी एचपीकेजी पैकेज है। ये सभी कर्नेल द्वारा आरोहित हैं।
• प्रत्येक फ़ाइल उस एप्लिकेशन द्वारा खोली जाती है जिसने इसे बनाया है, जब तक कि आप स्पष्ट रूप से अन्यथा निर्दिष्ट न करें। यह कितना बढ़िया है!

दो पीएनजी फ़ाइलें. विभिन्न आइकनों पर ध्यान दें जो दर्शाते हैं कि डबल-क्लिक करने पर वे विभिन्न एप्लिकेशन द्वारा खोले जाएंगे। "इसके साथ खोलें:" ड्रॉप-डाउन मेनू पर भी ध्यान दें जहां उपयोगकर्ता एक व्यक्तिगत एप्लिकेशन का चयन कर सकता है। कितना सरल!

ऐसा लगता है कि लिनक्स पर ऐपइमेज के लिए आवश्यक कई बैसाखियाँ और वर्कअराउंड हाइकु पर अनावश्यक हो जाते हैं, जिसके मूल में सरलता और परिष्कार है जो इसे हमारी अधिकांश जरूरतों को पूरा करने में सक्षम बनाता है।

क्या आख़िरकार हाइकु को ऐप पैकेज की ज़रूरत है?

इससे एक बड़ा सवाल खड़ा होता है. यदि लिनक्स की तुलना में हाइकु पर AppImage जैसा सिस्टम बनाना बहुत आसान होता, तो क्या यह करना उचित होता? या क्या हाइकु ने अपने एचपीकेजी पैकेज सिस्टम के साथ इस तरह के विचार को विकसित करने की आवश्यकता को प्रभावी ढंग से समाप्त कर दिया है? खैर, उत्तर देने के लिए हमें AppImages के अस्तित्व के पीछे की प्रेरणा को देखना होगा।

उपयोगकर्ता का दृष्टिकोण

आइए हमारे अंतिम उपयोगकर्ता पर नजर डालें:

• मैं व्यवस्थापक (रूट) पासवर्ड मांगे बिना एक एप्लिकेशन इंस्टॉल करना चाहता हूं। हाइकु पर प्रशासक की कोई अवधारणा नहीं है, यह एक व्यक्तिगत प्रणाली होने के कारण उपयोगकर्ता का पूर्ण नियंत्रण होता है! (सिद्धांत रूप में, आप मल्टीप्लेयर मोड में इसकी कल्पना कर सकते हैं, मुझे आशा है कि डेवलपर्स इसे सरल रखेंगे)
• मैं अपने वितरण में उनके प्रकट होने की प्रतीक्षा किए बिना, अनुप्रयोगों के नवीनतम और महानतम संस्करण प्राप्त करना चाहता हूं (अक्सर इसका अर्थ "कभी नहीं", कम से कम जब तक कि मैं संपूर्ण ऑपरेटिंग सिस्टम को अद्यतन नहीं करता)। हाइकु पर इसे फ़्लोटिंग रिलीज़ के साथ "समाधान" किया गया है। इसका मतलब है कि एप्लिकेशन के नवीनतम और महानतम संस्करण प्राप्त करना संभव है, लेकिन ऐसा करने के लिए आपको सिस्टम के बाकी हिस्सों को लगातार अपडेट करने की आवश्यकता है, इसे प्रभावी ढंग से "चलते लक्ष्य" में बदलना होगा।.
• मैं एक ही एप्लिकेशन के कई संस्करण एक साथ चाहता हूं, क्योंकि यह जानने का कोई तरीका नहीं है कि नवीनतम संस्करण में क्या टूटा है, या कहें, एक वेब डेवलपर के रूप में मुझे ब्राउज़र के विभिन्न संस्करणों के तहत अपने काम का परीक्षण करने की आवश्यकता है। हाइकु पहली समस्या का समाधान करता है, लेकिन दूसरी का नहीं। अपडेट को वापस रोल किया जाता है, लेकिन केवल पूरे सिस्टम के लिए; उदाहरण के लिए, एक ही समय में वेबपॉजिटिव या लिबरऑफिस के कई संस्करणों को चलाना असंभव है (जहाँ तक मुझे पता है)।

डेवलपर्स में से एक लिखता है:

मूलतः तर्क यह है: उपयोग का मामला इतना दुर्लभ है कि इसके लिए अनुकूलन का कोई मतलब नहीं बनता है; HaikuPorts में इसे एक विशेष मामले के रूप में मानना ​​स्वीकार्य से अधिक प्रतीत होता है।

• मुझे ऐप्स वहां रखने होंगे जहां वे मुझे पसंद हों, न कि अपने स्टार्टअप ड्राइव पर। मेरी डिस्क में अक्सर जगह खत्म हो जाती है, इसलिए मुझे एप्लिकेशन (सभी संस्करण जो मैंने डाउनलोड किए हैं) संग्रहीत करने के लिए एक बाहरी ड्राइव या नेटवर्क निर्देशिका को कनेक्ट करने की आवश्यकता होती है। यदि मैं ऐसी ड्राइव कनेक्ट करता हूं, तो मुझे डबल-क्लिक करके एप्लिकेशन लॉन्च करने की आवश्यकता है। हाइकु पैकेजों के पुराने संस्करणों को सहेजता है, लेकिन मुझे नहीं पता कि उन्हें बाहरी ड्राइव पर कैसे ले जाया जाए, या बाद में वहां से एप्लिकेशन कैसे लॉन्च किया जाए।

डेवलपर टिप्पणी:

तकनीकी रूप से, माउंट कमांड के साथ यह पहले से ही संभव है। निःसंदेह, जैसे ही हमारे पास पर्याप्त रुचि रखने वाले उपयोगकर्ता होंगे, हम इसके लिए एक GUI बनाएंगे।

• मुझे फ़ाइल सिस्टम में बिखरी हुई लाखों फ़ाइलों की आवश्यकता नहीं है जिन्हें मैं स्वयं मैन्युअल रूप से प्रबंधित नहीं कर सकता। मैं प्रति एप्लिकेशन एक फ़ाइल चाहता हूं जिसे मैं आसानी से डाउनलोड कर सकूं, स्थानांतरित कर सकूं, हटा सकूं। हाइकु पर पैकेजों का उपयोग करके इस समस्या का समाधान किया जाता है .hpkg, जो, उदाहरण के लिए, पायथन, हजारों फ़ाइलों से एक में स्थानांतरित करता है। लेकिन अगर, उदाहरण के लिए, पाइथॉन का उपयोग करने वाला स्क्रिबस है, तो मुझे कम से कम दो फाइलों से निपटना होगा। और मुझे उनके ऐसे संस्करण रखने का ध्यान रखना होगा जो एक-दूसरे के साथ काम करते हों।

AppImages के अनेक संस्करण एक ही Linux पर साथ-साथ चल रहे हैं

एक एप्लिकेशन डेवलपर का दृष्टिकोण

आइए एप्लिकेशन डेवलपर के दृष्टिकोण से देखें:

• मैं संपूर्ण उपयोगकर्ता अनुभव को नियंत्रित करना चाहता हूं. मैं यह बताने के लिए किसी ऑपरेटिंग सिस्टम पर निर्भर नहीं रहना चाहता कि मुझे एप्लिकेशन कब और कैसे जारी करनी चाहिए। हाइकु डेवलपर्स को अपने स्वयं के एचपीकेजी रिपॉजिटरी के साथ काम करने की अनुमति देता है, लेकिन इसका मतलब है कि उपयोगकर्ताओं को उन्हें मैन्युअल रूप से सेट करना होगा, जो विचार को "कम आकर्षक" बनाता है।
• मेरी वेबसाइट पर एक डाउनलोड पेज है जहां मैं वितरित करता हूं .exe विंडोज के लिए, .dmg मैक के लिए और .AppImage लिनक्स के लिए. या शायद मैं इस पृष्ठ तक पहुंच का मुद्रीकरण करना चाहता हूं, कुछ भी संभव है? हाइकु के लिए मुझे वहां क्या रखना चाहिए? फ़ाइल काफी है .hpkg केवल HaikuPorts पर निर्भरता के साथ
• मेरे सॉफ़्टवेयर को अन्य सॉफ़्टवेयर के विशिष्ट संस्करणों की आवश्यकता है। उदाहरण के लिए, यह ज्ञात है कि क्रिटा को क्यूटी, या क्यूटी के एक पैच किए गए संस्करण की आवश्यकता होती है जो कि क्रिटा के एक विशिष्ट संस्करण के लिए ठीक से ट्यून किया गया है, कम से कम जब तक पैच को क्यूटी में वापस नहीं धकेल दिया जाता है। आप अपने एप्लिकेशन के लिए अपनी स्वयं की क्यूटी को एक पैकेज में पैकेज कर सकते हैं .hpkg, लेकिन सबसे अधिक संभावना यह स्वागतयोग्य नहीं है।

नियमित आवेदन डाउनलोड पृष्ठ। मुझे हाइकु के लिए यहां क्या पोस्ट करना चाहिए?

विल बंडल (एप्लिकेशन निर्देशिका जैसे AppDir या के रूप में विद्यमान)। .app Apple शैली में) और/या छवियाँ (अत्यधिक संशोधित AppImages के रूप में या)। .dmg एप्पल से) एप्लिकेशन हाइकु डेस्कटॉप वातावरण के लिए एक उपयोगी अतिरिक्त है? या यह पूरी तस्वीर को कमजोर कर देगा और विखंडन की ओर ले जाएगा, और इसलिए जटिलता बढ़ जाएगी? मैं टूट गया हूँ: एक ओर, हाइकु की सुंदरता और परिष्कार इस तथ्य पर आधारित है कि आमतौर पर किसी चीज़ को करने का एक ही तरीका होता है, न कि कई। दूसरी ओर, कैटलॉग और/या एप्लिकेशन सूट के लिए अधिकांश बुनियादी ढांचा पहले से ही मौजूद है, इसलिए सिस्टम शेष कुछ प्रतिशत को लागू करने के लिए रोता है।

डेवलपर के अनुसार श्री। wadlesplash

लिनक्स पर वे (कैटलॉग और एप्लिकेशन किट, - लगभग। अनुवादक) संभवतः प्रणालीगत समस्याओं का एक तकनीकी समाधान है। हाइकु में हम केवल सिस्टम समस्याओं को हल करना पसंद करते हैं।

आपको क्या लगता है?

इससे पहले कि आप उत्तर दें...

रुको, आइए एक त्वरित वास्तविकता जांच करें: वास्तव में अनुप्रयोग निर्देशिकाएँ - पहले से ही हाइकु का हिस्सा:

एप्लिकेशन निर्देशिकाएँ हाइकु पर पहले से मौजूद हैं, लेकिन अभी तक फ़ाइल प्रबंधक में समर्थित नहीं हैं

वे उतने अच्छे से समर्थित नहीं हैं, जितना कि मैकिंटोश फाइंडर कहते हैं। यह कितना अच्छा होगा यदि QtCreator निर्देशिका में ऊपरी बाएँ कोने में "QtCreator" नाम और आइकन हो, जिससे डबल-क्लिक करने पर एप्लिकेशन लॉन्च हो सके?

थोड़ा पहले ही मैं पहले से ही पूछा:

क्या आप आश्वस्त हैं कि आप आज अपने एक दशक पुराने ऐप्स चला सकते हैं, जब सभी ऐप स्टोर और वितरण रिपॉजिटरी उनके और उनकी निर्भरता के बारे में भूल गए हैं? क्या आप आश्वस्त हैं कि आप भविष्य में भी अपनी वर्तमान नौकरी तक पहुंच पाएंगे?

क्या हाइकु की ओर से पहले से ही कोई उत्तर है, या कैटलॉग और एप्लिकेशन बंडल यहां मदद कर सकते हैं? मुझे लगता है वे कर सकते हैं.

श्रीमान के अनुसार. वैडलस्प्लैश:

हां, हमारे पास प्रश्न का उत्तर है: हम इन अनुप्रयोगों का तब तक समर्थन करेंगे जब तक आवश्यक हो, जब तक कोई उनके फ़ाइल स्वरूपों को सही तरीके से नहीं पढ़ लेता या एक-से-एक कार्यक्षमता प्रदान नहीं कर लेता। हाइकु पर BeOS R5 ऐप्स को समर्थन देने की हमारी प्रतिबद्धता इसका प्रमाण है...

यह निश्चित रूप से है!

हाइकु को क्या कदम उठाना चाहिए?

मैं एचपीकेजी, निर्देशिकाओं और एप्लिकेशन छवियों के शांतिपूर्ण सह-अस्तित्व की कल्पना कर सकता हूं:

• सिस्टम सॉफ्टवेयर का उपयोग करता है .hpkg
• सबसे अधिक उपयोग किए जाने वाले सॉफ़्टवेयर के लिए (विशेषकर जिनके लिए रोलिंग रिलीज़ शेड्यूल करने की आवश्यकता होती है), उपयोग करें .hpkg (सभी मामलों में से लगभग 80%)
• कुछ के माध्यम से स्थापित किया गया .hpkg, एप्लिकेशन को एप्लिकेशन डायरेक्टरी इंफ्रास्ट्रक्चर (जैसे QtCreator) में जाने से लाभ होगा: उन्हें इस प्रकार वितरित किया जाएगा .hpkg, पहले जैसा।

श्री। वैडलस्प्लैश लिखते हैं:

यदि आपको केवल एप्लिकेशन देखने की आवश्यकता है /system/apps, इसके बजाय हमें डेस्कबार में निर्देशिकाओं को उपयोगकर्ताओं के लिए अधिक प्रबंधनीय बनाना चाहिए /system/apps इसे उपयोगकर्ताओं द्वारा नियमित रूप से खोलने और देखने का इरादा नहीं है (MacOS के विपरीत)। ऐसी स्थितियों के लिए, हाइकु का एक अलग प्रतिमान है, लेकिन यह विकल्प, सिद्धांत रूप में, स्वीकार्य है।

• हाइकु को एप्लिकेशन छवियों को चलाने, सॉफ़्टवेयर के रात्रिकालीन, निरंतर और परीक्षण बिल्ड के साथ-साथ उन मामलों के लिए बुनियादी ढांचा प्राप्त होता है जब उपयोगकर्ता निजी और आंतरिक सॉफ़्टवेयर और अन्य विशेष उपयोग के मामलों के लिए "इसे समय पर फ़्रीज़ करना चाहता है" (लगभग 20%) के सभी)। इन छवियों में एप्लिकेशन चलाने के लिए आवश्यक फ़ाइलें हैं .hpkg, सिस्टम द्वारा माउंट किया जाता है, और एप्लिकेशन पूरा होने के बाद - अनमाउंट किया जाता है। (संभवतः कोई फ़ाइल प्रबंधक फ़ाइलें डाल सकता है .hpkg एप्लिकेशन छवियों में, स्वचालित रूप से या उपयोगकर्ता के अनुरोध पर - ठीक है, जैसे जब आप किसी एप्लिकेशन को नेटवर्क निर्देशिका या बाहरी ड्राइव पर खींचते हैं। यह सिर्फ एक गाना है! या बल्कि, कविता - हाइकु।) दूसरी ओर, उपयोगकर्ता छवि की सामग्री को फ़ाइलों के रूप में स्थापित करना चाह सकता है.hpkg, जिसके बाद उन्हें उसी तरह से अद्यतन और संसाधित किया जाएगा जैसे कि वे HaikuDepot के माध्यम से स्थापित किए गए थे... हमें विचार-मंथन करने की आवश्यकता है)।

श्रीमान का उद्धरण. वैडलस्प्लैश:

बाहरी ड्राइव या नेटवर्क निर्देशिकाओं से एप्लिकेशन चलाना संभावित रूप से उपयोगी हो सकता है। और pkgman के लिए अधिक "ज़ोन" कॉन्फ़िगर करने की क्षमता जोड़ना निश्चित रूप से एक अच्छी सुविधा होगी।

ऐसी प्रणाली एचपीकेजी, निर्देशिकाओं और एप्लिकेशन छवियों का लाभ उठाएगी। वे व्यक्तिगत रूप से अच्छे हैं, लेकिन साथ मिलकर वे अजेय हो जायेंगे।

निष्कर्ष

हाइकु में एक ढांचा है जो पीसी के लिए एक सरल और परिष्कृत उपयोगकर्ता अनुभव प्रदान करता है, और आमतौर पर लिनक्स पीसी के लिए जो प्रदान किया जाता है उससे कहीं आगे जाता है। पैकेज प्रणाली .hpkg यह एक ऐसा उदाहरण है, लेकिन शेष प्रणाली भी परिष्कार से ओत-प्रोत है। हालाँकि, हाइकु को उचित निर्देशिका और एप्लिकेशन छवि समर्थन से लाभ होगा। ऐसा करने का सबसे अच्छा तरीका उन लोगों के साथ चर्चा करना उचित है जो हाइकु, इसके दर्शन और वास्तुकला को मुझसे बेहतर जानते हैं। आख़िरकार, मैं एक सप्ताह से कुछ अधिक समय से हाइकु का उपयोग कर रहा हूँ। फिर भी, मेरा मानना ​​है कि हाइकु के डिजाइनरों, डेवलपर्स और वास्तुकारों को इस नए दृष्टिकोण से लाभ होगा। कम से कम, मुझे उनका "स्पैरिंग पार्टनर" बनकर खुशी होगी। मेरे पास लिनक्स एप्लिकेशन कैटलॉग और बंडलों के साथ 10 वर्षों से अधिक का व्यावहारिक अनुभव है, और मैं हाइकु में उनके लिए एक उपयोग ढूंढना चाहूंगा, जिसके लिए मुझे लगता है कि वे एकदम उपयुक्त हैं। मेरे द्वारा प्रस्तावित संभावित समाधान किसी भी तरह से मेरे द्वारा वर्णित समस्याओं के लिए एकमात्र सही समाधान नहीं हैं, और यदि हाइकु टीम अन्य, अधिक सुंदर समाधान खोजने का निर्णय लेती है, तो मैं इसके लिए तैयार हूं। मूल रूप से, मैं पहले से ही इस विचार पर विचार कर रहा हूं कि एक सिस्टम कैसे बनाया जाए hpkg इसके काम करने के तरीके को बदले बिना और भी अधिक आश्चर्यजनक। यह पता चला है कि पैकेज प्रबंधन प्रणाली को लागू करते समय हाइकु टीम लंबे समय से एप्लिकेशन बंडलों के बारे में सोच रही थी, लेकिन दुर्भाग्य से (मुझे लगता है) यह विचार "अप्रचलित" हो गया। शायद इसे पुनर्जीवित करने का समय आ गया है?

खुद कोशिश करना! आख़िरकार, हाइकु प्रोजेक्ट डीवीडी या यूएसबी से बूटिंग के लिए छवियां प्रदान करता है दैनिक.
क्या आपका कोई प्रश्न है? हम आपको रूसी बोलने के लिए आमंत्रित करते हैं टेलीग्राम चैनल.

त्रुटि अवलोकन: C और C++ में अपने पैरों पर कुल्हाड़ी कैसे मारें। हाइकू ओएस रेसिपी संग्रह

से लेखक अनुवाद: यह हाइकु के बारे में श्रृंखला का आठवां और अंतिम लेख है।

लेखों की सूची: पहले दूसरा तिहाई चौथा पांचवां छठा सातवाँ

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

क्या एचपीकेजी सिस्टम को लिनक्स में पोर्ट करना उचित है?

• Да

• नहीं

• पहले ही लागू हो चुका है, मैं टिप्पणियों में लिखूंगा

20 उपयोगकर्ताओं ने मतदान किया। 5 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com