چیز دیگری: بسته های برنامه هایکو؟

TL؛ DR: آیا هایکو می‌تواند پشتیبانی مناسبی از بسته‌های برنامه‌ها، مانند فهرست‌های برنامه (مانند .app در مک) و/یا تصاویر برنامه (لینوکس AppImage)؟ من فکر می‌کنم این افزودنی ارزشمند است که اجرای صحیح آن نسبت به سایر سیستم‌ها آسان‌تر است، زیرا بیشتر زیرساخت‌ها در حال حاضر در محل هستند.

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

برای درک کامل، من خالق و نویسنده AppImage هستم، یک قالب توزیع برنامه لینوکس که هدف آن سادگی مک است و کنترل کامل را به نویسندگان برنامه و کاربران نهایی می دهد (اگر می خواهید بیشتر بدانید، نگاه کنید به ویکی и مستندات).

اگر یک AppImage برای هایکو بسازیم چطور؟

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

در سیستم مکینتاش 1، هر برنامه یک فایل جداگانه "مدیریت" در Finder بود. با استفاده از AppImage من سعی می کنم همان تجربه کاربری را در لینوکس دوباره ایجاد کنم.

ابتدا، AppImage چیست؟ این یک سیستم برای انتشار برنامه های شخص ثالث است (به عنوان مثال، Ultimaker Cure)، به برنامه‌ها اجازه می‌دهد در زمان و به‌صورتی که می‌خواهند منتشر شوند: نیازی به دانستن ویژگی‌های توزیع‌های مختلف، خط‌مشی‌های ساخت یا ساخت زیرساخت نیست، به پشتیبانی نگهدارنده نیاز نیست، و به کاربران نمی‌گویند چه چیزی (نه) می‌توانند نصب کنند. روی کامپیوترهایشان AppImage را باید چیزی شبیه به یک بسته مک در قالب درک کرد .app داخل تصویر دیسک .dmg. تفاوت اصلی این است که برنامه ها کپی نمی شوند، اما برای همیشه در AppImage باقی می مانند، تقریباً مانند بسته های هایکو. .hpkg نصب شده است و هرگز به معنای معمول نصب نشده است.

در طول بیش از 10 سال عمر، AppImage تا حدی جذابیت و محبوبیت پیدا کرده است: خود لینوس توروالدز به طور عمومی آن را تأیید کرد و پروژه های رایج (به عنوان مثال، LibreOffice، Krita، Inkscape، Scribus، ImageMagick) آن را به عنوان راه اصلی پذیرفته اند. برای توزیع ساخت‌های پیوسته یا شبانه، بدون تداخل با برنامه‌های کاربر نصب‌شده یا حذف‌شده. با این حال، محیط‌ها و توزیع‌های دسک‌تاپ لینوکس اغلب همچنان به مدل توزیع سنتی و متمرکز مبتنی بر نگهدارنده می‌چسبند و/یا تجارت سازمانی و/یا برنامه‌های مهندسی خود را بر اساس تختپاک (RedHat، Fedora، GNOME) و اسنیپت (کانونیکال، اوبونتو). می آید به طرز مسخره ای.

چگونه همه کار می کند

• هر AppImage شامل 2 قسمت است: یک ELF کوچک دوبار کلیک (به اصطلاح. runtime.c)، به دنبال آن یک تصویر سیستم فایل SquashFS.

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

• زمانی که کاربر اجرا می کند، زمان اجرا از FUSE و squashfuse برای نصب فایل سیستم استفاده می کند و سپس برخی از نقاط ورودی (معروف به AppRun) را در داخل AppImage نصب شده کنترل می کند.
  پس از اتمام فرآیند، فایل سیستم از حالت نصب خارج می شود.

به نظر می رسد همه چیز ساده است.

و این چیزها همه چیز را پیچیده می کند:

• با چنین تنوعی از توزیع‌های لینوکس، هیچ چیز «در ذهن درست» را نمی‌توان «بخشی از نصب پیش‌فرض برای هر سیستم هدف جدید» نامید. ما با ساختن این موضوع را حل می کنیم فهرست حذف، به شما این امکان را می دهد که تعیین کنید چه چیزی در AppImage بسته بندی می شود و چه چیزی باید به جای دیگری برده شود. در عین حال، ما گاهی اوقات دلتنگ می شویم، علیرغم این واقعیت که، به طور کلی، همه چیز عالی کار می کند. به همین دلیل، ما به سازندگان بسته توصیه می‌کنیم AppImages را در تمام سیستم‌های هدف (توزیع) آزمایش کنند.
• بارهای برنامه باید در سراسر سیستم فایل قابل جابجایی باشند. متأسفانه، بسیاری از برنامه‌ها دارای مسیرهای مطلق کدگذاری شده برای مثال، منابع هستند /usr/share. این باید یه جوری درست بشه علاوه بر این، شما باید یا صادر کنید LD_LIBRARY_PATH، یا رفع کنید rpath تا لودر بتواند کتابخانه های مرتبط را پیدا کند. روش اول دارای اشکالاتی است (که به روش های پیچیده برطرف می شوند) و روش دوم به سادگی دست و پا گیر است.
• بزرگترین تله UX برای کاربران این است بیت اجرایی را تنظیم کنید فایل AppImage پس از دانلود. باور کنید یا نه، این یک مانع واقعی برای برخی است. نیاز به تنظیم بیت اجرایی حتی برای کاربران باتجربه نیز دشوار است. به عنوان یک راه حل، ما نصب یک سرویس کوچک را پیشنهاد کردیم که فایل های AppImage را نظارت می کند و بیت اجرایی آنها را تنظیم می کند. در شکل خالص خود، بهترین راه حل نیست، زیرا خارج از جعبه کار نخواهد کرد. توزیع‌های لینوکس این سرویس را ارائه نمی‌دهند، بنابراین، کاربران تجربه بدی دارند.
• کاربران لینوکس انتظار دارند که یک برنامه جدید یک نماد در منوی راه اندازی داشته باشد. شما نمی توانید به سیستم بگویید: "ببین، یک برنامه جدید وجود دارد، بیایید کار کنیم." در عوض، با توجه به مشخصات XDG، باید فایل را کپی کنید .desktop به مکان مناسب در /usr برای نصب در سراسر سیستم، یا در $HOME برای فردی آیکون هایی با اندازه های خاص، با توجه به مشخصات XDG، باید در مکان های خاصی قرار گیرند usr یا $HOMEو سپس دستورات را در محیط کاری اجرا کنید تا کش آیکون را به روز کنید، یا امیدوار باشید که مدیر محیط کاری آن را بفهمد و به طور خودکار همه چیز را شناسایی کند. در مورد انواع MIME هم همینطور. به عنوان یک راه حل، پیشنهاد می شود از همان سرویس استفاده شود که علاوه بر تنظیم پرچم اجرایی، در صورت وجود آیکون ها و غیره، این کار را انجام می دهد. در AppImage، آنها را از AppImage در مکان های مناسب مطابق با XDG کپی کنید. در صورت حذف یا جابجایی، انتظار می رود این سرویس همه چیز را پاک کند. البته در رفتار هر محیط کاری، در فرمت فایل های گرافیکی، اندازه، محل ذخیره سازی و روش های به روز رسانی کش ها تفاوت هایی وجود دارد که مشکل ایجاد می کند. به طور خلاصه، این روش یک عصا است.
• اگر موارد بالا کافی نیست، هنوز هیچ نماد AppImage در مدیر فایل وجود ندارد. دنیای لینوکس هنوز تصمیمی برای پیاده سازی elficon (با وجود بحث и پیاده سازی، بنابراین نمی توان نماد را مستقیماً در برنامه جاسازی کرد. بنابراین معلوم می شود که برنامه های موجود در فایل منیجر آیکون های خود را ندارند (بدون تفاوت، AppImage یا چیز دیگری)، آنها فقط در منوی شروع هستند. به عنوان یک راه حل، ما از تصاویر کوچک استفاده می کنیم، مکانیزمی که در اصل برای مدیران دسکتاپ طراحی شده بود تا تصاویر پیش نمایش بند انگشتی فایل های گرافیکی را به عنوان نماد خود نشان دهند. در نتیجه، سرویس تنظیم بیت اجرایی نیز به‌عنوان «کوچک‌ساز» کار می‌کند و تصاویر کوچک آیکون‌ها را در مکان‌های مناسب ایجاد و می‌نویسد. /usr и $HOME. این سرویس همچنین در صورت حذف یا جابجایی AppImage پاکسازی را انجام می دهد. با توجه به این واقعیت که هر مدیر دسکتاپ کمی متفاوت رفتار می کند، به عنوان مثال، در چه قالب هایی آیکون ها را می پذیرد، در چه اندازه ها یا مکان هایی، این همه واقعا دردناک است.
• در صورت بروز خطا، برنامه به سادگی هنگام اجرا از کار می افتد (به عنوان مثال، کتابخانه ای وجود دارد که بخشی از سیستم پایه نیست و در AppImage ارائه نشده است)، و هیچ کس در رابط کاربری گرافیکی به کاربر نمی گوید که دقیقاً چه اتفاقی می افتد. ما شروع به دور زدن این با استفاده کردیم اعلان ها در دسکتاپ، به این معنی که ما باید خطاها را از خط فرمان دریافت کنیم، آنها را به پیام هایی تبدیل کنیم که توسط کاربر قابل درک است، که سپس باید روی دسکتاپ نمایش داده شوند. و البته، هر محیط دسکتاپ کمی متفاوت با آنها رفتار می کند.
• در حال حاضر (سپتامبر 2019 - یادداشت مترجم) من یک راه ساده برای اینکه به سیستم بگویم فایل 1.png باید با استفاده از Krita باز شود، و 2.png - استفاده از GIMP

محل ذخیره برای مشخصات دسکتاپ متقابل مورد استفاده در گنوم, KDE и Xfce freedesktop.org است

دستیابی به سطحی از پیچیدگی که عمیقاً در محیط کار هایکو بافته شده است، به دلیل مشخصات، اگر غیرممکن نباشد، دشوار است. XDG از freedesktop.org برای کراس دسکتاپ و همچنین پیاده سازی مدیران دسکتاپ بر اساس این مشخصات. به عنوان مثال، می‌توانیم یک نماد فایرفاکس در سراسر سیستم را ذکر کنیم: ظاهراً نویسندگان XDG حتی فکر نمی‌کردند که یک کاربر می‌تواند چندین نسخه از یک برنامه مشابه را نصب کند.

آیکون های نسخه های مختلف فایرفاکس

من در این فکر بودم که دنیای لینوکس چه چیزی می تواند از Mac OS X بیاموزد تا از یکپارچگی سیستم جلوگیری کند. اگر وقت دارید و به این موضوع علاقه دارید، حتماً آنچه را که Arnaud Gurdol، یکی از اولین مهندسان Mac OS X گفته است، بخوانید:

ما می‌خواستیم نصب برنامه را به سادگی کشیدن نماد برنامه از جایی (سرور، درایو خارجی) روی درایو رایانه‌تان آسان کنیم. برای انجام این کار، بسته برنامه تمام اطلاعات، از جمله نمادها، نسخه، نوع فایل در حال پردازش، نوع طرح‌های URL را که سیستم برای پردازش برنامه باید بداند، ذخیره می‌کند. این همچنین شامل اطلاعات مربوط به "ذخیره سازی مرکزی" در پایگاه داده خدمات نماد و سرویس راه اندازی می شود. برای پشتیبانی از عملکرد، برنامه‌ها در چندین مکان «مشهور» «کشف» می‌شوند: دایرکتوری‌های برنامه‌های کاربردی سیستم و کاربر، و برخی دیگر به صورت خودکار اگر کاربر به Finder در فهرست حاوی برنامه هدایت شود. در عمل این خیلی خوب کار کرد.

https://youtu.be/qQsnqWJ8D2c
جلسه 2000 Apple WWDC 144 - Mac OS X: بسته بندی برنامه ها و چاپ اسناد.

هیچ چیزی شبیه به این زیرساخت در دسکتاپ های لینوکس وجود ندارد، بنابراین ما به دنبال راه حل هایی در مورد محدودیت های ساختاری در پروژه AppImage هستیم.

آیا هایکو به کمک می آید؟

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

گزارش من در مورد مشکلات محیط های دسکتاپ لینوکس در سال 2018

حتی لینوس توروالدز اعتراف کرد که چندپارگی دلیل شکست ایده فضای کاری بود.

از دیدن هایکو خوشحالم!

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

در حالی که رویکرد ساده لوحانه برای "انتقال" AppImage به هایکو این است که به سادگی سعی کنید اجزای آن را بسازید (عمدتاً runtime.c و سرویس) (که ممکن است حتی ممکن باشد!)، این کار سود زیادی برای هایکو به همراه نخواهد داشت. زیرا در واقع اکثر این مشکلات در هایکو حل می شود و از نظر مفهومی صحیح است. هایکو دقیقاً بلوک‌های ساختمان زیرساخت سیستمی را ارائه می‌کند که من مدت‌ها در محیط‌های دسکتاپ لینوکس به دنبال آن بودم و نمی‌توانستم باور کنم وجود نداشته باشد. برای مثال:

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

• فایل‌های ELF که بیت اجرایی ندارند، با دوبار کلیک کردن در مدیر فایل، به‌طور خودکار یک بیت اجرایی دریافت می‌کنند.
• برنامه ها می توانند منابع داخلی مانند نمادهایی داشته باشند که در مدیر فایل نمایش داده می شوند. نیازی به کپی کردن دسته ای از تصاویر در فهرست های خاص با آیکون نیست و بنابراین نیازی به پاکسازی آنها پس از حذف یا جابجایی برنامه نیست.
• یک پایگاه داده برای پیوند برنامه ها با اسناد وجود دارد، برای این کار نیازی به کپی کردن هیچ فایلی نیست.
• در دایرکتوری lib/ کنار فایل اجرایی، کتابخانه ها به طور پیش فرض جستجو می شوند.
• هیچ توزیع و محیط دسکتاپ متعددی وجود ندارد؛ هر چیزی که کار می کند، همه جا کار می کند.
• ماژول جداگانه ای برای اجرا وجود ندارد که با دایرکتوری Applications متفاوت باشد.
• برنامه ها دارای مسیرهای مطلق داخلی برای منابع خود نیستند، آنها عملکردهای ویژه ای برای تعیین مکان در زمان اجرا دارند.
• ایده تصاویر سیستم فایل فشرده معرفی شده است: این هر بسته hpkg است. همه آنها توسط هسته نصب شده اند.
• هر فایل توسط برنامه ای که آن را ایجاد کرده است باز می شود، مگر اینکه به صراحت خلاف آن را مشخص کنید. این چقدر باحاله

دو فایل png به نمادهای مختلف توجه کنید که نشان می دهد با دوبار کلیک کردن توسط برنامه های مختلف باز می شوند. همچنین به منوی کشویی «باز کردن با:» توجه کنید که در آن کاربر می تواند یک برنامه جداگانه را انتخاب کند. چقدر ساده!

به نظر می‌رسد بسیاری از عصاها و راه‌حل‌های مورد نیاز AppImage در لینوکس در هایکو غیرضروری می‌شوند، که در هسته خود سادگی و پیچیدگی دارد که باعث می‌شود بیشتر نیازهای ما را برطرف کند.

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

این منجر به یک سوال بزرگ می شود. اگر ایجاد سیستمی مانند AppImage در هایکو راحت تر از لینوکس بود، آیا ارزش انجام آن را داشت؟ یا هایکو با سیستم پکیج hpkg خود عملاً نیاز به توسعه چنین ایده ای را از بین برده است؟ خوب، برای پاسخ باید به انگیزه وجود AppImages نگاه کنیم.

دیدگاه کاربر

بیایید به کاربر نهایی خود نگاه کنیم:

• من می خواهم بدون درخواست رمز عبور مدیر (روت) یک برنامه را نصب کنم. هیچ مفهومی از مدیر در هایکو وجود ندارد، کاربر کنترل کامل دارد زیرا یک سیستم شخصی است! (در اصل، شما می توانید این را در حالت چند نفره تصور کنید، امیدوارم توسعه دهندگان آن را ساده نگه دارند)
• من می‌خواهم آخرین و بهترین نسخه برنامه‌ها را دریافت کنم، بدون اینکه منتظر بمانم تا در توزیع من ظاهر شوند (اغلب این به معنای "هرگز" است، حداقل مگر اینکه کل سیستم عامل را به روز کنم). در هایکو این با نسخه های شناور "حل" می شود. این به این معنی است که دریافت آخرین و بهترین نسخه برنامه ها امکان پذیر است، اما برای انجام این کار باید به طور مداوم بقیه سیستم را به روز کنید و آن را به طور موثر به یک "هدف متحرک" تبدیل کنید..
• من چندین نسخه از یک برنامه را در کنار هم می خواهم، زیرا هیچ راهی برای دانستن آنچه در آخرین نسخه خراب شده وجود ندارد، یا مثلاً من به عنوان یک توسعه دهنده وب، باید کارم را تحت نسخه های مختلف مرورگر آزمایش کنم. هایکو مشکل اول را حل می کند، اما مشکل دوم را حل نمی کند. به‌روزرسانی‌ها برگشت داده می‌شوند، اما فقط برای کل سیستم؛ غیرممکن است (تا آنجا که من می‌دانم) برای مثال چندین نسخه WebPositive یا LibreOffice را همزمان اجرا کنید.

یکی از توسعه دهندگان می نویسد:

اساساً منطق این است: مورد استفاده آنقدر نادر است که بهینه سازی برای آن منطقی نیست. برخورد با آن به عنوان یک مورد خاص در HaikuPorts بیش از حد قابل قبول به نظر می رسد.

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

نظر توسعه دهنده:

از نظر فنی، این از قبل با دستور mount امکان پذیر است. البته به محض اینکه کاربران علاقه مند کافی داشته باشیم برای این کار یک رابط کاربری گرافیکی خواهیم ساخت.

• من نیازی به میلیون ها فایل پراکنده در سیستم فایل ندارم که خودم نتوانم آنها را به صورت دستی مدیریت کنم. من یک فایل برای هر برنامه می خواهم که بتوانم آن را به راحتی دانلود، انتقال، حذف کنم. در هایکو این مشکل با استفاده از بسته ها حل می شود .hpkg، که مثلاً پایتون را از هزاران فایل به یک فایل منتقل می کند. اما اگر مثلاً Scribus از پایتون استفاده می کند، باید حداقل با دو فایل سر و کار داشته باشم. و من باید مراقب باشم که نسخه هایی از آنها را که با یکدیگر کار می کنند نگه دارم.

چندین نسخه از AppImages در حال اجرا در کنار هم در لینوکس یکسان

دیدگاه یک توسعه دهنده اپلیکیشن

بیایید از دیدگاه توسعه‌دهنده اپلیکیشن نگاه کنیم:

• من می خواهم کل تجربه کاربری را کنترل کنم. من نمی خواهم به یک سیستم عامل وابسته باشم که به من بگوید چه زمانی و چگونه باید برنامه ها را منتشر کنم. هایکو به توسعه دهندگان اجازه می دهد تا با مخازن hpkg خود کار کنند، اما این بدان معناست که کاربران باید آنها را به صورت دستی تنظیم کنند، که این ایده را "جذاب تر" می کند.
• من یک صفحه دانلود در وب سایت خود دارم که در آن توزیع می کنم .exe برای ویندوز، .dmg برای مک و .AppImage برای لینوکس یا شاید من می خواهم از دسترسی به این صفحه درآمد کسب کنم، هر چیزی ممکن است؟ برای هایکو چه چیزی باید در آنجا قرار دهم؟ فایل کافیه .hpkg با وابستگی فقط از HaikuPorts
• نرم افزار من به نسخه های خاصی از نرم افزارهای دیگر نیاز دارد. به عنوان مثال، مشخص است که Krita به یک نسخه وصله‌شده از Qt یا Qt نیاز دارد که روی نسخه خاصی از Krita تنظیم شده باشد، حداقل تا زمانی که وصله‌ها به Qt بازگردانده شوند. شما می توانید Qt خود را برای برنامه خود در یک بسته بسته بندی کنید .hpkg، اما به احتمال زیاد این مورد استقبال قرار نمی گیرد.

صفحه دانلود برنامه معمولی. برای هایکو در اینجا چه پست کنم؟

بسته‌های Will (که به عنوان دایرکتوری‌های برنامه مانند AppDir یا .app به سبک اپل) و/یا تصاویر (به شکل AppImages بسیار تغییر یافته یا .dmg از اپل) برنامه های کاربردی افزودنی مفید به محیط دسکتاپ هایکو؟ یا اینکه کل تصویر را رقیق می کند و منجر به تکه تکه شدن می شود و بنابراین پیچیدگی را اضافه می کند؟ من پاره شده ام: از یک طرف، زیبایی و پیچیدگی هایکو بر این واقعیت استوار است که معمولاً یک راه برای انجام کاری وجود دارد، نه راه های زیاد. از سوی دیگر، بیشتر زیرساخت‌ها برای کاتالوگ‌ها و/یا مجموعه‌های برنامه در حال حاضر وجود دارد، بنابراین سیستم فریاد می‌زند تا چند درصد باقی‌مانده در جای خود قرار گیرد.

به گفته توسعه دهنده آقای. آب پاش

در لینوکس آنها (کاتالوگ ها و کیت های کاربردی، - تقریبا. مترجم) به احتمال زیاد یک راه حل فنی برای مشکلات سیستمیک هستند. در هایکو ما ترجیح می دهیم به سادگی مشکلات سیستم را حل کنیم.

شما چی فکر میکنید؟

قبل از اینکه جواب بدی...

صبر کنید، بیایید یک بررسی سریع واقعیت انجام دهیم: در واقع دایرکتوری های برنامه - در حال حاضر بخشی از هایکو:

دایرکتوری های برنامه از قبل در هایکو وجود دارند، اما هنوز در مدیر فایل پشتیبانی نمی شوند

آنها فقط به اندازه مکینتاش یاب پشتیبانی نمی شوند. اگر فهرست QtCreator یک نام و نماد "QtCreator" در گوشه سمت چپ بالا داشته باشد، چقدر جالب است که با دوبار کلیک کردن، برنامه را راه اندازی می کند؟

کمی زودتر من در حال حاضر پرسید:

آیا مطمئن هستید که می توانید برنامه های ده ساله خود را امروز اجرا کنید که همه فروشگاه های برنامه و مخازن توزیع آن ها و وابستگی هایشان را فراموش کرده اند؟ آیا مطمئن هستید که همچنان می توانید به شغل فعلی خود در آینده دسترسی داشته باشید؟

آیا در حال حاضر پاسخی از سوی هایکو وجود دارد یا کاتالوگ ها و بسته های برنامه می توانند در اینجا کمک کنند؟ من فکر می کنم آنها می توانند.

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

بله، ما پاسخ این سوال را داریم: ما به سادگی از این برنامه‌ها تا زمانی که لازم باشد پشتیبانی می‌کنیم تا زمانی که کسی بتواند فرمت فایل‌های آنها را به روش صحیح بخواند یا عملکرد یک به یک را ارائه دهد. تعهد ما به پشتیبانی از برنامه های BeOS R5 در هایکو گواه این امر است...

مطمئنا!

هایکو چه اقدامی باید در پیش بگیرد؟

من می توانم همزیستی مسالمت آمیز hpkg، دایرکتوری ها و تصاویر برنامه را تصور کنم:

• استفاده از نرم افزار سیستم .hpkg
• برای نرم افزارهای پرکاربرد (مخصوصاً نرم افزارهایی که نیاز به زمان بندی انتشارات دارند)، استفاده کنید .hpkg (تقریباً 80٪ موارد)
• برخی از طریق نصب شده اند .hpkg، برنامه ها از انتقال به زیرساخت دایرکتوری برنامه (مانند QtCreator) سود خواهند برد: آنها به صورت توزیع می شوند. .hpkg، مثل قدیما.

آقای. waddlesplash می نویسد:

اگر تنها چیزی که نیاز دارید این است که برنامه ها را در آن مشاهده کنید /system/apps، به جای آن باید دایرکتوری های موجود در Deskbar را برای کاربران قابل مدیریت تر کنیم، زیرا /system/apps در نظر گرفته نشده است که به طور منظم توسط کاربران باز و مشاهده شود (برخلاف MacOS). برای چنین شرایطی، هایکو پارادایم متفاوتی دارد، اما این گزینه، در تئوری، قابل قبول است.

• هایکو زیرساختی را برای اجرای تصاویر برنامه، ساخت‌های شبانه، پیوسته و آزمایشی نرم‌افزار و همچنین برای مواردی که کاربر می‌خواهد آن را به موقع مسدود کند، برای نرم‌افزارهای خصوصی و داخلی و سایر موارد استفاده خاص (حدود 20٪) دریافت می‌کند. از همه). این تصاویر حاوی فایل های لازم برای اجرای برنامه هستند .hpkg، توسط سیستم نصب می شود و پس از تکمیل برنامه - unmount می شود. (شاید یک مدیر فایل بتواند فایل ها را قرار دهد .hpkg به تصاویر برنامه، به طور خودکار یا بنا به درخواست کاربر - خوب، مانند زمانی که یک برنامه را به دایرکتوری شبکه یا درایو خارجی می‌کشید. این فقط یک آهنگ است! یا بهتر بگوییم شعر - هایکو.) از طرفی ممکن است کاربر بخواهد محتویات تصویر را در قالب فایل نصب کند..hpkg، پس از آن به روز رسانی و پردازش می شوند مانند اینکه از طریق HaikuDepot نصب شده اند ... ما نیاز به طوفان فکری داریم).

نقل قول از آقای waddlesplash:

اجرای برنامه های کاربردی از درایوهای خارجی یا دایرکتوری های شبکه به طور بالقوه می تواند مفید باشد. و افزودن قابلیت پیکربندی بیشتر "مناطق" برای pkgman قطعا یک ویژگی خوب خواهد بود.

چنین سیستمی از hpkg، دایرکتوری ها و تصاویر برنامه بهره می برد. آنها به صورت فردی خوب هستند، اما با هم شکست ناپذیر خواهند شد.

نتیجه

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

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

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

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

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

فقط کاربران ثبت نام شده می توانند در نظرسنجی شرکت کنند. ورود، لطفا.

آیا پورت کردن سیستم hpkg به لینوکس منطقی است؟

• بله

• بدون

• قبلاً اجرا شده است، در نظرات می نویسم

20 کاربر رای دادند. 5 کاربر رای ممتنع دادند.

منبع: www.habr.com