कुछ और: हाइकु ऐप पैकेज?

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

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

एक पूर्ण समझ के लिए: मैं AppImage का निर्माता और लेखक हूं, जो मैक सादगी के उद्देश्य से लिनक्स अनुप्रयोग वितरण प्रारूप है और आवेदन लेखकों और अंतिम उपयोगकर्ताओं को पूर्ण नियंत्रण प्रदान करना चाहता है (अधिक जानना चाहते हैं - विकी और प्रलेखन देखें )।

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

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

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

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

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

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

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

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

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

ऐसा लगता है कि सब कुछ सरल है।

और ये चीजें जटिल होती हैं:

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

GNOME , KDE और Xfce द्वारा उपयोग किए जाने वाले क्रॉस-डेस्कटॉप विनिर्देशों के लिए संग्रहण स्थान freedesktop.org है

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

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

मैं सोच रहा था कि मैक ओएस एक्स से लिनक्स दुनिया क्या सीख सकती है, ताकि सिस्टम एकीकरण के साथ गड़बड़ न हो। यदि आपके पास समय है और आप ऐसा कर रहे हैं, तो अवश्य पढ़ें कि अर्नो गौरडोल, जो पहले मैक ओएस एक्स इंजीनियरों में से एक था, ने कहा:

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

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

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

क्या हाइकु मदद करने की जल्दी में है?

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

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

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

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

हाइकु के साथ, सब कुछ आश्चर्यजनक सरल है।

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

मानो या न मानो, कई लिनक्स उपयोगकर्ता इसे दूर नहीं कर सकते हैं। हाइकु में, सब कुछ अपने आप हो जाता है!

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

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

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

क्या हाइकु को अंत में एप्लिकेशन पैकेजों की आवश्यकता है?

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

उपयोगकर्ता से देखें

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

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

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

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

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

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

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

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

एकल लिनक्स पर अगल-बगल चलने वाले AppImages के कई संस्करण

एप्लिकेशन डेवलपर की ओर से देखें

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

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

सामान्य अनुप्रयोग डाउनलोड पृष्ठ। हाइकु के लिए यहां क्या रखा जाए?

क्या बंडलों (ऐप्पड शैली में ऐप्पर्ड या .app जैसी एप्लिकेशन निर्देशिकाओं के रूप में मौजूद) और / या छवियों (भारी रूप से संशोधित एप्पल के ऐपमैसेज या। डीएमजी के रूप में) हाइकु काम के माहौल के लिए उपयोगी जोड़ होंगे? या यह पूरी तस्वीर को पतला कर देगा और विखंडन की ओर ले जाएगा, और इसलिए जटिलता जोड़ देगा? मैं फटा हुआ हूं: एक तरफ, हाइकु की सुंदरता और परिष्कार इस तथ्य पर आधारित है कि आमतौर पर कुछ करने का एक तरीका है, बहुत कुछ नहीं। , / , , .

mr. waddlesplash

Linux ( , — . ) . Haiku .

?

...

, : — Haiku:

Haiku,

, , , Macintosh Finder. , QtCreator "QtCreator", ?

:

, , ? , - ?

Haiku, ? , .

mr. waddlesplash:

, : , , - . BeOS R5 Haiku — ...

!

Haiku?

hpkg, :

• .hpkg
• ( , ) .hpkg ( 80% )
• , .hpkg , ( , QtCreator): .hpkg , .

mr. waddlesplash :

, , — /system/apps , Deskbar , /system/apps , ( MacOS). Haiku , , , .

• Haiku , , , , " ", , ( 20% ). .hpkg , , — . (, .hpkg , — , . ! — .) , .hpkg , , HaikuDepot… ).

mr. waddlesplash:

. "" pkgman .

hpkg, . , .

निष्कर्ष

Haiku , , , Linux. .hpkg — , . , Haiku . — , Haiku, , . Haiku . , , , Haiku. , «-». 10 Linux, Haiku, , , . , , Haiku , , — . , , hpkg , . , Haiku , , ( ) "". , ?

! Haiku DVD USB, .
? telegram- .

: C C++. Haiku OS

: Haiku.

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