હાઈકુ સાથેનો મારો છઠ્ઠો દિવસ: સંસાધનો, ચિહ્નો અને પેકેજોના હૂડ હેઠળ

TL; DR: હાઈકુ એ ખાસ કરીને PC માટે રચાયેલ ઓપરેટિંગ સિસ્ટમ છે, તેથી તેમાં ઘણી યુક્તિઓ છે જે તેના ડેસ્કટોપ પર્યાવરણને અન્ય કરતા વધુ સારી બનાવે છે. પરંતુ તે કેવી રીતે કામ કરે છે?

તાજેતરમાં મેં હાઈકુ શોધ્યું, એક અણધારી રીતે સારી સિસ્ટમ. હું હજી પણ આશ્ચર્યચકિત છું કે તે કેવી રીતે સરળતાથી ચાલે છે, ખાસ કરીને Linux ડેસ્કટોપ વાતાવરણની તુલનામાં. આજે હું હૂડ હેઠળ એક નજર કરીશ. જ્યાં ઊંડાણપૂર્વકની સમજણ માટે જરૂરી હશે ત્યાં હું મૂળ Macintosh, Mac OS X અને Linux ડેસ્કટોપ એન્વાયર્નમેન્ટ્સ (freedesktop.org પરથી XDG સ્ટાન્ડર્ડ) સાથે સરખામણી કરીશ.

ELF ફાઇલોમાં સંસાધનો

ગઈ કાલે મેં જાણ્યું કે IconOMatic ELF એક્ઝિક્યુટેબલ્સમાં rdef સંસાધનોમાં ચિહ્નોને સાચવી શકે છે. આજે હું તે ખરેખર કેવી રીતે કામ કરે છે તે જોવા માંગુ છું.

સંસાધનો? ભાવ થી બ્રુસ હોર્ન, મેકિન્ટોશ ફાઇન્ડરના મૂળ લેખક અને મેકિન્ટોશ રિસોર્સ મેનેજરના "પિતા":

હું પરંપરાગત કોડિંગની સખત પ્રકૃતિ વિશે ચિંતિત છું. મારા માટે, ગતિશીલ રીતે કંઈપણ બદલવાની ક્ષમતા વિના, કોડમાં સ્થિર એપ્લિકેશનનો ખૂબ જ વિચાર, જંગલી ક્રૂરતા છે. રનટાઇમ પર શક્ય તેટલું બદલવું શક્ય હોવું જોઈએ. અલબત્ત, એપ્લિકેશન કોડ પોતે બદલી શકાતો નથી, પરંતુ કોડને ફરીથી કમ્પાઇલ કર્યા વિના ચોક્કસ કંઈક બદલી શકાય છે?

મૂળ મેકિન્ટોશ પર, તેઓએ આ ફાઇલોને "ડેટા વિભાગ" અને "સંસાધન વિભાગ" બનાવી છે, જેણે ચિહ્નો, અનુવાદો અને તેના જેવી વસ્તુઓને સાચવવાનું અતિ સરળ બનાવ્યું છે. એક્ઝિક્યુટેબલ ફાઇલોમાં.

Mac પર આનો ઉપયોગ થાય છે ફરીથી સંપાદિત કરો, એક ગ્રાફિકલ પ્રોગ્રામ માટે - અચાનક - સંપાદન સંસાધનો.

મૂળ મેકિન્ટોશ પર ફરીથી સંપાદિત કરો

પરિણામે, ચિહ્નો, મેનૂ વસ્તુઓ, અનુવાદો વગેરેને સંપાદિત કરવાનું શક્ય બન્યું. પર્યાપ્ત સરળ છે, પરંતુ તેઓ હજી પણ એપ્લિકેશન સાથે "મુસાફરી" કરે છે.
કોઈ પણ સંજોગોમાં, આ અભિગમમાં મોટી ખામી હતી: તે ફક્ત Appleપલ ફાઇલ સિસ્ટમ્સ પર જ કામ કરતી હતી, જે એક કારણ હતું કે Appleપલે Mac OS X પર જતી વખતે "સંસાધન વિભાગ" છોડી દીધું હતું.
Mac OS X પર, Appleને ફાઇલ સિસ્ટમ-સ્વતંત્ર સોલ્યુશન જોઈતું હતું, તેથી તેણે પેકેજીસનો ખ્યાલ અપનાવ્યો (NEXT), ડિરેક્ટરીઓ કે જેને ફાઇલ મેનેજર દ્વારા "અપારદર્શક ઑબ્જેક્ટ્સ" તરીકે ગણવામાં આવે છે, જેમ કે ડિરેક્ટરીઓને બદલે ફાઇલો. ફોર્મેટમાં એપ્લિકેશન સાથેનું કોઈપણ પેકેજ .app અન્ય વસ્તુઓની સાથે, એક ફાઇલ ધરાવે છે Info.plist (એપલના JSON અથવા YAML ની ​​સમકક્ષ અમુક પ્રકારની) એપ્લિકેશન મેટાડેટા ધરાવે છે.

Mac OS X એપ્લિકેશન પેકેજમાંથી Info.plist ફાઇલ માટેની કી.

સંસાધનો, જેમ કે ચિહ્નો, UI ફાઇલો અને અન્ય, પેકેજમાં ફાઇલો તરીકે સંગ્રહિત થાય છે. આ ખ્યાલ વાસ્તવમાં નેક્સ્ટમાં તેના મૂળમાં પાછો ગયો.

1.0 માં NeXTSTEP 1989 પર Mathematica.app: ટર્મિનલમાં ફાઇલોની ડિરેક્ટરી તરીકે દેખાય છે, પરંતુ ગ્રાફિકલ ફાઇલ મેનેજરમાં એક જ ઑબ્જેક્ટ તરીકે.

ચાલો BeOS પર પાછા ફરીએ, જે ખ્યાલો પર હાઈકુ આધારિત છે. તેના ડેવલપર્સે, જ્યારે PEF (PowerPC) થી ELF (x86) (Linux પર વપરાતા સમાન) પર સ્વિચ કરી રહ્યા હતા, ત્યારે ELF ફાઇલોના અંતમાં સંસાધન વિભાગ ઉમેરવાનું નક્કી કર્યું હતું. તે તેના પોતાના યોગ્ય ELF વિભાગનો ઉપયોગ કરતું નથી, તે ફક્ત ELF ફાઇલના અંતમાં જોડવામાં આવ્યું હતું. કાર્યક્રમના પરિણામે strip અને binutils ના અન્ય, આ વિશે જાણતા નથી, તેને ખાલી કાપી નાખો. તેથી, જ્યારે BeOS પર ELF ફાઇલમાં સંસાધનો ઉમેરતા હોય, ત્યારે તેને Linux ટૂલ્સ સાથે ચાલાકી ન કરવી તે વધુ સારું છે.

હાઈકુ સાથે હવે શું થઈ રહ્યું છે? મૂળભૂત રીતે, વધુ કે ઓછા સમાન.

સિદ્ધાંતમાં, ELF ના ઇચ્છિત વિભાગમાં સંસાધનો મૂકવાનું શક્ય બનશે. irc.freenode.net પર #haiku ચેનલ પરના વિકાસકર્તાઓ અનુસાર:

ELF સાથે વિભાગ વધુ અર્થપૂર્ણ બનશે... અમે તે રીતે નથી કરી રહ્યા તેનું એકમાત્ર કારણ એ છે કે અમે BeOS માં જે કર્યું છે તે જ છે."
અને હવે આને બદલવાનો કોઈ અર્થ નથી.

સંસાધન વ્યવસ્થાપન

સંસાધનો એક સંરચિત "સંસાધન" ફોર્મેટમાં લખવામાં આવે છે: આવશ્યકપણે કદ સાથે સંસાધનોની સૂચિ અને પછી તેમની સામગ્રી. મને યાદ છે ar ફોર્મેટ.
હાઈકુમાં સંસાધનો કેવી રીતે તપાસવા? શું ResEdit જેવું કંઈક છે?
અનુસાર દસ્તાવેજીકરણ:

એપ્લિકેશન પેકેજમાં આપેલા સંસાધનોને જોવા માટે, તમે એક્ઝેક્યુટેબલ ફાઇલને પ્રોગ્રામ પર ખેંચી શકો છો જેમ કે રિસોર્સર. તમે ટર્મિનલ પર જઈને આદેશ પણ ચલાવી શકો છો listres имя_файла.

રિસોર્સર 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, જે સિસ્ટમને જ્યારે પણ વપરાશકર્તા વિનંતી કરે ત્યારે નવી એપ્લિકેશન પ્રક્રિયા શરૂ કરવા દબાણ કરે છે (આ જ સિદ્ધાંત Linux પર મોટાભાગની એપ્લિકેશનો માટે વપરાય છે). ખાવું B_MULTIPLE_LAUNCH, જેના કારણે પ્રક્રિયા ચાલી રહી છે દરેક ફાઇલ. છેલ્લે ત્યાં છે B_EXCLUSIVE_LAUNCH, જે સિસ્ટમને એક સમયે માત્ર એક જ પ્રક્રિયા શરૂ કરવા દબાણ કરે છે, પછી ભલેને વપરાશકર્તાઓ તેને કેટલી વાર લોંચ કરે છે (ઉદાહરણ તરીકે, Linux પર ફાયરફોક્સ આ રીતે ચાલે છે; ફંક્શનનો ઉપયોગ કરીને Qt એપ્લિકેશન્સમાં સમાન પરિણામ પ્રાપ્ત કરી શકાય છે. QtSingleApplication). સાથે અરજીઓ B_EXCLUSIVE_LAUNCH જ્યારે વપરાશકર્તા તેમને ફરીથી ચલાવવાનો પ્રયાસ કરે છે ત્યારે તેમને સૂચિત કરવામાં આવે છે: ઉદાહરણ તરીકે, તેઓ ફાઇલનો પાથ મેળવે છે જે વપરાશકર્તા તેમની સહાયથી ખોલવા માંગે છે.
• vector_icon: વેક્ટર એપ્લીકેશન આઇકોન (BeOS પાસે વેક્ટર આઇકોન નહોતા, મોટાભાગની એપ્લીકેશનોમાં તેની એક્ઝિક્યુટેબલ ફાઇલોમાં બે રાસ્ટર આઇકોન હતા).

અલબત્ત, તમે કોઈપણ ઇચ્છિત ID અને પ્રકારો સાથે સંસાધનો ઉમેરી શકો છો, અને પછી તેને એપ્લિકેશનમાં અથવા વર્ગનો ઉપયોગ કરીને અન્ય એપ્લિકેશનમાં વાંચી શકો છો. BResources. પરંતુ પ્રથમ, ચાલો ચિહ્નોના રસપ્રદ વિષયને જોઈએ.

હાઈકુ શૈલીમાં વેક્ટર ચિહ્નો

અલબત્ત, માત્ર હાઇકુએ જ શ્રેષ્ઠ આઇકોન ફોર્મેટ પસંદ કર્યું નથી; આ ભાગમાં, Linux ડેસ્કટોપ વાતાવરણની પરિસ્થિતિ આદર્શથી ઘણી દૂર છે:

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

આને જોઈને તમે પહેલેથી જ અનુભવી શકો છો કે તે શું છે.

અલબત્ત, ત્યાં માપી શકાય તેવું છે, જેમાં તમે સમજી શકો તેમ, વેક્ટર ચિહ્નો ધરાવે છે. તો પછી બીજું કંઈ કેમ છે? કારણ કે નાના કદમાં વેક્ટર ગ્રાફિક્સ દોરવાનું પરિણામ આદર્શ કરતાં ઓછું હોઈ શકે છે. હું વિવિધ વિકલ્પોને વિવિધ કદ માટે ઑપ્ટિમાઇઝ કરવા ઈચ્છું છું. Linux ડેસ્કટોપ વાતાવરણમાં, આ સમગ્ર ફાઇલ સિસ્ટમમાં વિવિધ કદના ચિહ્નોને સ્કેટર કરીને પ્રાપ્ત થાય છે.

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

મહેરબાની કરીને નોંધ કરો: ફાયરફોક્સના વિવિધ સંસ્કરણોનો કોઈ ખ્યાલ નથી. આમ, સિસ્ટમ પર એપ્લિકેશનના બહુવિધ સંસ્કરણો હોવાની પરિસ્થિતિને આકર્ષક રીતે હેન્ડલ કરવી શક્ય નથી.

વિવિધ સંસ્કરણોમાં વિવિધ ફાયરફોક્સ ચિહ્નો. Linux માં વિવિધ ક્રેચ વિના આને હેન્ડલ કરવું હાલમાં અશક્ય છે.

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 લઈ શકતા નથી, તેને ઇમેજમેજિકમાં ફેંકી શકો છો અને તેને એક દિવસ કૉલ કરો; તમારે 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. સિસ્ટમ (ટ્રેકર અને ડેસ્કબારમાં) દ્વારા દર્શાવવામાં આવેલા ચિહ્નો આ વિસ્તૃત વિશેષતામાંથી વાંચવામાં આવે છે, કારણ કે આ ઉકેલ ઝડપથી કામ કરે છે. કેટલાક સ્થળોએ (જ્યાં ઝડપ મહત્વપૂર્ણ નથી, ઉદાહરણ તરીકે, સામાન્ય "વિશે" વિંડો), સિસ્ટમ ફાઇલમાંના સંસાધનમાંથી સીધા જ આઇકન મેળવે છે. પરંતુ આ અંત નથી. યાદ રાખો, Mac પર, વપરાશકર્તાઓ એપ્લિકેશન્સ, ડિરેક્ટરીઓ, દસ્તાવેજોના ચિહ્નોને તેમના પોતાના સાથે બદલી શકે છે, કારણ કે Mac પર આ "મહત્વપૂર્ણ" વસ્તુઓ કરવાનું શક્ય છે, ઉદાહરણ તરીકે પાછલા એક સાથે નવા સ્લેક આયકનને બદલીને. હાઈકુ પર, તમારે સંસાધનને (ફાઈલમાં) મૂળ ચિહ્ન તરીકે વિચારવું જોઈએ જે એપ્લિકેશન સાથે આવે છે, અને વિશેષતા (BFS ફાઈલ સિસ્ટમમાં) એવી વસ્તુ તરીકે વિચારવી જોઈએ જે વપરાશકર્તાને ઈચ્છા મુજબ ફેરફારો કરવાની મંજૂરી આપે છે (જોકે, સંકેત, આયકનની ટોચ પર કસ્ટમ આઇકન દાખલ કરવા માટે GUI એ વૈકલ્પિક છે). હજુ સુધી ડિફોલ્ટ રૂપે અમલમાં મૂકાયેલ નથી).

ફાઇલ સિસ્ટમ લક્ષણો તપાસી રહ્યું છે

ની મદદ સાથે resaddr ફાઇલ સિસ્ટમ વિશેષતાઓ તપાસવી અને સેટ કરવી શક્ય છે.

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

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

તે આવશ્યકપણે "ગુંદર" છે જે (વિશ્વસનીય) સંસાધનો અને (ઝડપી) ફાઇલસિસ્ટમ લક્ષણો વચ્ચે આગળ અને પાછળ રૂપાંતરણ કરે છે. અને સિસ્ટમ સંસાધનો પ્રાપ્ત કરવાની અપેક્ષા રાખે છે અને આપમેળે નકલ કરે છે, તેથી હું તેના વિશે વધુ ચિંતા કરીશ નહીં.

hpkg પેકેજોનો જાદુ

હાલમાં (મોટાભાગે) પેકેજોનો ઉપયોગ હાઈકુ પરના પ્રોગ્રામ્સ મેળવવા માટે થાય છે .hpkg. સાદા નામથી મૂર્ખ ન બનો: .hpkg ફોર્મેટ અન્ય ફોર્મેટ કરતા સમાન નામો સાથે સંપૂર્ણપણે અલગ રીતે કાર્ય કરે છે, જેમાં તમે અનુભવો છો, તેમાં વાસ્તવિક મહાસત્તાઓ છે.

પરંપરાગત પેકેજ ફોર્મેટ્સ સાથે, હું આ હકીકતને કારણે લાંબા સમયથી અસ્વસ્થ હતો: તમે એક વસ્તુ (પેકેજ) ડાઉનલોડ કરો છો, અને બીજી સિસ્ટમ પર ઇન્સ્ટોલ કરેલી છે (પેકેજની અંદરની ફાઇલો). પરંપરાગત રીતે પેકેજ ઇન્સ્ટોલ કરતી વખતે ફાઇલોનું સંચાલન કરવું (ઉદાહરણ તરીકે, તેમને કાઢી નાખવું) ખૂબ મુશ્કેલ છે. અને બધા કારણ કે પેકેજની સામગ્રી સમગ્ર ફાઈલ સિસ્ટમમાં વેરવિખેર, એ સ્થાનો સહિત જ્યાં સરેરાશ વપરાશકર્તાને લખવાની ઍક્સેસ ન હોય. આનાથી પ્રોગ્રામના આખા વર્ગને જન્મ મળે છે - પેકેજ મેનેજરો. પરંતુ પહેલાથી ઇન્સ્ટોલ કરેલ સૉફ્ટવેરને સ્થાનાંતરિત કરવું, ઉદાહરણ તરીકે, અન્ય મશીન પર, દૂર કરી શકાય તેવી ડિસ્ક અથવા ફાઇલ સર્વર વધુ મુશ્કેલ બની જાય છે, જો સંપૂર્ણપણે અશક્ય ન હોય. સામાન્ય લિનક્સ-આધારિત સિસ્ટમ પર, ત્યાં સરળતાથી લાખોથી લાખો વ્યક્તિગત ફાઇલો હોઈ શકે છે. કહેવાની જરૂર નથી, આ બંને નાજુક અને ધીમું છે, ઉદાહરણ તરીકે જ્યારે શરૂઆતમાં સિસ્ટમ સ્થાપિત કરી રહ્યા હોય, જ્યારે નિયમિત પેકેજો સ્થાપિત કરી રહ્યા હોય, અપડેટ કરી રહ્યા હોય અને અનઇન્સ્ટોલ કરી રહ્યા હોય, અને જ્યારે બુટ વોલ્યુમ (રુટ પાર્ટીશન) ને બીજા માધ્યમમાં નકલ કરી રહ્યા હોય.

હું AppImage પ્રોજેક્ટ પર કામ કરી રહ્યો છું, જે અંતિમ-વપરાશકર્તા એપ્લિકેશન માટે આંશિક ક્રચ છે. આ એક સૉફ્ટવેર વિતરણ ફોર્મેટ છે જે એપ્લિકેશન અને તેની તમામ અવલંબનને એક ફાઇલ સિસ્ટમ ઇમેજમાં એકત્રિત કરે છે જે જ્યારે એપ્લિકેશન શરૂ થાય ત્યારે માઉન્ટ થાય છે. નોંધપાત્ર રીતે વસ્તુઓને સરળ બનાવે છે, કારણ કે તે જ ઇમેજમેજિક અચાનક એક ફાઇલમાં ફેરવાય છે, જે ફક્ત માણસો દ્વારા ફાઇલ મેનેજરમાં સંચાલિત થાય છે. સૂચિત પદ્ધતિ ફક્ત સોફ્ટવેર માટે જ કામ કરે છે, જે પ્રોજેક્ટના નામમાં પ્રતિબિંબિત થાય છે, અને તેની પોતાની સમસ્યાઓનો સમૂહ પણ છે, કારણ કે Linux માટે સોફ્ટવેર વિતરિત કરવામાં સામેલ લોકો હંમેશા મારા તરફ તીર દર્શાવે છે.

ચાલો હાઈકુ પર પાછા ફરીએ. શું પરંપરાગત પેકેજ સિસ્ટમ્સ અને ઈમેજ-આધારિત સોફ્ટવેર ડિલિવરી વચ્ચે શ્રેષ્ઠ સંતુલન શોધવાનું શક્ય બન્યું છે? તેણીના પેકેજો .hpkg વાસ્તવમાં સંકુચિત ફાઇલ સિસ્ટમ છબીઓ. જ્યારે સિસ્ટમ બુટ થાય છે, ત્યારે કર્નલ લગભગ નીચેના કર્નલ સંદેશાઓ સાથે બધા સ્થાપિત અને સક્રિય પેકેજોને માઉન્ટ કરે છે:

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

સરસ, હા? ત્યાં અટકી જાઓ, તે વધુ ઠંડુ થશે!

ત્યાં એક ખૂબ જ વિશિષ્ટ પેકેજ છે:

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

તે કર્નલ સહિત ખૂબ જ ન્યૂનતમ ઓપરેટિંગ સિસ્ટમ ધરાવે છે. માનો કે ના માનો, કર્નલ પોતે પણ બુટ વોલ્યુમ (રુટ પાર્ટીશન) માંથી દૂર કરવામાં આવતું નથી, પરંતુ પેકેજમાંથી તેની જગ્યાએ કાળજીપૂર્વક લોડ કરવામાં આવે છે. .hpkg. વાહ! મેં પહેલેથી જ ઉલ્લેખ કર્યો છે કે મને લાગે છે કે હાઈકુના એકંદર અભિજાત્યપણુ અને સુસંગતતાનો એક ભાગ એ હકીકતથી આવે છે કે કર્નલ અને કોર યુઝરસ્પેસથી લઈને પેકેજ મેનેજમેન્ટ અને રનટાઈમ ઈન્ફ્રાસ્ટ્રક્ચર સુધીની સમગ્ર સિસ્ટમ એક ટીમ દ્વારા સહયોગથી વિકસાવવામાં આવી છે. કલ્પના કરો કે Linux પર આવું કંઈક ચલાવવા માટે કેટલા જુદા જુદા જૂથો અને ટીમો લેશે [હું PuppyLinux પ્રોજેક્ટની કલ્પના કરું છું - આશરે. અનુવાદક]. પછી કલ્પના કરો કે વિતરણમાં આ અભિગમ અપનાવવામાં કેટલો સમય લાગશે. તેઓ કહે છે: એક સરળ સમસ્યા લો, તેને જુદા જુદા કલાકારો વચ્ચે વહેંચો, અને તે એટલી જટિલ બની જશે કે તેને હલ કરવાનું હવે શક્ય રહેશે નહીં. આ કિસ્સામાં હાઈકુએ મારી આંખો ખોલી. મને લાગે છે કે અત્યારે Linux પર આ જ થઈ રહ્યું છે.

hpkg નો ઉપયોગ કરીને સિસ્ટમ રોલબેક

નીચેની પરિસ્થિતિ કેટલી વાર થાય છે: અપડેટ સફળ થયું હતું, અને પછી તે તારણ આપે છે કે કંઈક જોઈએ તે પ્રમાણે કામ કરી રહ્યું નથી? જો તમે પરંપરાગત પેકેજ મેનેજરનો ઉપયોગ કરો છો, તો નવા પેકેજો સ્થાપિત થયા પહેલા સિસ્ટમની સ્થિતિને સમયસર પાછી આપવી મુશ્કેલ છે (ઉદાહરણ તરીકે, કંઈક ખોટું થયું હોય તો). કેટલીક સિસ્ટમો ફાઇલ સિસ્ટમ સ્નેપશોટના રૂપમાં વર્કઅરાઉન્ડ ઓફર કરે છે, પરંતુ તે ખૂબ જ બોજારૂપ છે અને બધી સિસ્ટમો પર ઉપયોગમાં લેવાતી નથી. હાઈકુ પેકેજોનો ઉપયોગ કરીને તેને ઉકેલે છે .hpkg. જ્યારે પણ સિસ્ટમમાં પેકેજો બદલાય છે, ત્યારે જૂના પેકેજો કાઢી નાખવામાં આવતા નથી, પરંતુ સિસ્ટમમાં સબડિરેક્ટરીઝમાં સંગ્રહિત થાય છે જેમ કે /Haiku/system/packages/administrative/state-<...>/ સતત અધૂરી કામગીરી તેમના ડેટાને સબડિરેક્ટરીઝમાં સંગ્રહિત કરે છે /Haiku/system/packages/administrative/transaction-<...>/.

સામગ્રી /Haiku/system/packages/administrative. "સ્ટેટ..." ડિરેક્ટરીઓમાં સક્રિય પેકેજોના નામ સાથેની ટેક્સ્ટ ફાઇલો હોય છે, અને "ટ્રાન્ઝેક્શન..." ડિરેક્ટરીઓ પોતે જ પેકેજો ધરાવે છે.

"જૂની સક્રિય સ્થિતિ", એટલે કે. યાદી .hpkg ટેક્સ્ટ ફાઇલમાં ફાઇલ મેનેજરમાં દરેક ઑપરેશન પછી ફેરફારો રેકોર્ડ થાય તે પહેલાં સક્રિય પેકેજો /Haiku/system/packages/administrative/state-<...>/activated-packages. તેવી જ રીતે, ટેક્સ્ટ ફાઇલમાં નવી "સક્રિય સ્થિતિ" લખેલી છે /Haiku/system/packages/administrative/activated-packages.

ડિરેક્ટરી /Haiku/system/packages/administrative/state-<...>/ આ રાજ્યના સક્રિય પેકેજોની સૂચિ સાથે માત્ર એક ટેક્સ્ટ ફાઇલ સમાવે છે (દૂર કર્યા વિના પેકેજોના ઇન્સ્ટોલેશનના કિસ્સામાં), અને જો પેકેજો દૂર કરવામાં આવ્યા હોય અથવા અપડેટ કરવામાં આવ્યા હોય તો - રાજ્ય નિર્દેશિકામાં પેકેજોની જૂની આવૃત્તિઓ છે.

જ્યારે સિસ્ટમ બુટ થાય છે, પેકેજોની યાદીના આધારે, પેકેજોને સક્રિય (માઉન્ટ) કરવાનો નિર્ણય લેવામાં આવે છે. તે સરળ છે! જો ડાઉનલોડ દરમિયાન કંઈક ખોટું થાય, તો તમે ડાઉનલોડ મેનેજરને અલગ, જૂની સૂચિનો ઉપયોગ કરવા માટે કહી શકો છો. પ્રશ્ન ઉકેલાઈ ગયો!

હાઈકુ ડાઉનલોડર. દરેક પ્રવેશ બિંદુ અનુરૂપ "સક્રિય સ્થિતિ" દર્શાવે છે

મને સરળ ટેક્સ્ટ ફાઇલોને "સક્રિય સ્થિતિ" સૂચિ તરીકે રાખવાનો અભિગમ ગમે છે, જે નામો સમજવામાં સરળ છે .hpkg. આ મશીનો માટે-લોકો માટે નહીં-બનાવવાથી તદ્દન વિપરીત છે. એક ટોળું માં ફાઇલ સિસ્ટમમાં OSTree અથવા Flatpak માંથી (Microsoft GUID જેવા જ સ્તરમાં).

સમયના દરેક બિંદુ માટે સક્રિય પેકેજોની સૂચિ

રૂપરેખાંકન ડેટા

દેખીતી રીતે, કેટલોગમાં /Haiku/system/packages/administrative/writable-files પેકેજો માટે રૂપરેખાંકન ફાઈલો સમાવે છે, પરંતુ તે લખી શકાય તેવી છે. છેવટે, જેમ તમને યાદ છે, .hpkg ફક્ત વાંચવા માટે માઉન્ટ થયેલ. તેથી આ ફાઇલોને લખતા પહેલા પેકેજોમાંથી કોપી કરવી આવશ્યક છે. અર્થ ધરાવે છે.

.hpkg સિસ્ટમ માટે GUI એકીકરણ

ચાલો હવે જોઈએ કે કેવી છે આ ચમકદાર બેગ .hpkg વપરાશકર્તાના કાર્ય પર્યાવરણ (UX) માં એકીકરણનો સામનો કરો. છેવટે, હાઈકુ વ્યક્તિગત ઉપયોગ માટે બનાવાયેલ છે. વ્યક્તિગત રીતે, પેકેજો સાથે વપરાશકર્તા અનુભવની તુલના કરતી વખતે મેં બારને ઉચ્ચ સેટ કર્યો છે .app મેકિન્ટોશ પર સમાન અનુભવ સાથે .hpkg. હું લિનક્સ પર કાર્યકારી વાતાવરણ સાથે પરિસ્થિતિની તુલના પણ કરીશ નહીં, કારણ કે તે અન્ય કોઈપણની તુલનામાં એકદમ ભયંકર છે.

નીચેના દૃશ્યો ધ્યાનમાં આવે છે:

• હું પેકેજની સામગ્રી જોવા માંગુ છું .hpkg
• હું એક પેકેજ ઇન્સ્ટોલ કરવા માંગુ છું
• હું પેકેજ દૂર કરવા માંગુ છું
• હું પેકેજના ભાગ રૂપે સિસ્ટમમાં આવેલું કંઈક દૂર કરવા માંગુ છું
• હું પેકેજના ભાગ રૂપે સિસ્ટમમાં આવી હોય તેવી કોઈ વસ્તુની નકલ કરવા માંગુ છું
• હું પેકેજની તમામ નિર્ભરતાઓ ડાઉનલોડ કરવા માંગુ છું, જે દરેક હાઈકુ ઇન્સ્ટોલેશનનો ભાગ ન હોઈ શકે (ઉદાહરણ તરીકે, મારી પાસે ઇન્ટરનેટ ઍક્સેસ વિનાનું ભૌતિક રીતે અલગ મશીન છે.)
• હું મારા પેકેજો (અથવા તેનો ભાગ) અલગથી બીજા સ્થાને ખસેડવા માંગુ છું, બૂટ વોલ્યુમ (રુટ પાર્ટીશન)થી અલગ (કારણ કે, ઉદાહરણ તરીકે, મારી પાસે તેના પર પૂરતી જગ્યા નથી).

આમાં મારા રોજિંદા કામના મોટા ભાગના મોટા કેસો આવરી લેવા જોઈએ. સારું, ચાલો શરૂ કરીએ.

પેકેજ સમાવિષ્ટો તપાસી રહ્યું છે

મેક પર હું તેને ખોલવા માટે પેકેજ પર જમણું-ક્લિક કરું છું અને ફાઇન્ડરમાં સમાવિષ્ટો જોઉં છું. છેવટે, વાસ્તવમાં તે માત્ર એક છૂપી ડિરેક્ટરી છે! (હું જાણું છું કે ત્યાં પેકેજો છે .pkg સિસ્ટમના એક ભાગ માટે કે જે એપ્લિકેશન નથી, પરંતુ સામાન્ય વપરાશકર્તાઓ મોટાભાગે તેમની સાથે ક્રિયાપ્રતિક્રિયા કરતા નથી).

હાઈકુ પર હું પેકેજ પર રાઇટ-ક્લિક કરું છું, પછી અંદર શું છે તે જોવા માટે "સામગ્રી" પર ક્લિક કરો. પરંતુ અહીં ફક્ત ફાઇલોની સૂચિ છે જેમાં તેને ડબલ-ક્લિક કરીને ખોલવાની ક્ષમતા નથી.
જો પેકેજને માઉન્ટ કરવાની (અસ્થાયી રૂપે) કોઈ રીત હોય તો તે વધુ સારું રહેશે .hpkg ફાઇલ મેનેજર દ્વારા જોવા માટે, અને વપરાશકર્તાને અમલીકરણ વિગતો વિશે ચિંતા કરવાની જરૂર નથી. (માર્ગ દ્વારા, તમે ખોલી શકો છો .hpkg માં પેકેજ Expander, જે તેને કોઈપણ અન્ય આર્કાઇવની જેમ અનપૅક કરી શકે છે).

હાઈકુડેપોટનું ઈન્ટરફેસ તમને પેકેજ ફાઈલોની યાદી જોવા માટે પરવાનગી આપે છે, પરંતુ સમાવિષ્ટો જોવાની કોઈ રીત નથી, ઉદાહરણ તરીકે, README.md પર ડબલ-ક્લિક કરીને

મેક આ કેટેગરીમાં જીતે છે, પરંતુ તમે ઇચ્છો તે હાઇકુડેપોટ કાર્યક્ષમતા ઉમેરવી ખૂબ મુશ્કેલ ન હોવી જોઈએ.

GUI દ્વારા પેકેજ ઇન્સ્ટોલ કરી રહ્યું છે

મેક પર, મોટાભાગની ડિસ્ક છબીઓ .dmg પેકેજો સમાવે છે .app. ડિસ્ક ઈમેજ પર બે વાર ક્લિક કરો અને પછી પેકેજની નકલ કરો, ઉદાહરણ તરીકે, તેને અંદર ખેંચીને /Applications ફાઇન્ડર માં. આ મારા માટે કહ્યા વિના જાય છે, પરંતુ મેં સાંભળ્યું છે કે કેટલાક નવોદિતો આને હેન્ડલ કરી શકશે નહીં. મૂળભૂત રીતે, Apple સિસ્ટમ-વ્યાપી ડિરેક્ટરી "સૂચન કરે છે". /Applications (આગળ પર તે નેટવર્ક તેમજ વ્યક્તિગત હતું), પરંતુ તમે તમારી એપ્લિકેશનને ફાઇલ સર્વર પર અથવા સબડિરેક્ટરીમાં સરળતાથી મૂકી શકો છો $HOME/Applications, જો તમને તે રીતે ગમે છે.

હાઈકુ પર, પેકેજ પર ડબલ ક્લિક કરો, પછી "ઇન્સ્ટોલ કરો" પર ક્લિક કરો, તે સરળ ન હોઈ શકે. હું આશ્ચર્ય પામી રહ્યો છું કે જો કોઈ પેકેજમાં ડિપેન્ડન્સી હોય જે હાઈકુપોર્ટ્સમાં ઉપલબ્ધ હોય પરંતુ હજુ સુધી ઇન્સ્ટોલ કરેલ ન હોય તો શું થશે. Linux પર તેઓ ખરેખર આ પરિસ્થિતિમાં શું કરવું તે જાણતા નથી, પરંતુ ઉકેલ સ્પષ્ટ છે - વપરાશકર્તાને પૂછો કે શું તેમને નિર્ભરતા ડાઉનલોડ અને ઇન્સ્ટોલ કરવાની જરૂર છે. હાઈકુ જે કરે છે તે બરાબર છે.

મેં 'સેનિટી' પેકેજ મેન્યુઅલી ડાઉનલોડ કર્યું અને તેના પર ક્લિક કર્યું, પેકેજ મેનેજર જાણે છે કે તેની નિર્ભરતા ક્યાંથી મેળવવી (ધારી લઈએ કે રીપોઝીટરીઝ સિસ્ટમ પર પહેલેથી જ નોંધાયેલ છે). દરેક Linux વિતરણ આ કરી શકતું નથી.

બીજી રીત ફાઇલ મેનેજરનો ઉપયોગ કરવાનો છે, ફક્ત ખેંચો અને છોડો .hpkg પેકેજ અથવા માં /Haiku/system/packages (સિસ્ટમ-વ્યાપી ઇન્સ્ટોલેશન માટે, મૂળભૂત રીતે), અથવા માં /Haiku/home/config/packages (વ્યક્તિગત ઇન્સ્ટોલેશન માટે; ડબલ-ક્લિક કરતી વખતે ઉપલબ્ધ નથી - હું હજી પણ આ જગ્યાએ "config" શબ્દથી નારાજ છું, જે આ કિસ્સામાં મારા માટે "સેટિંગ્સ" નો સમાનાર્થી છે). અને હાઈકુ માટે બહુવિધ વપરાશકર્તાઓનો ખ્યાલ હજી સુધી ઉપલબ્ધ નથી (તેથી જ કદાચ તે ખૂબ સરળ છે - મને ખબર નથી, કદાચ બહુ-વપરાશકર્તા ક્ષમતાઓ ડેસ્કટોપ ડેસ્કટોપ પર્યાવરણ માટે વસ્તુઓને બિનજરૂરી રીતે જટિલ બનાવશે).

હાઈકુ આ કેટેગરીમાં જીતે છે કારણ કે તે માત્ર એપ્લીકેશન સાથે જ નહીં, પરંતુ સિસ્ટમ પ્રોગ્રામ્સ સાથે પણ કામ કરી શકે છે.

GUI માંથી પેકેજ દૂર કરી રહ્યા છીએ

મેક પર, તમારે એપ્લિકેશન આયકનને ટ્રેશ કેનમાં ખેંચવાની જરૂર છે, અને આટલું જ. સરળતાથી!

હાઈકુ પર, સૌ પ્રથમ, તમારે સિસ્ટમ પર પેકેજ ક્યાં સ્થિત છે તે શોધવાની જરૂર છે, કારણ કે તમે ભાગ્યે જ તેને યોગ્ય જગ્યાએ ઇન્સ્ટોલ કરો છો (સિસ્ટમ બધું કરે છે). સામાન્ય રીતે તમારે અંદર જોવાની જરૂર છે /Haiku/system/packages (સિસ્ટમ-વ્યાપી ડિફોલ્ટ ઇન્સ્ટોલેશન સાથે), અથવા માં /Haiku/home/config/packages (શું મેં ઉલ્લેખ કર્યો છે કે "રૂપરેખા" એ ખોટું નામ છે?). પછી એપ્લિકેશનને ખાલી કચરાપેટીમાં ખેંચવામાં આવે છે, અને બસ.
સરળતાથી! જો કે, હું તે કહીશ નહીં. ખરેખર શું થઈ રહ્યું છે તે અહીં છે:

જો તમે એપ્લિકેશનમાંથી ટ્રેશ કેનમાં ખેંચો છો તો આવું થાય છે /Haiku/system/packages

હમણાં જ QtQuickApp પરની મારી ગઈકાલની "હેલો વર્લ્ડ" એપ્લિકેશનને ટ્રેશમાં ખસેડવાનો પ્રયાસ કર્યો. મેં સિસ્ટમ ડિરેક્ટરીને ખસેડવાનો પ્રયાસ કર્યો નથી, અને બધા પેકેજો સિસ્ટમ ડિરેક્ટરીમાં ઇન્સ્ટોલ કરેલ હોવાથી, પેકેજને દૂર કરવું અશક્ય છે .hpkg ફેરફાર વિના "તેની સામગ્રી". સામાન્ય વપરાશકર્તા ડરી જશે અને ડિફૉલ્ટ રૂપે સોંપેલ "રદ કરો" બટન દબાવો.

સમજાવે છે શ્રીમાન. waddlesplash:

આ પોસ્ટ 10 વર્ષથી વધુ જૂની છે. મોટે ભાગે આપણે તેને રૂપરેખાંકિત કરવાની જરૂર છે જેથી ચેતવણી ફક્ત ત્યારે જ દેખાય જ્યારે પેકેજ પોતે જ ખસેડવામાં આવે. નિયમિત વપરાશકર્તાઓને કોઈપણ રીતે આ કરવાની જરૂર નથી.

ઠીક છે, કદાચ મારે આ HaikuDepot નો ઉપયોગ કરીને કરવું જોઈએ? હું પેકેજ પર બે વાર ક્લિક કરું છું /Haiku/system/packages, "અનઇન્સ્ટોલ કરો" બટન દેખાય તેની રાહ જુઓ. ના, ત્યાં (માત્ર) “ઇન્સ્ટોલ” છે. "અનઇન્સ્ટોલ", તમે ક્યાં છો?

માત્ર આનંદ માટે, મેં એ જોવાનો પ્રયાસ કર્યો કે જો મેં પહેલેથી જ ઇન્સ્ટોલ કરેલ પેકેજ પર "ઇન્સ્ટોલ કરો" ક્લિક કર્યું તો શું થશે. તે આની જેમ બહાર આવે છે:

જો તમે પહેલાથી ઇન્સ્ટોલ કરેલ પેકેજ ઇન્સ્ટોલ કરવાનો પ્રયાસ કરો તો આવું થાય છે.

આગળ દેખાય છે:

જો તમે પહેલાની વિંડોમાં "ફેરફારો લાગુ કરો" પર ક્લિક કરો છો, તો તે આના જેવું દેખાશે

હું માનું છું કે આ એક સોફ્ટવેર ભૂલ છે; એપ્લિકેશનની લિંક પહેલેથી જ છે. [લેખકે લિંક આપી નથી - આશરે. અનુવાદક]

ઝડપી ઉકેલ: જો પેકેજ પહેલેથી અંદર હોય તો "અનઇન્સ્ટોલ કરો" બટન ઉમેરો /Haiku/system/packages, અથવા માં /Haiku/home/config/packages.

HaikuDepot માં સ્થાપિત પેકેજોની યાદી જોતી વખતે, હું યાદીમાં મારું પેકેજ જોઉં છું અને તેને દૂર કરી શકું છું.

આ શ્રેણીમાં મેક જીતે છે. પરંતુ હું કલ્પના કરી શકું છું કે યોગ્ય સેટઅપ સાથે, હાઈકુ પરનો વપરાશકર્તા અનુભવ Mac કરતાં વધુ સારો હશે. (વિકાસકર્તાઓમાંના એકે તેને આ રીતે રેટ કર્યું છે: "હાઈકુડેપોટમાં ઉલ્લેખિત કાર્યક્ષમતા ઉમેરવા માટે એક કલાક કરતાં ઓછો સમય, જો તમે થોડું C++ જાણો છો", તો કોઈ સ્વયંસેવકો?)

પેકેજમાંથી કંઈક દૂર કરવું

ચાલો એપ્લિકેશનને જ દૂર કરવાનો પ્રયાસ કરીએ, પેકેજને નહીં .hpkg, જેમાંથી તે આવ્યું છે (મને શંકા છે કે "માત્ર મનુષ્યો" માટે કોઈ તફાવત છે).

મેક પર, વપરાશકર્તા સામાન્ય રીતે ફાઇલ સાથે કામ કરે છે .dmgએપ્લિકેશન પેકેજ ક્યાંથી આવે છે .app. સામાન્ય રીતે છબીઓ .dmg ડાઉનલોડ ડિરેક્ટરીમાં સંચિત થાય છે, અને પેકેજોની નકલ વપરાશકર્તા દ્વારા કરવામાં આવે છે /Applications. એવું માનવામાં આવે છે કે ઘણા વપરાશકર્તાઓ પોતે જાણતા નથી કે તેઓ શું કરી રહ્યા છે, આ પૂર્વધારણાની પુષ્ટિ એપલના ભૂતપૂર્વ કર્મચારી દ્વારા કરવામાં આવી છે. (મેક પર એક વસ્તુ મને ગમતી નથી. અને, ઉદાહરણ તરીકે, AppImage સાથે, એપ્લિકેશન અને તે જે પેકેજમાં હતું તેમાં કોઈ તફાવત નથી. આયકનને ટ્રેશમાં ખેંચો = બસ. સરળ!)

હાઈકુ પર, વચ્ચે પણ વિભાજન છે apps/ и packages/, તેથી મને શંકા છે કે આનાથી તે વપરાશકર્તાઓ માટે વધુ સ્પષ્ટ થઈ ગયું છે. પરંતુ જો તમે કોઈ એપ્લિકેશનને માંથી ખેંચો તો શું થશે apps/ સૂચી માં સામેલ કરો:

જ્યારે તમે ફાઇલમાંથી લીધેલી એપ્લિકેશનને દૂર કરવાનો પ્રયાસ કરો છો ત્યારે આવું થાય છે .hpkg

તકનીકી રીતે તે સાચું છે (છેવટે, એપ્લિકેશન પ્રથમ સ્થાને ફક્ત વાંચવા માટે ફાઇલ સિસ્ટમ પર હોસ્ટ કરવામાં આવે છે), પરંતુ તે વપરાશકર્તા માટે ખાસ ઉપયોગી નથી.

ઝડપી ઉકેલ: તેના બદલે કાઢી નાખવા માટે GUI નો ઉપયોગ કરવાનું સૂચન કરો .hpkg

માત્ર આનંદ માટે, મેં Alt+D દબાવીને એપ્લિકેશનને ડુપ્લિકેટ કરવાનો પ્રયાસ કર્યો. મને સંદેશ મળ્યો "ઓન્લી-રીડ-ઓન્લી વોલ્યુમ પર ઑબ્જેક્ટ્સને ખસેડવામાં અથવા કૉપિ કરવામાં અસમર્થ." અને બધા કારણ કે /system (ઉપરાંત /system/packages и /system/settings) એ packagefs માઉન્ટ પોઈન્ટ છે (યાદ રાખો કે તે આઉટપુટમાં કેવી રીતે દેખાય છે df?). કમનસીબે, આદેશનું આઉટપુટ mount પરિસ્થિતિને સ્પષ્ટ કરતું નથી (જેમ કે અગાઉના લેખોમાંના એકમાં કહેવામાં આવ્યું હતું), mountvolume તમે જે શોધી રહ્યા છો તે બતાવતું નથી (દેખીતી રીતે લૂપ દ્વારા માઉન્ટ થયેલ પેકેજો .hpkg "વોલ્યુમ્સ" ગણવામાં આવતા નથી), અને હું વૈકલ્પિક આદેશો પણ ભૂલી ગયો.

AppImage સિવાય આ કેટેગરીમાં કોઈ જીતી શક્યું નથી (પરંતુ, સંપૂર્ણ પ્રમાણિકતાથી, આ એક પક્ષપાતી અભિપ્રાય છે). જો કે, કોઈ કલ્પના કરી શકે છે કે ટ્વિક કર્યા પછી, હાઈકુ પરનો વપરાશકર્તા અનુભવ Mac કરતાં વધુ સારો હશે.

નોંધ: તમારે "વિભાગ" ના સંબંધમાં "વોલ્યુમ" શું છે તે શોધવાની જરૂર છે. આ કદાચ "ફોલ્ડર" અને "ડિરેક્ટરી" ના સંબંધ સમાન છે: મોટાભાગની ડિરેક્ટરીઓ ફાઇલ મેનેજરમાં ફોલ્ડર્સ તરીકે દેખાય છે, પરંતુ તે બધી નથી (ઉદાહરણ તરીકે, ફાઇલો તરીકે ગણવામાં આવતા પેકેજો). શું આ પ્રકારનું પ્રદર્શન મને સત્તાવાર જ્ઞાની બનાવે છે?

પેકેજની સામગ્રીને બીજી સિસ્ટમમાં નકલ કરી રહ્યા છીએ

મેક પર, હું stupidly પેકેજ ખેંચો .app, અને નિર્ભરતા પેકેજની અંદર હોવાથી, તેઓ એકસાથે આગળ વધે છે.

હાઈકુ પર, હું એપ્લિકેશન ખેંચું છું, પરંતુ નિર્ભરતાઓ પર બિલકુલ પ્રક્રિયા થતી નથી.

ઝડપી ઉકેલ: ચાલો તેના બદલે આખા `.hpkg પેકેજને કોઈપણ નિર્ભરતા સાથે, જો કોઈ હોય તો ખેંચવાનું સૂચન કરીએ.

મેક સ્પષ્ટપણે આ શ્રેણીમાં જીતે છે. ઓછામાં ઓછા મારા માટે, તેમના દૃષ્ટાંતનો પ્રેમી. મારે તેની નકલ હાઈકુમાં કરવી જોઈએ .hpkg એપ્લિકેશનને બદલે, પરંતુ સિસ્ટમ મને આ ઓફર કરતી નથી...

તેની તમામ અવલંબન સાથે પેકેજ ડાઉનલોડ કરો

દરેક મશીન હંમેશા નેટવર્ક સાથે જોડાયેલ નથી. તેનાથી વિપરીત, કેટલાક મશીનો (હા, હું તમને જોઈ રહ્યો છું, આધુનિક વિન્ડોઝ, મેક અને લિનક્સ) આ વિશે ભૂલી જાય છે. મારા માટે તે અગત્યનું છે કે હું ઈન્ટરનેટ કાફેમાં જઈ શકું, દૂર કરી શકાય તેવી ડ્રાઈવ પર સોફ્ટવેર ડાઉનલોડ કરી શકું, આ ડ્રાઈવને મારા હોમ કોમ્પ્યુટરમાં ઈન્સર્ટ કરી શકું અને ખાતરી કરો કે બધું જ કામ કરશે [જોખમી વ્યક્તિ, વિન્ડોઝ પર આવું કરવું... - આશરે. અનુવાદક].

પરિણામે, હું સામાન્ય કરતાં થોડી વધુ વાર વિન્ડોઝ અને લિનક્સ પર અપૂર્ણ નિર્ભરતા સાથે સમાપ્ત થવાનું વલણ ધરાવે છે.

મેક પર આ સામાન્ય રીતે એક ફાઇલ છે, તમારે ફક્ત ડાઉનલોડ કરવાની જરૂર છે .dmg. મોટાભાગે, તેની પાસે ડિફોલ્ટ રૂપે MacOS દ્વારા પૂરી પાડવામાં આવેલ સિવાય અન્ય કોઈ નિર્ભરતા હોતી નથી. એક અપવાદ એ જટિલ એપ્લિકેશનો છે જેને યોગ્ય એક્ઝેક્યુશન પર્યાવરણની જરૂર હોય છે, ઉદાહરણ તરીકે java.

હાઈકુ પર પેકેજ ડાઉનલોડ કરો .hpkg માટે, કહો, java માં સમાન એપ્લિકેશન, પર્યાપ્ત નથી, કારણ કે java લક્ષ્ય મશીન પર હાજર હોઈ શકે છે અથવા ન પણ હોઈ શકે. આપેલ પેકેજ માટે બધી નિર્ભરતાને ડાઉનલોડ કરવાની કોઈ રીત છે? .hpkg, તે સિવાય કે જે હાઈકુમાં ડિફૉલ્ટ રૂપે ઇન્સ્ટોલ કરેલ છે અને તેથી દરેક હાઈકુ સિસ્ટમ પર હોવું જોઈએ?

Mac આ કેટેગરીમાં નાના માર્જિનથી જીતે છે.

ટિપ્પણીઓ શ્રી. waddlesplash:

પેકેજના સમૂહ તરીકે એપ્લિકેશનની તમામ નિર્ભરતાને એકત્રિત કરવા માટે પ્રોગ્રામ લખવા માટે .hpkg હાઈકુના આંતરિક કાર્યથી પરિચિત વ્યક્તિ માટે, લગભગ 15 મિનિટ પૂરતી છે. જો તેની વાસ્તવિક જરૂરિયાત હોય તો આ માટે સમર્થન ઉમેરવું એટલું મુશ્કેલ નથી. પરંતુ મારા માટે આ એક દુર્લભ પરિસ્થિતિ છે.

ચાલો આ શ્રેણીના આગલા લેખ સુધી આપણા શ્વાસને પકડી રાખીએ.

પેકેજોને અલગ સ્થાન પર ખસેડવું

મેં અગાઉ લખ્યું તેમ, હું મારા પેકેજો મૂકવા માંગુ છું .hpkg (સારી રીતે, અથવા તેનો ભાગ) વિશિષ્ટ સ્થાન પર, બૂટ વોલ્યુમ (રુટ પાર્ટીશન) પરના સામાન્ય પ્લેસમેન્ટથી અલગ. સામાન્ય (તેટલું સૈદ્ધાંતિક નથી) કિસ્સામાં, આનું કારણ એ છે કે મારી (બિલ્ટ-ઇન) ડિસ્ક પર ખાલી જગ્યા સતત સમાપ્ત થઈ જાય છે, પછી ભલે તે ગમે તેટલી મોટી હોય. અને હું સામાન્ય રીતે જ્યાં મારી એપ્લીકેશનો સ્થિત છે ત્યાં બાહ્ય ડ્રાઈવો અથવા નેટવર્ક શેર્સને કનેક્ટ કરું છું.

મેક પર હું માત્ર પેકેજો ખસેડી રહ્યો છું .app ફાઇન્ડરમાં દૂર કરી શકાય તેવી ડ્રાઇવ અથવા નેટવર્ક ડિરેક્ટરીમાં, અને બસ. હું હજુ પણ એપ્લીકેશન ખોલવા માટે ડબલ-ક્લિક કરી શકું છું જેમ કે હું સામાન્ય રીતે બૂટ વોલ્યુમથી કરું છું. માત્ર!

હાઈકુ પર, જેમ મને કહેવામાં આવ્યું હતું, આ મારા ખસેડીને પ્રાપ્ત કરી શકાય છે .hpkg પેકેજો દૂર કરી શકાય તેવી ડ્રાઈવ અથવા નેટવર્ક ડિરેક્ટરીમાં, પરંતુ પછી તમારે તેમને સિસ્ટમ પર માઉન્ટ કરવા માટે કન્સોલમાં કેટલાક બિનદસ્તાવેજીકૃત આદેશોનો ઉપયોગ કરવાની જરૂર છે. માત્ર GUI નો ઉપયોગ કરીને આ કેવી રીતે કરવું તે મને ખબર નથી.

આ કેટેગરીમાં મેક જીતે છે.

મિસ્ટર મુજબ. waddlesplash:

આ સામાન્ય ઉપયોગ પર આધારિત ઓપ્ટિમાઇઝેશન છે. જો એક કરતા વધુ યુઝર્સ તરફથી ડિમાન્ડ હશે તો અમે તેનો અમલ કરીશું. કોઈ પણ સંજોગોમાં, તૃતીય-પક્ષ અમલીકરણની શક્યતા છે.

આ વિશે હવે પછીના લેખમાં વાત કરીશું.

નેટવર્ક ડિરેક્ટરીઓની વાત કરીએ તો, સરળ, શોધી શકાય તેવી, નેટવર્ક-વ્યાપી એપ્લિકેશનો (જેમ કે Zeroconf) હોવી ખૂબ જ સરસ રહેશે (હું LAN પક્ષોને અનુમાન લગાવું છું) કે જે સ્થાનિક કમ્પ્યુટર પર કૉપિ કરી શકાય છે અથવા સ્થાનિક નેટવર્કથી સીધા જ ચલાવી શકાય છે. અલબત્ત, વિકાસકર્તાઓ પાસે આ દ્વારા નાપસંદ કરવાનો વિકલ્પ છે app_flags.

GUI સાથે hpkg સિસ્ટમના એકીકરણ પર અંતિમ અહેવાલ

મને લાગે છે કે મુખ્યત્વે એકીકરણની સંબંધિત નવીનતાને કારણે .hpkg GUI હજુ પણ ઇચ્છિત થવા માટે ઘણું છોડી દે છે. કોઈપણ રીતે, યુએક્સના સંદર્ભમાં કેટલીક વસ્તુઓ સુધારી શકાય છે...

એક વધુ વસ્તુ: કર્નલ ડીબગ લેન્ડ

ઉદાહરણ તરીકે, કર્નલ ગભરાટ દરમિયાન આદેશો દાખલ કરવામાં સક્ષમ બનવું તે સરસ રહેશે syslog | grep usb. ઠીક છે, હાઇકુ પર તે કર્નલ ડીબગ લેન્ડને કારણે શક્ય છે. જો કર્નલ ગભરાટમાં આવ્યા વિના બધું જોઈએ તે પ્રમાણે કાર્ય કરે તો તમે આ જાદુને કેવી રીતે કાર્યમાં જોઈ શકો છો? Alt+PrintScn+D (ડીબગ નેમોનિક) દબાવીને સરળ. મને તરત જ યાદ આવે છે પ્રોગ્રામરની કી, જેણે મૂળ મેકિન્ટોશ ડેવલપર્સને ડીબગર દાખલ કરવાની મંજૂરી આપી હતી (જો કોઈ ઇન્સ્ટોલ કરેલું હોય, અલબત્ત).

નિષ્કર્ષ

હું એ સમજવા લાગ્યો છું કે હાઈકુ સિસ્ટમની અભિજાત્યપણુ એ હકીકતથી આવે છે કે કાર્ય એક નાની ટીમ દ્વારા કાર્ય પર્યાવરણ પર સ્પષ્ટ ધ્યાન કેન્દ્રિત કરીને, સિસ્ટમના તમામ સ્તરો સુલભતા સાથે હાથ ધરવામાં આવે છે.
Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu ની દુનિયા સાથે તીવ્ર વિરોધાભાસ, જ્યાં દરેક વસ્તુ એટલી હદે નાના ટુકડાઓમાં વિભાજિત થઈ ગઈ છે કે એબ્સ્ટ્રેક્શન એબ્સ્ટ્રેક્શન પર બેસે છે અને ક્રૉચ સાથે ચલાવે છે.
કેવી રીતે વ્યવસ્થા છે તેની પણ સમજ હતી .hpkg પરંપરાગત પેકેજ મેનેજર, Snappy, Flatpak, AppImage, ઇવન btrfs ની શ્રેષ્ઠ પ્રથાઓને જોડે છે અને તેમને Mac ના "જસ્ટ વર્ક્સ" અભિગમ સાથે ભેળવે છે.

એવું હતું કે મારા માથામાં કંઈક "સ્વિચ" થયું, અને હું સમજી ગયો કે સિસ્ટમ કેવી છે .hpkg માત્ર તેણીને જોઈને, કેવી રીતે દૂર થવું તે જાણે છે. પરંતુ તે હું નથી, પરંતુ સિસ્ટમની સુંદરતા અને સરળતા છે. આમાંથી મોટા ભાગની મૂળ મેકની ભાવનાથી પ્રેરિત છે.

હા, બ્રાઉઝરમાં બ્રાઉઝિંગ આંચકાજનક હોઈ શકે છે અને ગોકળગાયની જેમ ચાલે છે, એપ્લિકેશનનો અભાવ હોઈ શકે છે (કોઈ Gtk, ઇલેક્ટ્રોન - વિકાસકર્તાઓ નિષ્કર્ષ પર આવ્યા છે કે તેઓ અભિજાત્યપણુ સાથે સારી રીતે જતા નથી), વિડિઓ અને 3d પ્રવેગક સંપૂર્ણપણે ગેરહાજર હોઈ શકે છે, પરંતુ હું હજી પણ આ સિસ્ટમ ગમે છે. છેવટે, આ વસ્તુઓને સુધારી શકાય છે અને તે વહેલા અથવા પછીના સમયમાં દેખાશે. તે માત્ર સમયની બાબત છે અને કદાચ થોડી લાલ આંખ.

હું મદદ આપી શકતો નથી, પરંતુ મને લાગે છે કે તે હવેથી શરૂ થશે ડેસ્કટોપ પર હાઈકુનું વર્ષ.

રેન્ડમ સમસ્યાઓ

કદાચ ત્યાં પહેલેથી જ વિનંતીઓ છે, અથવા મારે તેને ખોલવી જોઈએ?

• BeScreenCapture પીકની જેમ GIF પર નિકાસ કરવામાં સક્ષમ હોવું જોઈએ. હાઈકુ માટે પહેલેથી જ ઉપલબ્ધ ffmpeg નો ઉપયોગ કરીને આ કરી શકાય છે. અરજી.
• સ્ક્રીનશોટ સોફ્ટવેર મોડલ વિન્ડોને કેપ્ચર કરવામાં નિષ્ફળ જાય છે, તેના બદલે સમગ્ર સ્ક્રીનને કેપ્ચર કરે છે
• તમે વન્ડરબ્રશના ક્રોપિંગ ટૂલનો ઉપયોગ કરીને સ્ક્રીનશૉટ્સ કાપી શકતા નથી અને પછી પરિણામને ફાઇલમાં સાચવી શકો છો
• મને ખાસ કરીને હાઈકુમાં હેન્ડ કર્સર ગમતું નથી, પરંતુ મને લાગે છે કે તેનો સંબંધ ગરમ નોસ્ટાલ્જિક લાગણી સાથે છે. ક્રિતામાં ક્રોપ ટૂલનો ઉપયોગ કરતી વખતે આ ખાસ કરીને હેરાન કરે છે, કારણ કે તે અચોક્કસ પાકમાં પરિણમે છે (આ લેખમાં મોડલ સંવાદોના સ્ક્રીનશોટ જુઓ). ક્રોસહેર કર્સર અદ્ભુત હશે. અરજી.

તેને જાતે અજમાવી જુઓ! છેવટે, હાઈકુ પ્રોજેક્ટ ડીવીડી અથવા યુએસબી માંથી બુટ કરવા માટે ઈમેજો પ્રદાન કરે છે, જે જનરેટ થાય છે દૈનિક. ઇન્સ્ટોલ કરવા માટે, ફક્ત ઇમેજ ડાઉનલોડ કરો અને તેનો ઉપયોગ કરીને ફ્લેશ ડ્રાઇવ પર લખો Etcher

શું તમારી પાસે કોઈ પ્રશ્નો છે? અમે તમને રશિયન બોલતા માટે આમંત્રિત કરીએ છીએ ટેલિગ્રામ ચેનલ.

ભૂલ વિહંગાવલોકન: C અને C++ માં પગમાં તમારી જાતને કેવી રીતે મારવી. હાઈકુ ઓએસ રેસીપી સંગ્રહ

થી લેખક અનુવાદ: હાઈકુ વિશેની શ્રેણીનો આ છઠ્ઠો લેખ છે.

લેખોની સૂચિ: પ્રથમ બીજો ત્રીજો ચોથું પાંચમો

સોર્સ: www.habr.com