Tl; DR: Ang Haiku ay isang operating system na partikular na idinisenyo para sa mga PC, kaya mayroon itong ilang mga trick na ginagawang mas mahusay ang desktop environment nito kaysa sa iba. Ngunit paano ito gumagana?
Natuklasan ko ang Haiku, isang hindi inaasahang magandang sistema. Namangha pa rin ako sa kung gaano ito kabilis tumakbo, lalo na kung ikukumpara sa mga Linux desktop environment. Ngayon ay titingnan ko ang ilalim ng talukbong. Kung kinakailangan para sa malalim na pag-unawa, gagawa ako ng mga paghahambing sa orihinal na Macintosh, Mac OS X at Linux desktop environment (XDG standard mula sa freedesktop.org).
Mga mapagkukunan sa ELF file
Kahapon nalaman ko na ang IconOMatic ay makakapag-save ng mga icon sa rdef resources sa ELF executables. Ngayon gusto kong makita kung paano ito gumagana.
Mga mapagkukunan? mula sa , ang orihinal na may-akda ng Macintosh Finder at ang "ama" ng Macintosh Resource Manager:
Nag-aalala ako tungkol sa mahigpit na katangian ng tradisyonal na coding. Para sa akin, ang mismong ideya ng isang application na naka-freeze sa code, nang walang kakayahang baguhin ang anumang bagay nang pabago-bago, ay ang pinakamabangis na kalupitan. Posibleng baguhin hangga't maaari sa runtime. Siyempre, ang application code mismo ay hindi mababago, ngunit tiyak na may mababago nang hindi muling kino-compile ang code?
Sa orihinal na Macintosh, ginawa nila ang mga file na ito na magkaroon ng isang "seksyon ng data" at isang "seksyon ng mapagkukunan," na ginawang napakadaling i-save ang mga bagay tulad ng mga icon, pagsasalin, at iba pa. sa mga executable na file.
Sa Mac ito ay ginagamit , isang graphical na programa para sa - biglang - pag-edit ng mga mapagkukunan.
I-resEdit sa orihinal na Macintosh
Bilang resulta, naging posible ang pag-edit ng mga icon, mga item sa menu, mga pagsasalin, atbp. sapat na madali, ngunit sila ay "naglalakbay" pa rin kasama ang mga application.
Sa anumang kaso, ang diskarte na ito ay may malaking sagabal: ito ay gumagana lamang sa mga Apple file system, na isa sa mga dahilan kung bakit inabandona ng Apple ang "seksyon ng mapagkukunan" kapag lumipat sa Mac OS X.
Sa Mac OS X, gusto ng Apple ang isang file system-independent na solusyon, kaya pinagtibay nila ang konsepto ng mga pakete (mula sa NeXT), mga direktoryo na itinuturing bilang "mga opaque na bagay" ng file manager, tulad ng mga file sa halip na mga direktoryo. Anumang package na may application sa format .app ay may, bukod sa iba pang mga bagay, isang file Info.plist (sa ilang uri ng katumbas ng Apple ng JSON o YAML) na naglalaman ng metadata ng application.
Mga key para sa Info.plist file mula sa Mac OS X application package.
Ang mga mapagkukunan, tulad ng mga icon, UI file, at iba pa, ay iniimbak sa package bilang mga file. Ang konsepto ay talagang bumalik sa mga ugat nito sa NeXT.
Mathematica.app sa NeXTSTEP 1.0 noong 1989: lumalabas bilang isang direktoryo ng mga file sa terminal, ngunit bilang isang bagay sa graphical file manager.
Bumalik tayo sa BeOS, ang mga konsepto kung saan nakabatay ang Haiku. Ang mga developer nito, nang lumipat mula sa PEF (PowerPC) patungo sa ELF (x86) (katulad ng ginamit sa Linux), ay nagpasya na magdagdag ng seksyon ng mapagkukunan sa dulo ng mga ELF file. Hindi nito ginamit ang sarili nitong wastong seksyon ng ELF, ito ay idinagdag lamang sa dulo ng ELF file. Bilang resulta ng programa strip at iba pang mga binutil, hindi alam ito, putulin na lang. Samakatuwid, kapag nagdaragdag ng mga mapagkukunan sa isang ELF file sa BeOS, mas mahusay na huwag manipulahin ito gamit ang mga tool sa Linux.
Ano na ang nangyayari kay Haiku ngayon? Talaga, higit pa o hindi gaanong pareho.
Sa teorya, posibleng maglagay ng mga mapagkukunan sa nais na seksyon ng ELF. Ayon sa mga developer sa #haiku channel sa irc.freenode.net:
Sa ELF mas magiging makabuluhan ang seksyon... ang tanging dahilan kung bakit hindi namin ginagawa iyon ay dahil ito ang ginawa namin sa BeOS."
At walang saysay na baguhin ito ngayon.
Pamamahala ng mapagkukunan
Ang mga mapagkukunan ay nakasulat sa isang structured na "resource" na format: mahalagang isang listahan ng mga mapagkukunan na may mga laki at pagkatapos ay ang kanilang nilalaman. naalala ko .
Paano suriin ang mga mapagkukunan sa Haiku? Mayroon bang katulad ng ResEdit?
Ayon sa :
Upang tingnan ang mga mapagkukunang ibinigay sa package ng application, maaari mong i-drag ang executable file papunta sa isang program tulad ng . Maaari ka ring pumunta sa terminal at patakbuhin ang command
listres ΠΈΠΌΡ_ΡΠ°ΠΉΠ»Π°.
Available ang Resourcer sa HaikuDepot, ngunit nag-crash lang ito para sa akin.
Paano pamahalaan ang mga mapagkukunan sa mga file ng ELF? Gamit rsrc ΠΈ rdef. rdef ang mga file ay nakolekta sa rsrc. file rdef ay naka-imbak sa plain text na format, kaya mas madaling gamitin. Format ng file rsrc idinagdag sa dulo ng ELF file. Subukan nating maglaro:
~> 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 licenseMaaari mong gamitin ang programa xres para sa pagsuri at pagkontrol:
/> 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.
(...)Okay, subukan natin?
/> 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_VERSIONHigit pa tungkol sa mga mapagkukunan at format rdef mababasa mo .
Mga karaniwang uri ng mapagkukunan
Bagama't maaari mong ilagay ang anumang bagay sa mga mapagkukunan, mayroong ilang tinukoy na karaniwang mga uri:
app_signature: Uri ng aplikasyon ng MIME, para sa file open mapping, launch, IPC, atbp.app_name_catalog_entry: Dahil ang pangalan ng application ay karaniwang nasa Ingles, maaari mong tukuyin ang mga lugar kung saan matatagpuan ang mga isinaling pangalan, upang makita ng mga user ng iba't ibang wika ang isinalin na pangalan ng application kung ninanais.app_version: kung ano ang naisip moapp_flags: nagpapahiwatigregistrarpaano iproseso ang aplikasyon. Sa tingin ko ay may higit pa rito kaysa sa nakikita ng mata. Halimbawa, mayroonB_SINGLE_LAUNCH, na pinipilit ang system na maglunsad ng bagong proseso ng aplikasyon sa tuwing hihilingin ito ng user (ang parehong prinsipyo ay ginagamit para sa karamihan ng mga application sa Linux). KumainB_MULTIPLE_LAUNCH, na nagiging sanhi upang tumakbo ang proseso para sa bawat file. Sa wakas meron naB_EXCLUSIVE_LAUNCH, na pinipilit ang system na maglunsad lamang ng isang proseso sa isang pagkakataon, gaano man kadalas ilunsad ito ng mga user (halimbawa, ganito ang pagtakbo ng Firefox sa Linux; ang parehong resulta ay maaaring makamit sa mga Qt application gamit ang function ). Mga application na mayB_EXCLUSIVE_LAUNCHay inaabisuhan kapag sinubukan ng user na patakbuhin muli ang mga ito: halimbawa, natatanggap nila ang path ng file na gustong buksan ng user sa kanilang tulong.vector_icon: Vector application icon (Walang vector icon ang BeOS, karamihan sa mga application ay may dalawang raster icon sa kanilang mga executable na file).
Siyempre, maaari kang magdagdag ng mga mapagkukunan gamit ang anumang nais na mga ID at uri, at pagkatapos ay basahin ang mga ito sa mismong application o iba pang mga application gamit ang klase BResources. Ngunit una, tingnan natin ang kaakit-akit na paksa ng mga icon.
Mga icon ng vector sa istilong Haiku
Siyempre, hindi lamang Haiku ang pumili ng pinakamahusay na format ng icon; sa bahaging ito, ang sitwasyon sa mga Linux desktop environment ay malayo sa perpekto:
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.cacheKung titingnan mo ito ay mararamdaman mo na kung ano ang isang piraso nito.
Siyempre, mayroong scalable, na naglalaman, tulad ng naiintindihan mo, mga icon ng vector. Bakit may iba pa? Dahil ang resulta ng pagguhit ng mga vector graphics sa maliliit na sukat ay maaaring mas mababa sa perpekto. Gusto kong magkaroon ng iba't ibang opsyon na na-optimize para sa iba't ibang laki. Sa Linux desktop environment, ito ay nakakamit sa pamamagitan ng pagkakalat ng mga icon na may iba't ibang laki sa buong file system.
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.pngPakitandaan: walang konsepto ng iba't ibang bersyon ng Firefox. Kaya, hindi posible na maayos na pangasiwaan ang sitwasyon ng pagkakaroon ng maraming bersyon ng isang application sa system.
Iba't ibang mga icon ng Firefox sa iba't ibang bersyon. Kasalukuyang imposibleng pangasiwaan ito sa Linux nang walang iba't ibang saklay.
Ang Mac OS X ay pinangangasiwaan ito nang kaunti nang mas banayad:
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.icnsIto ay makikita na mayroong isang file firefox.icns sa pakete Firefox.app, na naglalaman ng lahat ng laki upang ang iba't ibang bersyon ng parehong application ay may magkakaibang mga icon.
Mas mabuti! Ang mga icon ay naglalakbay kasama ang application, ang lahat ng mga mapagkukunan ay nasa isang file.
Bumalik tayo sa Haiku. Isang solusyon sa isip-blowing, walang mga pagbubukod. Ayon kay :
Isang espesyal na format ng HVIF, na lubos na na-optimize para sa maliliit na laki at mabilis na pag-render, ay binuo. Samakatuwid, ang aming mga icon sa karamihan ay mas maliit kaysa sa raster o sa malawakang ginagamit na format na SVG.
At na-optimize pa rin sila:
Mga laki ng icon sa HVIF kumpara sa ibang mga format.
Ang pagkakaiba ay isang order ng magnitude!
Ngunit ang mahika ay hindi nagtatapos dito. Ang parehong HVIF ay maaaring magpakita ng iba't ibang antas ng detalye depende sa laki na ipinapakita, kahit na ito ay isang vector format.
Iba't ibang antas ng detalye (LOD) depende sa laki ng render
Ngayon tungkol sa mga disadvantages: hindi ka maaaring kumuha ng SVG, itapon ito sa ImageMagick at tawagan ito sa isang araw; kailangan mong dumaan sa ilang mga cycle upang lumikha ng isang icon sa HVIF na format. mga paliwanag. Gayunpaman, ang IconOMatic ay maaaring mag-import ng SVG nang hindi perpekto; humigit-kumulang 90% ng mga detalye ng SVG ang na-import na may ilang posibilidad, ang natitirang 10% ay kailangang i-configure at baguhin nang manu-mano. Magbasa pa tungkol sa kung paano ginagawa ng HVIF ang magic nito sa blog
Pagdaragdag ng icon sa application
Ngayon ay maaari na akong magdagdag ng icon sa ginawang package , isinasaalang-alang ang lahat ng impormasyong natanggap.
Well, dahil hindi ako partikular na sabik na gumuhit ng sarili kong icon para sa aking "Hello, World" QtQuickApp sa ngayon, kinuha ko ito sa Qt Creator.
/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt Creator -o /Haiku/home/QtQuickApp/QtQuickApp -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt CreatorSuriin natin na ang icon ay nakopya:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONMukhang maganda, ngunit bakit kapag ang bagong icon ay kinopya ay hindi ito lumalabas?
Ang kinopyang VICN:101:BEOS:ICONs ay hindi pa ginagamit bilang icon ng application sa file manager
Anong hindi ko inabutan?
Komento ng developer:
Kailangan nating gumawa ng file
rdefsa lahat ng mapagkukunan, pagkatapos ay isagawa ang utosrc ΠΈΠΌΡ.rdef, lilikha ito ng file.rsrc. Pagkatapos ay kailangan mong patakbuhin ang utosresattr -o ΠΈΠΌΡ_Π±ΠΈΠ½Π°ΡΠ½ΠΈΠΊΠ° ΠΈΠΌΡ.rsrc. Sa pinakamababa, gumagamit ako ng mga command na tulad nito upang magdagdag ng mga icon sa aking mga script.
Well, gusto kong lumikha ng isang mapagkukunan, hindi isang katangian. naguguluhan na talaga ako.
Smart caching gamit ang file system
Mabagal ang pagbubukas at pagbabasa ng mga katangian ng ELF. Tulad ng isinulat ko sa itaas, ang icon ay nakasulat bilang isang mapagkukunan sa file mismo. Ang pamamaraang ito ay mas maaasahan at nagbibigay-daan sa iyo na makaligtas sa pagkopya sa isa pang file system. Gayunpaman, ito ay kinopya din sa katangian ng file system, halimbawa BEOS:ICON. Gumagana lang ito sa ilang mga file system, gaya ng BFS. Ang mga icon na ipinapakita ng system (sa Tracker at Deskbar) ay binabasa mula sa pinahabang katangiang ito, dahil mabilis na gumagana ang solusyon na ito. Sa ilang mga lugar (kung saan ang bilis ay hindi mahalaga, halimbawa, isang tipikal na "Tungkol sa" window), natatanggap ng system ang icon nang direkta mula sa mapagkukunan sa file. Ngunit hindi ito ang katapusan. Tandaan, sa Mac, maaaring palitan ng mga user ang mga icon ng mga application, direktoryo, dokumento ng kanilang sarili, dahil sa Mac posibleng gawin ang mga "mahahalagang" bagay na ito, halimbawa. . Sa Haiku, dapat mong isipin ang mapagkukunan (sa file) bilang ang orihinal na icon na kasama ng application, at ang katangian (sa BFS file system) bilang isang bagay na nagpapahintulot sa user na gumawa ng mga pagbabago sa kalooban (bagama't, pahiwatig, ang GUI para sa paglalagay ng custom na icon sa tuktok ng icon ay opsyonal). hindi pa ipinapatupad bilang default).
Sinusuri ang mga katangian ng file system
May resaddr Posibleng suriin at itakda ang mga katangian ng file system.
/> 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.
(...)Ito ay mahalagang "glue" na nagsasagawa ng conversion pabalik-balik sa pagitan ng (maaasahang) mapagkukunan at (mabilis) na mga katangian ng filesystem. At dahil inaasahan ng system na makatanggap ng mga mapagkukunan at awtomatikong ginagawa ang pagkopya, hindi na ako mag-aalala tungkol dito.
Ang magic ng hpkg packages
Sa kasalukuyan (madalas) ang mga pakete ay ginagamit upang makakuha ng mga programa sa Haiku .hpkg. Huwag magpalinlang sa simpleng pangalan: ang .hpkg na format ay gumagana nang ganap na naiiba kaysa sa iba pang mga format na may katulad na mga pangalan na iyong naranasan, ito ay may mga tunay na superpower.
Sa tradisyunal na mga format ng pakete, ako ay nabalisa sa loob ng mahabang panahon dahil sa katotohanang ito: nag-download ka ng isang bagay (package), at isa pa ay naka-install sa system (mga file sa loob ng package). Medyo mahirap pamahalaan ang mga file (halimbawa, tanggalin ang mga ito) kapag nag-i-install ng isang pakete sa tradisyonal na paraan. At lahat dahil ang mga nilalaman ng pakete nakakalat sa buong file system, kabilang ang mga lugar kung saan maaaring walang access sa pagsulat ang karaniwang user. Nagbubunga ito ng isang buong klase ng mga programa - mga tagapamahala ng pakete. Ngunit ang paglilipat ng naka-install na software, halimbawa, sa isa pang makina, ang naaalis na disk o file server ay nagiging mas mahirap, kung hindi man ganap na imposible. Sa isang tipikal na sistemang nakabatay sa Linux, madaling magkaroon ng ilang daang libo hanggang milyon-milyong indibidwal na mga file. Hindi na kailangang sabihin, ito ay parehong marupok at mabagal, halimbawa kapag unang nag-install ng isang system, kapag nag-i-install, nag-a-update at nag-uninstall ng mga regular na pakete, at kapag kinopya ang boot volume (root partition) sa isa pang medium.
Nagtatrabaho ako sa proyekto ng AppImage, isang bahagyang saklay para sa mga aplikasyon ng end-user. Ito ay isang format ng pamamahagi ng software na nangongolekta ng isang application at lahat ng mga dependency nito sa isang imahe ng file system na naka-mount kapag nagsimula ang application. Kapansin-pansing pinapasimple ang mga bagay, dahil ang parehong ImageMagick ay biglang naging isang file, na pinamamahalaan sa isang file manager ng mga mortal lang. Ang iminungkahing paraan ay gumagana lamang para sa software, tulad ng makikita sa pangalan ng proyekto, at mayroon ding sariling hanay ng mga problema, dahil ang mga taong kasangkot sa paghahatid ng software para sa Linux ay palaging nakatutok sa akin ang arrow.
Bumalik tayo sa Haiku. Posible bang mahanap ang pinakamainam na balanse sa pagitan ng tradisyonal na mga sistema ng pakete at paghahatid ng software na nakabatay sa imahe? Ang kanyang mga pakete .hpkg aktwal na naka-compress na mga imahe ng file system. Kapag nag-boot ang system, ini-mount ng kernel ang lahat ng naka-install at aktibong pakete na may humigit-kumulang sumusunod na mga mensahe ng kernel:
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"Astig, oo? Maghintay ka diyan, magiging mas cool pa!
Mayroong isang napaka-espesyal na pakete:
KERN: package_daemon [16040020: 924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Naglalaman ito ng isang napaka minimalistic na operating system, kabilang ang kernel. Maniwala ka man o hindi, kahit na ang kernel mismo ay hindi tinanggal mula sa dami ng boot (root partition), ngunit maingat na na-load sa lugar nito mula sa package .hpkg. Wow! Nabanggit ko na na sa tingin ko bahagi ng pangkalahatang pagiging sopistikado at pagkakapare-pareho ng Haiku ay nagmumula sa katotohanan na ang buong system, mula sa kernel at core userspace hanggang sa pamamahala ng package at imprastraktura ng runtime, ay sama-samang binuo ng isang team. Isipin kung gaano karaming iba't ibang mga grupo at koponan ang kakailanganin upang magpatakbo ng isang bagay na tulad nito sa Linux [Akala ko ang PuppyLinux project - approx. tagasalin]. Pagkatapos ay isipin kung gaano katagal bago ang diskarte na ito ay pinagtibay sa mga pamamahagi. Sabi nila: kumuha ng isang simpleng problema, hatiin ito sa pagitan ng iba't ibang mga gumaganap, at ito ay magiging kumplikado na hindi na posible na malutas ito. Haiku sa kasong ito ay binuksan ang aking mga mata. Sa tingin ko ito mismo ang nangyayari sa Linux ngayon (Linux sa kasong ito ay isang kolektibong termino para sa Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu stack).
Rollback ng system gamit ang hpkg
Gaano kadalas nangyayari ang sumusunod na sitwasyon: matagumpay ang pag-update, at pagkatapos ay lumalabas na may hindi gumagana ayon sa nararapat? Kung gumagamit ka ng mga kumbensyonal na manager ng package, mahirap ibalik ang estado ng system sa isang punto sa oras bago mag-install ng mga bagong package (halimbawa, kung sakaling may nangyaring mali). Ang ilang mga system ay nag-aalok ng mga workaround sa anyo ng mga snapshot ng file system, ngunit ang mga ito ay medyo mahirap at hindi ginagamit sa lahat ng mga system. Niresolba ito ng Haiku gamit ang mga pakete .hpkg. Sa tuwing nagbabago ang mga pakete sa system, ang mga lumang pakete ay hindi tinatanggal, ngunit naka-imbak sa system sa mga subdirectory tulad ng /Haiku/system/packages/administrative/state-<...>/ tuloy-tuloy. Ang mga hindi natapos na operasyon ay nag-iimbak ng kanilang data sa mga subdirectory /Haiku/system/packages/administrative/transaction-<...>/.
Nilalaman /Haiku/system/packages/administrative. Ang mga direktoryo ng "estado..." ay naglalaman ng mga text file na may mga pangalan ng mga aktibong pakete, at ang mga direktoryo ng "transaksyon..." ay naglalaman ng mga pakete mismo.
"Lumang aktibong estado", i.e. listahan .hpkg mga package na aktibo bago maitala ang mga pagbabago pagkatapos ng bawat operasyon sa file manager sa isang text file /Haiku/system/packages/administrative/state-<...>/activated-packages. Sa katulad na paraan, ang isang bagong "aktibong estado" ay nakasulat sa isang text file /Haiku/system/packages/administrative/activated-packages.
Directory /Haiku/system/packages/administrative/state-<...>/ naglalaman lamang ng isang text file na may listahan ng mga aktibong pakete ng estadong ito (sa kaso ng pag-install ng mga pakete nang hindi inaalis), at kung ang mga pakete ay tinanggal o na-update - ang direktoryo ng estado ay naglalaman ng mga lumang bersyon ng mga pakete.
Kapag nag-boot ang system, batay sa listahan ng mga pakete, isang desisyon ang ginawa upang i-activate (i-mount) ang mga pakete. Ganyan kasimple! Kung may nangyaring mali sa panahon ng pag-download, maaari mong sabihin sa download manager na gumamit ng ibang mas lumang listahan. Nalutas ang problema!
Downloader ng Haiku. Ang bawat entry point ay nagpapakita ng kaukulang "aktibong estado"
Gusto ko ang diskarte ng pagkakaroon ng mga simpleng text file bilang listahan ng "aktibong estado", na may mga pangalan na madaling maunawaan .hpkg. Malaki ang kaibahan nito sa pagiging built-for-machine-not-for-people. mula sa OSTree o Flatpak sa file system (sa parehong antas ng Microsoft GUID).
Listahan ng mga aktibong pakete para sa bawat punto ng oras
Data ng configuration
Kumbaga, nasa catalog /Haiku/system/packages/administrative/writable-files naglalaman ng mga configuration file para sa mga pakete, ngunit ang mga ito ay maisusulat. Pagkatapos ng lahat, tulad ng naaalala mo, .hpkg naka-mount na read-only. Kaya't ang mga file na ito ay dapat makopya mula sa mga pakete bago isulat. May kahulugan.
Pagsasama ng GUI para sa .hpkg system
Tingnan natin ngayon kung paano ang mga makintab na paketeng ito .hpkg makayanan ang pagsasama sa kapaligiran ng trabaho (UX) ng user. Pagkatapos ng lahat, ang Haiku ay inilaan para sa personal na paggamit, pagkatapos ng lahat. Sa personal, itinatakda ko ang mataas na bar kapag inihahambing ang karanasan ng gumagamit sa mga pakete .app sa Macintosh na may parehong karanasan sa .hpkg. Hindi ko ihahambing ang sitwasyon sa mga nagtatrabaho na kapaligiran sa Linux, dahil ito ay talagang kakila-kilabot kumpara sa iba pa.
Ang mga sumusunod na senaryo ay naiisip:
- Gusto kong tingnan ang mga nilalaman ng isang pakete
.hpkg - Gusto kong mag-install ng package
- Gusto kong tanggalin ang pakete
- Gusto kong tanggalin ang isang bagay na pumasok sa system bilang bahagi ng isang package
- Gusto kong kopyahin ang isang bagay na pumasok sa system bilang bahagi ng isang pakete
- Gusto kong i-download ang lahat ng dependencies ng isang package, na maaaring hindi bahagi ng bawat pag-install ng Haiku (halimbawa, mayroon akong physically isolated machine na walang internet access.)
- Gusto kong ilipat ang aking mga pakete (o bahagi ng mga ito) nang hiwalay sa ibang lokasyon, hiwalay sa dami ng boot (root partition) (dahil, halimbawa, wala akong sapat na espasyo dito).
Dapat nitong saklawin ang karamihan sa mga pangunahing kaso mula sa aking pang-araw-araw na trabaho. Well, simulan na natin.
Sinusuri ang mga nilalaman ng pakete
Sa Mac I-right click lang ako sa package para buksan ito at tingnan ang mga content sa Finder. Pagkatapos ng lahat, sa katotohanan ito ay isang disguised directory lamang! (Alam kong may mga pakete .pkg para sa isang bahagi ng system na hindi mga application, ngunit ang mga karaniwang gumagamit ay kadalasang hindi nakikipag-ugnayan sa kanila).
Sa Haiku Nag-right click ako sa package, pagkatapos ay nag-click sa "Contents" para makita kung ano ang nasa loob. Ngunit narito lamang ang isang listahan ng mga file na walang kakayahang buksan ang mga ito sa pamamagitan ng pag-double click.
Mas mabuti kung may paraan para (pansamantalang) i-mount ang package .hpkg upang matingnan sa pamamagitan ng isang file manager, at ang user ay hindi kailangang mag-alala tungkol sa mga detalye ng pagpapatupad. (By the way, pwede mong buksan .hpkg pakete sa Expander, na maaaring i-unpack ito tulad ng anumang iba pang archive).
Hinahayaan ka ng interface ng HaikuDepot na tingnan ang isang listahan ng mga file ng package, ngunit walang paraan upang tingnan ang mga nilalaman sa pamamagitan ng, halimbawa, pag-double click sa README.md
Ang Mac ay nanalo sa kategoryang ito, ngunit ang pagdaragdag ng HaikuDepot functionality na gusto mo ay hindi dapat maging masyadong mahirap.
Pag-install ng package sa pamamagitan ng GUI
Sa Mac, karamihan sa mga imahe sa disk .dmg naglalaman ng mga pakete .app. I-double click ang disk image at pagkatapos ay kopyahin ang package, halimbawa, sa pamamagitan ng pag-drag dito /Applications sa Finder. Ito ay walang sinasabi para sa akin, ngunit narinig ko na ang ilang mga baguhan ay maaaring hindi makayanan ito. Bilang default, "nagmumungkahi" ang Apple ng isang direktoryo sa buong system /Applications (sa NeXT ito ay naka-network pati na rin bilang indibidwal), ngunit madali mong mailalagay ang iyong mga application sa isang file server o sa isang subdirectory $HOME/Applications, kung gusto mo sa ganoong paraan.
Sa Haiku, i-double click ang package, pagkatapos ay i-click ang "I-install", hindi ito maaaring maging mas madali. Iniisip ko kung ano ang mangyayari kung ang isang package ay may mga dependency na available sa HaikuPorts ngunit hindi pa naka-install. Sa Linux hindi talaga nila alam kung ano ang gagawin sa sitwasyong ito, ngunit ang solusyon ay halata - tanungin ang user kung kailangan nilang mag-download at mag-install ng mga dependency. Eksakto sa ginagawa ni Haiku.
Na-download ko nang manu-mano ang package na 'sanity' at nag-click dito, alam ng manager ng package kung saan kukunin ang mga dependency nito (ipagpalagay na ang mga repository ay nakarehistro na sa system). Hindi lahat ng pamamahagi ng Linux ay magagawa ito.
Ang isa pang paraan ay ang paggamit ng file manager, i-drag lang at i-drop .hpkg pakete o sa /Haiku/system/packages (para sa pag-install sa buong system, bilang default), o sa /Haiku/home/config/packages (para sa indibidwal na pag-install; hindi magagamit kapag nag-double click - naiinis pa rin ako sa salitang "config" sa lugar na ito, na para sa akin sa kasong ito ay kasingkahulugan ng "mga setting"). At ang konsepto ng maraming user ay hindi pa magagamit para sa Haiku (malamang kung bakit ito ay napakasimple - hindi ko alam, marahil ang mga kakayahan ng multi-user ay hindi kinakailangang gawing kumplikado ang mga bagay para sa isang desktop desktop environment).
Nanalo ang Haiku sa kategoryang ito dahil maaari itong gumana hindi lamang sa mga application, kundi pati na rin sa mga program ng system.
Pag-alis ng package mula sa GUI
Sa Mac, kailangan mong i-drag ang icon ng application sa basurahan, at iyon lang. Madali lang!
Sa Haiku, una, kailangan mong hanapin kung saan matatagpuan ang package sa system, dahil bihira mo itong mai-install sa tamang lugar (ginagawa ng system ang lahat). Kadalasan kailangan mong tumingin sa loob /Haiku/system/packages (na may default na pag-install sa buong system), o sa /Haiku/home/config/packages (Nabanggit ko ba na ang "config" ay isang maling tawag?). Pagkatapos ay i-drag lamang ang application sa basurahan, at iyon na.
Madali lang! Gayunpaman, hindi ko sasabihin iyon. Narito kung ano talaga ang nangyayari:
Ito ang mangyayari kung mag-drag ka ng isang application papunta sa basurahan mula sa /Haiku/system/packages
Sinubukan ko lang ilipat sa basurahan ang "Hello World" application ko kahapon sa QtQuickApp. Hindi ko sinubukang ilipat ang direktoryo ng system, at dahil ang lahat ng mga pakete ay naka-install sa direktoryo ng system, imposibleng alisin ang pakete .hpkg walang pagbabago "nilalaman nito". Ang isang ordinaryong gumagamit ay matatakot at pipindutin ang pindutang "Kanselahin" na itinalaga bilang default.
Nagpapaliwanag :
Ang post na ito ay higit sa 10 taong gulang. Malamang na kailangan nating i-configure ito upang ang babala ay lilitaw lamang kapag ang package mismo ay inilipat. Ang mga regular na gumagamit ay hindi pa rin kailangang gawin ito.
Okay, siguro dapat kong gawin ito gamit ang HaikuDepot? I-double click ko ang package in /Haiku/system/packages, naghihintay na lumitaw ang "I-uninstall" na buton. Hindi, mayroon (lamang) "I-install". "I-uninstall", nasaan ka?
Para lang masaya, sinubukan kong makita kung ano ang mangyayari kung i-click ko ang "I-install" sa isang naka-install na package. Ito ay lumalabas na ganito:
Nangyayari ito kung susubukan mong mag-install ng naka-install na package.
Susunod na lilitaw:
Kung na-click mo ang "Ilapat ang mga pagbabago" sa nakaraang window, magiging ganito ang hitsura
Ipinapalagay ko na ito ay isang error sa software; ang link sa application ay naroon na. [ang may-akda ay hindi nagbigay ng isang link - humigit-kumulang. tagasalin]
Mabilis na solusyon: Magdagdag ng button na "I-uninstall" kung nasa loob na ang package
/Haiku/system/packages, o sa/Haiku/home/config/packages.
Kapag tinitingnan ang listahan ng mga package na naka-install sa HaikuDepot, nakikita ko ang aking package sa listahan at maaari ko itong alisin.
Panalo ang Mac sa kategoryang ito. Ngunit naiisip ko na sa wastong pag-setup, ang karanasan ng user sa Haiku ay magiging mas mahusay kaysa sa Mac. (Ni-rate ito ng isa sa mga developer sa ganitong paraan: "Wala pang isang oras upang idagdag ang tinukoy na pag-andar sa HaikuDepot, kung alam mo ang isang maliit na C++", anumang mga boluntaryo?)
Pag-alis ng isang bagay mula sa isang pakete
Subukan nating tanggalin ang mismong application, hindi ang package .hpkg, kung saan ito nanggaling (nagdududa ako na para sa "mga mortal lamang" ay may anumang pagkakaiba).
Sa Mac, ang gumagamit ay karaniwang gumagana sa file .dmgsaan galing ang application package .app. Karaniwang mga larawan .dmg ay naipon sa direktoryo ng mga pag-download, at ang mga pakete ay kinopya ng gumagamit sa /Applications. Ito ay pinaniniwalaan na maraming mga gumagamit ang kanilang sarili ay hindi alam kung ano ang kanilang ginagawa, ang hypothesis na ito ay nakumpirma ng isang dating empleyado ng Apple. (Isa sa mga bagay na hindi ko gusto sa Mac. At, halimbawa, sa AppImage walang pagkakaiba sa pagitan ng application at ng package na kinaroroonan nito. I-drag ang icon sa basurahan = iyon lang. Madali!)
Sa Haiku, mayroon ding dibisyon sa pagitan apps/ ΠΈ packages/, kaya nagdududa ako na ginawa nitong mas malinaw sa mga user. Ngunit ano ang mangyayari kung mag-drag ka ng isang application mula sa apps/ Idagdag sa cart:
Ito ang mangyayari kapag sinubukan mong tanggalin ang isang application na kinuha mula sa isang file .hpkg
Sa teknikal, ito ay tama (pagkatapos ng lahat, ang application ay naka-host sa isang read-only na file system sa unang lugar), ngunit hindi ito partikular na kapaki-pakinabang sa user.
Mabilis na solusyon: imungkahi ang paggamit ng GUI upang tanggalin sa halip
.hpkg
Para lang masaya, sinubukan kong i-duplicate ang application sa pamamagitan ng pagpindot sa Alt+D. Natanggap ko ang mensaheng "Hindi mailipat o makopya ang mga bagay sa isang read-only na volume." At lahat dahil /system (Bukod sa /system/packages ΠΈ /system/settings) ay ang packagefs mount point (tandaan kung paano ito lumilitaw sa output df?). Sa kasamaang palad, ang output ng command mount hindi nilinaw ang sitwasyon (tulad ng sinabi sa isa sa mga nakaraang artikulo), mountvolume ay hindi nagpapakita kung ano ang iyong hinahanap (tila ang mga pakete na naka-mount sa pamamagitan ng loop .hpkg ay hindi itinuturing na "mga volume"), at nakalimutan ko rin ang mga alternatibong utos.
Walang nanalo sa kategoryang ito maliban sa AppImage (ngunit ito, upang maging ganap na tapat, ay isang bias na opinyon). Gayunpaman, maiisip ng isa na pagkatapos ng pag-aayos, ang karanasan ng gumagamit sa Haiku ay magiging mas mahusay kaysa sa Mac.
Tandaan: kailangan mong malaman kung ano ang isang "volume" na may kaugnayan sa isang "seksyon". Ito ay malamang na katulad ng kaugnayan ng "folder" sa "direktoryo": karamihan sa mga direktoryo ay lumilitaw bilang mga folder sa file manager, ngunit hindi lahat ng mga ito (mga pakete na itinuturing bilang mga file, halimbawa). Ginagawa ba akong opisyal na nerd sa ganitong uri ng pagpapakita?
Pagkopya ng mga nilalaman ng isang pakete sa ibang system
Sa Mac, hangal kong hilahin ang pakete .app, at dahil ang mga dependency ay nasa loob ng package, gumagalaw sila nang magkasama.
Sa Haiku, I-drag ko ang application, ngunit ang mga dependency ay hindi naproseso sa lahat.
Mabilis na solusyon: Sa halip, imungkahi natin na i-drag ang buong package na `.hpkg, kasama ang anumang mga dependency, kung mayroon man.
Malinaw na panalo ang Mac sa kategoryang ito. At least para sa akin, isang lover ng kanilang paradigm. Dapat ko itong kopyahin sa Haiku .hpkg sa halip na isang application, ngunit hindi ito inaalok sa akin ng system...
Mag-download ng package kasama ang lahat ng dependencies nito
Hindi lahat ng makina ay konektado sa network sa lahat ng oras. Sa kabaligtaran, nakakalimutan ito ng ilang makina (oo, tinitingnan kita, modernong Windows, Mac at Linux). Mahalaga para sa akin na makapunta ako, halimbawa, sa isang Internet cafe, mag-download ng software sa isang naaalis na drive, ipasok ang drive na ito sa aking computer sa bahay at siguraduhing gagana ang lahat [peligrong tao, ginagawa ito sa Windows... - tinatayang. tagasalin].
Bilang isang resulta, madalas akong magkaroon ng mga hindi natutugunan na dependency sa Windows at Linux nang mas madalas kaysa karaniwan.
Sa Mac ito ay karaniwang isang file, ang kailangan mo lang gawin ay i-download .dmg. Kadalasan, wala itong mga dependency maliban sa ibinigay ng MacOS mismo bilang default. Ang isang pagbubukod ay mga kumplikadong application na nangangailangan ng naaangkop na kapaligiran ng pagpapatupad, halimbawa java.
Sa Haiku download package .hpkg para sa, sabihin nating, ang parehong aplikasyon sa java, ay maaaring hindi sapat, dahil ang java ay maaaring naroroon o maaaring wala sa target na makina. Mayroon bang paraan upang i-download ang lahat ng mga dependency para sa isang ibinigay na pakete .hpkg, maliban sa mga naka-install bilang default sa Haiku at samakatuwid ay dapat nasa bawat Haiku system?
Nanalo ang Mac sa kategoryang ito sa maliit na margin.
Mga komento ni Mr. waddlesplash:
Upang magsulat ng isang programa upang mangolekta ng lahat ng mga dependency ng isang application bilang isang set ng mga pakete
.hpkgpara sa isang taong pamilyar sa mga panloob na gawain ng Haiku, mga 15 minuto ay sapat na. Ang pagdaragdag ng suporta para dito ay hindi ganoon kahirap kung talagang kailangan ito. Ngunit para sa akin ito ay isang bihirang sitwasyon.
Huminga tayo hanggang sa susunod na artikulo sa seryeng ito.
Ang paglipat ng mga pakete sa isang hiwalay na lokasyon
Tulad ng isinulat ko kanina, gusto kong ilagay ang aking mga pakete .hpkg (well, o bahagi ng mga ito) sa isang espesyal na lugar, hiwalay sa karaniwang pagkakalagay sa boot volume (root partition). Sa karaniwan (hindi gaanong teoretikal) na kaso, ang dahilan para dito ay patuloy akong nauubusan ng libreng espasyo sa aking (built-in) na mga disk, gaano man kalaki ang mga ito. At karaniwan kong ikinonekta ang mga panlabas na drive o network share kung saan matatagpuan ang aking mga application.
Sa Mac Naglilipat lang ako ng packages .app sa isang naaalis na drive o direktoryo ng network sa Finder, at iyon lang. Maaari pa rin akong mag-double click upang buksan ang application tulad ng karaniwan kong ginagawa mula sa dami ng boot. Basta!
Sa Haiku, gaya ng sinabi sa akin, ito ay makakamit sa pamamagitan ng paglipat ng aking .hpkg package sa isang naaalis na drive o direktoryo ng network, ngunit pagkatapos ay kailangan mong gumamit ng ilang hindi dokumentadong command sa console upang mai-mount ang mga ito sa system. Hindi ko alam kung paano ito gagawin gamit lamang ang GUI.
Panalo ang Mac sa kategoryang ito.
Ayon kay mr. waddlesplash:
Ito ay isang pag-optimize batay sa normal na paggamit. Kung mayroong demand mula sa higit sa isang user, ipapatupad namin ito. Sa anumang kaso, may posibilidad ng pagpapatupad ng third-party.
Pag-uusapan natin ito sa susunod na artikulo.
Sa pagsasalita tungkol sa mga direktoryo ng network, magiging mahusay (hulaan ko ang mga LAN party) na magkaroon ng simple, natutuklasan, mga application sa buong network (tulad ng Zeroconf) na maaaring kopyahin sa lokal na computer o direktang tumakbo mula sa lokal na network. Siyempre, may opsyon ang mga developer na mag-opt out sa pamamagitan ng app_flags.
Panghuling ulat sa pagsasama ng hpkg system sa GUI
Sa tingin ko na pangunahin dahil sa kamag-anak na bago ng pagsasama .hpkg ang GUI ay nag-iiwan pa rin ng maraming naisin. Gayon pa man, may ilang mga bagay na maaaring mapabuti sa mga tuntunin ng UX...
Isa pang bagay: Kernel Debug Land
Magiging mahusay na makapagpasok ng mga utos sa panahon ng kernel panic, halimbawa syslog | grep usb. Well, sa Haiku posible ito salamat sa Kernel Debug Land. Paano mo makikita ang magic na ito sa aksyon kung ang lahat ay gumagana ayon sa nararapat nang hindi nagkakaroon ng kernel panic? Madali sa pamamagitan ng pagpindot sa Alt+PrintScn+D (Debug mnemonic). naalala ko agad , na nagpapahintulot sa orihinal na mga developer ng Macintosh na ipasok ang debugger (kung may naka-install, siyempre).
Konklusyon
Nagsisimula na akong maunawaan na ang pagiging sopistikado ng sistema ng Haiku ay nagmumula sa katotohanan na ang gawain ay isinasagawa ng isang maliit na pangkat na may malinaw na pagtuon sa kapaligiran ng trabaho, na ang lahat ng mga layer ng system ay naa-access.
Isang matalim na kaibahan sa mundo ng Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, kung saan ang lahat ay nahahati sa maliliit na piraso hanggang sa ang abstraction ay nakaupo sa abstraction at nagmamaneho gamit ang mga saklay.
Nagkaroon din ng pag-unawa kung paano ang sistema .hpkg pinagsasama ang pinakamahuhusay na kagawian ng mga tradisyunal na manager ng package, Snappy, Flatpak, AppImage, kahit btrfs, at pinagsasama ang mga ito sa "just works" approach ng Mac.
Parang may "lumipat" sa ulo ko, at naintindihan ko kung paano ang sistema .hpkg alam kung paano gumulong, sa pamamagitan lamang ng pagtingin sa kanya. Ngunit hindi ako, ngunit ang kagandahan at pagiging simple ng sistema. Karamihan sa mga ito ay inspirasyon ng diwa ng orihinal na Mac.
Oo, ang pag-browse sa browser ay maaaring maalog at tumakbo tulad ng isang snail, ang mga application ay maaaring kulang (walang Gtk, Electron - ang mga developer ay napagpasyahan na hindi sila napupunta nang maayos sa pagiging sopistikado), ang video at 3d acceleration ay maaaring ganap na wala, ngunit ako pa rin gusto nitong sistema. Pagkatapos ng lahat, ang mga bagay na ito ay maaaring itama at ang mga ito ay lilitaw nang maaga o huli. Sandali lang at baka mamula-mula ang mata.
Hindi ako makapag-alok ng tulong, ngunit sa tingin ko ay magsisimula na ito mula ngayon taon ng Haiku sa desktop.
Random na mga problema
Baka may mga request na, or should I open them?
- Ang BeScreenCapture ay dapat na makapag-export sa GIF tulad ng Peek. Magagawa ito gamit ang ffmpeg, available na para sa Haiku. .
- Nabigo ang screenshot software na kumuha ng modal window, sa halip ay kumukuha ng buong screen
- Hindi mo maaaring i-crop ang mga screenshot gamit ang tool sa pag-crop ng WonderBrush at pagkatapos ay i-save ang resulta sa isang file
- Hindi ko partikular na gusto ang hand cursor sa Haiku, ngunit sa tingin ko ay may kinalaman ito sa mainit na nostalgic na pakiramdam. Ito ay lalo na nakakainis kapag gumagamit ng tool sa pag-crop sa Krita, dahil nagreresulta ito sa hindi tumpak na pag-crop (tingnan ang mga screenshot ng mga modal dialog sa artikulong ito). Ang isang crosshair cursor ay magiging kahanga-hanga. .
Subukan ito sa iyong sarili! Pagkatapos ng lahat, ang proyekto ng Haiku ay nagbibigay ng mga larawan para sa pag-boot mula sa DVD o USB, na nabuo . Upang i-install, i-download lamang ang imahe at isulat ito sa isang flash drive gamit
May tanong ka ba? Inaanyayahan ka namin sa nagsasalita ng Ruso .
Pangkalahatang-ideya ng error:
Mula sa pagsasalin: ito ang ikaanim na artikulo sa serye tungkol sa Haiku.
Listahan ng mga artikulo:
Pinagmulan: www.habr.com