ششمین روز من با هایکو: زیر پوشش منابع، نمادها و بسته ها

TL؛ DR: هایکو سیستم عاملی است که به طور خاص برای رایانه های شخصی طراحی شده است، بنابراین ترفندهای مختلفی دارد که محیط دسکتاپ آن را بسیار بهتر از سایرین می کند. اما چگونه کار می کند؟

تازه من هایکو را کشف کردم، یک سیستم غیرمنتظره خوب. من هنوز از عملکرد روان آن به خصوص در مقایسه با محیط های دسکتاپ لینوکس شگفت زده هستم. امروز نگاهی به زیر کاپوت می اندازم. در صورت لزوم برای درک عمیق، مقایسه‌ای با محیط‌های دسکتاپ اصلی Macintosh، Mac OS X و Linux انجام خواهم داد (استاندارد XDG از freedesktop.org).

منابع موجود در فایل های ELF

دیروز فهمیدم که IconOMatic می تواند آیکون ها را در منابع rdef در فایل های اجرایی ELF ذخیره کند. امروز می خواهم ببینم واقعا چگونه کار می کند.

منابع؟ نقل قول از بروس هورن، نویسنده اصلی مکینتاش یاب و "پدر" مدیر منابع مکینتاش:

من نگران ماهیت سفت و سخت کدنویسی سنتی هستم. برای من، ایده یک برنامه منجمد در کد، بدون توانایی تغییر هر چیزی به صورت پویا، وحشیانه ترین وحشیانه است. باید امکان تغییر تا حد امکان در زمان اجرا وجود داشته باشد. البته خود کد برنامه قابل تغییر نیست، اما مطمئناً می توان چیزی را بدون کامپایل مجدد کد تغییر داد؟

در مکینتاش اصلی، آنها این فایل‌ها را دارای یک «بخش داده» و یک «بخش منابع» ساختند که ذخیره مواردی مانند نمادها، ترجمه‌ها و مواردی از این قبیل را بسیار آسان کرد. در فایل های اجرایی

در مک از این استفاده می شود ویرایش مجدد، یک برنامه گرافیکی برای - به طور ناگهانی - ویرایش منابع.

ویرایش مجدد در مکینتاش اصلی

در نتیجه، امکان ویرایش آیکون ها، آیتم های منو، ترجمه ها و غیره فراهم شد. به اندازه کافی آسان است، اما آنها هنوز با برنامه ها "سفر می کنند".
در هر صورت، این رویکرد یک اشکال بزرگ داشت: فقط روی سیستم های فایل اپل کار می کرد، که یکی از دلایلی بود که اپل هنگام انتقال به Mac OS X، «بخش منابع» را رها کرد.
در Mac OS X، اپل یک راه حل مستقل از سیستم فایل می خواست، بنابراین آنها مفهوم بسته ها (از NeXT) را پذیرفتند، دایرکتوری هایی که توسط مدیر فایل به عنوان "اشیاء مات" در نظر گرفته می شوند، مانند فایل ها نه دایرکتوری ها. هر بسته با یک برنامه در قالب .app از جمله دارای یک فایل است Info.plist (به نوعی معادل JSON یا YAML اپل) حاوی ابرداده برنامه.

کلیدهای فایل Info.plist از بسته برنامه Mac OS X.

منابعی مانند آیکون ها، فایل های رابط کاربری و موارد دیگر در بسته به عنوان فایل ذخیره می شوند. این مفهوم در واقع به ریشه های خود در NeXT بازگشت.

Mathematica.app در NeXTSTEP 1.0 در سال 1989: به عنوان فهرستی از فایل ها در ترمینال ظاهر می شود، اما به عنوان یک شی واحد در مدیر فایل گرافیکی.

بیایید به BeOS برگردیم، مفاهیمی که هایکو بر اساس آنها ساخته شده است. توسعه دهندگان آن، هنگام تغییر از PEF (PowerPC) به ELF (x86) (همان چیزی که در لینوکس استفاده می شود)، تصمیم گرفتند یک بخش منبع را به انتهای فایل های ELF اضافه کنند. از بخش ELF مناسب خود استفاده نکرد، به سادگی به انتهای فایل ELF اضافه شد. در نتیجه برنامه strip و دیگران از binutils که از این موضوع آگاه نیستند، به سادگی آن را قطع می کنند. بنابراین، هنگام افزودن منابع به فایل ELF در BeOS، بهتر است آن را با ابزارهای لینوکس دستکاری نکنید.

حالا در مورد هایکو چه خبر است؟ اصولاً کم و بیش همینطور است.

در تئوری، امکان قرار دادن منابع در بخش مورد نظر ELF وجود دارد. به گفته توسعه دهندگان در کانال #haiku در irc.freenode.net:

با 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 "Hello, World" خود نیستم، آن را از Qt Creator بیرون می کشم.

/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 کار می کند. نمادهای نشان داده شده توسط سیستم (در Tracker و Deskbar) از این ویژگی توسعه یافته خوانده می شوند، زیرا این راه حل به سرعت کار می کند. در برخی مکان‌ها (جایی که سرعت مهم نیست، به عنوان مثال، یک پنجره معمولی «درباره»)، سیستم نماد را مستقیماً از منبع موجود در فایل دریافت می‌کند. اما این پایان کار نیست. به یاد داشته باشید، در مک، کاربران می توانند نمادهای برنامه ها، دایرکتوری ها، اسناد را با نمادهای خود جایگزین کنند، زیرا در مک می توان این موارد "مهم" را انجام داد. جایگزین کردن نماد Slack جدید با نماد قبلی. در هایکو، شما باید منبع (در فایل) را به عنوان نماد اصلی همراه با برنامه و ویژگی (در سیستم فایل BFS) به عنوان چیزی که به کاربر اجازه می دهد تا به میل خود تغییراتی ایجاد کند (هر چند، اشاره، رابط کاربری گرافیکی برای درج یک نماد سفارشی در بالای نماد اختیاری است).

بررسی ویژگی های سیستم فایل

با 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. وای! قبلاً اشاره کرده‌ام که فکر می‌کنم بخشی از پیچیدگی و سازگاری کلی هایکو از این واقعیت ناشی می‌شود که کل سیستم، از هسته و فضای کاربران اصلی گرفته تا مدیریت بسته‌ها و زیرساخت زمان اجرا، توسط یک تیم به طور مشترک توسعه می‌یابد. تصور کنید برای اجرای چنین چیزی در لینوکس چند گروه و تیم مختلف لازم است [من پروژه PuppyLinux را تصور می کنم - تقریبا. مترجم]. سپس تصور کنید چه مدت طول می کشد تا این رویکرد در توزیع ها اتخاذ شود. می گویند: یک مسئله ساده را بگیرید، آن را بین مجریان مختلف تقسیم کنید، آنقدر پیچیده می شود که دیگر حل آن ممکن نیست. هایکو در این مورد چشمانم را باز کرد. من فکر می کنم این دقیقاً همان چیزی است که اکنون در لینوکس اتفاق می افتد (لینوکس در این مورد یک اصطلاح جمعی برای پشته 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. دایرکتوری های "state..." حاوی فایل های متنی با نام بسته های فعال هستند و دایرکتوری های "transaction..." حاوی خود بسته ها هستند.

"حالت فعال قدیمی"، یعنی. فهرست .hpkg بسته های فعال قبل از تغییرات پس از هر عملیات در مدیر فایل در یک فایل متنی ثبت می شوند /Haiku/system/packages/administrative/state-<...>/activated-packages. به روشی مشابه، یک "وضعیت فعال" جدید در یک فایل متنی نوشته می شود /Haiku/system/packages/administrative/activated-packages.

راهنمای /Haiku/system/packages/administrative/state-<...>/ فقط حاوی یک فایل متنی با لیست بسته های فعال این حالت است (در صورت نصب بسته ها بدون حذف) و اگر بسته ها حذف یا به روز شدند - فهرست ایالت حاوی نسخه های قدیمی بسته ها است.

هنگامی که سیستم بوت می شود، بر اساس لیست بسته ها، تصمیم به فعال سازی (mount) بسته ها گرفته می شود. ساده است! اگر در حین دانلود مشکلی پیش آمد، می‌توانید به مدیر دانلود بگویید از فهرست قدیمی‌تری استفاده کند. مشکل حل شد!

دانلود کننده هایکو. هر نقطه ورودی یک "وضعیت فعال" مربوطه را نشان می دهد

من رویکرد داشتن فایل های متنی ساده را به عنوان لیست "وضعیت فعال" با نام هایی که به راحتی قابل درک هستند دوست دارم .hpkg. این در تضاد کامل با ساخت ماشین‌ها-نه-برای مردم است. دسته از OSTree یا Flatpak در سیستم فایل (در همان سطح Microsoft GUID).

لیست بسته های فعال برای هر نقطه در زمان

داده های پیکربندی

ظاهراً در کاتالوگ /Haiku/system/packages/administrative/writable-files حاوی فایل های پیکربندی برای بسته ها است، اما آنها قابل نوشتن هستند. پس از همه، همانطور که به یاد دارید، .hpkg نصب شده فقط خواندنی بنابراین این فایل ها باید قبل از نوشتن از روی بسته ها کپی شوند. معنی دارد.

یکپارچه سازی رابط کاربری گرافیکی برای سیستم hpkg

حالا بیایید ببینیم این کیف های براق چگونه هستند .hpkg با ادغام در محیط کار کاربر (UX) مقابله کنید. به هر حال، هایکو برای استفاده شخصی در نظر گرفته شده است. من شخصاً هنگام مقایسه تجربه کاربر با بسته ها، نوار را بالا می گذارم .app در مکینتاش با همین تجربه در .hpkg. من حتی وضعیت را با محیط های کاری در لینوکس مقایسه نمی کنم، زیرا در مقایسه با سایر محیط ها کاملاً وحشتناک است.

سناریوهای زیر به ذهن می رسد:

• من می خواهم محتویات یک بسته را ببینم .hpkg
• من می خواهم یک پکیج نصب کنم
• من می خواهم بسته را حذف کنم
• من می خواهم چیزی را که به عنوان بخشی از یک بسته وارد سیستم شده است حذف کنم
• من می خواهم چیزی را که به عنوان بخشی از یک بسته وارد سیستم شده است کپی کنم
• من می‌خواهم تمام وابستگی‌های یک بسته را دانلود کنم، که ممکن است بخشی از هر نصب هایکو نباشد (به عنوان مثال، من یک دستگاه فیزیکی ایزوله بدون دسترسی به اینترنت دارم.)
• من می خواهم بسته های خود (یا بخشی از آنها) را جداگانه به مکان دیگری جدا از حجم بوت (پارتیشن ریشه) منتقل کنم (چون مثلاً فضای کافی روی آن ندارم).

این باید بیشتر موارد اصلی را از کار روزانه من پوشش دهد. خوب، بیایید شروع کنیم.

بررسی محتویات بسته

در مک من به سادگی روی بسته کلیک راست می کنم تا باز شود و محتویات آن در Finder مشاهده شود. پس از همه، در واقعیت این فقط یک فهرست پنهان است! (می دانم که بسته هایی وجود دارد .pkg برای بخشی از سیستم که برنامه کاربردی نیست، اما کاربران عادی اغلب با آنها تعامل ندارند).

روی هایکو من روی بسته کلیک راست می کنم، سپس روی "محتواها" کلیک می کنم تا ببینم داخل آن چیست. اما در اینجا فقط لیستی از فایل ها وجود دارد که امکان باز کردن آنها با دوبار کلیک وجود ندارد.
اگر راهی برای (موقت) سوار کردن بسته وجود داشت خیلی بهتر بود .hpkg از طریق یک مدیر فایل مشاهده شود و کاربر نگران جزئیات پیاده سازی نباشد. (به هر حال، می توانید باز کنید .hpkg بسته در Expander، که می تواند آن را مانند هر آرشیو دیگری باز کند).

رابط HaikuDepot به شما امکان می دهد لیستی از فایل های بسته را مشاهده کنید، اما هیچ راهی برای مشاهده محتویات، به عنوان مثال، دوبار کلیک کردن بر روی README.md وجود ندارد.

Mac در این رده برنده است، اما افزودن قابلیت HaikuDepot مورد نظر شما نباید خیلی سخت باشد.

نصب بسته از طریق رابط کاربری گرافیکی

در مک، اکثر تصاویر دیسک .dmg حاوی بسته ها .app. روی تصویر دیسک دوبار کلیک کنید و سپس بسته را برای مثال با کشیدن آن به داخل کپی کنید /Applications در Finder. این برای من ناگفته نماند، اما شنیده ام که برخی از تازه کارها ممکن است نتوانند از عهده این کار برآیند. به طور پیش فرض، اپل یک دایرکتوری در سطح سیستم را "پیشنهاد" می کند /Applications (در NeXT شبکه ای و فردی بود)، اما می توانید به راحتی برنامه های خود را در یک سرور فایل یا در یک زیر شاخه قرار دهید. $HOME/Applications، اگر آن را دوست دارید.

روی هایکو، روی بسته دوبار کلیک کنید، سپس روی "Install" کلیک کنید، این کار ساده تر نیست. من نمی‌پرسم اگر بسته‌ای وابستگی‌هایی داشته باشد که در HaikuPorts موجود هستند اما هنوز نصب نشده‌اند، چه اتفاقی می‌افتد. در لینوکس آنها واقعا نمی دانند در این شرایط چه کاری انجام دهند، اما راه حل واضح است - از کاربر بپرسید که آیا نیاز به دانلود و نصب وابستگی دارد یا خیر. دقیقا کاری که هایکو انجام می دهد.

من بسته 'sanity' را به صورت دستی دانلود کردم و روی آن کلیک کردم، مدیر بسته می داند که وابستگی های آن را از کجا دریافت کند (با فرض اینکه مخازن قبلاً در سیستم ثبت شده باشند). هر توزیع لینوکس نمی تواند این کار را انجام دهد.

راه دیگر استفاده از فایل منیجر است، فقط بکشید و رها کنید .hpkg بسته یا در /Haiku/system/packages (برای نصب در سراسر سیستم، به طور پیش فرض)، یا در /Haiku/home/config/packages (برای نصب انفرادی؛ هنگام دوبار کلیک کردن در دسترس نیست - من هنوز از کلمه "config" در این مکان آزارم می دهد، که برای من در این مورد مترادف با "تنظیمات" است). و مفهوم چندین کاربر حتی برای هایکو هنوز در دسترس نیست (احتمالاً به همین دلیل است که بسیار ساده است - نمی دانم، شاید قابلیت های چند کاربره به طور غیر ضروری همه چیز را برای محیط دسکتاپ دسکتاپ پیچیده کند).

هایکو در این رده برنده می شود زیرا می تواند نه تنها با برنامه ها، بلکه با برنامه های سیستمی نیز کار کند.

حذف یک بسته از رابط کاربری گرافیکی

در مک، باید نماد برنامه را به سطل زباله بکشید، و تمام. به آسانی!

روی هایکو، ابتدا باید محل قرارگیری بسته را در سیستم پیدا کنید، زیرا به ندرت آن را در مکان مناسب نصب می کنید (سیستم همه کارها را انجام می دهد). معمولاً باید به داخل نگاه کنید /Haiku/system/packages (با نصب پیش فرض در سراسر سیستم)، یا در /Haiku/home/config/packages (آیا من اشاره کردم که "پیکربندی" یک نام اشتباه است؟). سپس برنامه به سادگی به سطل زباله کشیده می شود و تمام.
به آسانی! با این حال، من این را نمی گویم. در اینجا چیزی است که واقعاً اتفاق می افتد:

اگر برنامه ای را از داخل سطل زباله بکشید، این اتفاق می افتد /Haiku/system/packages

فقط سعی کردم برنامه دیروز "Hello World" خود را در QtQuickApp به سطل زباله منتقل کنم. من سعی نکردم دایرکتوری سیستم را جابجا کنم، و از آنجایی که تمام بسته ها در دایرکتوری سیستم نصب شده اند، حذف بسته غیرممکن است .hpkg بدون تغییر "محتوای آن". یک کاربر معمولی می ترسد و دکمه "لغو" را که به طور پیش فرض اختصاص داده شده است فشار می دهد.

توضیح می دهد آقای. آب پاش:

این پست بیش از 10 سال است. به احتمال زیاد ما باید آن را به گونه ای پیکربندی کنیم که اخطار فقط زمانی ظاهر شود که خود بسته منتقل شود. به هر حال کاربران عادی نیازی به انجام این کار ندارند.

خوب، شاید باید این کار را با استفاده از HaikuDepot انجام دهم؟ روی بسته داخل دابل کلیک می کنم /Haiku/system/packages، منتظر ظاهر شدن دکمه «حذف نصب» باشید. خیر، (فقط) "نصب" وجود دارد. "حذف"، کجا هستید؟

فقط برای سرگرمی، سعی کردم ببینم اگر روی "نصب" روی یک بسته از قبل نصب شده کلیک کنم چه اتفاقی می افتد. اینطور معلوم می شود:

اگر بخواهید یک بسته از قبل نصب شده را نصب کنید، این اتفاق می افتد.

بعدی ظاهر می شود:

اگر در پنجره قبلی روی "اعمال تغییرات" کلیک کنید، به این شکل خواهد بود

من فرض می‌کنم که این یک خطای نرم‌افزاری است؛ پیوند برنامه قبلاً وجود دارد. [نویسنده پیوندی ارائه نکرده است - تقریباً. مترجم]

راه حل سریع: اگر بسته از قبل در دسترس است، دکمه «حذف نصب» را اضافه کنید /Haiku/system/packages، یا در /Haiku/home/config/packages.

هنگام مشاهده لیست بسته های نصب شده در HaikuDepot، بسته خود را در لیست می بینم و می توانم آن را حذف کنم.

مک در این رده برنده است. اما می توانم تصور کنم که با راه اندازی مناسب، تجربه کاربری در هایکو بهتر از مک خواهد بود. (یکی از توسعه دهندگان آن را اینگونه ارزیابی کرد: "کمتر از یک ساعت برای افزودن عملکرد مشخص شده به HaikuDepot، اگر کمی C++ می دانید"، هیچ داوطلبی؟)

برداشتن چیزی از یک بسته

بیایید سعی کنیم خود برنامه را حذف کنیم، نه بسته را .hpkg، که از آن آمده است (من شک دارم که برای "فانیان صرف" تفاوتی وجود داشته باشد).

در مک، کاربر در واقع معمولاً با فایل کار می کند .dmgبسته برنامه از کجا می آید .app. معمولا تصاویر .dmg در دایرکتوری دانلودها جمع می شوند و بسته ها توسط کاربر کپی می شوند /Applications. اعتقاد بر این است که بسیاری از کاربران خود نمی دانند چه کار می کنند، این فرضیه توسط یکی از کارمندان سابق اپل تأیید شده است. (یکی از چیزهایی که من در مک دوست ندارم. و مثلاً با AppImage هیچ تفاوتی بین برنامه و بسته ای که در آن بود وجود ندارد. نماد را به سطل زباله بکشید = همین. آسان است!)

روی هایکو، همچنین یک تقسیم بین وجود دارد apps/ и packages/، بنابراین من شک دارم که این موضوع برای کاربران واضح تر شده باشد. اما چه اتفاقی می افتد اگر یک برنامه را از آن بکشید apps/ افزودن به سبد خرید:

این چیزی است که زمانی اتفاق می افتد که شما سعی می کنید یک برنامه را از یک فایل حذف کنید .hpkg

از نظر فنی درست است (بالاخره، برنامه در وهله اول بر روی یک سیستم فایل فقط خواندنی میزبانی می شود)، اما به خصوص برای کاربر مفید نیست.

راه حل سریع: پیشنهاد کنید به جای آن از رابط کاربری گرافیکی برای حذف استفاده کنید .hpkg

فقط برای سرگرمی، سعی کردم با فشار دادن Alt+D برنامه را کپی کنم. من پیام "نمی توان به جابجایی یا کپی اشیاء در یک حجم فقط خواندنی" دریافت کرد. و همه به این دلیل /system (بعلاوه /system/packages и /system/settings) نقطه اتصال packagefs است (به یاد داشته باشید که چگونه در خروجی ظاهر می شود df؟). متاسفانه خروجی دستور mount وضعیت را روشن نمی کند (همانطور که در یکی از مقالات قبلی گفته شد) mountvolume آنچه شما به دنبال آن هستید را نشان نمی دهد (ظاهراً بسته هایی که از طریق حلقه نصب شده اند .hpkg "حجم" در نظر گرفته نمی شوند)، و من دستورات جایگزین را نیز فراموش کردم.

هیچ کس در این رده به جز AppImage برنده نشد (اما این، کاملاً صادقانه است، یک نظر مغرضانه است). با این حال، می توان تصور کرد که پس از بهینه سازی، تجربه کاربری در هایکو بهتر از مک خواهد بود.

توجه: باید دریابید که "جلد" در رابطه با "بخش" چیست. این احتمالاً شبیه رابطه "پوشه" با "دایرکتوری" است: بیشتر دایرکتوری ها به عنوان پوشه در مدیر فایل ظاهر می شوند، اما نه همه آنها (مثلاً بسته هایی که به عنوان فایل در نظر گرفته می شوند). آیا این نوع نمایشگر باعث می شود که من یک نرد رسمی باشم؟

کپی کردن محتویات یک بسته در سیستم دیگری

در مک، من احمقانه بسته را می کشم .app، و از آنجایی که وابستگی ها داخل بسته هستند، با هم حرکت می کنند.

روی هایکو، برنامه را درگ می کنم، اما وابستگی ها اصلا پردازش نمی شوند.

راه حل سریع: به جای آن پیشنهاد می کنیم کل بسته hpkg .hpkg را همراه با هر وابستگی، در صورت وجود، بکشید.

مک به وضوح در این رده برنده است. حداقل برای من که عاشق پارادایم آنها هستم. من باید آن را در هایکو کپی کنم .hpkg به جای یک برنامه، اما سیستم این را به من ارائه نمی دهد ...

دانلود یک بسته با تمام وابستگی های آن

هر ماشینی همیشه به شبکه متصل نیست. برعکس، برخی از ماشین ها (بله، من به شما نگاه می کنم، ویندوز، مک و لینوکس مدرن) این را فراموش می کنند. برای من مهم است که می توانم مثلاً به یک کافی نت بروم، نرم افزار را روی یک درایو قابل جابجایی دانلود کنم، این درایو را در رایانه خانه خود قرار دهم و مطمئن باشم که همه چیز درست می شود [مرد خطرناک، این کار را در ویندوز انجام می دهد... - تقریبا مترجم].

در نتیجه، من تمایل دارم کمی بیشتر از حد معمول با وابستگی های برآورده نشده به ویندوز و لینوکس مواجه شوم.

در مک این معمولا یک فایل است، تنها کاری که باید انجام دهید این است که دانلود کنید .dmg. اغلب، هیچ وابستگی دیگری به جز وابستگی هایی که توسط خود MacOS به طور پیش فرض ارائه می شود، ندارد. یک استثنا برنامه های پیچیده ای هستند که به یک محیط اجرای مناسب نیاز دارند، به عنوان مثال جاوا.

روی هایکو دانلود بسته .hpkg برای مثال، همان کاربرد در جاوا، ممکن است کافی نباشد، زیرا جاوا ممکن است در ماشین هدف وجود داشته باشد یا نباشد. آیا راهی برای دانلود همه وابستگی ها برای یک بسته مشخص وجود دارد؟ .hpkg، غیر از آنهایی که به طور پیش فرض در هایکو نصب می شوند و بنابراین باید روی هر سیستم هایکو باشند؟

مک با اختلاف اندکی برنده این رده است.

نظرات آقای waddlesplash:

برای نوشتن برنامه ای برای جمع آوری تمام وابستگی های یک برنامه به عنوان مجموعه ای از بسته ها .hpkg برای کسی که با کارهای درونی هایکو آشناست، حدود 15 دقیقه کافی است. در صورت نیاز واقعی، افزودن پشتیبانی برای این کار چندان دشوار نیست. اما برای من این یک موقعیت نادر است.

تا مقاله بعدی این مجموعه نفس خود را حبس کنیم.

انتقال بسته ها به مکان جداگانه

همانطور که قبلاً نوشتم، می خواهم بسته های خود را قرار دهم .hpkg (خوب، یا بخشی از آنها) به یک مکان خاص، جدا از قرار دادن معمول در حجم بوت (پارتیشن ریشه). در حالت معمولی (نه چندان تئوری)، دلیل این امر این است که من دائماً فضای خالی دیسک های (توکار) خود را، صرف نظر از اینکه چقدر بزرگ هستند، تمام می شود. و من معمولاً درایوهای خارجی یا اشتراک‌گذاری‌های شبکه را در جایی که برنامه‌هایم قرار دارند وصل می‌کنم.

در مک من فقط بسته ها را جابجا می کنم .app به یک درایو قابل جابجایی یا دایرکتوری شبکه در Finder، و تمام. من همچنان می‌توانم برای باز کردن برنامه، همانطور که معمولاً از حجم بوت انجام می‌دهم، دوبار کلیک کنم. فقط!

روی هایکوهمانطور که به من گفته شد، با جابجایی من می توان به این امر دست یافت .hpkg بسته ها را به یک درایو قابل جابجایی یا دایرکتوری شبکه می فرستند، اما پس از آن باید از برخی دستورات غیرمستند در کنسول استفاده کنید تا آنها را روی سیستم نصب کنید. من نمی دانم چگونه این کار را فقط با استفاده از رابط کاربری گرافیکی انجام دهم.

مک در این رده برنده است.

به گفته آقای waddlesplash:

این یک بهینه سازی مبتنی بر استفاده معمولی است. در صورت وجود تقاضا از سوی بیش از یک کاربر، آن را اجرا می کنیم. در هر صورت امکان اجرای شخص ثالث وجود دارد.

در مقاله بعدی در این مورد صحبت خواهیم کرد.

در مورد دایرکتوری های شبکه، بسیار عالی است (من حدس می زنم احزاب LAN) داشتن برنامه های کاربردی ساده، قابل کشف و گسترده در شبکه (مانند Zeroconf) که می توانند در رایانه محلی کپی شوند یا مستقیماً از شبکه محلی اجرا شوند. البته، توسعه دهندگان این گزینه را دارند که از طریق آن انصراف دهند app_flags.

گزارش نهایی در مورد ادغام سیستم hpkg با رابط کاربری گرافیکی

من فکر می کنم که در درجه اول به دلیل جدید بودن ادغام است .hpkg رابط کاربری گرافیکی هنوز چیزهای زیادی برای دلخواه باقی می گذارد. به هر حال، چند چیز وجود دارد که از نظر UX قابل بهبود است...

یک چیز دیگر: Kernel Debug Land

برای مثال، اگر بتوانیم دستورات را در هنگام وحشت هسته وارد کنیم، عالی خواهد بود syslog | grep usb. خوب، در هایکو به لطف سرزمین اشکال زدایی هسته این امکان وجود دارد. چگونه می توانید این جادو را در عمل ببینید اگر همه چیز همانطور که باید بدون وارد شدن به وحشت هسته کار کند؟ با فشار دادن Alt+PrintScn+D (اشکال زدایی یادداشت) آسان است. بلافاصله یادم می آید کلید برنامه نویس، که به توسعه دهندگان اصلی مکینتاش اجازه می داد وارد دیباگر شوند (البته اگر یکی نصب شده بود).

نتیجه

من شروع به درک این موضوع کردم که پیچیدگی سیستم هایکو از این واقعیت ناشی می شود که کار توسط یک تیم کوچک با تمرکز واضح بر محیط کار انجام می شود و همه لایه های سیستم در دسترس هستند.
تضاد شدید با دنیای Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu، جایی که همه چیز به اندازه‌ای به قطعات کوچک تقسیم می‌شود که انتزاع روی انتزاع می‌نشیند و با عصا حرکت می‌کند.
همچنین درک درستی از نحوه سیستم وجود داشت .hpkg بهترین شیوه‌های مدیران بسته‌های سنتی، Snappy، Flatpak، AppImage، حتی btrfs را ترکیب می‌کند و آنها را با رویکرد "فقط کار می‌کند" مک ترکیب می‌کند.

انگار چیزی در سرم "تغییر" کرد و من متوجه شدم که چگونه سیستم .hpkg فقط با نگاه کردن به او می‌داند که چگونه دور شود. اما این من نیستم، بلکه زیبایی و سادگی سیستم هستم. بیشتر اینها از روح مک اصلی الهام گرفته شده است.

بله، مرور در مرورگر ممکن است تند باشد و مانند یک حلزون اجرا شود، ممکن است برنامه ها کم باشند (بدون Gtk، Electron - توسعه دهندگان به این نتیجه رسیدند که با پیچیدگی خوب پیش نمی روند)، ویدئو و شتاب سه بعدی ممکن است کاملاً وجود نداشته باشد، اما من هنوز این سیستم را دوست دارد بالاخره این موارد قابل اصلاح هستند و دیر یا زود ظاهر می شوند. این فقط یک مسئله زمان است و شاید کمی قرمزی چشم.

من نمی توانم کمکی ارائه کنم، اما فکر می کنم از این به بعد شروع شود سال هایکو روی دسکتاپ.

مشکلات تصادفی

شاید از قبل درخواست هایی وجود داشته باشد یا باید آنها را باز کنم؟

• BeScreenCapture باید بتواند مانند Peek به GIF صادر کند. این را می توان با استفاده از ffmpeg که از قبل برای هایکو موجود است انجام داد. کاربرد.
• نرم افزار اسکرین شات نمی تواند یک پنجره مودال را بگیرد، در عوض کل صفحه را می گیرد
• با استفاده از ابزار برش WonderBrush نمی توانید اسکرین شات ها را برش دهید و سپس نتیجه را در یک فایل ذخیره کنید
• من مکان‌نمای دستی در هایکو را دوست ندارم، اما فکر می‌کنم به حس نوستالژیک گرم مربوط می‌شود. این به ویژه هنگام استفاده از ابزار برش در Krita آزاردهنده است، زیرا منجر به برش نادرست می شود (تصاویر از دیالوگ های مدال را در این مقاله ببینید). مکان نما متقاطع فوق العاده خواهد بود. کاربرد.

خودت آن را امتحان کن! پس از همه، پروژه هایکو تصاویری را برای بوت شدن از DVD یا USB، تولید شده فراهم می کند روزانه. برای نصب، کافی است تصویر را دانلود کرده و با استفاده از درایو فلش USB آن را رایت کنید اتچر

سوالاتی دارید؟ شما را به روسی زبان دعوت می کنیم کانال تلگرام.

نمای کلی خطا: چگونه در C و C++ به پای خود شلیک کنید. مجموعه دستور العمل هایکو سیستم عامل

از نویسنده ترجمه: این ششمین مقاله از مجموعه در مورد هایکو است.

فهرست مقالات: ابتدا دوم Третья چهارم پنجم

منبع: www.habr.com