हायकूसह माझा सहावा दिवस: संसाधने, चिन्हे आणि पॅकेजेसच्या हुड अंतर्गत

TL; डॉA: हायकू ही एक ऑपरेटिंग सिस्टीम आहे जी विशेषतः PC साठी डिझाइन केलेली आहे, त्यामुळे इतरांपेक्षा ते अधिक चांगले डेस्कटॉप वातावरण बनवण्यासाठी त्यात काही युक्त्या आहेत. पण ते कसे चालते?

अलीकडे मी हायकू शोधला, एक अनपेक्षितपणे चांगली प्रणाली. मी अजूनही आश्चर्यचकित आहे की ते किती सहजतेने चालते, विशेषतः जेव्हा लिनक्स डेस्कटॉप वातावरणाशी तुलना केली जाते. आज मी हुड अंतर्गत एक नजर टाकू. सखोल समजून घेण्यासाठी आवश्यक असल्यास, मी मूळ Macintosh, Mac OS X आणि Linux डेस्कटॉप (freedesktop.org वरील XDG मानक) यांच्याशी तुलना करेन.

ELF फायलींमधील संसाधने

काल मला कळले की IconOMatic ELF एक्झिक्युटेबल फायलींमध्ये rdef संसाधनांमध्ये चिन्ह संचयित करू शकते. आज मला ते प्रत्यक्षात कसे कार्य करते ते पहायचे आहे.

संसाधने? कोट पासून ब्रुस हॉर्न, Macintosh Finder चे मूळ लेखक आणि Macintosh संसाधन व्यवस्थापकाचे वडील:

मी पारंपारिक कोडिंगच्या कठोर स्वरूपाबद्दल चिंतित आहे. माझ्यासाठी, कोडमध्ये गोठवलेल्या ऍप्लिकेशनची कल्पना, गतिशीलपणे काहीही बदलण्याची क्षमता न घेता, सर्वात जंगलीपणा आहे. रनटाइममध्ये शक्य तितके बदल करणे शक्य असले पाहिजे. अर्थात, ऍप्लिकेशन कोड स्वतः बदलला जाऊ शकत नाही, परंतु कोड पुन्हा संकलित केल्याशिवाय काहीतरी बदलता येईल का?

मूळ Macintosh ने या फायलींना "डेटा विभाग" आणि "संसाधन विभाग" बनवले आहे, ज्यामुळे आयकॉन, भाषांतरे इत्यादी गोष्टी जतन करणे अत्यंत सोपे झाले आहे. एक्झिक्युटेबल फाइल्समध्ये.

Mac वर, हे लागू होते पुन्हा संपादित करा, एक ग्राफिकल प्रोग्राम - अचानक - संपादन संसाधने.

मूळ Macintosh वर पुन्हा संपादित करा

परिणामी, चिन्हे, मेनू आयटम, भाषांतरे इत्यादी संपादित करणे शक्य झाले. पुरेसे सोपे, परंतु ते अद्याप अनुप्रयोगांसह "प्रवास" करतात.
कोणत्याही परिस्थितीत, या दृष्टिकोनात मोठी कमतरता होती: ते केवळ ऍपल फाइल सिस्टमवर कार्य करते, जे Mac OS X वर जाताना ऍपलने "संसाधन विभाग" सोडण्याचे एक कारण होते.
मॅक ओएस एक्स वर, ऍपलला फाइल सिस्टम-स्वतंत्र समाधान हवे होते, म्हणून त्यांनी पॅकेजेसची संकल्पना स्वीकारली (नेक्स्ट वरून), डिरेक्टरी ज्या फाइल व्यवस्थापकाद्वारे "अपारदर्शक वस्तू" म्हणून हाताळल्या जातात, जसे की फाइल्स, डिरेक्टरी नव्हे. फॉर्मेटमधील अनुप्रयोगासह कोणतेही पॅकेज .app इतर गोष्टींबरोबरच, फाइल आहे Info.plist (Apple कडील 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 फाइलमध्ये संसाधने जोडल्यानंतर, Linux टूल्ससह कार्य न करणे चांगले.

आणि आता हायकूचे काय होत आहे? मुळात, कमी-अधिक प्रमाणात समान.

सिद्धांतानुसार, ELF च्या इच्छित विभागात संसाधने ठेवणे शक्य होईल. irc.freenode.net वरील #haiku चॅनेलवरील विकसकांच्या मते:

ELF सह, विभाग अधिक अर्थपूर्ण होईल... आम्ही असे न करण्याचे एकमेव कारण म्हणजे आम्ही ते BeOS मध्ये केले."
आणि आता बदलण्याची गरज नाही.

संसाधन व्यवस्थापन

संसाधने संरचित "संसाधन" स्वरूपात लिहिलेली आहेत: खरं तर, ही आकार आणि नंतर त्यांची सामग्री असलेली संसाधनांची सूची आहे. लक्षात ठेवले ar स्वरूप.
हायकूमधील संसाधने कशी तपासायची? ResEdit असे काही आहे का?
मते दस्तऐवजीकरण:

तुम्ही एक्झिक्यूटेबलला प्रोग्रामवर ड्रॅग आणि ड्रॉप करू शकता जसे की संसाधनकर्ता. तुम्ही टर्मिनलवर जाऊन कमांड रन देखील करू शकता listres имя_файла.

Resourcer HaikuDepot मध्ये आहे, पण तो फक्त माझ्यासाठी क्रॅश होतो.

तर तुम्ही ईएलएफ फाइल्समधील संसाधने कशी व्यवस्थापित कराल? वापरत आहे 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 फॉरमॅटमध्ये आयकॉन तयार करण्यासाठी तुम्हाला अनेक चक्रांमधून जावे लागेल. येथे स्पष्टीकरण तथापि, SVGs आयात करताना IconOMatic अपूर्ण असू शकते; सुमारे 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 प्रकल्पावर काम करत आहे, अंतिम वापरकर्ता अनुप्रयोगांसाठी एक आंशिक क्रॅच. हे एक सॉफ्टवेअर वितरण स्वरूप आहे जे अनुप्रयोग आणि त्याच्या सर्व अवलंबनांना एकाच फाइल सिस्टम प्रतिमेमध्ये एकत्रित करते जे अनुप्रयोग सुरू झाल्यावर माउंट केले जाते. हे गोष्टी मोठ्या प्रमाणात सुलभ करते, कारण तीच इमेज मॅजिक अचानक फाईल मॅनेजरमध्ये मॅनेज केलेल्या एका फाईलमध्ये बदलते. सुचवलेली पद्धत केवळ सॉफ्टवेअरसाठी कार्य करते, जसे की प्रकल्पाच्या नावात प्रतिबिंबित होते, आणि त्याचे स्वतःचे बग आहेत, कारण Linux सॉफ्टवेअर विक्रेते नेहमी मला सूचित करतात.

चला हायकूकडे परत जाऊया. तुम्हाला पारंपारिक पॅकेजिंग सिस्टम आणि इमेज-आधारित सॉफ्टवेअर डिलिव्हरी दरम्यान योग्य संतुलन सापडले आहे का? तिची पॅकेजेस .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. व्वा! मी आधी नमूद केले आहे की, माझ्या दृष्टीने, हायकूच्या एकूण परिष्कृततेचा आणि सातत्याचा एक भाग म्हणजे कर्नल आणि अंतर्निहित वापरकर्ता स्थानापासून पॅकेज व्यवस्थापन आणि डेस्कटॉप पायाभूत सुविधांपर्यंत संपूर्ण प्रणाली एका टीमद्वारे सहकार्याने विकसित केली जाते. लिनक्सवर असे काहीतरी चालविण्यासाठी किती भिन्न गट आणि संघ लागतील याची कल्पना करा. [मी पप्पीलिनक्स प्रकल्पाची कल्पना करतो, - अंदाजे. अनुवादक]. मग कल्पना करा की वितरणांमध्ये हा दृष्टिकोन लागू होण्यासाठी किती वेळ लागेल. ते म्हणतात: एक साधे कार्य घ्या, ते वेगवेगळ्या कलाकारांमध्ये विभाजित करा आणि ते इतके गुंतागुंतीचे होईल की ते यापुढे सोडवले जाणार नाही. या प्रकरणात हायकूने माझे डोळे उघडले. मला वाटते की आता लिनक्सवर नेमके हेच घडत आहे (या प्रकरणात लिनक्स ही Linux/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
• मला एक पॅकेज स्थापित करायचे आहे
• मला एक पॅकेज काढायचे आहे
• मला पॅकेजचा भाग म्हणून सिस्टममध्ये आलेले काहीतरी हटवायचे आहे
• मला पॅकेजचा भाग म्हणून सिस्टममध्ये आलेले काहीतरी कॉपी करायचे आहे
• मला सर्व पॅकेज अवलंबित्व डाउनलोड करायचे आहे जे प्रत्येक हायकू स्थापनेचा भाग असू शकत नाहीत (उदाहरणार्थ, माझ्याकडे इंटरनेट प्रवेश नसलेले भौतिकदृष्ट्या वेगळे मशीन आहे.)
• मला माझे पॅकेजेस (चांगले, त्यातील काही भाग) वेगळ्या ठिकाणी, बूट व्हॉल्यूम (रूट विभाजन) पासून वेगळे करायचे आहेत (कारण, उदाहरणार्थ, माझ्याकडे त्यावर पुरेशी जागा नाही).

यात माझ्या दैनंदिन कामातील बहुतेक मुख्य प्रकरणांचा समावेश असावा. बरं, चला सुरुवात करूया.

पॅकेजची सामग्री तपासत आहे

Mac वर मी पॅकेज उघडण्यासाठी त्यावर उजवे-क्लिक करतो आणि फाइंडरमधील सामग्री पाहतो. ती खरोखरच फक्त वेशात एक निर्देशिका आहे! (मला माहित आहे की तेथे पॅकेजेस आहेत .pkg सिस्टमच्या एका भागासाठी जो अनुप्रयोग नाही, परंतु सामान्य वापरकर्ते सहसा त्यांच्याशी संवाद साधत नाहीत).

हायकू वर मी पॅकेजवर उजवे क्लिक करतो, नंतर आत काय आहे ते पाहण्यासाठी "सामग्री" वर क्लिक करा. परंतु ती उघडण्यासाठी डबल-क्लिक करण्याची क्षमता नसलेल्या फायलींची फक्त सूची आहे.
पॅकेज माउंट करण्याचा (तात्पुरता) मार्ग असल्यास ते अधिक चांगले होईल .hpkg फाइल व्यवस्थापकाद्वारे पाहण्यासाठी, आणि वापरकर्त्याला अंमलबजावणी तपशीलांची काळजी करण्याची गरज नाही. (तसे, आपण उघडू शकता .hpkg मध्ये पॅकेज Expander, जे इतर कोणत्याही संग्रहाप्रमाणे अनपॅक करू शकते).

HaikuDepot च्या इंटरफेसमध्ये, आपण पॅकेज फाइल्सची सूची पाहू शकता, परंतु सामग्री पाहण्याचा कोणताही मार्ग नाही, उदाहरणार्थ, README.md वर डबल-क्लिक करून

या वर्गवारीत, मॅक जिंकतो, परंतु HaikuDepot मध्ये योग्य कार्यक्षमता जोडणे ही मोठी गोष्ट असू नये.

GUI द्वारे पॅकेज स्थापित करणे

Mac वर, बहुतेक डिस्क प्रतिमा .dmg पॅकेजेस समाविष्ट आहेत .app. डबल-क्लिक करून डिस्क प्रतिमा उघडा, आणि नंतर पॅकेज कॉपी करा, उदाहरणार्थ, त्यास ड्रॅग करून /Applications फाइंडर मध्ये. माझ्यासाठी हे सांगण्याशिवाय आहे, परंतु मी ऐकले आहे की काही नवशिक्या हे हाताळू शकत नाहीत. डीफॉल्टनुसार, ऍपल सिस्टम-व्यापी निर्देशिका "सुचवते". /Applications (पुढील वर ते नेटवर्क तसेच वैयक्तिक होते), परंतु तुम्ही तुमचे अनुप्रयोग फाइल सर्व्हरवर किंवा उपनिर्देशिकेमध्ये सहजपणे ठेवू शकता $HOME/Applicationsजर तुम्हाला ते खूप आवडत असेल.

हायकू वर, पॅकेजवर डबल क्लिक करा, नंतर "स्थापित करा" वर क्लिक करा, हे सोपे होऊ शकत नाही. हायकुपोर्ट्समध्ये पॅकेजमध्ये अवलंबित्व उपलब्ध असल्यास, परंतु अद्याप स्थापित न केल्यास काय होईल याबद्दल मला आश्चर्य वाटत आहे. लिनक्सवर त्यांना या परिस्थितीत काय करावे हे खरोखर माहित नाही, परंतु उपाय स्पष्ट आहे - अवलंबित्व डाउनलोड आणि स्थापित करणे आवश्यक आहे का ते वापरकर्त्याला विचारा. हायकू नक्की काय करतो.

मी 'सॅनिटी' पॅकेज मॅन्युअली डाउनलोड केले आणि त्यावर क्लिक केले, पॅकेज मॅनेजरला माहित आहे की त्याचे अवलंबित्व कोठून मिळवायचे (रेपॉजिटरीज सिस्टमवर आधीपासूनच आहेत असे गृहीत धरून). प्रत्येक लिनक्स वितरण हे करू शकत नाही.

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

या श्रेणीमध्ये, हायकू जिंकतो, कारण ते केवळ अनुप्रयोगांसहच नाही तर सिस्टम प्रोग्रामसह देखील कार्य करू शकते.

GUI मधून पॅकेज काढत आहे

Mac वर, तुम्हाला ॲप्लिकेशन आयकॉन कचर्‍यात ड्रॅग करणे आवश्यक आहे आणि ते झाले. सहज!

हायकू वर, प्रथम, आपल्याला सिस्टममध्ये पॅकेज कुठे आहे ते शोधण्याची आवश्यकता आहे, कारण आपण ते क्वचितच योग्य ठिकाणी स्थापित करता (सिस्टम सर्वकाही करते). सहसा आपल्याला शोधण्याची आवश्यकता असते /Haiku/system/packages (सिस्टम-व्यापी डीफॉल्ट इंस्टॉलेशनमध्ये), किंवा मध्ये /Haiku/home/config/packages (मी उल्लेख केला आहे की "कॉन्फिग" हे चुकीचे नाव आहे?). मग ऍप्लिकेशन फक्त कचर्‍यात ड्रॅग केले जाते आणि तेच.
सहज! तथापि, मी असे म्हणणार नाही. खरोखर काय चालले आहे ते येथे आहे:

जेव्हा तुम्ही एखादे अॅप कचर्‍यात ड्रॅग करता तेव्हा असे होते /Haiku/system/packages

माझे कालचे "हॅलो वर्ल्ड" अॅप QtQuickApp वरील कचर्‍यात हलवण्याचा प्रयत्न केला. मी सिस्टम निर्देशिका हलवण्याचा प्रयत्न केला नाही, आणि सर्व पॅकेजेस सिस्टम निर्देशिकेत स्थापित केल्यामुळे - पॅकेज काढणे अशक्य आहे .hpkg बदल न करता "त्यातील सामग्री". एक सामान्य वापरकर्ता घाबरेल, डीफॉल्टनुसार नियुक्त केलेले "रद्द करा" बटण दाबेल.

समजावतो श्री. waddlesplash:

ही पोस्ट 10 वर्षांपेक्षा जुनी आहे. बहुधा, आम्हाला ते कॉन्फिगर करणे आवश्यक आहे जेणेकरून जेव्हा पॅकेज स्वतः हलविले जाईल तेव्हाच चेतावणी येईल. सामान्य वापरकर्त्यांना तरीही हे करण्याची आवश्यकता नाही.

ठीक आहे, कदाचित तुम्ही ते हायकुडेपो वापरून करावे? पॅकेजवर डबल क्लिक करा /Haiku/system/packages, "अनइंस्टॉल" बटण दिसण्यासाठी प्रतीक्षा करत आहे. नाही, तेथे (फक्त) "इंस्टॉल" आहे. विस्थापित करा, तुम्ही कुठे आहात?

गंमत म्हणून, मी आधीपासून स्थापित पॅकेजवर "इंस्टॉल करा" वर क्लिक केल्यास काय होते हे पाहण्याचा प्रयत्न केला. हे असे बाहेर वळते:

आपण आधीच स्थापित पॅकेज स्थापित करण्याचा प्रयत्न केल्यास हे घडते.

हे पुढे दिसते:

तुम्ही मागील विंडोमध्ये "बदल लागू करा" वर क्लिक केल्यास, ते असे होईल

मी गृहीत धरतो की ही एक सॉफ्टवेअर त्रुटी आहे, अनुप्रयोगाची लिंक आधीपासूनच आहे. [लेखकाने दुवा दिलेला नाही, - अंदाजे. अनुवादक]

द्रुत निराकरण: पॅकेज आधीपासूनच असल्यास "अनइंस्टॉल करा" बटण जोडा /Haiku/system/packages, किंवा मध्ये /Haiku/home/config/packages.

HaikuDepot मध्ये स्थापित पॅकेजेसची यादी पाहताना, मी माझे पॅकेज सूचीमध्ये पाहू शकतो आणि ते काढू शकतो.

मॅक ही श्रेणी जिंकतो. पण मी कल्पना करू शकतो की योग्य सेटअपसह, हायकूवरील वापरकर्ता अनुभव Mac पेक्षा चांगला असेल. (एका ​​डेव्हलपरने असे रेट केले आहे: "आपल्याला थोडेसे C++ माहित असल्यास, हायकुडेपोमध्ये निर्दिष्ट कार्यक्षमता जोडण्यासाठी एका तासापेक्षा कमी वेळ लागेल", कोणत्याही स्वयंसेवक?)

पॅकेजमधून काहीतरी काढून टाकत आहे

पॅकेज नाही तर अॅप स्वतःच अनइंस्टॉल करण्याचा प्रयत्न करूया .hpkg, ज्यावरून ते दिसून आले (मला शंका आहे की "फक्त मर्त्यांसाठी" काही फरक आहे).

Mac वर, वापरकर्ता प्रत्यक्षात फाइलसह सामान्यपणे कार्य करतो .dmgअनुप्रयोग पॅकेज कुठून येते .app. सहसा प्रतिमा .dmg डाउनलोड निर्देशिकेत जमा केले जातात, पॅकेजेस वापरकर्त्याद्वारे कॉपी केले जातात /Applications. असे मानले जाते की बर्याच वापरकर्त्यांना ते काय करत आहेत हे स्वतःला माहित नाही, या गृहितकाची पुष्टी ऍपलच्या माजी कर्मचार्याने केली आहे. (मला मॅकवर आवडत नसलेल्या गोष्टींपैकी एक. आणि AppImage सह, उदाहरणार्थ, अॅप आणि ते ज्या पॅकेजमध्ये होते त्यात कोणताही फरक नाही. चिन्ह कचर्‍यामध्ये ड्रॅग करा = तेच आहे. सोपे!)

हायकू वर, दरम्यान एक विभागणी देखील आहे apps/ и packages/, त्यामुळे मला शंका आहे की यामुळे वापरकर्त्यांना ते अधिक स्पष्ट झाले आहे. परंतु आपण वरून अनुप्रयोग ड्रॅग केल्यास काय होईल apps/ कार्टमध्ये जोडा:

जेव्हा तुम्ही फाइलमधून घेतलेला अनुप्रयोग काढण्याचा प्रयत्न करता तेव्हा असे होते .hpkg

हे तांत्रिकदृष्ट्या बरोबर आहे (सर्वप्रथम, अनुप्रयोग केवळ-वाचनीय फाइल सिस्टमवर होस्ट केला जातो), परंतु वापरकर्त्यासाठी ते विशेषतः उपयुक्त नाही.

द्रुत निराकरण: त्याऐवजी हटविण्यासाठी GUI द्वारे सुचवा .hpkg

गंमत म्हणून, मी Alt + D दाबून अनुप्रयोग डुप्लिकेट करण्याचा प्रयत्न केला. "ओन्ली-रीड व्हॉल्यूमवर ऑब्जेक्ट हलवू किंवा कॉपी करण्यात अक्षम" असा संदेश आला. आणि सर्व कारण /system (याशिवाय /system/packages и /system/settings) हे packagefs माउंट पॉइंट आहे (आऊटपुटमध्ये ते कसे दिसते ते लक्षात ठेवा df?). दुर्दैवाने, कमांडचे आउटपुट mount परिस्थिती स्पष्ट करत नाही (मागील एका लेखात म्हटल्याप्रमाणे), mountvolume तुम्ही काय शोधत आहात ते दाखवत नाही (वरवर पाहता पॅकेजेस लूपद्वारे माउंट केले जातात .hpkg "व्हॉल्यूम" मानले जात नाहीत), आणि मी पर्यायी आदेश देखील विसरलो.

या श्रेणीमध्ये, AppImage शिवाय कोणीही जिंकले नाही (परंतु हे पूर्णपणे प्रामाणिकपणे सांगायचे तर पक्षपाती मत आहे). तथापि, कोणीही कल्पना करू शकतो की ट्वीक केल्यानंतर, हायकूवरील वापरकर्त्याचा अनुभव Mac पेक्षा चांगला असेल.

टीप: तुम्हाला "विभाजन" च्या संबंधात "व्हॉल्यूम" काय आहे हे शोधण्याची आवश्यकता आहे. हे कदाचित "फोल्डर" ते "डिरेक्टरी" संबंधासारखे आहे: बहुतेक निर्देशिका फाईल व्यवस्थापकामध्ये फोल्डरच्या रूपात दिसतात, परंतु त्या सर्व नाहीत (उदा. पॅकेजेस फाइल्स म्हणून मानले जातात). या प्रकारामुळे मला अधिकृतपणे मूर्ख बनवते का?

पॅकेजची सामग्री दुसर्‍या सिस्टममध्ये कॉपी करणे

Mac वर, मूर्खपणे पॅकेज खेचत आहे .app, आणि अवलंबित्व पॅकेजच्या आत असल्याने, ते एकत्र फिरतात.

हायकू वर, मी ऍप्लिकेशन ड्रॅग करतो, परंतु अवलंबित्वांवर अजिबात प्रक्रिया केली जात नाही.

द्रुत निराकरण: त्याऐवजी, अवलंबित्वांसह, जर असेल तर संपूर्ण "`.hpkg" पॅकेज ड्रॅग करण्याचे सुचवा.

या श्रेणीमध्ये, मॅक स्पष्टपणे जिंकतो. निदान माझ्यासाठी तरी त्यांच्या प्रतिमेचा प्रियकर. हायकू कॉपी कराव्यात .hpkg अनुप्रयोगाऐवजी, परंतु सिस्टम मला हे ऑफर करत नाही ...

सर्व अवलंबनांसह पॅकेज डाउनलोड करत आहे

प्रत्येक मशीन नेहमी ऑनलाइन नसते. उलटपक्षी, काही मशीन्स (होय, मी तुमच्याकडे पाहत आहे, आधुनिक विंडोज, मॅक आणि लिनक्स) त्याबद्दल विसरतात. माझ्यासाठी हे महत्त्वाचे आहे की मी इंटरनेट कॅफेमध्ये जाऊ शकतो, उदाहरणार्थ, काढता येण्याजोग्या मीडियासाठी सॉफ्टवेअर डाउनलोड करा, हा मीडिया माझ्या होम कॉम्प्युटरमध्ये घाला आणि सर्वकाही कार्य करेल याची खात्री करा [जोखीम माणूस, विंडोजवर हे करा ... - अंदाजे . अनुवादक].

परिणामी, नेहमीपेक्षा किंचित जास्त वेळा, मी सहसा Windows आणि Linux वर न पूर्ण अवलंबित्वांसह समाप्त होतो.

Mac वर ही सहसा एक फाईल असते, आपल्याला फक्त डाउनलोड करण्याची आवश्यकता असते .dmg. बर्‍याचदा, मॅकओएस द्वारे डीफॉल्टनुसार प्रदान केलेल्या व्यतिरिक्त इतर कोणतेही अवलंबित्व नसते. अपवाद म्हणजे जटिल अनुप्रयोग ज्यांना योग्य रनटाइम वातावरण आवश्यक आहे, जसे की java.

हायकू वर पॅकेज डाउनलोड करा .hpkg त्याच java ऍप्लिकेशनसाठी, म्हणा, पुरेसा असू शकत नाही, कारण java लक्ष्य मशीनवर असू शकते किंवा नसू शकते. दिलेल्या पॅकेजसाठी सर्व अवलंबित्व डाउनलोड करण्याचा मार्ग आहे का? .hpkgहायकूमध्ये बाय डीफॉल्ट इन्स्टॉल केलेल्या आणि म्हणून प्रत्येक हायकू सिस्टीमवर असायला हवे त्या व्यतिरिक्त?

या प्रकारात, मॅक थोड्या फरकाने जिंकतो.

श्री यांनी टिप्पणी दिली. waddlesplash:

पॅकेजचा संच म्हणून ऍप्लिकेशनचे सर्व अवलंबन गोळा करण्यासाठी प्रोग्राम लिहिण्यासाठी .hpkg हायकूच्या अंतर्गत गोष्टींशी परिचित असलेल्या व्यक्तीसाठी, सुमारे 15 मिनिटे पुरेसे आहेत. याची खरी गरज असल्यास त्यासाठी समर्थन जोडणे इतके अवघड नाही. पण माझ्यासाठी हे दुर्मिळ आहे.

या मालिकेतील पुढील लेखापर्यंत आपला श्वास रोखून धरूया.

पॅकेजेस वेगळ्या ठिकाणी हलवत आहे

मी आधी लिहिल्याप्रमाणे, मला माझी पॅकेजेस ठेवायची आहेत .hpkg बूट व्हॉल्यूम (रूट विभाजन) वरील नेहमीच्या प्लेसमेंटपासून वेगळे (तसेच, किंवा त्यांचा भाग) विशिष्ट ठिकाणी. नेहमीच्या (इतके सैद्धांतिक नाही) बाबतीत, याचे कारण असे आहे की माझ्या (अंगभूत) ड्राइव्हस् कितीही मोठ्या असल्या तरी त्या सतत मोकळ्या जागेतून बाहेर पडत आहेत. आणि माझे ऍप्लिकेशन जिथे राहतात तिथे मी सहसा बाह्य ड्राइव्ह किंवा नेटवर्क शेअर्स मॅप करतो.

Mac वर मी फक्त पॅकेजेस हलवतो .app फाइंडरमधील काढता येण्याजोग्या ड्राइव्ह किंवा नेटवर्क निर्देशिकेवर, आणि तेच. मी साधारणपणे बूट व्हॉल्यूममधून करतो तसे अॅप उघडण्यासाठी मी अजूनही डबल-क्लिक करू शकतो. फक्त!

हायकू वर, मला सांगितल्याप्रमाणे, हे माझे हलवून प्राप्त केले जाऊ शकते .hpkg काढता येण्याजोग्या ड्राइव्ह किंवा नेटवर्क डिरेक्ट्रीमध्ये पॅकेजेस, परंतु नंतर सिस्टमवर माउंट करण्यासाठी तुम्हाला कन्सोलमध्ये काही कागदपत्र नसलेल्या आदेशांचा वापर करणे आवश्यक आहे. फक्त GUI वापरून ते कसे करायचे ते मला माहित नाही.

मॅक ही श्रेणी जिंकतो.

त्यानुसार श्री. waddlesplash:

हे सामान्य वापरावर आधारित ऑप्टिमायझेशन आहे. जर एकापेक्षा जास्त वापरकर्त्यांची मागणी असेल तर आम्ही त्याची अंमलबजावणी करू. कोणत्याही परिस्थितीत, तृतीय-पक्ष अंमलबजावणीची शक्यता आहे.

पुढील लेखात आपण याबद्दल बोलू.

नेटवर्क डिरेक्टरीबद्दल बोलायचे तर: साधे, शोधण्यायोग्य, नेटवर्क-व्यापी ऍप्लिकेशन्स (उदा. Zeroconf द्वारे) जे स्थानिक संगणकावर कॉपी केले जाऊ शकतात किंवा स्थानिक नेटवर्कवरून थेट चालवता येतील असे (मी LAN पक्षांचा अंदाज लावत आहे) चांगले होईल. अर्थात, विकसकांकडे याद्वारे निवड रद्द करण्याचा पर्याय आहे app_flags.

GUI सह hpkg प्रणालीच्या एकत्रीकरणाचा अंतिम अहवाल

मला असे वाटते की मुख्यतः एकीकरणाच्या सापेक्ष नवीनतेमुळे .hpkg GUI सह अजूनही बरेच काही हवे आहे. असं असलं तरी, UX च्या बाबतीत काही गोष्टी सुधारल्या जाऊ शकतात…

आणखी एक गोष्ट: कर्नल डीबग जमीन

कर्नल पॅनिक दरम्यान आदेश प्रविष्ट करण्यास सक्षम असणे चांगले होईल, उदाहरणार्थ syslog | grep usb. बरं, हायकूवर हे शक्य आहे कर्नल डीबग लँडमुळे. कर्नल घाबरून न जाता सर्व काही आपल्यासाठी जसे पाहिजे तसे कार्य करत असल्यास आपण ही जादू कृतीत कशी पाहू शकता? Alt+PrintScn+D (डीबग नेमोनिक) दाबून सहज. मला लगेच आठवते प्रोग्रामर की, ज्याने मूळ Macintosh विकासकांना डीबगरमध्ये प्रवेश करण्याची परवानगी दिली (जर एखादे स्थापित केले असेल, तर).

निष्कर्ष

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

माझ्या डोक्यात काहीतरी "स्विच" झाल्यासारखे होते आणि मला समजले की सिस्टम कशी आहे .hpkg फक्त तिच्याकडे बघून कसे दूर लोळायचे हे माहित आहे. पण हे मी नाही तर व्यवस्थेचे सौंदर्य आणि साधेपणा आहे. येथे बरेच काही मूळ मॅकच्या आत्म्याने ओतलेले आहे.

होय, ब्राउझरमध्ये ब्राउझ करणे धक्कादायक असू शकते आणि गोगलगायसारखे कार्य करू शकते, अनुप्रयोगांची कमतरता असू शकते (जीटीके, इलेक्ट्रॉन नाही - विकसकांनी निष्कर्ष काढला की ते अत्याधुनिकतेसह चांगले जात नाहीत), व्हिडिओ आणि 3 डी प्रवेग पूर्णपणे अनुपस्थित असू शकतात, परंतु तरीही मी ही प्रणाली आवडली. अखेर, या गोष्टी दुरुस्त केल्या जाऊ शकतात आणि लवकरच किंवा नंतर ते दिसून येतील. हे फक्त वेळ आणि कदाचित थोडे लाल डोळा बाब आहे.

मी मदत देऊ शकत नाही, परंतु मला वाटते की ते आतापासून सुरू होईल. डेस्कटॉपवर हायकूचे वर्ष.

यादृच्छिक समस्या

कदाचित आधीच अनुप्रयोग आहेत, किंवा मी ते उघडावे?

• BeScreenCapture पीक प्रमाणे GIF वर निर्यात करण्यास सक्षम असावे. हे हायकूसाठी आधीच उपलब्ध असलेल्या ffmpeg द्वारे केले जाऊ शकते. अर्ज.
• स्क्रीनशॉट टूल संपूर्ण स्क्रीन कॅप्चर करण्याऐवजी मॉडेल विंडोचा स्क्रीनशॉट घेण्यात अयशस्वी ठरते
• तुम्ही वंडरब्रशच्या क्रॉप टूलसह स्क्रीनशॉट क्रॉप करू शकत नाही आणि नंतर निकाल फाइलमध्ये सेव्ह करू शकत नाही
• मला हायकूमधला हँड कर्सर फारसा आवडत नाही, पण मला वाटतं की त्यात एक उबदार नॉस्टॅल्जिक फील आहे. कृतामध्ये क्रॉप टूल वापरताना हे विशेषतः त्रासदायक आहे, कारण यामुळे चुकीचे पीक येते (या लेखातील मोडल संवादांचे स्क्रीनशॉट पहा). क्रॉसहेअर कर्सर उत्तम असेल. अर्ज.

ते स्वतः वापरून पहा! शेवटी, हायकू प्रकल्प DVD किंवा USB वरून बूट करण्यासाठी प्रतिमा प्रदान करतो, व्युत्पन्न दररोज. स्थापित करण्यासाठी, फक्त प्रतिमा डाउनलोड करा आणि वापरून USB फ्लॅश ड्राइव्हवर बर्न करा Etcher

प्रश्न आहेत? आम्ही तुम्हाला रशियन भाषिकांना आमंत्रित करतो टेलिग्राम चॅनेल.

त्रुटी विहंगावलोकन: C आणि C++ मध्ये स्वतःला पायात कसे शूट करायचे. हायकू ओएस रेसिपी कलेक्शन

पासून लेखक अनुवाद: हायकू मालिकेतील हा सहावा लेख आहे.

लेखांची यादी: पहिला दुसरा तिसरे चौथा पाचवा

स्त्रोत: www.habr.com