🥇 हाइकु संग मेरो छैटौं दिन: संसाधन, प्रतिमा र प्याकेज को हुड अन्तर्गत

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

हालै मैले हाइकु पत्ता लगाए, एक अप्रत्याशित रूपमा राम्रो प्रणाली। विशेष गरी लिनक्स डेस्कटप वातावरणको तुलनामा यो कत्तिको सहज रूपमा चल्छ भनेर म अझै छक्क परेको छु। आज म हुड मुनि हेर्नेछु। जहाँ गहिरो बुझाइको लागि आवश्यक छ, म मौलिक Macintosh, Mac OS X र Linux डेस्कटप वातावरणहरू (freedesktop.org बाट XDG मानक) सँग तुलना गर्नेछु।

ELF फाइलहरूमा स्रोतहरू

हिजो मैले IconOMatic ले ELF कार्यान्वयनयोग्यहरूमा rdef संसाधनहरूमा आइकनहरू बचत गर्न सक्छ भनी सिकें। आज म हेर्न चाहन्छु कि यो कसरी काम गर्दछ।

स्रोतहरू? उद्धरण देखि ब्रुस हर्न, Macintosh Finder को मूल लेखक र Macintosh संसाधन प्रबन्धक को "बुवा":

म परम्परागत कोडिङको कठोर प्रकृतिको बारेमा चिन्तित छु। मेरो लागि, गतिशील रूपमा केहि परिवर्तन गर्न सक्ने क्षमता बिना, कोडमा जमेको एप्लिकेसनको विचार सबैभन्दा जंगली बर्बरता हो। यो रनटाइम मा सकेसम्म धेरै परिवर्तन गर्न सम्भव हुनुपर्छ। निस्सन्देह, अनुप्रयोग कोड आफैं परिवर्तन गर्न सकिँदैन, तर निश्चित रूपमा कोड पुन: कम्पाइल नगरी केहि परिवर्तन गर्न सकिन्छ?

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

Mac मा यो प्रयोग गरिन्छ पुन: सम्पादन गर्नुहोस्, अचानक - सम्पादन स्रोतहरूको लागि ग्राफिकल कार्यक्रम।

मूल Macintosh मा पुन: सम्पादन गर्नुहोस्

नतिजाको रूपमा, आइकनहरू, मेनु वस्तुहरू, अनुवादहरू, आदि सम्पादन गर्न सम्भव भयो। पर्याप्त सजिलो, तर तिनीहरू अझै पनि अनुप्रयोगहरूसँग "यात्रा" गर्छन्।
जे भए पनि, यो दृष्टिकोणमा ठूलो कमजोरी थियो: यसले एप्पल फाइल प्रणालीहरूमा मात्र काम गर्‍यो, जुन म्याक ओएस एक्समा सर्दा एप्पलले "संसाधन खण्ड" त्याग्नुको एउटा कारण थियो।
Mac OS X मा, एप्पलले फाइल प्रणाली-स्वतन्त्र समाधान चाहन्थे, त्यसैले तिनीहरूले प्याकेजहरूको अवधारणा (NEXT बाट), डाइरेक्टरीहरूलाई अपनाए जसलाई फाइल प्रबन्धकद्वारा "अपारदर्शी वस्तुहरू" को रूपमा व्यवहार गरिन्छ, जस्तै डाइरेक्टरीहरू भन्दा फाइलहरू। ढाँचामा अनुप्रयोगको साथ कुनै पनि प्याकेज .app अन्य चीजहरूको बीचमा, एउटा फाइल छ Info.plist (एप्पलको JSON वा YAML को बराबरको कुनै प्रकारमा) अनुप्रयोग मेटाडेटा समावेश गर्दछ।

Mac OS X अनुप्रयोग प्याकेजबाट Info.plist फाइलका लागि कुञ्जीहरू।

स्रोतहरू, जस्तै आइकनहरू, UI फाइलहरू, र अन्य, प्याकेजमा फाइलहरूको रूपमा भण्डारण गरिन्छ। अवधारणा वास्तवमा नेक्स्टमा यसको जराहरूमा फर्कियो।

1.0 मा NeXTSTEP 1989 मा Mathematica.app: टर्मिनलमा फाइलहरूको डाइरेक्टरीको रूपमा देखिन्छ, तर ग्राफिकल फाइल प्रबन्धकमा एकल वस्तुको रूपमा।

BeOS मा फर्कौं, हाइकुमा आधारित अवधारणाहरू। यसको विकासकर्ताहरूले PEF (PowerPC) बाट ELF (x86) मा स्विच गर्दा (Linux मा प्रयोग गरिए जस्तै), ELF फाइलहरूको अन्त्यमा स्रोत खण्ड थप्ने निर्णय गरे। यसले आफ्नै उचित ELF खण्ड प्रयोग गर्दैन, यो केवल ELF फाइलको अन्त्यमा जोडिएको थियो। कार्यक्रमको फलस्वरूप strip र binutils बाट अरू, यो थाहा छैन, बस यसलाई काट्नुहोस्। त्यसकारण, BeOS मा ELF फाइलमा स्रोतहरू थप्दा, यसलाई लिनक्स उपकरणहरूसँग हेरफेर नगर्नु राम्रो हुन्छ।

हाइकुमा अहिले के भइरहेको छ ? सामान्यतया, कम वा कम समान।

सिद्धान्तमा, यो ELF को इच्छित खण्डमा स्रोतहरू राख्न सम्भव हुनेछ। irc.freenode.net मा #haiku च्यानलमा विकासकर्ताहरूका अनुसार:

ELF को साथ खण्डले अझ अर्थपूर्ण बनाउनेछ... हामीले यसलाई त्यसरी नगरेको एउटै कारण हो किनभने हामीले BeOS मा गरेका थियौं।"
र अब यसलाई परिवर्तन गर्नुको कुनै मतलब छैन।

स्रोत व्यवस्थापन

संसाधनहरू एक संरचित "संसाधन" ढाँचामा लेखिएका छन्: अनिवार्य रूपमा आकारहरू र त्यसपछि तिनीहरूको सामग्रीको स्रोतहरूको सूची। याद आयो ar ढाँचा.
हाइकुमा स्रोतहरू कसरी जाँच गर्ने? त्यहाँ ResEdit जस्तै केहि छ?
अनुसार कागजात:

एप्लिकेसन प्याकेजमा प्रदान गरिएका स्रोतहरू हेर्नको लागि, तपाईंले कार्यान्वयनयोग्य फाइललाई जस्तै प्रोग्राममा तान्न सक्नुहुन्छ रिसोर्सर। तपाईं टर्मिनलमा गएर आदेश चलाउन पनि सक्नुहुन्छ listres имя_файла.

Resourcer HaikuDepot मा उपलब्ध छ, तर यो मेरो लागि मात्र क्र्यास हुन्छ।

ELF फाइलहरूमा स्रोतहरू कसरी व्यवस्थापन गर्ने? प्रयोग गर्दै rsrc и rdef. rdef फाइलहरू सङ्कलन गरिन्छ rsrc। फाइल rdef सादा पाठ ढाँचामा भण्डारण गरिएको छ, त्यसैले यो काम गर्न धेरै सजिलो छ। फाइल ढाँचा rsrc ELF फाइलको अन्त्यमा जोडिएको छ। खेल्ने प्रयास गरौं:

~> rc -h
Haiku Resource Compiler 1.1To compile an rdef script into a resource file:
    rc [options] [-o <file>] <file>...To convert a resource file back into an rdef script:
    rc [options] [-o <file>] -d <file>...Options:
    -d --decompile       create an rdef script from a resource file
       --auto-names      construct resource names from ID symbols
    -h --help            show this message
    -I --include <dir>   add <dir> to the list of include paths
    -m --merge           do not erase existing contents of output file
    -o --output          specify output file name, default is out.xxx
    -q --quiet           do not display any error messages
    -V --version         show software version and license

तपाईं कार्यक्रम प्रयोग गर्न सक्नुहुन्छ xres जाँच र नियन्त्रणको लागि:

/> xres
Usage: xres ( -h | --help )
       xres -l <file> ...
       xres <command> ...The first form prints this help text and exits.The second form lists the resources of all given files.The third form manipulates the resources of one or more files according to
the given commands.
(...)

ठीक छ, प्रयास गरौं?

/> xres -l /Haiku/system/apps/WebPositive/Haiku/system/apps/WebPositive resources:type           ID        size  name
------ ----------- -----------  --------------------
'MIMS'           1          36  BEOS:APP_SIG
'APPF'           1           4  BEOS:APP_FLAGS
'MSGG'           1         421  BEOS:FILE_TYPES
'VICN'         101        7025  BEOS:ICON
'VICN'         201          91  kActionBack
'VICN'         202          91  kActionForward
'VICN'         203         300  kActionForward2
'VICN'         204         101  kActionStop
'VICN'         206         243  kActionGoStart
'MSGG'         205        1342  kActionGo
'APPV'           1         680  BEOS:APP_VERSION

स्रोत र ढाँचा बारे थप rdef तपाईं पढ्न सक्नुहुन्छ यहाँ.

मानक स्रोत प्रकारहरू

यद्यपि तपाइँ स्रोतहरूमा केहि पनि राख्न सक्नुहुन्छ, त्यहाँ केहि परिभाषित मानक प्रकारहरू छन्:

app_signature: MIME अनुप्रयोग प्रकार, फाइल खुला म्यापिङको लागि, प्रक्षेपण, IPC, आदि।
app_name_catalog_entry: अनुप्रयोगको नाम सामान्यतया अङ्ग्रेजीमा भएको हुनाले, तपाईंले अनुवाद गरिएका नामहरू अवस्थित भएका ठाउँहरू निर्दिष्ट गर्न सक्नुहुन्छ, ताकि विभिन्न भाषाका प्रयोगकर्ताहरूले चाहेमा अनुवादित अनुप्रयोगको नाम देख्न सक्नेछन्।
app_version: ठ्याक्कै तपाईले सोचेको कुरा
app_flags: संकेत गर्दछ registrar आवेदन प्रक्रिया कसरी गर्ने। मलाई लाग्छ यसमा आँखा भेट्नु भन्दा पनि धेरै छ। उदाहरणका लागि, त्यहाँ छ B_SINGLE_LAUNCH, जसले प्रणालीलाई प्रत्येक पटक प्रयोगकर्ताले अनुरोध गर्दा नयाँ अनुप्रयोग प्रक्रिया सुरु गर्न बाध्य पार्छ (लिनक्समा धेरैजसो अनुप्रयोगहरूको लागि समान सिद्धान्त प्रयोग गरिन्छ)। खानुहोस् B_MULTIPLE_LAUNCH, प्रक्रिया चलाउन को लागी प्रत्येक फाइल। अन्ततः त्यहाँ छ B_EXCLUSIVE_LAUNCH, जसले प्रणालीलाई एक पटकमा एउटा मात्र प्रक्रिया सुरु गर्न बाध्य पार्छ, प्रयोगकर्ताहरूले यसलाई जतिसुकै पटक लन्च गरे पनि (उदाहरणका लागि, यसरी लिनक्समा फायरफक्स चल्छ; प्रकार्य प्रयोग गरेर Qt अनुप्रयोगहरूमा समान परिणाम प्राप्त गर्न सकिन्छ। QtSingleApplication)। संग आवेदनहरू B_EXCLUSIVE_LAUNCH प्रयोगकर्ताले तिनीहरूलाई फेरि चलाउन खोज्दा सूचित गरिन्छ: उदाहरणका लागि, तिनीहरूले फाइलको मार्ग प्राप्त गर्छन् जुन प्रयोगकर्ताले उनीहरूको मद्दतमा खोल्न चाहन्छ।
vector_icon: भेक्टर एप्लिकेसन आइकन (BeOS सँग भेक्टर आइकनहरू थिएनन्, धेरै जसो अनुप्रयोगहरूको सट्टा तिनीहरूको कार्यान्वयनयोग्य फाइलहरूमा दुईवटा रास्टर आइकनहरू थिए)।

निस्सन्देह, तपाइँ कुनै पनि इच्छित आईडी र प्रकारहरूसँग स्रोतहरू थप्न सक्नुहुन्छ, र त्यसपछि कक्षा प्रयोग गरेर अनुप्रयोगमा वा अन्य अनुप्रयोगहरूमा पढ्न सक्नुहुन्छ। BResources। तर पहिले, आइकनहरूको आकर्षक विषयलाई हेरौं।

हाइकु शैलीमा भेक्टर आइकनहरू

निस्सन्देह, हाइकुले उत्कृष्ट आइकन ढाँचा मात्र छनौट गर्दैन; यस भागमा, लिनक्स डेस्कटप वातावरणको अवस्था आदर्शबाट टाढा छ:

me@host:~$ ls /usr/share/icons/hicolor/
128x128  256x256  512x512           index.theme
160x160  28x28    64x64             scalable
16x16    32x32    72x72             symbolic
192x192  36x36    8x8
22x22    42x42    96x96
24x24    48x48    icon-theme.cache

यसलाई हेर्दा तपाईले पहिले नै महसुस गर्न सक्नुहुन्छ कि यो कस्तो टुक्रा हो।

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

me@host:~$ find /usr/share/icons/ -name 'firefox.*'
/usr/share/icons/HighContrast/16x16/apps/firefox.png
/usr/share/icons/HighContrast/22x22/apps/firefox.png
/usr/share/icons/HighContrast/24x24/apps/firefox.png
/usr/share/icons/HighContrast/256x256/apps/firefox.png
/usr/share/icons/HighContrast/32x32/apps/firefox.png
/usr/share/icons/HighContrast/48x48/apps/firefox.png
/usr/share/icons/elementary-xfce/apps/128/firefox.png
/usr/share/icons/elementary-xfce/apps/16/firefox.png
/usr/share/icons/elementary-xfce/apps/22/firefox.png
/usr/share/icons/elementary-xfce/apps/24/firefox.png
/usr/share/icons/elementary-xfce/apps/32/firefox.png
/usr/share/icons/elementary-xfce/apps/48/firefox.png
/usr/share/icons/elementary-xfce/apps/64/firefox.png
/usr/share/icons/elementary-xfce/apps/96/firefox.png
/usr/share/icons/hicolor/128x128/apps/firefox.png

कृपया ध्यान दिनुहोस्: फायरफक्सको विभिन्न संस्करणहरूको कुनै अवधारणा छैन। तसर्थ, प्रणालीमा एप्लिकेसनको धेरै संस्करणहरू भएको अवस्थालाई अनुग्रहपूर्वक ह्यान्डल गर्न सम्भव छैन।

विभिन्न संस्करणहरूमा फरक फायरफक्स आइकनहरू। लिनक्समा विभिन्न बैसाखी बिना यसलाई ह्यान्डल गर्न हाल असम्भव छ।

Mac OS X ले यसलाई अलि बढी सूक्ष्म रूपमा ह्यान्डल गर्छ:

Mac:~ me$ find /Applications/Firefox.app | grep icns
/Applications/Firefox.app/Contents/MacOS/crashreporter.app
/Contents/Resources/crashreporter.icns
/Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns
/Applications/Firefox.app/Contents/Resources/document.icns
/Applications/Firefox.app/Contents/Resources/firefox.icns

यो देख्न सकिन्छ कि त्यहाँ एउटा फाइल छ firefox.icns प्याकेज मा Firefox.app, सबै आकारहरू समावेश गर्दछ ताकि एउटै अनुप्रयोगको विभिन्न संस्करणहरूमा फरक आइकनहरू छन्।
धेरै राम्रो! आइकनहरू अनुप्रयोगको साथ यात्रा गर्दछ, सबै स्रोतहरू एक फाइलमा छन्।

हाइकुमा फर्कौं। एक दिमाग उडाउने समाधान, कुनै अपवाद छैन। यस अनुसार कागजात:

एक विशेष HVIF ढाँचा, सानो आकार र छिटो रेन्डरिङको लागि अत्यधिक अनुकूलित, विकसित गरिएको थियो। त्यसकारण, हाम्रा आइकनहरू धेरैजसो भागका लागि रास्टर वा व्यापक रूपमा प्रयोग हुने SVG ढाँचामा भन्दा धेरै सानो छन्।

र तिनीहरू अझै पनि अनुकूलित छन्:

अन्य ढाँचाहरूको तुलनामा HVIF मा आइकन आकारहरू।

भिन्नता परिमाणको क्रम हो!

तर जादू यहाँ समाप्त हुँदैन। एउटै HVIF ले भेक्टर ढाँचा भए तापनि प्रदर्शित आकारको आधारमा विभिन्न स्तरका विवरणहरू देखाउन सक्छ।

रेन्डर साइजमा निर्भर गर्दै विभिन्न स्तरको विवरण (LOD)

अब बेफाइदाहरूको बारेमा: तपाइँ SVG लिन सक्नुहुन्न, यसलाई ImageMagick मा फ्याँक्नुहोस् र यसलाई एक दिन कल गर्नुहोस्; तपाईंले HVIF ढाँचामा आइकन सिर्जना गर्न धेरै चक्रहरू पार गर्नुपर्नेछ। यहाँ स्पष्टीकरणहरू। यद्यपि, IconOMatic ले SVG लाई अपूर्ण रूपमा आयात गर्न सक्छ; लगभग 90% SVG विवरणहरू केही सम्भाव्यताका साथ आयात गरिएका छन्, बाँकी 10% कन्फिगर र म्यानुअल रूपमा परिवर्तन गर्न आवश्यक हुनेछ। HVIF ले कसरी जादू गर्छ भन्ने बारे थप पढ्नुहोस् गर्न सक्छन् ब्लग मा लेह गान्सन

अनुप्रयोगमा आइकन थप्दै

अब म सिर्जना गरिएको प्याकेजमा आइकन थप्न सक्छु अन्तिम पटक, प्राप्त सबै जानकारीलाई ध्यानमा राख्दै।
ठिक छ, किनकि म अहिले मेरो "हेलो, वर्ल्ड" QtQuickApp को लागि मेरो आफ्नै आइकन कोर्न विशेष उत्सुक छैन, म यसलाई Qt क्रिएटरबाट बाहिर निकाल्छु।

/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt Creator  -o /Haiku/home/QtQuickApp/QtQuickApp  -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt Creator

आइकन प्रतिलिपि गरिएको छ कि छैन जाँच गरौं:

/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type           ID        size  name
------ ----------- -----------  --------------------
'VICN'         101      152238  BEOS:ICON

राम्रो देखिन्छ, तर किन यो नयाँ आइकन प्रतिलिपि हुँदा यो देखा पर्दैन?

प्रतिलिपि गरिएको VICN:101:BEOS:ICONs अझै फाइल प्रबन्धकमा एप्लिकेसन आइकनको रूपमा प्रयोग गरिएको छैन।

मैले के मिस गरेँ?

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

हामीले एउटा फाइल बनाउनु पर्छ rdef सबै स्रोतहरूसँग, त्यसपछि आदेश कार्यान्वयन गर्नुहोस् rc имя.rdef, यसले फाइल सिर्जना गर्नेछ .rsrc। त्यसपछि तपाईंले आदेश चलाउन आवश्यक छ resattr -o имя_бинарника имя.rsrc। कम्तिमा, म मेरो स्क्रिप्टहरूमा आइकनहरू थप्न यी जस्ता आदेशहरू प्रयोग गर्छु।

ठिक छ, म स्रोत सिर्जना गर्न चाहन्थे, विशेषता होइन। म साँच्चै अलमलमा छु।

फाइल प्रणाली प्रयोग गरेर स्मार्ट क्यासिङ

ELF विशेषताहरू खोल्न र पढ्न ढिलो छ। मैले माथि लेखेको रूपमा, प्रतिमा फाइलमा स्रोतको रूपमा लेखिएको छ। यो विधि अधिक भरपर्दो छ र तपाईंलाई अर्को फाइल प्रणालीमा प्रतिलिपि गर्न बाँच्न अनुमति दिन्छ। यद्यपि, यो पनि फाइल प्रणाली विशेषतामा प्रतिलिपि गरिएको छ, उदाहरणका लागि BEOS:ICON। यसले BFS जस्ता निश्चित फाइल प्रणालीहरूमा मात्र काम गर्छ। प्रणालीद्वारा देखाइएका आइकनहरू (ट्रयाकर र डेस्कबारमा) यस विस्तारित विशेषताबाट पढिन्छन्, किनभने यो समाधानले छिटो काम गर्छ। केही स्थानहरूमा (जहाँ गति महत्त्वपूर्ण छैन, उदाहरणका लागि, एक सामान्य "बारेमा" विन्डो), प्रणालीले फाइलमा स्रोतबाट सीधै प्रतिमा प्राप्त गर्दछ। तर यो अन्त्य होइन। याद गर्नुहोस्, म्याकमा, प्रयोगकर्ताहरूले अनुप्रयोगहरू, डाइरेक्टरीहरू, कागजातहरूको आइकनहरू आफ्नैसँग बदल्न सक्छन्, किनकि म्याकमा यी "महत्वपूर्ण" चीजहरू गर्न सम्भव छ, उदाहरणका लागि। अघिल्लोको साथ नयाँ स्ल्याक आइकन प्रतिस्थापन गर्दै। हाइकुमा, तपाईंले स्रोत (फाइलमा) लाई एप्लिकेसनसँग आउने मूल आइकनको रूपमा र विशेषता (BFS फाइल प्रणालीमा) लाई प्रयोगकर्ताले इच्छा अनुसार परिवर्तन गर्न अनुमति दिने कुराको रूपमा सोच्नुपर्छ (यद्यपि, संकेत, प्रतिमाको शीर्षमा अनुकूलन प्रतिमा सम्मिलित गर्नको लागि GUI वैकल्पिक छ। अझै पूर्वनिर्धारित रूपमा लागू गरिएको छैन)।

फाइल प्रणाली विशेषताहरू जाँच गर्दै

सहयोगको साथ resaddr फाइल प्रणाली विशेषताहरू जाँच गर्न र सेट गर्न सम्भव छ।

/> resattr
Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ]

Reads resources from zero or more input files and adds them as attributes
to the specified output file, or (in reverse mode) reads attributes from
zero or more input files and adds them as resources to the specified output
file. If not existent the output file is created as an empty file.
(...)

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

hpkg प्याकेजहरूको जादू

हाल (अधिकतर) प्याकेजहरू हाइकुमा कार्यक्रमहरू प्राप्त गर्न प्रयोग गरिन्छ .hpkg। साधारण नामबाट मूर्ख नबन्नुहोस्: .hpkg ढाँचाले तपाईंले सामना गर्नुभएका समान नामहरूका अन्य ढाँचाहरू भन्दा पूर्ण रूपमा फरक काम गर्दछ, यसमा वास्तविक महाशक्तिहरू छन्।

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

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

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

KERN: package_daemon [16042853:   924] active package: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023:   924] active package: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232:   924] active package: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405:   924] active package: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611:   924] active package: "llvm_libs-5.0.0-3-x86_64.hpkg"

राम्रो, हो? त्यहाँ बस्नुहोस्, यो अझ चिसो हुनेछ!

त्यहाँ एक धेरै विशेष प्याकेज छ:

KERN: package_daemon [16040020:   924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"

यसले कर्नेल सहित धेरै न्यूनतम अपरेटिङ सिस्टम समावेश गर्दछ। विश्वास गर्नुहोस् वा नगर्नुहोस्, बुट भोल्युम (रूट विभाजन) बाट कर्नेल पनि हटाइएको छैन, तर प्याकेजबाट यसको स्थानमा सावधानीपूर्वक लोड गरिएको छ। .hpkg। वाह! मैले पहिले नै उल्लेख गरिसकेको छु कि हाइकुको समग्र परिष्कार र स्थिरताको अंश कर्नेल र कोर प्रयोगकर्ता स्थानदेखि प्याकेज व्यवस्थापन र रनटाइम पूर्वाधारसम्मको सम्पूर्ण प्रणाली एउटै टोलीद्वारा सहकार्यमा विकसित भएको तथ्यबाट आएको हो। कल्पना गर्नुहोस् कि लिनक्समा यस्तो केहि चलाउन कति फरक समूह र टोलीहरू लिनेछन् [म पप्पीलिनक्स परियोजनाको कल्पना गर्छु - लगभग। अनुवादक]। त्यसोभए कल्पना गर्नुहोस् कि यो दृष्टिकोणलाई वितरणमा अपनाउन कति समय लाग्नेछ। तिनीहरू भन्छन्: एक साधारण समस्या लिनुहोस्, यसलाई विभिन्न कलाकारहरू बीच विभाजित गर्नुहोस्, र यो यति जटिल हुनेछ कि यो अब समाधान गर्न सम्भव छैन। यस अवस्थामा हाइकुले मेरो आँखा खोल्यो। मलाई लाग्छ कि यो लिनक्समा अहिले के भइरहेको छ (यस अवस्थामा लिनक्स लिनक्स/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu स्ट्याकको लागि सामूहिक शब्द हो)।

hpkg प्रयोग गरेर प्रणाली रोलब्याक

निम्न अवस्था कति पटक हुन्छ: अद्यावधिक सफल भयो, र त्यसपछि यो बाहिर जान्छ कि केहि काम गरिरहेको छैन जस्तो कि यो गर्नुपर्छ? यदि तपाइँ परम्परागत प्याकेज प्रबन्धकहरू प्रयोग गर्नुहुन्छ भने, नयाँ प्याकेजहरू स्थापना हुनु अघि प्रणालीको स्थितिलाई एक बिन्दुमा फर्काउन गाह्रो हुन्छ (उदाहरणका लागि, केहि गलत भएको घटनामा)। केही प्रणालीहरूले फाइल प्रणाली स्न्यापशटहरूको रूपमा समाधान प्रस्ताव गर्दछ, तर तिनीहरू धेरै बोझिलो हुन्छन् र सबै प्रणालीहरूमा प्रयोग हुँदैनन्। हाइकुले प्याकेजहरू प्रयोग गरेर यसलाई समाधान गर्दछ .hpkg। प्रणालीमा प्याकेजहरू परिवर्तन हुँदा, पुराना प्याकेजहरू मेटाइँदैन, तर प्रणालीमा उपनिर्देशिकाहरूमा भण्डारण गरिन्छ। /Haiku/system/packages/administrative/state-<...>/ लगातार। अधूरा कार्यहरूले उपनिर्देशिकाहरूमा तिनीहरूको डाटा भण्डारण गर्दछ /Haiku/system/packages/administrative/transaction-<...>/.

सामाग्री /Haiku/system/packages/administrative। "राज्य..." डाइरेक्टरीहरूले सक्रिय प्याकेजहरूको नामसहितको पाठ फाइलहरू समावेश गर्दछ, र "लेनदेन..." डाइरेक्टरीहरूले प्याकेजहरू आफैंमा समावेश गर्दछ।

"पुरानो सक्रिय राज्य", अर्थात् सूची .hpkg पाठ फाइलमा फाइल प्रबन्धकमा प्रत्येक अपरेशन पछि परिवर्तनहरू रेकर्ड हुनु अघि सक्रिय प्याकेजहरू /Haiku/system/packages/administrative/state-<...>/activated-packages। त्यस्तै गरी, नयाँ "सक्रिय अवस्था" पाठ फाइलमा लेखिएको छ /Haiku/system/packages/administrative/activated-packages.

निर्देशिका /Haiku/system/packages/administrative/state-<...>/ यस राज्यको सक्रिय प्याकेजहरूको सूची भएको पाठ फाइल मात्र समावेश गर्दछ (हटाउन बिना प्याकेजहरूको स्थापनाको अवस्थामा), र यदि प्याकेजहरू हटाइयो वा अद्यावधिक गरियो भने - राज्य निर्देशिकाले प्याकेजहरूको पुरानो संस्करणहरू समावेश गर्दछ।

जब प्रणाली बुट हुन्छ, प्याकेजहरूको सूचीमा आधारित, प्याकेजहरू (माउन्ट) सक्रिय गर्ने निर्णय गरिन्छ। यो एकदम सरल छ! यदि डाउनलोड गर्दा केही गलत भयो भने, तपाईंले डाउनलोड प्रबन्धकलाई फरक, पुरानो सूची प्रयोग गर्न भन्न सक्नुहुन्छ। समस्या समाधान भयो!

हाइकु डाउनलोडर। प्रत्येक प्रविष्टि बिन्दुले सम्बन्धित "सक्रिय अवस्था" देखाउँछ।

मलाई सरल पाठ फाइलहरू "सक्रिय अवस्था" सूचीको रूपमा राख्ने दृष्टिकोण मनपर्छ, नामहरू जुन बुझ्न सजिलो छ .hpkg। यो मेसिनहरूका लागि-मानिसहरूको लागि होइन-बनाईएको विपरीत हो। एक गुच्छा मा फाइल प्रणालीमा OSTree वा Flatpak बाट (Microsoft GUID को समान स्तरमा)।

समयमा प्रत्येक बिन्दुको लागि सक्रिय प्याकेजहरूको सूची

कन्फिगरेसन डाटा

स्पष्ट रूपमा, सूचीमा /Haiku/system/packages/administrative/writable-files प्याकेजहरूको लागि कन्फिगरेसन फाइलहरू समावेश गर्दछ, तर तिनीहरू लेख्न योग्य छन्। आखिर, तपाईलाई सम्झना अनुसार, .hpkg पढ्नका लागि मात्र माउन्ट गरिएको। त्यसैले यी फाइलहरू लेख्नु अघि प्याकेजहरूबाट प्रतिलिपि गर्नुपर्छ। अर्थ छ।

.hpkg प्रणालीको लागि GUI एकीकरण

अब हेरौं यी चम्किलो झोलाहरू .hpkg प्रयोगकर्ताको कार्य वातावरण (UX) मा एकीकरण संग सामना। आखिर, हाइकु व्यक्तिगत प्रयोगको लागि हो। व्यक्तिगत रूपमा, मैले प्याकेजहरूसँग प्रयोगकर्ता अनुभव तुलना गर्दा बार उच्च सेट गर्छु .app Macintosh मा उही अनुभव संग .hpkg। म स्थितिलाई लिनक्समा काम गर्ने वातावरणसँग तुलना पनि गर्दिन, किनकि यो अरूको तुलनामा एकदमै भयानक छ।

निम्न परिदृश्यहरू दिमागमा आउँछन्:

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

यसले मेरो दैनिक कामबाट धेरै जसो प्रमुख केसहरू कभर गर्नुपर्दछ। खैर, सुरु गरौं।

प्याकेज सामग्रीहरू जाँच गर्दै

На म्याक म यसलाई खोल्न र खोजकर्तामा सामग्रीहरू हेर्न प्याकेजमा दायाँ क्लिक गर्छु। आखिर, वास्तवमा यो केवल एक प्रच्छन्न डाइरेक्टरी हो! (मलाई थाहा छ त्यहाँ प्याकेजहरू छन् .pkg प्रणालीको एक भागको लागि जुन अनुप्रयोगहरू होइनन्, तर साधारण प्रयोगकर्ताहरू प्रायः तिनीहरूसँग अन्तर्क्रिया गर्दैनन्)।

हाइकु मा म प्याकेजमा दायाँ क्लिक गर्छु, त्यसपछि भित्र के छ भनेर हेर्न "सामग्री" मा क्लिक गर्नुहोस्। तर यहाँ दुईवटा क्लिक गरेर खोल्ने क्षमता बिना फाइलहरूको सूची मात्र छ।
प्याकेज (अस्थायी रूपमा) माउन्ट गर्ने तरिका हो भने यो धेरै राम्रो हुनेछ .hpkg फाइल प्रबन्धक मार्फत हेर्नको लागि, र प्रयोगकर्ताले कार्यान्वयन विवरणहरूको बारेमा चिन्ता लिनु पर्दैन। (वैसे, तपाईं खोल्न सक्नुहुन्छ .hpkg प्याकेज मा Expander, जसले यसलाई कुनै अन्य संग्रह जस्तै अनप्याक गर्न सक्छ)।

HaikuDepot को इन्टरफेसले तपाईंलाई प्याकेज फाइलहरूको सूची हेर्न अनुमति दिन्छ, तर त्यहाँ सामग्रीहरू हेर्ने कुनै तरिका छैन, उदाहरणका लागि, README.md डबल-क्लिक गरेर।

म्याकले यस कोटीमा जित्छ, तर तपाईले चाहानु भएको हाइकुडिपोट कार्यक्षमता थप्न धेरै गाह्रो हुनु हुँदैन।

GUI मार्फत प्याकेज स्थापना गर्दै

На म्याक, धेरै डिस्क छविहरू .dmg प्याकेजहरू समावेश छन् .app। डिस्क छविमा डबल-क्लिक गर्नुहोस् र त्यसपछि प्याकेज प्रतिलिपि गर्नुहोस्, उदाहरणका लागि, यसलाई ड्र्याग गरेर /Applications खोजकर्ता मा। यो मेरो लागि नभन्दै जान्छ, तर मैले सुनेको छु कि केहि newbies यसलाई ह्यान्डल गर्न सक्षम नहुन सक्छ। पूर्वनिर्धारित रूपमा, एप्पलले प्रणाली-व्यापी डाइरेक्टरी "सुझाव" दिन्छ /Applications (NEXT मा यो व्यक्तिगत रूपमा नेटवर्क गरिएको थियो), तर तपाइँ सजिलैसँग तपाइँको अनुप्रयोगहरू फाइल सर्भर वा उपनिर्देशिकामा राख्न सक्नुहुन्छ। $HOME/Applications, यदि तपाईंलाई यो मनपर्छ भने।

हाइकु मा, प्याकेजमा डबल क्लिक गर्नुहोस्, त्यसपछि "स्थापना गर्नुहोस्" मा क्लिक गर्नुहोस्, यो सजिलो हुन सक्दैन। म सोचिरहेको छु कि के हुन्छ यदि प्याकेजमा हाइकुपोर्टमा उपलब्ध रहेका तर अझै स्थापित नभएका निर्भरताहरू छन्। लिनक्समा उनीहरूलाई यस अवस्थामा के गर्ने भनेर वास्तवमै थाहा छैन, तर समाधान स्पष्ट छ - प्रयोगकर्तालाई सोध्नुहोस् कि उनीहरूले निर्भरताहरू डाउनलोड र स्थापना गर्न आवश्यक छ कि छैन। ठ्याक्कै के हाइकु गर्छ।

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

अर्को तरिका भनेको फाइल प्रबन्धक प्रयोग गर्नु हो, केवल तान्नुहोस् र छोड्नुहोस् .hpkg प्याकेज वा भित्र /Haiku/system/packages (प्रणाली-व्यापी स्थापनाको लागि, पूर्वनिर्धारित रूपमा), वा भित्र /Haiku/home/config/packages (व्यक्तिगत स्थापनाको लागि; डबल-क्लिक गर्दा उपलब्ध छैन - म अझै पनि यस ठाउँमा "कन्फिग" शब्दबाट रिसाएको छु, जुन यस अवस्थामा मेरो लागि "सेटिङ्स" को पर्यायवाची हो)। र हाइकुको लागि धेरै प्रयोगकर्ताहरूको अवधारणा अझै उपलब्ध छैन (त्यसैले सायद यो धेरै सरल छ - मलाई थाहा छैन, बहु-प्रयोगकर्ता क्षमताहरूले अनावश्यक रूपमा डेस्कटप डेस्कटप वातावरणको लागि चीजहरू जटिल बनाउँदछ)।

हाइकु यस श्रेणीमा जित्छ किनभने यसले अनुप्रयोगहरूमा मात्र होइन, प्रणाली कार्यक्रमहरूमा पनि काम गर्न सक्छ।

GUI बाट प्याकेज हटाउँदै

На म्याक, तपाईंले रद्दीको टोकरीमा अनुप्रयोग आइकन तान्नु आवश्यक छ, र यति मात्र हो। सजिलै!

हाइकु मा, सर्वप्रथम, तपाइँले प्रणालीमा प्याकेज कहाँ अवस्थित छ भनेर पत्ता लगाउन आवश्यक छ, किनकि तपाइँ विरलै यसलाई सही ठाउँमा स्थापना गर्नुहुन्छ (प्रणालीले सबै गर्छ)। सामान्यतया तपाईले भित्र हेर्नु पर्छ /Haiku/system/packages (प्रणाली-व्यापी पूर्वनिर्धारित स्थापनाको साथ), वा भित्र /Haiku/home/config/packages (के मैले उल्लेख गरें कि "कन्फिग" एक गलत नाम हो?) त्यसपछि अनुप्रयोगलाई रद्दीटोकरीमा तानिन्छ, र त्यो हो।
सजिलै! तर, म त्यो भन्दिनँ । यहाँ साँच्चै के भइरहेको छ:

यदि तपाइँ रद्दीटोकरीमा एउटा अनुप्रयोग तान्नु भयो भने यो के हुन्छ /Haiku/system/packages

QtQuickApp मा रहेको मेरो हिजोको एप्लिकेसन "Hello World" लाई रद्दीटोकरीमा सार्ने प्रयास गरेको छु। मैले प्रणाली डाइरेक्टरी सार्न प्रयास गरेन, र सबै प्याकेजहरू प्रणाली डाइरेक्टरीमा स्थापना भएकाले, प्याकेज हटाउन असम्भव छ .hpkg परिवर्तन बिना "यसको सामग्री"। एक साधारण प्रयोगकर्ता डराउँनेछ र पूर्वनिर्धारित रूपमा तोकिएको "रद्द" बटन थिच्नेछ।

व्याख्या गर्छ श्री। waddlesplash:

यो पोस्ट 10 वर्ष भन्दा पुरानो हो। प्राय: हामीले यसलाई कन्फिगर गर्न आवश्यक छ ताकि प्याकेज आफै सारियो जब चेतावनी मात्र देखिन्छ। नियमित प्रयोगकर्ताहरूले जे भए पनि यो गर्न आवश्यक छैन।

ठीक छ, सायद मैले हाइकुडेपो प्रयोग गरेर यो गर्नु पर्छ? म प्याकेजमा डबल क्लिक गर्छु /Haiku/system/packages, "अनइन्स्टल" बटन देखा पर्नको लागि पर्खँदै। होइन, त्यहाँ (केवल) "स्थापना" छ। "Uninstall", तपाईं कहाँ हुनुहुन्छ?

केवल रमाइलोको लागि, मैले पहिले नै स्थापित प्याकेजमा "स्थापना गर्नुहोस्" क्लिक गरेमा के हुन्छ भनेर हेर्ने प्रयास गरें। यो यस्तो निस्कन्छ:

यदि तपाइँ पहिले नै स्थापित प्याकेज स्थापना गर्ने प्रयास गर्नुहुन्छ भने यो हुन्छ।

अर्को देखिन्छ:

यदि तपाईंले अघिल्लो विन्डोमा "परिवर्तनहरू लागू गर्नुहोस्" मा क्लिक गर्नुभयो भने, यो यस्तो देखिन्छ

मलाई लाग्छ कि यो सफ्टवेयर त्रुटि हो; अनुप्रयोगको लिङ्क पहिले नै त्यहाँ छ। [लेखकले लिङ्क प्रदान गर्नुभएको छैन - लगभग। अनुवादक]

द्रुत समाधान: प्याकेज पहिले नै भित्र छ भने "अनइन्स्टल" बटन थप्नुहोस् /Haiku/system/packages, वा मा /Haiku/home/config/packages.

HaikuDepot मा स्थापित प्याकेजहरूको सूची हेर्दा, म सूचीमा मेरो प्याकेज देख्छु र यसलाई हटाउन सक्छु।

म्याकले यस श्रेणीमा जित्छ। तर म कल्पना गर्न सक्छु कि उचित सेटअप संग, Haiku मा प्रयोगकर्ता अनुभव Mac मा भन्दा राम्रो हुनेछ। (एकजना विकासकर्ताले यसलाई यसरी मूल्याङ्कन गरे: "हाइकुडेपोमा निर्दिष्ट कार्यक्षमता थप्न एक घण्टा भन्दा कम, यदि तपाईलाई थोरै C++ थाहा छ भने, कुनै स्वयंसेवकहरू?)

प्याकेजबाट केहि हटाउँदै

एप्लिकेसनलाई नै हटाउने प्रयास गरौं, प्याकेज होइन .hpkg, जसबाट यो आयो (मलाई शंका छ कि "केवल मर्त्यहरू" को लागी कुनै फरक छ)।

На म्याक, प्रयोगकर्ताले सामान्यतया फाइलसँग काम गर्दछ .dmgआवेदन प्याकेज कहाँबाट आउँछ .app। सामान्यतया छविहरू .dmg डाउनलोड डाइरेक्टरीमा जम्मा गरिन्छ, र प्याकेजहरू प्रयोगकर्ताद्वारा प्रतिलिपि गरिन्छ /Applications। यो विश्वास गरिन्छ कि धेरै प्रयोगकर्ताहरू आफैलाई थाहा छैन कि तिनीहरू के गर्दैछन्, यो परिकल्पना एक पूर्व एप्पल कर्मचारी द्वारा पुष्टि गरिएको छ। (मलाई म्याकमा मन नपर्ने चीजहरू मध्ये एउटा। र, उदाहरणका लागि, AppImage सँग त्यहाँ अनुप्रयोग र प्याकेजमा कुनै भिन्नता छैन। प्रतिमालाई रद्दीटोकरीमा तान्नुहोस् = यो हो। सजिलो!)

हाइकु माबीचमा विभाजन पनि छ apps/ и packages/, त्यसैले मलाई शंका छ कि यसले प्रयोगकर्ताहरूलाई स्पष्ट पारेको छ। तर के हुन्छ यदि तपाइँ बाट एप्लिकेसन तान्नु हुन्छ apps/ भाडोमा हाल:

यो के हुन्छ जब तपाइँ फाइलबाट लिइएको अनुप्रयोग हटाउन प्रयास गर्नुहुन्छ .hpkg

प्राविधिक रूपमा यो सही छ (सबै पछि, अनुप्रयोग पहिलो स्थानमा पढ्न-मात्र फाइल प्रणालीमा होस्ट गरिएको छ), तर यो प्रयोगकर्ताको लागि विशेष उपयोगी छैन।

द्रुत समाधान: यसको सट्टा मेटाउन GUI प्रयोग गर्न सुझाव दिनुहोस् .hpkg

केवल रमाइलोको लागि, मैले Alt+D थिचेर अनुप्रयोगको नक्कल गर्ने प्रयास गरें। मैले "पढ्न-मात्र भोल्युममा वस्तुहरू सार्न वा प्रतिलिपि गर्न असमर्थ" सन्देश प्राप्त गरें। र सबै कारण /system (बाहेक /system/packages и /system/settings) packagefs माउन्ट पोइन्ट हो (यो आउटपुटमा कसरी देखिन्छ भनेर सम्झनुहोस् df?) दुर्भाग्यवश, आदेशको आउटपुट mount स्थिति स्पष्ट गर्दैन (जस्तै अघिल्लो लेख मध्ये एक मा भनिएको थियो), mountvolume तपाईंले के खोजिरहनु भएको देखाउँदैन (स्पष्ट रूपमा प्याकेजहरू लुप मार्फत माउन्ट गरिएको छ .hpkg "भोल्युमहरू" मानिने छैन), र मैले वैकल्पिक आदेशहरू पनि बिर्सें।

AppImage बाहेक यस श्रेणीमा कसैले जितेन (तर यो, पूर्ण रूपमा इमानदार हुन, एक पक्षपाती विचार हो)। यद्यपि, कसैले कल्पना गर्न सक्छ कि tweaking पछि, हाइकु मा प्रयोगकर्ता अनुभव म्याक मा भन्दा राम्रो हुनेछ।

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

प्याकेजको सामग्रीलाई अर्को प्रणालीमा प्रतिलिपि गर्दै

На म्याक, म मूर्खतापूर्वक प्याकेज तान्नुहोस् .app, र निर्भरताहरू प्याकेज भित्र भएकाले, तिनीहरू सँगै सर्छन्।

हाइकु मा, म एप्लिकेसन तान्दछु, तर निर्भरताहरू कुनै पनि प्रक्रियामा छैनन्।

द्रुत समाधान: यसको सट्टा सम्पूर्ण `.hpkg प्याकेज, कुनै पनि निर्भरताहरू, यदि कुनै छ भने तान्नुहोस् सुझाव दिनुहोस्।

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

यसको सबै निर्भरता संग प्याकेज डाउनलोड गर्नुहोस्

हरेक मेसिन सँधै नेटवर्कमा जडान हुँदैन। यसको विपरित, केहि मेसिनहरू (हो, म तपाईलाई हेर्दै छु, आधुनिक विन्डोज, म्याक र लिनक्स) यो बिर्सन्छ। यो मेरो लागि महत्त्वपूर्ण छ कि म इन्टरनेट क्याफेमा जान सक्छु, उदाहरणका लागि, हटाउन सकिने ड्राइभमा सफ्टवेयर डाउनलोड गर्नुहोस्, यो ड्राइभलाई मेरो गृह कम्प्युटरमा घुसाउनुहोस् र सबै कुराले काम गर्नेछ भन्ने कुरामा निश्चित हुनुहोस् [जोखिमपूर्ण मान्छे, विन्डोजमा यो गर्दै... - लगभग। अनुवादक]।

नतिजाको रूपमा, म विन्डोज र लिनक्समा सामान्य भन्दा अलि बढी अमेट निर्भरताहरूको साथ समाप्त हुन्छु।

На म्याक यो सामान्यतया एउटा फाइल हो, तपाईंले डाउनलोड गर्न आवश्यक छ .dmg। प्रायः, यसमा पूर्वनिर्धारित रूपमा MacOS द्वारा प्रदान गरिएको बाहेक अन्य कुनै निर्भरताहरू छैनन्। एउटा अपवाद जटिल अनुप्रयोगहरू हुन् जसलाई उपयुक्त कार्यान्वयन वातावरण चाहिन्छ, उदाहरणका लागि java।

हाइकु मा प्याकेज डाउनलोड गर्नुहोस् .hpkg का लागि, भन्नुहोस्, java मा उही अनुप्रयोग, पर्याप्त नहुन सक्छ, किनकि java लक्षित मेसिनमा उपस्थित हुन सक्छ वा नहुन सक्छ। त्यहाँ दिइएको प्याकेजको लागि सबै निर्भरताहरू डाउनलोड गर्ने तरिका छ .hpkg, हाइकुमा पूर्वनिर्धारित रूपमा स्थापना गरिएका बाहेक प्रत्येक हाइकु प्रणालीमा हुनुपर्छ?

म्याकले यो वर्गलाई सानो अन्तरले जित्छ।

टिप्पणी श्री. waddlesplash:

प्याकेजहरूको सेटको रूपमा अनुप्रयोगको सबै निर्भरताहरू सङ्कलन गर्न एउटा कार्यक्रम लेख्न .hpkg हाइकुको भित्री कार्यसँग परिचित कसैको लागि, लगभग 15 मिनेट पर्याप्त छ। यदि यसको लागि वास्तविक आवश्यकता छ भने यसको लागि समर्थन थप्न गाह्रो छैन। तर मेरो लागि यो दुर्लभ अवस्था हो।

यस शृङ्खलाको अर्को लेख सम्म हाम्रो सास होल्ड गरौं।

प्याकेजहरूलाई छुट्टै स्थानमा सार्दै

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

На म्याक म केवल प्याकेजहरू सार्दै छु .app फाइन्डरमा हटाउन सकिने ड्राइभ वा नेटवर्क डाइरेक्टरीमा, र त्यो हो। म अझै पनि एप्लिकेसन खोल्न डबल-क्लिक गर्न सक्छु जसरी म सामान्यतया बुट भोल्युमबाट गर्छु। बस!

हाइकु मा, मलाई भनिएको थियो, यो मेरो सार्न द्वारा प्राप्त गर्न सकिन्छ .hpkg हटाउन सकिने ड्राइभ वा सञ्जाल डाइरेक्टरीमा प्याकेजहरू, तर त्यसपछि तपाइँलाई प्रणालीमा माउन्ट गर्नको लागि कन्सोलमा केही दस्तावेज नगरिएका आदेशहरू प्रयोग गर्न आवश्यक छ। मलाई GUI प्रयोग गरेर यो कसरी गर्ने थाहा छैन।

म्याकले यस श्रेणीमा जित्छ।

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

यो सामान्य प्रयोगमा आधारित एक अनुकूलन हो। यदि एक भन्दा बढी प्रयोगकर्ताहरूको माग छ भने, हामी यसलाई लागू गर्नेछौं। कुनै पनि अवस्थामा, तेस्रो-पक्ष कार्यान्वयनको सम्भावना छ।

यसबारे हामी अर्को लेखमा कुरा गर्नेछौं।

नेटवर्क डाइरेक्टरीहरूको कुरा गर्दा, स्थानीय कम्प्युटरमा प्रतिलिपि गर्न वा स्थानीय नेटवर्कबाट सिधै चलाउन सकिने सरल, खोजीयोग्य, नेटवर्क-वाइड अनुप्रयोगहरू (जस्तै Zeroconf) हुनु राम्रो हुन्छ (म ल्यान पार्टीहरू अनुमान गर्दैछु)। अवश्य पनि, विकासकर्ताहरूसँग मार्फत अप्ट आउट गर्ने विकल्प छ app_flags.

GUI सँग hpkg प्रणालीको एकीकरणमा अन्तिम रिपोर्ट

मलाई लाग्छ कि मुख्य रूपमा एकीकरणको सापेक्ष नयाँपनको कारणले .hpkg GUI ले अझै धेरै चाहिएको छ। जे भए पनि, त्यहाँ केहि चीजहरू छन् जुन UX को सर्तमा सुधार गर्न सकिन्छ ...

अर्को कुरा: कर्नेल डिबग ल्यान्ड

उदाहरणका लागि, कर्नेल प्यानिकको समयमा आदेशहरू प्रविष्ट गर्न सक्षम हुनु राम्रो हुनेछ syslog | grep usb। खैर, हाइकु मा यो सम्भव छ कर्नेल डिबग ल्याण्ड को लागी धन्यवाद। यदि सबै कुरा कर्नेल आतंकमा नपरिकन जसरी नै काम गर्छ भने तपाईले यो जादू कसरी कार्यमा देख्न सक्नुहुन्छ? Alt+PrintScn+D (डिबग निमोनिक) थिचेर सजिलो। तुरुन्तै सम्झन्छु प्रोग्रामर कुञ्जी, जसले मूल Macintosh विकासकर्ताहरूलाई डिबगरमा प्रवेश गर्न अनुमति दियो (यदि एक स्थापना गरिएको थियो, अवश्य पनि)।

निष्कर्षमा

मैले बुझ्न थालेको छु कि हाइकु प्रणालीको परिष्कृतता यस तथ्यबाट आएको हो कि काम एउटा सानो टोलीले कार्य वातावरणमा स्पष्ट ध्यान केन्द्रित गरी प्रणालीका सबै तहहरू पहुँचयोग्य भएकोमा गरिन्छ।
लिनक्स/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu को संसारसँग तीव्र भिन्नता, जहाँ सबै चीजहरू साना टुक्राहरूमा यस हदसम्म टुक्रिएको छ कि एब्स्ट्र्याक्शन एब्स्ट्र्यासनमा बस्छ र बैसाखीको साथ ड्राइभ गर्दछ।
प्रणाली कस्तो छ भन्ने बुझाइ पनि थियो .hpkg परम्परागत प्याकेज प्रबन्धकहरू, Snappy, Flatpak, AppImage, यहाँ सम्म कि btrfs को सबै भन्दा राम्रो अभ्यासहरू संयोजन गर्दछ, र तिनीहरूलाई म्याकको "मात्र काम गर्ने" दृष्टिकोणसँग मिश्रण गर्दछ।

यो मेरो टाउकोमा केहि "स्विच" जस्तै थियो, र मैले प्रणाली कसरी बुझे .hpkg उसलाई हेरेर मात्र कसरी टाढा रोल गर्ने थाहा छ। तर यो म होइन, तर प्रणालीको सुन्दरता र सरलता हो। यो धेरै मौलिक म्याक को आत्मा द्वारा प्रेरित छ।

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

म मद्दत प्रस्ताव गर्न सक्दिन, तर मलाई लाग्छ कि यो अब देखि सुरु हुनेछ डेस्कटपमा हाइकुको वर्ष.

अनियमित समस्याहरू

हुनसक्छ त्यहाँ पहिले नै अनुरोधहरू छन्, वा मैले तिनीहरूलाई खोल्नु पर्छ?

BeScreenCapture ले Peek जस्तै GIF मा निर्यात गर्न सक्षम हुनुपर्छ। यो हाइकुको लागि पहिले नै उपलब्ध ffmpeg प्रयोग गरेर गर्न सकिन्छ। आवेदन.
स्क्रिनसट सफ्टवेयरले सम्पूर्ण स्क्रिन क्याप्चर गर्नुको सट्टा मोडल विन्डो क्याप्चर गर्न असफल हुन्छ
तपाईंले WonderBrush को क्रपिङ उपकरण प्रयोग गरेर स्क्रिनसटहरू क्रप गर्न सक्नुहुन्न र त्यसपछि फाइलमा परिणाम बचत गर्नुहोस्
मलाई हाइकुमा ह्यान्ड कर्सर मन पर्दैन, तर मलाई लाग्छ कि यो न्यानो उदासीन भावनासँग सम्बन्धित छ। Krita मा क्रप उपकरण प्रयोग गर्दा यो विशेष गरी कष्टप्रद हुन्छ, किनकि यसले गलत फसलको परिणाम दिन्छ (यस लेखमा मोडल संवादहरूको स्क्रिनसटहरू हेर्नुहोस्)। एक क्रसहेयर कर्सर अद्भुत हुनेछ। आवेदन.

आफैलाई प्रयास गर्नुहोस्! जे भए पनि, हाइकु परियोजनाले DVD वा USB बाट बुट गर्नका लागि छविहरू प्रदान गर्दछ ежедневно। स्थापना गर्न, केवल छवि डाउनलोड गर्नुहोस् र यसलाई प्रयोग गरेर फ्लैश ड्राइभमा लेख्नुहोस् Etcher

के तपाईंको कुनै प्रश्न छन्? हामी तपाईंलाई रूसी भाषा बोल्न आमन्त्रित गर्छौं टेलिग्राम च्यानल.

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

बाट लेखक अनुवाद: हाइकुको शृङ्खलाको यो छैटौं लेख हो।

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

स्रोत: www.habr.com

हाइकुको साथ मेरो छैटौं दिन: स्रोतहरू, आइकनहरू र प्याकेजहरूको हुड अन्तर्गत