হাইকু নিয়ে আমার ষষ্ঠ দিন: সম্পদ, আইকন এবং প্যাকেজের হুডের নিচে

TL; ডিআর: হাইকু একটি অপারেটিং সিস্টেম যা বিশেষভাবে পিসিগুলির জন্য ডিজাইন করা হয়েছে, তাই এটির বেশ কিছু কৌশল রয়েছে যা এর ডেস্কটপ পরিবেশকে অন্যদের তুলনায় অনেক ভালো করে তোলে৷ কিন্তু এটা কিভাবে কাজ করে?

সম্প্রতি আমি হাইকু আবিষ্কার করেছি, একটি অপ্রত্যাশিতভাবে ভাল সিস্টেম। বিশেষ করে লিনাক্স ডেস্কটপ পরিবেশের তুলনায় এটি কতটা মসৃণভাবে চলে তা দেখে আমি এখনও বিস্মিত। আজ আমি হুডের নিচে দেখে নেব। গভীরভাবে বোঝার জন্য যেখানে প্রয়োজন, আমি মূল Macintosh, Mac OS X এবং Linux ডেস্কটপ পরিবেশের সাথে তুলনা করব (freedesktop.org থেকে XDG স্ট্যান্ডার্ড)।

ELF ফাইলে সম্পদ

গতকাল আমি শিখেছি যে IconOMatic ELF এক্সিকিউটেবলে rdef রিসোর্সে আইকন সংরক্ষণ করতে পারে। আজ আমি দেখতে চাই কিভাবে এটা সত্যিই কাজ করে.

সম্পদ? তলব থেকে ব্রুস হর্ন, ম্যাকিনটোশ ফাইন্ডারের মূল লেখক এবং ম্যাকিনটোশ রিসোর্স ম্যানেজারের "পিতা":

আমি ঐতিহ্যগত কোডিং এর কঠোর প্রকৃতি সম্পর্কে চিন্তিত। আমার জন্য, গতিশীলভাবে কিছু পরিবর্তন করার ক্ষমতা ছাড়াই কোডে হিমায়িত একটি অ্যাপ্লিকেশনের ধারণাটি সবচেয়ে জঘন্যতম বর্বরতা। রানটাইমে যতটা সম্ভব পরিবর্তন করা উচিত। অবশ্যই, অ্যাপ্লিকেশন কোড নিজেই পরিবর্তন করা যাবে না, তবে কোডটি পুনরায় কম্পাইল না করে অবশ্যই কিছু পরিবর্তন করা যেতে পারে?

আসল Macintosh-এ, তারা এই ফাইলগুলিতে একটি "ডেটা বিভাগ" এবং একটি "রিসোর্স বিভাগ" তৈরি করেছে, যা আইকন, অনুবাদ এবং এর মতো জিনিসগুলিকে সংরক্ষণ করা অবিশ্বাস্যভাবে সহজ করে তুলেছে৷ এক্সিকিউটেবল ফাইলগুলিতে।

ম্যাকে এটি ব্যবহার করা হয় পুনরায় সম্পাদনা করুন, একটি গ্রাফিকাল প্রোগ্রাম - হঠাৎ - সম্পদ সম্পাদনা করার জন্য।

মূল Macintosh এ পুনরায় সম্পাদনা করুন

ফলস্বরূপ, আইকন, মেনু আইটেম, অনুবাদ ইত্যাদি সম্পাদনা করা সম্ভব হয়েছে। যথেষ্ট সহজ, কিন্তু তারা এখনও অ্যাপ্লিকেশনগুলির সাথে "ভ্রমণ" করে।
যাই হোক না কেন, এই পদ্ধতির একটি বড় ত্রুটি ছিল: এটি শুধুমাত্র অ্যাপল ফাইল সিস্টেমে কাজ করে, যা ম্যাক ওএস এক্স-এ যাওয়ার সময় অ্যাপল "রিসোর্স বিভাগ" ত্যাগ করার একটি কারণ ছিল।
ম্যাক ওএস এক্স-এ, অ্যাপল একটি ফাইল সিস্টেম-স্বাধীন সমাধান চেয়েছিল, তাই তারা প্যাকেজগুলির ধারণা (NEXT থেকে), ডিরেক্টরিগুলিকে গ্রহণ করেছিল যেগুলি ফাইল ম্যানেজার দ্বারা "অস্বচ্ছ বস্তু" হিসাবে বিবেচিত হয়, যেমন ডিরেক্টরির পরিবর্তে ফাইলগুলির মতো। বিন্যাসে একটি অ্যাপ্লিকেশন সহ যেকোনো প্যাকেজ .app অন্যান্য জিনিসের মধ্যে একটি ফাইল আছে Info.plist (অ্যাপলের সমতুল্য JSON বা YAML এর কোনো প্রকারে) অ্যাপ্লিকেশন মেটাডেটা ধারণকারী।

Mac OS X অ্যাপ্লিকেশন প্যাকেজ থেকে Info.plist ফাইলের কী।

সম্পদ, যেমন আইকন, UI ফাইল এবং অন্যান্য, ফাইল হিসাবে প্যাকেজে সংরক্ষণ করা হয়। ধারণাটি আসলে নেক্সটে তার মূলে ফিরে গেছে।

1.0 সালে NeXTSTEP 1989-এ Mathematica.app: টার্মিনালে ফাইলগুলির একটি ডিরেক্টরি হিসাবে প্রদর্শিত হয়, কিন্তু গ্রাফিক্যাল ফাইল ম্যানেজারে একটি একক বস্তু হিসাবে।

আসুন BeOS-এ ফিরে যাই, যে ধারণাগুলোর উপর ভিত্তি করে হাইকু। এর বিকাশকারীরা, যখন PEF (PowerPC) থেকে ELF (x86) (লিনাক্সে ব্যবহার করা হয়) তে স্যুইচ করার সময়, ELF ফাইলগুলির শেষে একটি সংস্থান বিভাগ যুক্ত করার সিদ্ধান্ত নেয়। এটি তার নিজস্ব সঠিক ELF বিভাগ ব্যবহার করেনি, এটি কেবল ELF ফাইলের শেষে যুক্ত করা হয়েছিল। কর্মসূচির ফলে ড strip এবং বিনুটিল থেকে অন্যরা, এই সম্পর্কে সচেতন নয়, কেবল এটি কেটে ফেলুন। অতএব, যখন BeOS-এ একটি ELF ফাইলে সংস্থান যোগ করা হয়, তখন এটিকে লিনাক্স টুলের সাহায্যে ব্যবহার না করাই ভালো।

হাইকু নিয়ে এখন কী হচ্ছে? মূলত, কমবেশি একই।

তাত্ত্বিকভাবে, ELF এর পছন্দসই বিভাগে সংস্থান স্থাপন করা সম্ভব হবে। irc.freenode.net-এ #haiku চ্যানেলের বিকাশকারীদের মতে:

ELF-এর সাথে বিভাগটি আরও অর্থবহ হবে... আমরা এইভাবে না করার একমাত্র কারণ হল আমরা BeOS-এ যা করেছি।"
এবং এখন এটি পরিবর্তন করার কোন মানে নেই।

সম্পদ ব্যবস্থাপনা

সংস্থানগুলি একটি কাঠামোগত "সম্পদ" বিন্যাসে লেখা হয়: মূলত আকার সহ সংস্থানগুলির একটি তালিকা এবং তারপরে তাদের বিষয়বস্তু৷ মনে পড়ল ar বিন্যাস.
হাইকুতে সংস্থানগুলি কীভাবে পরীক্ষা করবেন? ResEdit মত কিছু আছে?
অনুযায়ী ডকুমেন্টেশন:

অ্যাপ্লিকেশন প্যাকেজে প্রদত্ত সংস্থানগুলি দেখতে, আপনি এক্সিকিউটেবল ফাইলটিকে একটি প্রোগ্রামে টেনে আনতে পারেন রিসোর্সার. এছাড়াও আপনি টার্মিনালে গিয়ে কমান্ড চালাতে পারেন listres имя_файла.

রিসোর্সার হাইকুডিপোতে পাওয়া যায়, কিন্তু এটি আমার জন্য ক্র্যাশ হয়।

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 অ্যাপ্লিকেশনগুলিতে একই ফলাফল অর্জন করা যেতে পারে। QtSingle অ্যাপ্লিকেশন) সঙ্গে অ্যাপ্লিকেশন 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:~ 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. কি দারুন! আমি ইতিমধ্যে উল্লেখ করেছি যে আমি মনে করি হাইকুর সামগ্রিক পরিশীলিততা এবং সামঞ্জস্যের একটি অংশ এই সত্য থেকে আসে যে কার্নেল এবং মূল ব্যবহারকারী স্থান থেকে প্যাকেজ পরিচালনা এবং রানটাইম অবকাঠামো পর্যন্ত পুরো সিস্টেমটি একটি দল দ্বারা সহযোগিতামূলকভাবে তৈরি করা হয়েছে। কল্পনা করুন যে লিনাক্সে এরকম কিছু চালানোর জন্য কতগুলি বিভিন্ন গ্রুপ এবং দল লাগবে [আমি 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..." ডিরেক্টরিতে সক্রিয় প্যাকেজের নাম সহ টেক্সট ফাইল থাকে এবং "লেনদেন..." ডিরেক্টরিতে প্যাকেজগুলো থাকে।

"পুরাতন সক্রিয় অবস্থা", i.e. তালিকা .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, যা অন্য যেকোনো আর্কাইভের মতো এটিকে আনপ্যাক করতে পারে)।

হাইকুডিপোটের ইন্টারফেস আপনাকে প্যাকেজ ফাইলগুলির একটি তালিকা দেখতে দেয়, তবে বিষয়বস্তু দেখার কোন উপায় নেই, উদাহরণস্বরূপ, README.md-এ ডাবল ক্লিক করে

ম্যাক এই বিভাগে জিতেছে, কিন্তু আপনি যে হাইকুডিপোট কার্যকারিতা চান তা যোগ করা খুব কঠিন হবে না।

GUI এর মাধ্যমে একটি প্যাকেজ ইনস্টল করা হচ্ছে

ম্যাকে, অধিকাংশ ডিস্ক ইমেজ .dmg প্যাকেজ ধারণ করে .app. ডিস্ক ইমেজে ডাবল-ক্লিক করুন এবং তারপর প্যাকেজটি অনুলিপি করুন, উদাহরণস্বরূপ, এটিতে টেনে নিয়ে /Applications ফাইন্ডারে। এটি আমার জন্য বলার অপেক্ষা রাখে না, কিন্তু আমি শুনেছি যে কিছু নতুনরা এটি পরিচালনা করতে সক্ষম নাও হতে পারে। ডিফল্টরূপে, অ্যাপল একটি সিস্টেম-ওয়াইড ডিরেক্টরি "সাজেস্ট" করে /Applications (পরবর্তীতে এটি নেটওয়ার্কের পাশাপাশি পৃথক ছিল), তবে আপনি সহজেই আপনার অ্যাপ্লিকেশনগুলি একটি ফাইল সার্ভারে বা একটি সাবডিরেক্টরিতে রাখতে পারেন $HOME/Applications, যদি আপনি এই ভাবে এটা পছন্দ করেন.

হাইকুতে, প্যাকেজটিতে ডাবল ক্লিক করুন, তারপরে "ইনস্টল" এ ক্লিক করুন, এটি সহজ হতে পারে না। আমি ভাবছি যদি একটি প্যাকেজের নির্ভরতা থাকে যা হাইকুপোর্টে পাওয়া যায় কিন্তু এখনও ইনস্টল করা হয়নি। লিনাক্সে তারা সত্যিই এই পরিস্থিতিতে কী করবেন তা জানেন না, তবে সমাধানটি সুস্পষ্ট - ব্যবহারকারীকে জিজ্ঞাসা করুন তাদের নির্ভরতা ডাউনলোড এবং ইনস্টল করতে হবে কিনা। ঠিক কী হাইকু করে।

আমি ম্যানুয়ালি 'স্যানিটি' প্যাকেজটি ডাউনলোড করেছি এবং এটিতে ক্লিক করেছি, প্যাকেজ ম্যানেজার জানেন যে এটির নির্ভরতা কোথা থেকে পেতে হবে (ধরে নিচ্ছি যে সংগ্রহস্থলগুলি ইতিমধ্যে সিস্টেমে নিবন্ধিত আছে)। প্রতিটি লিনাক্স বিতরণ এটি করতে পারে না।

আরেকটি উপায় হল একটি ফাইল ম্যানেজার ব্যবহার করা, শুধু টেনে আনুন .hpkg প্যাকেজ বা মধ্যে /Haiku/system/packages (একটি সিস্টেম-ব্যাপী ইনস্টলেশনের জন্য, ডিফল্টরূপে), বা ইন /Haiku/home/config/packages (স্বতন্ত্র ইনস্টলেশনের জন্য; ডাবল-ক্লিক করার সময় উপলব্ধ নয় - আমি এখনও এই জায়গায় "কনফিগ" শব্দটি দ্বারা বিরক্ত, যা এই ক্ষেত্রে আমার জন্য "সেটিংস" এর সমার্থক)। এবং একাধিক ব্যবহারকারীর ধারণা হাইকু-এর জন্য এখনও উপলব্ধ নয় (এ কারণেই সম্ভবত এটি এত সহজ - আমি জানি না, সম্ভবত বহু-ব্যবহারকারীর ক্ষমতাগুলি ডেস্কটপ ডেস্কটপ পরিবেশের জন্য অপ্রয়োজনীয়ভাবে জিনিসগুলিকে জটিল করে তুলবে)।

হাইকু এই বিভাগে জিতেছে কারণ এটি শুধুমাত্র অ্যাপ্লিকেশনের সাথেই নয়, সিস্টেম প্রোগ্রামগুলির সাথেও কাজ করতে পারে।

GUI থেকে একটি প্যাকেজ সরানো হচ্ছে

ম্যাকে, আপনাকে ট্র্যাশ ক্যানে অ্যাপ্লিকেশন আইকনটি টেনে আনতে হবে এবং এটিই। সহজে !

হাইকুতে, প্রথমত, আপনাকে প্যাকেজটি সিস্টেমে কোথায় অবস্থিত তা খুঁজে বের করতে হবে, কারণ আপনি খুব কমই এটি সঠিক জায়গায় ইনস্টল করেন (সিস্টেম সবকিছু করে)। সাধারণত আপনি দেখতে হবে /Haiku/system/packages (একটি সিস্টেম-ব্যাপী ডিফল্ট ইনস্টলেশন সহ), বা ইন /Haiku/home/config/packages (আমি কি উল্লেখ করেছি যে "কনফিগার" একটি ভুল নাম?) তারপরে অ্যাপ্লিকেশনটি কেবল ট্র্যাশ ক্যানে টেনে আনা হয় এবং এটিই।
সহজে ! যাইহোক, আমি এটা বলব না। এখানে সত্যিই কি ঘটছে:

আপনি যদি একটি অ্যাপ্লিকেশন থেকে ট্র্যাশ ক্যানে টেনে আনেন তাহলে এটিই ঘটবে৷ /Haiku/system/packages

QtQuickApp-এ আমার গতকালের "হ্যালো ওয়ার্ল্ড" অ্যাপ্লিকেশনটিকে ট্র্যাশে সরানোর চেষ্টা করেছি৷ আমি সিস্টেম ডিরেক্টরি সরানোর চেষ্টা করিনি, এবং যেহেতু সমস্ত প্যাকেজ সিস্টেম ডিরেক্টরিতে ইনস্টল করা আছে, প্যাকেজ অপসারণ করা অসম্ভব .hpkg পরিবর্তন ছাড়া "এর বিষয়বস্তু". একজন সাধারণ ব্যবহারকারী ভয় পেয়ে যাবেন এবং ডিফল্টরূপে নির্ধারিত "বাতিল" বোতাম টিপুন।

ব্যাখ্যা করে জনাব. waddlesplash:

এই পোস্ট 10 বছরের বেশি পুরানো. খুব সম্ভবত আমাদের এটি কনফিগার করতে হবে যাতে প্যাকেজটি নিজেই সরানো হলে সতর্কতাটি উপস্থিত হয়। নিয়মিত ব্যবহারকারীদের যাইহোক এটি করার দরকার নেই।

ঠিক আছে, সম্ভবত আমার হাইকুডিপোট ব্যবহার করে এটি করা উচিত? আমি প্যাকেজে ডাবল ক্লিক করি /Haiku/system/packages, "আনইনস্টল" বোতামটি প্রদর্শিত হওয়ার জন্য অপেক্ষা করুন৷ না, সেখানে (শুধুমাত্র) "ইনস্টল" আছে। "আনইন্সটল", আপনি কোথায়?

শুধুমাত্র মজা করার জন্য, আমি আগে থেকে ইনস্টল করা প্যাকেজে "ইনস্টল" ক্লিক করলে কী ঘটবে তা দেখার চেষ্টা করেছি। এটি এই মত দেখা যাচ্ছে:

আপনি যদি ইতিমধ্যে ইনস্টল করা একটি প্যাকেজ ইনস্টল করার চেষ্টা করেন তবে এটি ঘটে।

পরবর্তী প্রদর্শিত হয়:

আপনি যদি পূর্ববর্তী উইন্ডোতে "পরিবর্তন প্রয়োগ করুন" এ ক্লিক করেন, তাহলে এটি এরকম দেখাবে

আমি অনুমান করছি যে এটি একটি সফ্টওয়্যার ত্রুটি; অ্যাপ্লিকেশনটির লিঙ্কটি ইতিমধ্যেই রয়েছে৷ [লেখক একটি লিঙ্ক প্রদান করেননি - প্রায়. অনুবাদক]

দ্রুত সমাধান: প্যাকেজটি ইতিমধ্যেই থাকলে একটি "আনইনস্টল" বোতাম যোগ করুন /Haiku/system/packages, অথবা মধ্যে /Haiku/home/config/packages.

হাইকুডিপোতে ইনস্টল করা প্যাকেজগুলির তালিকা দেখার সময়, আমি তালিকায় আমার প্যাকেজ দেখতে পাই এবং এটি সরাতে পারি।

ম্যাক এই বিভাগে জিতেছে। কিন্তু আমি কল্পনা করতে পারি যে সঠিক সেটআপের সাথে, হাইকুতে ব্যবহারকারীর অভিজ্ঞতা ম্যাকের চেয়ে ভাল হবে। (একজন বিকাশকারী এটিকে এইভাবে রেট দিয়েছেন: "হাইকুডিপোতে নির্দিষ্ট কার্যকারিতা যোগ করতে এক ঘন্টারও কম, যদি আপনি একটু 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 ছাড়া কেউ এই বিভাগে জিতেনি (কিন্তু এটি, সম্পূর্ণরূপে সৎ হতে, একটি পক্ষপাতমূলক মতামত)। যাইহোক, কেউ কল্পনা করতে পারেন যে টুইক করার পরে, হাইকুতে ব্যবহারকারীর অভিজ্ঞতা ম্যাকের চেয়ে ভাল হবে।

দ্রষ্টব্য: একটি "বিভাগ" এর সাথে সম্পর্কিত একটি "ভলিউম" কী তা আপনাকে খুঁজে বের করতে হবে। এটি সম্ভবত "ফোল্ডার" এবং "ডিরেক্টরি" এর সম্পর্কের অনুরূপ: বেশিরভাগ ডিরেক্টরি ফাইল ম্যানেজারে ফোল্ডার হিসাবে উপস্থিত হয়, তবে সেগুলি সব নয় (উদাহরণস্বরূপ প্যাকেজগুলিকে ফাইল হিসাবে বিবেচনা করা হয়)। এই ধরনের ডিসপ্লে কি আমাকে একজন অফিসিয়াল নর্ড করে তোলে?

একটি প্যাকেজের বিষয়বস্তু অন্য সিস্টেমে অনুলিপি করা

ম্যাকে, আমি নির্বোধভাবে প্যাকেজটি টেনে আনলাম .app, এবং যেহেতু নির্ভরতাগুলি প্যাকেজের ভিতরে থাকে, তাই তারা একসাথে চলে।

হাইকুতে, আমি অ্যাপ্লিকেশন টেনে আনছি, কিন্তু নির্ভরতাগুলি মোটেও প্রক্রিয়া করা হয় না।

দ্রুত সমাধান: চলুন এর পরিবর্তে পুরো `.hpkg প্যাকেজ, কোনো নির্ভরতা সহ, যদি থাকে, টেনে আনার পরামর্শ দেওয়া যাক।

ম্যাক স্পষ্টভাবে এই বিভাগে জিতেছে। অন্তত আমার জন্য, তাদের দৃষ্টান্ত একটি প্রেমিক. আমার হাইকুতে কপি করা উচিত .hpkg একটি অ্যাপ্লিকেশনের পরিবর্তে, কিন্তু সিস্টেম আমাকে এটি অফার করে না ...

তার সমস্ত নির্ভরতা সহ একটি প্যাকেজ ডাউনলোড করুন

প্রতিটি মেশিন সর্বদা নেটওয়ার্কের সাথে সংযুক্ত থাকে না। বিপরীতভাবে, কিছু মেশিন (হ্যাঁ, আমি আপনাকে দেখছি, আধুনিক উইন্ডোজ, ম্যাক এবং লিনাক্স) এটি ভুলে যায়। এটি আমার জন্য গুরুত্বপূর্ণ যে আমি একটি ইন্টারনেট ক্যাফেতে যেতে পারি, একটি অপসারণযোগ্য ড্রাইভে সফ্টওয়্যার ডাউনলোড করতে পারি, আমার হোম কম্পিউটারে এই ড্রাইভটি ঢোকাতে পারি এবং নিশ্চিত হতে পারি যে সবকিছুই কাজ করবে [ঝুঁকিপূর্ণ লোক, উইন্ডোজে এটি করা... - প্রায়. অনুবাদক]।

ফলস্বরূপ, আমি উইন্ডোজ এবং লিনাক্সে স্বাভাবিকের চেয়ে কিছুটা বেশি ঘন ঘন অসামঞ্জস্যপূর্ণ নির্ভরতার সাথে শেষ হওয়ার প্রবণতা রাখি।

ম্যাকে এটি সাধারণত একটি ফাইল, আপনাকে যা করতে হবে তা হল ডাউনলোড .dmg. প্রায়শই, ডিফল্টরূপে MacOS দ্বারা প্রদত্ত ব্যতীত অন্য কোন নির্ভরতা থাকে না। একটি ব্যতিক্রম হল জটিল অ্যাপ্লিকেশন যার জন্য উপযুক্ত কার্যকর পরিবেশ প্রয়োজন, উদাহরণস্বরূপ java।

হাইকুতে প্যাকেজ ডাউনলোড করুন .hpkg জন্য, বলুন, জাভাতে একই অ্যাপ্লিকেশন যথেষ্ট নাও হতে পারে, যেহেতু জাভা টার্গেট মেশিনে উপস্থিত থাকতে পারে বা নাও থাকতে পারে। একটি প্রদত্ত প্যাকেজের জন্য সমস্ত নির্ভরতা ডাউনলোড করার একটি উপায় আছে কি? .hpkg, হাইকুতে ডিফল্টরূপে ইনস্টল করা এবং তাই প্রতিটি হাইকু সিস্টেমে থাকা উচিত?

ম্যাক অল্প ব্যবধানে এই বিভাগে জিতেছে।

মন্তব্য মি. waddlesplash:

প্যাকেজের সেট হিসাবে একটি অ্যাপ্লিকেশনের সমস্ত নির্ভরতা সংগ্রহ করার জন্য একটি প্রোগ্রাম লিখতে .hpkg হাইকুর অভ্যন্তরীণ কাজের সাথে পরিচিত কারো জন্য, প্রায় 15 মিনিটই যথেষ্ট। এর জন্য সমর্থন যোগ করা এতটা কঠিন নয় যদি এটির সত্যিকারের প্রয়োজন হয়। কিন্তু আমার জন্য এটি একটি বিরল পরিস্থিতি।

আসুন এই সিরিজের পরবর্তী নিবন্ধ পর্যন্ত আমাদের দম ধরে রাখি।

একটি পৃথক অবস্থানে প্যাকেজ সরানো

আমি আগে লিখেছি, আমি আমার প্যাকেজ স্থাপন করতে চাই .hpkg (ভাল, বা তাদের অংশ) একটি বিশেষ স্থানে, বুট ভলিউমের (রুট পার্টিশন) স্বাভাবিক স্থাপন থেকে পৃথক। স্বাভাবিক (অতটা তাত্ত্বিক নয়) ক্ষেত্রে, এর কারণ হল যে আমার (বিল্ট-ইন) ডিস্কগুলিতে ক্রমাগত ফাঁকা স্থান ফুরিয়ে যায়, সেগুলি যত বড়ই হোক না কেন। এবং আমি সাধারণত বহিরাগত ড্রাইভ বা নেটওয়ার্ক শেয়ার সংযোগ করি যেখানে আমার অ্যাপ্লিকেশনগুলি অবস্থিত।

ম্যাকে আমি শুধু প্যাকেজ সরানো করছি .app ফাইন্ডারে একটি অপসারণযোগ্য ড্রাইভ বা নেটওয়ার্ক ডিরেক্টরিতে, এবং এটিই। আমি সাধারণত বুট ভলিউম থেকে অ্যাপ্লিকেশনটি খুলতে ডাবল-ক্লিক করতে পারি। শুধু!

হাইকুতে, যেমন আমাকে বলা হয়েছিল, এটি আমার সরানোর দ্বারা অর্জন করা যেতে পারে .hpkg একটি অপসারণযোগ্য ড্রাইভ বা নেটওয়ার্ক ডিরেক্টরিতে প্যাকেজ, কিন্তু তারপর আপনাকে সিস্টেমে মাউন্ট করার জন্য কনসোলে কিছু নথিবিহীন কমান্ড ব্যবহার করতে হবে। আমি জানি না কিভাবে শুধুমাত্র GUI ব্যবহার করে এটি করতে হয়।

ম্যাক এই বিভাগে জিতেছে।

মি. অনুযায়ী. waddlesplash:

এটি স্বাভাবিক ব্যবহারের উপর ভিত্তি করে একটি অপ্টিমাইজেশান। একাধিক ব্যবহারকারীর কাছ থেকে চাহিদা থাকলে আমরা তা বাস্তবায়ন করব। যাই হোক না কেন, তৃতীয় পক্ষের বাস্তবায়নের সম্ভাবনা রয়েছে।

আমরা পরবর্তী নিবন্ধে এই সম্পর্কে কথা বলতে হবে.

নেটওয়ার্ক ডিরেক্টরির কথা বললে, সহজ, আবিষ্কারযোগ্য, নেটওয়ার্ক-ওয়াইড অ্যাপ্লিকেশন (যেমন Zeroconf) থাকলে এটি দুর্দান্ত হবে (আমি LAN পার্টিগুলি অনুমান করছি) যা স্থানীয় কম্পিউটারে অনুলিপি করা যেতে পারে বা স্থানীয় নেটওয়ার্ক থেকে সরাসরি চালানো যেতে পারে। অবশ্যই, বিকাশকারীদের এর মাধ্যমে অপ্ট আউট করার বিকল্প রয়েছে৷ 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 পিকের মতো জিআইএফ-এ রপ্তানি করতে সক্ষম হওয়া উচিত। হাইকুর জন্য ইতিমধ্যে উপলব্ধ ffmpeg ব্যবহার করে এটি করা যেতে পারে। আবেদন.
• স্ক্রিনশট সফ্টওয়্যার পুরো স্ক্রিন ক্যাপচার করার পরিবর্তে একটি মডেল উইন্ডো ক্যাপচার করতে ব্যর্থ হয়
• আপনি WonderBrush এর ক্রপিং টুল ব্যবহার করে স্ক্রিনশট ক্রপ করতে পারবেন না এবং তারপর ফলাফলটি একটি ফাইলে সংরক্ষণ করুন
• আমি হাইকুতে হ্যান্ড কার্সারটি বিশেষভাবে পছন্দ করি না, তবে আমি মনে করি এটি উষ্ণ নস্টালজিক অনুভূতির সাথে সম্পর্কিত। কৃতাতে ক্রপ টুল ব্যবহার করার সময় এটি বিশেষত বিরক্তিকর, কারণ এর ফলে ভুল ক্রপিং হয় (এই নিবন্ধে মডেল ডায়ালগের স্ক্রিনশট দেখুন)। একটি ক্রসহেয়ার কার্সার চমৎকার হবে। আবেদন.

এটি নিজে চেষ্টা করো! সর্বোপরি, হাইকু প্রজেক্ট ডিভিডি বা ইউএসবি থেকে বুট করার জন্য ইমেজ প্রদান করে ежедневно. ইনস্টল করতে, শুধু ছবিটি ডাউনলোড করুন এবং এটি ব্যবহার করে একটি ফ্ল্যাশ ড্রাইভে লিখুন ক্ষোদক

আপনি কি কিছু জানতে চান? আমরা আপনাকে রাশিয়ান-ভাষী আমন্ত্রণ জানাই টেলিগ্রাম চ্যানেল.

ত্রুটি ওভারভিউ: সি এবং সি++ এ কীভাবে নিজেকে পায়ে গুলি করবেন। হাইকু ওএস রেসিপি সংগ্রহ

থেকে লেখক অনুবাদ: এটি হাইকু সম্পর্কে সিরিজের ষষ্ঠ নিবন্ধ।

নিবন্ধের তালিকা: প্রথম দ্বিতীয় তৃতীয় চতুর্থ পঞ্চম

উত্স: www.habr.com