अरू केही: हाइकु एप बन्डलहरू?

TL; ड: के हाइकुले एप्लिकेसन प्याकेजहरूको लागि उपयुक्त समर्थन प्राप्त गर्न सक्छ, जस्तै एप्लिकेसन डाइरेक्टरीहरू (जस्तै .app म्याकमा) र/वा अनुप्रयोग छविहरू (लिनक्स AppImage)? मलाई लाग्छ कि यो एक योग्य थप हुनेछ जुन अन्य प्रणालीहरू भन्दा सही रूपमा कार्यान्वयन गर्न सजिलो छ किनकि अधिकांश पूर्वाधारहरू पहिले नै ठाउँमा छन्।

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

पूर्ण बुझाइको लागि, म AppImage को निर्माता र लेखक हुँ, एक लिनक्स अनुप्रयोग वितरण ढाँचा जसले म्याक सरलताको लागि लक्ष्य राख्छ र अनुप्रयोग लेखकहरू र अन्तिम प्रयोगकर्ताहरूलाई पूर्ण नियन्त्रण दिन्छ (यदि तपाईं थप जान्न चाहनुहुन्छ भने, हेर्नुहोस् wiki и कागजात).

यदि हामीले हाइकुको लागि एउटा AppImage बनायौं भने के हुन्छ?

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

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

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

10 वर्ष भन्दा बढी अस्तित्वको अवधिमा, AppImage ले केहि अपील र लोकप्रियता प्राप्त गरेको छ: लिनस टोर्भाल्ड्स आफैले यसलाई सार्वजनिक रूपमा समर्थन गरे, र साझा परियोजनाहरू (उदाहरणका लागि, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) ले यसलाई मुख्य तरिकाको रूपमा अपनाएका छन्। स्थापित वा अनइन्स्टल गरिएका प्रयोगकर्ता अनुप्रयोगहरूमा हस्तक्षेप नगरी, निरन्तर वा राती निर्माणहरू वितरण गर्न। जे होस्, लिनक्स डेस्कटप वातावरण र वितरणहरू प्रायः अझै पनि परम्परागत, केन्द्रीकृत मर्मतकर्ता-आधारित वितरण मोडेलमा टाँसिन्छन् र/वा तिनीहरूको आफ्नै उद्यम व्यवसाय र/वा इन्जिनियरि programs कार्यक्रमहरूमा आधारित हुन्छन्। Flatpak (रेडह्याट, फेडोरा, जिनोम) र दु: खी (क्यानोनिकल, उबुन्टु)। यो आउँछ हास्यास्पद रूपमा.

यस्ले कसरी काम गर्छ

• प्रत्येक AppImage मा 2 भागहरू हुन्छन्: एउटा सानो डबल-क्लिक ELF (तथाकथित। runtime.c), फाइल प्रणाली छवि पछि SquashFS.

• SquashFS फाइल प्रणालीले अनुप्रयोगको पेलोड र यसलाई चलाउन आवश्यक सबै चीजहरू समावेश गर्दछ, जुन सही दिमागमा प्रत्येक हालको लक्ष्य प्रणाली (लिनक्स वितरण) को लागि पूर्वनिर्धारित स्थापनाको अंश मान्न सकिँदैन। यसले मेटाडेटा पनि समावेश गर्दछ, जस्तै अनुप्रयोगको नाम, आइकनहरू, MIME प्रकारहरू, आदि।

• प्रयोगकर्ताद्वारा चलाउँदा, रनटाइमले फाइल प्रणाली माउन्ट गर्न FUSE र squashfuse प्रयोग गर्दछ, र त्यसपछि माउन्ट गरिएको 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 प्रतिमा छैन। लिनक्स संसारले अझै पनि elficon लागू गर्ने निर्णय गरेको छैन (बावजुद छलफल и कार्यान्वयन), त्यसैले आईकनलाई सिधै एपमा इम्बेड गर्न असम्भव छ। त्यसोभए यो बाहिर जान्छ कि फाइल प्रबन्धकमा अनुप्रयोगहरूको आफ्नै आइकनहरू छैनन् (कुनै फरक छैन, AppImage वा अरू केहि), तिनीहरू केवल सुरु मेनुमा छन्। एक समाधानको रूपमा, हामी थम्बनेलहरू प्रयोग गर्दैछौं, एउटा संयन्त्र जुन मूल रूपमा डेस्कटप प्रबन्धकहरूलाई ग्राफिक फाइलहरूको थम्बनेल पूर्वावलोकन छविहरूलाई तिनीहरूको आइकनको रूपमा देखाउन अनुमति दिन डिजाइन गरिएको थियो। फलस्वरूप, कार्यान्वयनयोग्यता बिट सेट गर्ने सेवाले उपयुक्त स्थानहरूमा आइकन थम्बनेलहरू सिर्जना गर्ने र लेख्ने, "मिनिएचराइजर" को रूपमा पनि काम गर्दछ। /usr и $HOME। यदि AppImage मेटाइयो वा सारियो भने यो सेवाले सफाई पनि गर्छ। प्रत्येक डेस्कटप प्रबन्धकले अलि फरक व्यवहार गर्ने तथ्यको कारण, उदाहरणका लागि, कुन ढाँचाहरूमा यसले आइकनहरू स्वीकार गर्दछ, कुन आकार वा ठाउँहरूमा, यो सबै साँच्चै पीडादायी छ।
• त्रुटिहरू देखा पर्दा एप्लिकेसन केवल कार्यान्वयनमा क्र्यास हुन्छ (उदाहरणका लागि, त्यहाँ एउटा पुस्तकालय छ जुन आधार प्रणालीको अंश होइन र AppImage मा आपूर्ति गरिएको छैन), र GUI मा प्रयोगकर्तालाई वास्तवमा के भइरहेको छ भनेर बताउन सक्ने कोही छैन। हामीले यसको प्रयोग गरेर वरिपरि जान थाल्यौं सूचनाहरू डेस्कटपमा, जसको मतलब हामीले कमाण्ड लाइनबाट त्रुटिहरू समात्न आवश्यक छ, तिनीहरूलाई प्रयोगकर्ताले बुझेका सन्देशहरूमा रूपान्तरण गर्न आवश्यक छ, जुन त्यसपछि डेस्कटपमा प्रदर्शन गर्न आवश्यक छ। र निस्सन्देह, प्रत्येक डेस्कटप वातावरण तिनीहरूलाई अलि फरक रूपमा ह्यान्डल गर्दछ।
• हाल (सेप्टेम्बर 2019 - अनुवादकको नोट) मैले प्रणालीलाई फाइल बताउनको लागि सरल तरिका फेला पारेको छैन। 1.png Krita प्रयोग गरेर खोल्नु पर्छ, र 2.png - GIMP प्रयोग गर्दै।

मा प्रयोग गरिएको क्रस-डेस्कटप विशिष्टताहरूको लागि भण्डारण स्थान GNOME, केडीई и Xfce freedesktop.org हो

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

फायरफक्सका विभिन्न संस्करणहरूका लागि आइकनहरू

म सोचिरहेको थिएँ कि लिनक्स संसारले Mac OS X बाट प्रणाली एकीकरणलाई बिगार्नबाट बच्न के सिक्न सक्छ। यदि तपाईंसँग समय छ र यसमा हुनुहुन्छ भने, पहिलो म्याक ओएस एक्स इन्जिनियरहरू मध्ये एक अर्नाउड गुरडोलले के भनेका थिए भनेर पढ्न निश्चित हुनुहोस्:

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

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 सत्र 144 - Mac OS X: प्याकेजिङ्ग अनुप्रयोगहरू र मुद्रण कागजातहरू।

लिनक्स डेस्कटपहरूमा यो पूर्वाधार जस्तो केहि छैन, त्यसैले हामी AppImage परियोजनामा ​​संरचनात्मक सीमितताहरू वरिपरि workarounds खोजिरहेका छौं।

के हाइकु उद्धारमा आउँदैछ?

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

2018 मा लिनक्स डेस्कटप वातावरणको समस्याहरूमा मेरो रिपोर्ट

लिनस टोर्भाल्ड्सले पनि स्वीकार गरे कि कार्यक्षेत्र विचार असफल भएको कारण विखंडन थियो।

हाइकु देख्दा खुसी लाग्यो!

हाइकुले सबै कुरालाई आश्चर्यजनक रूपमा सरल बनाउँछ

जबकि हाइकुमा AppImage लाई "पोर्टिङ" गर्ने सरल दृष्टिकोण भनेको यसको कम्पोनेन्टहरू (मुख्य रूपमा runtime.c र सेवा) निर्माण गर्ने प्रयास गर्नु हो (जुन सम्भव पनि हुन सक्छ!), यसले हाइकुलाई धेरै फाइदा प्रदान गर्दैन। किनभने वास्तवमा, यी धेरैजसो समस्या हाइकुमा हल हुन्छन् र वैचारिक रूपमा सही छन्। हाइकुले ठ्याक्कै प्रणाली पूर्वाधार निर्माण ब्लकहरू प्रदान गर्दछ जुन मैले लामो समयदेखि लिनक्स डेस्कटप वातावरणमा खोजिरहेको थिएँ र त्यहाँ थिएनन् भन्ने विश्वास गर्न सकिन। अर्थात्:

विश्वास गर्नुहोस् वा नगर्नुहोस्, यो केहि चीज हो जुन धेरै लिनक्स प्रयोगकर्ताहरूले पार गर्न सक्दैनन्। हाइकुमा सबै कुरा स्वतः हुन्छ!

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

दुई png फाइलहरू। दुईवटा क्लिक गर्दा फरक-फरक एप्लिकेसनहरूद्वारा खोलिनेछ भनी संकेत गर्ने बिभिन्न आइकनहरूलाई ध्यान दिनुहोस्। प्रयोगकर्ताले व्यक्तिगत एप्लिकेसन चयन गर्न सक्ने ड्रप-डाउन मेनुमा "खुल्ला:" लाई पनि ध्यान दिनुहोस्। कति सरल!

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

आखिर हाइकुलाई एप प्याकेज चाहिन्छ?

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

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

हाम्रो अन्तिम प्रयोगकर्तालाई हेरौं:

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

एक विकासकर्ता लेख्छन्:

मूलत: तर्क यो हो: प्रयोग केस यति दुर्लभ छ कि यसको लागि अनुकूलन गर्न अर्थ छैन; हाइकुपोर्टमा यसलाई विशेष मामलाको रूपमा व्यवहार गर्नु स्वीकार्य भन्दा बढी देखिन्छ।

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

विकासकर्ता टिप्पणी:

प्राविधिक रूपमा, यो पहिले नै माउन्ट आदेशको साथ सम्भव छ। अवश्य पनि, हामीसँग पर्याप्त चासो प्रयोगकर्ताहरू हुने बित्तिकै हामी यसको लागि GUI बनाउनेछौं।

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

एउटै Linux मा छेउछाउमा चलिरहेको AppImages को बहु संस्करणहरू

अनुप्रयोग विकासकर्ताको दृष्टिकोण

अनुप्रयोग विकासकर्ताको दृष्टिकोणबाट हेरौं:

• म सम्पूर्ण प्रयोगकर्ता अनुभव नियन्त्रण गर्न चाहन्छु। म कहिले र कसरी अनुप्रयोगहरू रिलिज गर्नुपर्छ भनेर मलाई बताउनको लागि अपरेटिङ सिस्टममा निर्भर हुन चाहन्न। हाइकुले विकासकर्ताहरूलाई आफ्नै hpkg भण्डारहरूसँग काम गर्न अनुमति दिन्छ, तर यसको मतलब प्रयोगकर्ताहरूले तिनीहरूलाई म्यानुअल रूपमा सेट अप गर्नुपर्नेछ, जसले विचारलाई "कम आकर्षक" बनाउँछ।
• मसँग मेरो वेबसाइटमा डाउनलोड पृष्ठ छ जहाँ म वितरण गर्छु .exe विन्डोज को लागी, .dmg म्याक र को लागि .AppImage लिनक्स को लागी। वा हुनसक्छ म यो पृष्ठमा पहुँच मुद्रीकरण गर्न चाहन्छु, केहि सम्भव छ? हाइकुको लागि त्यहाँ के राख्नु पर्छ? फाइल पर्याप्त छ .hpkg हाइकुपोर्ट्सबाट मात्र निर्भरता संग
• मेरो सफ्टवेयरलाई अन्य सफ्टवेयरको विशेष संस्करण चाहिन्छ। उदाहरणका लागि, यो ज्ञात छ कि Krita लाई Qt को प्याच गरिएको संस्करण चाहिन्छ, वा Qt जुन Krita को एक विशिष्ट संस्करणमा ठीक-ट्यून गरिएको छ, कम्तिमा प्याचहरूलाई Qt मा फिर्ता नपुगेसम्म। तपाइँ प्याकेज मा तपाइँको आवेदन को लागी तपाइँको आफ्नै Qt प्याकेज गर्न सक्नुहुन्छ .hpkg, तर सम्भवतः यो स्वागत छैन।

नियमित आवेदन डाउनलोड पृष्ठ। हाइकुको लागि मैले यहाँ के पोस्ट गर्नुपर्छ?

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

विकासकर्ताका अनुसार श्री। waddlesplash

लिनक्समा तिनीहरू (क्याटलग र एप्लिकेसन किटहरू, - लगभग। अनुवादक) सम्भवतः प्रणालीगत समस्याहरूको प्राविधिक समाधान हो। हाइकुमा हामी केवल प्रणाली समस्याहरू समाधान गर्न रुचाउँछौं।

तिम्रो के बिचार छ?

जवाफ दिनु अघि...

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

हाइकुमा एप डाइरेक्टरीहरू पहिले नै अवस्थित छन्, तर फाइल प्रबन्धकमा अझै समर्थित छैनन्

तिनीहरू केवल Macintosh Finder को रूपमा राम्रोसँग समर्थित छैनन्। यदि QtCreator डाइरेक्टरीमा माथिल्लो बायाँ कुनामा "QtCreator" नाम र आइकन भएको भए, डबल-क्लिक गर्दा अनुप्रयोग सुरू गर्दा कस्तो राम्रो हुनेछ?

अलि पहिले नै म सोध्यो:

के तपाइँ निश्चित हुनुहुन्छ कि तपाइँ आज तपाइँको दशक पुरानो एपहरू चलाउन सक्नुहुन्छ जब सबै एप स्टोरहरू र वितरण भण्डारहरूले तिनीहरू र तिनीहरूको निर्भरताहरू बिर्सिसकेका छन्? के तपाइँ विश्वस्त हुनुहुन्छ कि तपाइँ अझै पनि भविष्यमा तपाइँको हालको जागिर पहुँच गर्न सक्षम हुनुहुनेछ?

के हाइकुबाट पहिले नै जवाफ छ, वा क्याटलग र एप्लिकेसन बन्डलहरूले यहाँ मद्दत गर्न सक्छन्? मलाई लाग्छ तिनीहरूले सक्छन्।

उनका अनुसार श्री. waddlesplash:

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

त्यो पक्का हो!

हाइकुले कस्तो कदम चाल्नुपर्छ?

म hpkg, निर्देशिका र अनुप्रयोग छविहरूको शान्तिपूर्ण सहअस्तित्वको कल्पना गर्न सक्छु:

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

श्री। Waddlesplash लेख्छन्:

यदि तपाईलाई आवश्यक छ भने अनुप्रयोगहरू हेर्नु हो /system/apps, यसको सट्टामा हामीले डेस्कबारका डाइरेक्टरीहरूलाई प्रयोगकर्ताहरूका लागि अझ व्यवस्थित बनाउनु पर्छ /system/apps प्रयोगकर्ताहरू द्वारा नियमित रूपमा खोल्न र हेर्नको लागि अभिप्रेरित छैन (MacOS को विपरीत)। त्यस्ता परिस्थितिहरूको लागि, हाइकुको फरक प्रतिमान छ, तर यो विकल्प सैद्धान्तिक रूपमा स्वीकार्य छ।

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

मिस्टरबाट उद्धरण। waddlesplash:

बाह्य ड्राइभहरू वा नेटवर्क डाइरेक्टरीहरूबाट चलिरहेको अनुप्रयोगहरू सम्भावित रूपमा उपयोगी हुन सक्छ। र pkgman का लागि थप "क्षेत्रहरू" कन्फिगर गर्ने क्षमता थप्नु निश्चित रूपमा राम्रो सुविधा हुनेछ।

यस्तो प्रणालीले hpkg, डाइरेक्टरीहरू, र अनुप्रयोग छविहरूको फाइदा लिनेछ। तिनीहरू व्यक्तिगत रूपमा राम्रो छन्, तर तिनीहरू सँगै अजेय हुनेछन्।

निष्कर्षमा

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

आफैलाई प्रयास गर्नुहोस्! जे भए पनि, हाइकु परियोजनाले DVD वा USB बाट बुट गर्नका लागि छविहरू प्रदान गर्दछ ежедневно.
के तपाईंको कुनै प्रश्न छन्? हामी तपाईंलाई रूसी भाषा बोल्न आमन्त्रित गर्छौं टेलिग्राम च्यानल.

त्रुटि अवलोकन: C र C++ मा खुट्टामा आफैलाई कसरी गोली हान्ने। हाइकु ओएस रेसिपी संग्रह

बाट लेखक अनुवाद: यो हाइकुको शृङ्खलाको आठौं र अन्तिम लेख हो।

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

दर्ता भएका प्रयोगकर्ताहरूले मात्र सर्वेक्षणमा भाग लिन सक्छन्। साइन इन गर्नुहोस्कृपया

के यो लिनक्समा hpkg प्रणाली पोर्ट गर्न अर्थ बनाउँछ?

• हो

• कुनै

• पहिले नै लागू, म टिप्पणी मा लेख्नेछु

20 प्रयोगकर्ताहरूले मतदान गरे। 5 प्रयोगकर्ताहरू रोकिए।

स्रोत: www.habr.com