🥇Nire seigarren eguna Haikurekin: baliabideen, ikonoen eta paketeen kaputxapean

TL; DR: Haiku ordenagailuetarako bereziki diseinatutako sistema eragilea da, beraz, mahaigaineko ingurunea beste batzuk baino askoz hobea egiten duten hainbat trikimailu ditu. Baina nola funtzionatzen du?

Duela gutxi Haiku aurkitu nuen, ustekabeko sistema ona. Oraindik txundituta nago nola funtzionatzen duen, batez ere Linux mahaigaineko inguruneekin alderatuta. Gaur begirada bat botako dut kanpai azpian. Sakon ulertzeko beharrezkoa denean, jatorrizko Macintosh, Mac OS X eta Linux mahaigaineko inguruneekin alderaketak egingo ditut (freedesktop.org-eko XDG estandarra).

Baliabideak ELF fitxategietan

Atzo jakin nuen IconOMatic-ek rdef baliabideetan ikonoak gorde ditzakeela ELF exekutagarrietan. Gaur benetan nola funtzionatzen duen ikusi nahi dut.

Baliabideak? Aipatzeko tik Bruce Horn, Macintosh Finder-en jatorrizko egilea eta Macintosh Resource Manager-en "aita":

Kodetze tradizionalaren izaera zurrunak kezkatzen nau. Niretzat, kodean izoztutako aplikazio baten ideia bera da, ezer dinamikoki aldatzeko gaitasunik gabe, basakeriarik basatiena. Exekuzio garaian ahalik eta gehien aldatzea posible izan beharko litzateke. Noski, aplikazioaren kodea bera ezin da aldatu, baina ziur aski zerbait alda daiteke kodea berriro konpilatu gabe?

Jatorrizko Macintosh-en, fitxategi hauek "datuen atala" eta "baliabideen atala" izan zituzten, eta horri esker ikonoak, itzulpenak eta antzekoak bezalako gauzak gordetzea izugarri erraza zen. fitxategi exekutagarrietan.

Mac-en hau erabiltzen da Berriz editatu, baliabideak -bat-batean- editatzeko programa grafikoa.

Berriro editatu jatorrizko Macintosh-en

Ondorioz, ikonoak, menu-elementuak, itzulpenak eta abar editatu ahal izan ziren. nahikoa erraza, baina oraindik aplikazioekin "bidaiatzen" dira.
Nolanahi ere, ikuspegi honek eragozpen handi bat zuen: Apple fitxategi-sistemetan bakarrik funtzionatzen zuen, eta hori izan zen Applek "baliabideen atala" alde batera utzi zuen Mac OS X-ra pasatzean.
Mac OS X-n, Apple-k fitxategi-sistematik independentea den irtenbide bat nahi zuen, beraz, paketeen kontzeptua (NeXT-tik) hartu zuen, fitxategi-kudeatzaileak "objektu opako" gisa tratatzen dituen direktorioek, fitxategiak bezala, direktorioek baino. Formatuan aplikazio bat duen edozein pakete .app du, besteak beste, fitxategi bat Info.plist (Appleren JSON edo YAMLren baliokide moduko batean) aplikazioaren metadatuak dituena.

Mac OS X aplikazio-paketearen Info.plist fitxategiaren gakoak.

Baliabideak, hala nola ikonoak, UI fitxategiak eta beste batzuk, fitxategi gisa gordetzen dira paketean. Kontzeptua NeXT-en sustraietara itzuli zen.

Mathematica.app NeXTSTEP 1.0-n 1989an: terminaleko fitxategien direktorio gisa agertzen da, baina fitxategi kudeatzaile grafikoan objektu bakar gisa.

Itzuli gaitezen BeOSera, Haikuk oinarri dituen kontzeptuetara. Bere garatzaileek, PEF (PowerPC) ELF (x86) (Linux-en erabiltzen den berdina) aldatzean, ELF fitxategien amaieran baliabide atal bat gehitzea erabaki zuten. Ez zuen bere ELF atal propioa erabili, ELF fitxategiaren amaieran erantsi besterik ez zuen egin. Programaren ondorioz strip eta binutils-eko beste batzuk, honetaz jabetu gabe, moztu besterik ez dute egiten. Hori dela eta, BeOSeko ELF fitxategi bati baliabideak gehitzean, hobe da Linux tresnekin ez manipulatzea.

Zer gertatzen da orain Haikurekin? Funtsean, gutxi gorabehera berdin.

Teorian, ELFren nahi den atalean baliabideak jartzea posible izango litzateke. Irc.freenode.net-eko #haiku kanaleko garatzaileen arabera:

ELFrekin atalak zentzu handiagoa izango luke... horrela ez egiteko arrazoi bakarra BeOSen egin genuena delako".
Eta hori aldatzeak ez du balio orain.

Baliabideen kudeaketa

Baliabideak egituratutako “baliabide” formatuan idazten dira: funtsean, tamainak dituzten baliabideen zerrenda eta gero haien edukia. gogoratu nintzen ar formatua.
Nola egiaztatu baliabideak Haiku-n? Ba al dago ResEdit bezalako zerbait?
Arabera dokumentazioa:

Aplikazio paketean emandako baliabideak ikusteko, fitxategi exekutagarria arrastatu dezakezu bezalako programa batera Baliabidea. Terminalera ere joan eta komandoa exekutatu dezakezu listres имя_файла.

Resourcer eskuragarri dago HaikuDepot-en, baina huts egiten zait.

Nola kudeatu baliabideak ELF fitxategietan? Erabiliz rsrc и rdef. rdef fitxategiak biltzen dira rsrc. Fitxategia rdef testu arrunteko formatuan gordetzen da, beraz, lan egitea askoz errazagoa da. Fitxategi formatua rsrc ELF fitxategiaren amaieran erantsita. Saia gaitezen jolasten:

~> 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

Programa erabil dezakezu xres egiaztatzeko eta kontrolatzeko:

/> 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.
(...)

Ados, saiatu gaitezen?

/> 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

Baliabideei eta formatuari buruzko informazio gehiago rdef irakur dezakezu Hemen.

Baliabide mota estandarrak

Baliabideetan edozer gauza jar dezakezun arren, estandar mota batzuk daude:

app_signature: MIME aplikazio mota, fitxategi irekien mapak egiteko, abiarazteko, IPC, etab.
app_name_catalog_entry: Aplikazioaren izena normalean ingelesez dagoenez, itzulitako izenak non dauden lekuak zehaztu ditzakezu, hizkuntza ezberdinetako erabiltzaileek itzulitako aplikazioaren izena ikusi ahal izateko, nahi izanez gero.
app_version: uste zenuena zehazki
app_flags: adierazten du registrar eskaera nola prozesatu. Uste dut begiz ikusten dena baino gehiago dagoela. Esaterako, badago B_SINGLE_LAUNCH, erabiltzaileak eskatzen duen bakoitzean aplikazio prozesu berri bat abiarazteko sistema behartzen duena (printzipio bera erabiltzen da Linux-en aplikazio gehienetarako). Jan B_MULTIPLE_LAUNCH, prozesua exekutatzea eraginez fitxategi bakoitza. Azkenean dago B_EXCLUSIVE_LAUNCH, sistema aldi berean prozesu bakarra abiarazteko behartzen duena, erabiltzaileek zenbateko maiztasuna abiarazten duten (adibidez, horrela dabil Firefox Linux-en; emaitza bera lor daiteke Qt aplikazioetan funtzioa erabiliz). QtSingleApplication). Aplikazioekin B_EXCLUSIVE_LAUNCH erabiltzailea berriro exekutatzen saiatzen denean jakinarazten zaie: adibidez, erabiltzaileak ireki nahi duen fitxategiaren bidea jasotzen du bere laguntzarekin.
vector_icon: Bektore-aplikazioaren ikonoa (BeOS-ek ez zuen ikono bektorialik, aplikazio gehienek bi raster ikono zituzten fitxategi exekutagarrietan).

Jakina, baliabideak gehi ditzakezu nahi dituzun ID eta motekin, eta gero irakurri aplikazioan bertan edo klasea erabiliz beste aplikazio batzuetan. BResources. Baina lehenik eta behin, ikus dezagun ikonoen gai liluragarria.

Haiku estiloko ikono bektorialak

Jakina, Haikuk ez ezik ikono formatu onena aukeratu zuen; zati honetan, Linux mahaigaineko inguruneen egoera ezin hobea da:

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

Honi begira jada suma daiteke zer pieza den.

Jakina, eskalagarria da, uler dezakezun bezala ikono bektorialak dituena. Zergatik bada beste ezer? Tamaina txikietan grafiko bektorialak marraztearen emaitza ideala baino txikiagoa izan daitekeelako. Tamaina ezberdinetarako aukera desberdinak optimizatu nahi nituzke. Linux mahaigaineko inguruneetan, tamaina ezberdinetako ikonoak fitxategi-sisteman barreiatuz lortzen da.

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

Kontuan izan: ez dago Firefox-en bertsio ezberdinen kontzepturik. Beraz, ezin da sisteman aplikazio baten hainbat bertsio edukitzearen egoera dotoretasunez kudeatu.

Firefox ikono desberdinak bertsio ezberdinetan. Gaur egun ezinezkoa da Linux-en hori kudeatzea hainbat makulu gabe.

Mac OS X apur bat sotilagoa da:

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

Fitxategi bat dagoela ikus daiteke firefox.icns paketean Firefox.app, tamaina guztiak dituena, aplikazio beraren bertsio ezberdinek ikono desberdinak izan ditzaten.
Askoz hobeto! Ikonoek aplikazioarekin bidaiatzen dute, baliabide guztiak fitxategi batean daude.

Itzuli gaitezen Haikura. Konponbide harrigarria, salbuespenik gabe. Ren arabera dokumentazioa:

HVIF formatu berezi bat garatu zen, tamaina txikietarako eta errendatze azkarrerako oso optimizatua. Hori dela eta, gure ikonoak gehienetan raster edo SVG formatuan baino askoz txikiagoak dira.

Eta oraindik optimizatuta daude:

HVIF-en ikonoen tamainak beste formatuekin alderatuta.

Aldea magnitude ordena bat da!

Baina magia ez da hemen amaitzen. HVIF berak xehetasun-maila desberdinak erakutsi ditzake bistaratzen den tamainaren arabera, formatu bektoriala izan arren.

Xehetasun maila (LOD) desberdinak errendatzearen tamainaren arabera

Orain desabantailei buruz: ezin duzu SVG hartu, ImageMagick-era bota eta egun bat deitu; hainbat ziklo egin behar dituzu HVIF formatuan ikono bat sortzeko. Hemen azalpenak. Hala ere, IconOMatic-ek SVG nahiko inperfektu inporta dezake; SVG xehetasunen % 90 inguru probabilitate batekin inportatzen dira, gainerako % 10a eskuz konfiguratu eta aldatu beharko da. Irakurri gehiago HVIFek magia nola egiten duen ko ahal blogean Leah Ganson

Aplikazioari ikono bat gehitzea

Orain ikono bat gehi dezaket sortutako paketeari Azken aldiz, jasotako informazio guztia kontuan hartuta.
Beno, oraintxe bertan nire "Kaixo, Mundua" QtQuickApp-erako nire ikonoa marrazteko gogo handirik ez dudanez, Qt Creator-etik ateratzen dut.

/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

Egiaztatu dezagun ikonoa kopiatu dela:

/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type           ID        size  name
------ ----------- -----------  --------------------
'VICN'         101      152238  BEOS:ICON

Itxura ona du, baina zergatik ikono berria kopiatzen denean ez da agertzen?

Kopiatutako VICN:101:BEOS:ICONs ez da oraindik aplikazioaren ikono gisa erabiltzen fitxategi-kudeatzailean

Zer galdu nuen?

Garatzailearen iruzkina:

Fitxategi bat sortu behar dugu rdef baliabide guztiekin, gero exekutatu komandoa rc имя.rdef, honek fitxategia sortuko du .rsrc. Ondoren, komandoa exekutatu behar duzu resattr -o имя_бинарника имя.rsrc. Gutxienez, honelako komandoak erabiltzen ditut nire scriptei ikonoak gehitzeko.

Beno, baliabide bat sortu nahi nuen, ez atributu bat. Benetan nahastuta nago.

Cache adimenduna fitxategi-sistema erabiliz

ELF atributuak irekitzea eta irakurtzea motela da. Goian idatzi dudan bezala, ikonoa baliabide gisa idatzita dago fitxategian bertan. Metodo hau fidagarriagoa da eta beste fitxategi-sistema batera kopiatzen bizirik irauteko aukera ematen du. Hala ere, fitxategi-sistemaren atributuan ere kopiatzen da, adibidez BEOS:ICON. Honek fitxategi-sistema jakin batzuetan bakarrik funtzionatzen du, BFS adibidez. Sistemak erakusten dituen ikonoak ( Tracker eta Deskbar -en) atributu hedatu honetatik irakurtzen dira, irtenbide honek azkar funtzionatzen duelako. Leku batzuetan (abiadura garrantzitsua ez den lekuetan, adibidez, "Hori buruz" leiho tipikoa), sistemak fitxategiko baliabidetik zuzenean jasotzen du ikonoa. Baina hau ez da amaiera. Gogoratu, Mac-en, erabiltzaileek aplikazioen, direktorioen, dokumentuen ikonoekin ordezkatu ditzaketela, Mac-en gauza "garrantzitsu" hauek egin daitezkeelako, adibidez. Slack ikono berri bat aurrekoarekin ordezkatuz. Haiku-n, baliabidea (fitxategian) aplikazioarekin batera datorren jatorrizko ikonoa dela pentsatu beharko zenuke, eta atributua (BFS fitxategi-sisteman) erabiltzaileari nahierara aldaketak egiteko aukera ematen dion zerbait bezala (hala ere, iradokizuna, ikonoaren gainean pertsonalizatutako ikono bat txertatzeko GUI aukerakoa da). oraindik ez da inplementatu lehenespenez).

Fitxategi-sistemaren atributuak egiaztatzea

With resaddr Fitxategi-sistemaren atributuak egiaztatu eta ezartzea posible da.

/> 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.
(...)

Funtsean, baliabide (fidagarriak) eta fitxategi-sistemaren atributu (azkar) arteko bihurketa aurrera eta atzera egiten duen "kola" da. Eta sistemak baliabideak jasotzea espero duenez eta kopiak automatikoki egiten dituenez, ez naiz gehiago kezkatuko.

Hpkg paketeen magia

Gaur egun (gehienetan) paketeak erabiltzen dira Haikuko programak lortzeko .hpkg. Ez utzi izen soilarekin engaina: .hpkg formatuak topatu dituzun antzeko izenak dituzten beste formatuek baino guztiz ezberdin funtzionatzen dute, benetako superbotereak ditu.

Pakete formatu tradizionalekin, denbora luzez haserretu nintzen gertaera honengatik: gauza bat deskargatzen duzu (paketea), eta beste bat instalatuta dago sisteman (paketearen barruan dauden fitxategiak). Nahiko zaila da fitxategiak kudeatzea (adibidez, ezabatzea) pakete bat modu tradizionalean instalatzean. Eta dena paketearen edukia delako fitxategi-sisteman zehar sakabanatuta, batez besteko erabiltzaileak idazteko sarbiderik ez duen tokiak barne. Honek programa klase oso bat sortzen du - paketeen kudeatzaileak. Baina dagoeneko instalatutako softwarea transferitzea, adibidez, beste makina batera, disko aldagarri batera edo fitxategi zerbitzari batera are zailagoa bihurtzen da, guztiz ezinezkoa ez bada. Linux-en oinarritutako sistema tipiko batean, erraz egon daitezke ehunka mila edo milioika fitxategi indibidual. Esan beharrik ez dago hau hauskorra eta motela dela, adibidez, hasiera batean sistema bat instalatzean, pakete arruntak instalatzean, eguneratzean eta desinstalatzean eta abio-bolumena (root partizioa) beste euskarri batean kopiatzean.

AppImage proiektuan ari naiz lanean, azken erabiltzailearen aplikazioetarako makulu partziala. Aplikazio bat eta bere menpekotasun guztiak fitxategi-sistemaren irudi bakarrean biltzen dituen software banaketa formatua da, aplikazioa abiarazten denean muntatzen dena. Gauzak nabarmen sinplifikatzen ditu, izan ere, ImageMagick bera bat-batean fitxategi bakar batean bihurtzen da, hilkor soilek fitxategi-kudeatzaile batean kudeatuta. Proposatutako metodoak softwarerako bakarrik funtzionatzen du, proiektuaren izenean islatzen den moduan, eta bere arazo multzoa ere badu, Linuxerako softwarea entregatzen parte hartzen duten pertsonek beti gezia niri begira jartzen baitute.

Itzuli gaitezen Haikura. Posible izan al da pakete-sistemen tradizionalen eta irudietan oinarritutako softwarearen entregaren arteko oreka optimoa aurkitzea? Bere paketeak .hpkg benetan konprimitutako fitxategi-sistemako irudiak. Sistema abiaraztean, nukleoak instalatutako pakete guztiak muntatzen ditu, gutxi gorabehera, nukleoko mezu hauekin:

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"

Polita, bai? Eskatu hor, are freskoagoa izango da!

Oso pakete berezi bat dago:

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

Sistema eragile oso minimalista dauka, nukleoa barne. Sinetsi ala ez, nukleoa bera ere ez da abioko bolumenetik (root partizioa) kentzen, baina kontu handiz kargatzen da paketetik bere lekuan. .hpkg. Aupa! Dagoeneko aipatu dut Haikuren sofistikazio eta koherentzia orokorraren zati bat sistema osoa, nukleotik eta core erabiltzaile-espaziotik hasi eta paketeen kudeaketa eta exekuzio-azpiegituraraino, talde batek elkarlanean garatzen duelako. Imajinatu zenbat talde eta talde ezberdin beharko liratekeen Linux-en horrelako zerbait exekutatzeko [PuppyLinux proiektua imajinatzen dut - gutxi gorabehera. itzultzailea]. Orduan, imajinatu zenbat denbora beharko duen ikuspegi hori banaketetan hartzeko. Esaten dute: hartu arazo soil bat, banatu interpretatzaile ezberdinen artean, eta hain konplikatua izango da, ezen jada ezinezkoa izango dena konpondu. Haiku kasu honetan begiak ireki zizkidan. Uste dut horixe dela orain Linux-en gertatzen ari dena (Linux kasu honetan Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu pilarako termino kolektiboa da).

Sistemaren itzulera hpkg erabiliz

Zenbat aldiz gertatzen da honako egoera hau: eguneratzea arrakastatsua izan da eta gero zerbait ez dabilela behar bezala funtzionatzen du? Pakete-kudeatzaile konbentzionalak erabiltzen badituzu, zaila da sistemaren egoera pakete berriak instalatu baino lehenagoko une batera itzultzea (adibidez, zerbait gaizki gertatuz gero). Sistema batzuek konponbideak eskaintzen dituzte fitxategi-sistemaren argazkien moduan, baina nahiko astunak dira eta ez dira sistema guztietan erabiltzen. Haikuk paketeak erabiliz konpontzen du .hpkg. Paketeak sisteman aldatzen diren bakoitzean, pakete zaharrak ez dira ezabatzen, baina sisteman gordetzen dira azpidirektorioetan. /Haiku/system/packages/administrative/state-<...>/ etengabe. Amaitu gabeko eragiketek beren datuak azpidirektorioetan gordetzen dituzte /Haiku/system/packages/administrative/transaction-<...>/.

edukien /Haiku/system/packages/administrative. "egoera..." direktorioek pakete aktiboen izenak dituzten testu-fitxategiak dituzte, eta "transakzio..." direktorioek paketeak beraiek dituzte.

"Egoera aktibo zaharra", hau da. zerrenda .hpkg fitxategi-kudeatzailean eragiketa bakoitzaren ondoren aldaketak testu-fitxategi batean erregistratu aurretik aktibo dauden paketeak /Haiku/system/packages/administrative/state-<...>/activated-packages. Era berean, "egoera aktibo" berri bat idazten da testu fitxategi batean /Haiku/system/packages/administrative/activated-packages.

Каталог /Haiku/system/packages/administrative/state-<...>/ Egoera honetako pakete aktiboen zerrenda duen testu-fitxategi bat baino ez dauka (paketeak kendu gabe instalatzen badira), eta paketeak kendu edo eguneratu badira - egoera direktorioak paketeen bertsio zaharrak ditu.

Sistema abiarazten denean, paketeen zerrendan oinarrituta, paketeak aktibatzeko (muntatzeko) erabakia hartzen da. Hain sinplea da! Deskargan zerbait gaizki gertatzen bada, deskarga-kudeatzaileari esan diezaiokezu beste zerrenda zaharrago bat erabiltzeko. Arazoa konponduta!

Haiku deskargatzailea. Sarrera puntu bakoitzak dagokion "egoera aktiboa" erakusten du

Gustatzen zait testu-fitxategi sinpleak "egoera aktibo" zerrenda gisa edukitzea, ulertzeko errazak diren izenekin .hpkg. Horrek kontrastea nabarmena du makinentzat-ez-pertsonentzat eraikia izatearekin. mordo batean OSTree edo Flatpak fitxategi-sisteman (Microsoft GUID-en maila berean).

Denbora-puntu bakoitzeko pakete aktiboen zerrenda

Konfigurazio datuak

Antza, katalogoan /Haiku/system/packages/administrative/writable-files paketeen konfigurazio fitxategiak ditu, baina idazteko modukoak dira. Azken finean, gogoratzen duzun bezala, .hpkg irakurtzeko soilik muntatua. Beraz, fitxategi hauek paketeetatik kopiatu behar dira idatzi aurretik. Esanahia du.

GUI integrazioa .hpkg sistemarako

Ikus dezagun orain nola poltsa distiratsu hauek .hpkg erabiltzailearen lan-ingurunean (UX) integrazioari aurre egin. Azken finean, Haiku erabilera pertsonalerako pentsatuta dago, azken finean. Pertsonalki, barra altua jartzen dut erabiltzailearen esperientzia paketeekin alderatzean .app Macintosh-en esperientzia bera piztuta .hpkg. Ez dut egoera Linux-eko lan-inguruneekin alderatuko ere, erabat ikaragarria baita beste edozeinekin alderatuta.

Honako eszenatoki hauek etortzen zaizkigu burura:

Pakete baten edukia ikusi nahi dut .hpkg
Pakete bat instalatu nahi dut
Paketea kendu nahi dut
Pakete baten zati gisa sistemara sartu zen zerbait kendu nahi dut
Pakete baten parte gisa sisteman sartu den zerbait kopiatu nahi dut
Pakete baten menpekotasun guztiak deskargatu nahi ditut, agian Haiku instalazio guztietan ez egotea (adibidez, Interneterako sarbiderik gabeko makina fisikoki isolatuta daukat).
Nire paketeak (edo horien zati bat) beste toki batera eraman nahi ditut, abioko bolumenetik (erroaren partizioa) bereizita (adibidez, ez dudalako leku nahikorik).

Honek nire eguneroko laneko kasu nagusi gehienak estali beharko lituzke. Tira, has gaitezen.

Paketearen edukia egiaztatzea

Mac-en Besterik gabe, eskuineko botoiarekin klik egiten dut paketean irekitzeko eta edukia Finder-en ikusteko. Azken finean, errealitatean mozorrotutako direktorio bat besterik ez da! (Badakit paketeak daudela .pkg aplikazioak ez diren sistemaren zati batentzat, baina erabiltzaile arruntek gehienetan haiekin elkarreragiten ez dutenak).

Haikuan Paketearen gainean eskuineko botoiarekin klik egiten dut, gero "Edukia"-n klik egiten dut barruan zer dagoen ikusteko. Baina hemen klik bikoitza eginez irekitzeko gaitasunik gabeko fitxategien zerrenda besterik ez dago.
Askoz hobe litzateke paketea (aldi baterako) muntatzeko modu bat egongo balitz .hpkg fitxategi-kudeatzaile baten bidez ikusteko, eta erabiltzaileak ez luke inplementazioaren xehetasunez kezkatu beharko. (Bide batez, ireki dezakezu .hpkg paketea sartu Expander, beste edozein artxibo bezala deskonpaktatu dezakeena).

HaikuDepot-en interfazeak pakete fitxategien zerrenda ikusteko aukera ematen du, baina ez dago edukia ikusteko modurik, adibidez, README.md klik bikoitza eginez.

Mac-ek irabazten du kategoria honetan, baina nahi duzun HaikuDepot funtzionaltasuna gehitzea ez da oso zaila izan behar.

GUI bidez pakete bat instalatzea

Mac-en, diskoko irudi gehienak .dmg paketeak eduki .app. Egin klik bikoitza diskoaren irudian eta kopiatu paketea, adibidez, arrastatuz /Applications Bilatzailean. Hau esan gabe doa niretzat, baina entzun dut berriki batzuek ezin izango dutela hori kudeatu. Berez, Applek sistema osorako direktorio bat "iradokitzen du". /Applications (NeXT-en sarean sartuta zegoen, baita banakakoa ere), baina erraz jar ditzakezu zure aplikazioak fitxategi zerbitzari batean edo azpidirektorio batean $HOME/Applications, horrela gustatzen bazaizu.

Haikuan, egin klik bikoitza paketean, eta gero egin klik "Instalatu", ezin da errazagoa izan. Zer gertatuko den pakete batek HaikuPorts-en eskuragarri dauden baina oraindik instalatuta ez dauden menpekotasunak baditu galdetzen ari naiz. Linux-en benetan ez dakite zer egin egoera honetan, baina irtenbidea begi-bistakoa da: galdetu erabiltzaileari ea mendekotasunak deskargatu eta instalatu behar dituen. Haikuk egiten duena zehazki.

'Sanity' paketea eskuz deskargatu nuen eta gainean klik egin nuen, paketeen kudeatzaileak badaki nondik lortu bere mendekotasunak (biltegiak sisteman erregistratuta daudela suposatuz). Linux banaketa guztiek ezin dute hori egin.

Beste modu bat fitxategi-kudeatzailea erabiltzea da, arrastatu eta jaregin .hpkg paketea edo barruan /Haiku/system/packages (sistema osoko instalazio baterako, lehenespenez), edo barruan /Haiku/home/config/packages (Banakako instalaziorako; ez dago eskuragarri klik bikoitzean - oraindik ere gogaituta nago leku honetan "config" hitzak, niretzat kasu honetan "ezarpenak" sinonimoa dena). Eta erabiltzaile anitzen kontzeptua oraindik ez dago erabilgarri Haikurako (seguruenik horregatik da hain sinplea; ez dakit, agian erabiltzaile anitzeko gaitasunek alferrik zailduko dituzte mahaigaineko ingurunerako).

Haikuk irabazi du kategoria honetan, aplikazioekin ez ezik, sistemako programekin ere funtziona dezakeelako.

GUI-tik pakete bat kentzen

Mac-en, aplikazioaren ikonoa zakarrontzira arrastatu behar duzu, eta kito. Erraz!

Haikuan, lehenik eta behin, paketea sisteman non dagoen aurkitu behar duzu, oso gutxitan instalatzen duzulako leku egokian (sistemak dena egiten du). Normalean barrura begiratu behar duzu /Haiku/system/packages (sistema osorako lehenetsitako instalazio batekin), edo barruan /Haiku/home/config/packages (Aipatu al dut "config" izen okerra dela?). Ondoren, aplikazioa zakarrontzira arrastatzen da, eta kito.
Erraz! Hala ere, ez nuke hori esango. Hona hemen benetan gertatzen ari dena:

Hau da aplikazio bat zakarrontzira arrastatuz gero gertatzen dena /Haiku/system/packages

QtQuickApp-en nire atzoko "Kaixo mundua" aplikazioa zaborrontzira eramaten saiatu naiz. Ez naiz saiatu sistemaren direktorioa mugitzen, eta pakete guztiak sistemaren direktorioan instalatuta daudenez, ezinezkoa da paketea kentzea .hpkg aldaketarik gabe "bere edukia". Erabiltzaile arrunt batek beldurtu egingo luke eta lehenespenez esleitutako "Utzi" botoia sakatuko luke.

Azaltzen du jauna. waddlesplash:

Mezu honek 10 urte baino gehiago ditu. Seguruenik, konfiguratu beharko dugu abisua paketea bera mugitzen denean bakarrik ager dadin. Erabiltzaile arruntek ez dute hori egin behar, hala ere.

Ados, agian hau HaikuDepot erabiliz egin beharko nuke? Paketearen gainean klik bikoitza egiten dut /Haiku/system/packages, "Desinstalatu" botoia noiz agertuko zain. Ez, "Instalatu" dago (soilik). "Desinstalatu", non zaude?

Dibertitzeko, jada instalatutako pakete batean "Instalatu" sakatuz gero zer gertatuko zen ikusten saiatu nintzen. Honela ateratzen da:

Hau jada instalatutako pakete bat instalatzen saiatzen bazara gertatzen da.

Hurrengoa agertzen da:

Aurreko leihoan "Aplikatu aldaketak" sakatzen baduzu, itxura hau izango du

Suposatzen dut software-errore bat dela; aplikaziorako esteka dagoeneko hor dago. [egileak ez du estekarik eman - gutxi gorabehera. itzultzailea]

Irtenbide azkarra: Gehitu "Desinstalatu" botoia paketea dagoeneko sartuta badago /Haiku/system/packages, edo /Haiku/home/config/packages.

HaikuDepot-en instalatutako paketeen zerrenda ikustean, nire paketea zerrendan ikusten dut eta kendu dezaket.

Mac-ek irabazi du kategoria honetan. Baina imajina dezaket konfigurazio egokiarekin, Haiku-n erabiltzailearen esperientzia Mac-en baino hobea izango dela. (Garatzaileetako batek honela baloratu zuen: "HaikuDepot-era zehaztutako funtzionaltasuna gehitzeko ordubete baino gutxiago, C++ apur bat ezagutzen baduzu", boluntariorik?)

Pakete batetik zerbait kentzea

Saia gaitezen aplikazioa bera kentzen, ez paketea .hpkg, bertatik zetorren (zalantza dut “hilkor hutsentzat” alderik dagoenik).

Mac-en, erabiltzaileak normalean fitxategiarekin lan egiten du .dmgnondik dator aplikazio paketea .app. Normalean irudiak .dmg deskarga-direktorioan pilatzen dira, eta paketeak erabiltzaileak bertan kopiatzen ditu /Applications. Uste da erabiltzaile askok beraiek ez dakitela zer egiten ari diren, hipotesi hau Appleko langile ohi batek baieztatzen du. (Mac-en gustatzen ez zaidan gauzetako bat. Eta, adibidez, AppImage-rekin ez dago desberdintasunik aplikazioaren eta zegoen paketearen artean. Arrastatu ikonoa zakarrontzira = hori da. Erraza!)

Haikuan, arteko banaketa ere badago apps/ и packages/, beraz, zalantza dut horrek erabiltzaileei argiago utzi dienik. Baina zer gertatzen da aplikazio bat arrastatuz gero apps/ Gehitu saskira:

Hau da fitxategi batetik hartutako aplikazio bat kentzen saiatzen zarenean gertatzen dena .hpkg

Teknikoki zuzena da (azken finean, aplikazioa irakurtzeko soilik den fitxategi-sistema batean dago ostatatuta), baina ez da bereziki erabilgarria erabiltzailearentzat.

Irtenbide azkarra: iradoki GUI erabiltzea ezabatzeko .hpkg

Dibertitzeko, aplikazioa bikoizten saiatu naiz Alt+D sakatuz. "Ezin dira mugitu edo kopiatu objektuak irakurtzeko soilik den bolumen batean" mezua jaso nuen. Eta dena delako /system (gainera /system/packages и /system/settings) packagefs muntatze-puntua da (gogoratu nola agertzen den irteeran df?). Zoritxarrez, komandoaren irteera mount ez du egoera argitzen (aurreko artikuluetako batean esan bezala), mountvolume ez du bilatzen ari zarena erakusten (itxuraz loop bidez muntatutako paketeak .hpkg ez dira "bolumen"tzat hartzen), eta komando alternatiboak ere ahaztu ditut.

Inork ez zuen irabazi kategoria honetan AppImage izan ezik (baina hau, guztiz zintzoa izateko, iritzi alboratzailea da). Dena den, pentsa daiteke moldatu ondoren, Haiku-n erabiltzailearen esperientzia Mac-en baino hobea izango dela.

Oharra: jakin behar duzu zer den "bolumena" "atal" bati dagokionez. Hau seguruenik "karpeta" eta "direktorioa"-ren erlazioaren antzekoa da: direktorio gehienak fitxategi-kudeatzailean karpeta gisa agertzen dira, baina ez denak (fitxategi gisa tratatzen diren paketeak, adibidez). Erakusketa mota honek nerd ofizial bihurtzen al nau?

Pakete baten edukia beste sistema batera kopiatzea

Mac-en, ergelki arrastatzen dut paketea .app, eta menpekotasunak pakete barruan daudenez, elkarrekin mugitzen dira.

Haikuan, aplikazioa arrastatzen dut, baina menpekotasunak ez dira batere prozesatzen.

Irtenbide azkarra: iradoki dezagun `.hpkg pakete osoa arrastatzea, edozein menpekotasunekin batera, baldin badago.

Mac-ek argi eta garbi irabazi du kategoria honetan. Ni behintzat, euren paradigmaren maitalea. Haikura kopiatu beharko nuke .hpkg aplikazio baten ordez, baina sistemak ez dit hau eskaintzen...

Deskargatu pakete bat bere menpekotasun guztiekin

Makina guztiak ez daude sarera konektatuta uneoro. Aitzitik, makina batzuk (bai, zuri begira nago, Windows, Mac eta Linux modernoak) horretaz ahazten dira. Garrantzitsua da niretzat, adibidez, Internet kafetegi batera joatea, softwarea deskargatu ahal izatea disko aldagarri batean, disko hau nire etxeko ordenagailuan sartzea eta ziur dena funtzionatuko duela [arriskutsua, hau Windows-en egiten... - gutxi gorabehera. itzultzailea].

Ondorioz, Windows eta Linux-en bete gabeko menpekotasunekin amaitzen dut ohi baino apur bat maizago.

Mac-en normalean fitxategi bat da, egin behar duzun guztia deskargatu baino ez da .dmg. Gehienetan, MacOSek berak ematen dituen menpekotasunik ez du lehenespenez. Salbuespen bat exekuzio ingurune egokia behar duten aplikazio konplexuak dira, adibidez java.

Haikuan deskargatu paketea .hpkg izan ere, demagun, java-n aplikazio bera agian ez da nahikoa, java helburuko makinan egon baitaiteke edo ez. Ba al dago pakete jakin baten menpekotasun guztiak deskargatzeko modurik .hpkg, Haiku-n lehenespenez instalatuta daudenak ez ezik, eta, beraz, Haiku sistema guztietan egon beharko lukete?

Mac-ek kategoria hau irabazten du alde txiki batekin.

Iruzkinak Mr. waddlesplash:

Aplikazio baten menpekotasun guztiak pakete multzo gisa biltzeko programa bat idazteko .hpkg Haikuren barne funtzionamendua ezagutzen duen norbaitentzat, 15 minutu inguru nahikoa da. Honi laguntza gehitzea ez da hain zaila, benetako beharra badago. Baina niretzat egoera arraroa da.

Eutsi diezaiogun arnasa serie honetako hurrengo artikulura arte.

Paketeak beste kokapen batera eramatea

Lehen idatzi nuen bezala, nire paketeak jarri nahi ditut .hpkg (ondo, edo horietako zati bat) leku berezi batera, abioko bolumenean ohiko kokapenetik bereizita (root partizioa). Ohiko kasuetan (ez hain teorikoetan), horren arrazoia da nire (eraikitako) diskoetan leku librerik gabe gelditzen naizela etengabe, zein handiak diren arren. Eta normalean kanpoko unitateak edo sare partekatzeak konektatzen ditut nire aplikazioak dauden tokian.

Mac-en paketeak mugitzen ari naiz .app Finder-eko disko aldagarri edo sareko direktorio batera, eta kito. Oraindik egin dezaket klik bikoitza aplikazioa irekitzeko normalean abioko bolumenetik egingo nukeen moduan. Besterik gabe!

Haikuan, esan zidaten bezala, hau nire mugituz lor daiteke .hpkg paketeak disko aldagarri edo sareko direktorio batera, baina gero kontsolan dokumentatu gabeko komando batzuk erabili behar dituzu sisteman muntatzeko. Ez dakit hau nola egin GUI soilik erabiliz.

Mac-ek irabazi du kategoria honetan.

mr. waddlesplash:

Hau erabilera arruntean oinarritutako optimizazioa da. Erabiltzaile baten baino gehiagoren eskaera badago, ezarriko dugu. Nolanahi ere, badago hirugarrenen ezarpena egiteko aukera.

Honetaz hurrengo artikuluan hitz egingo dugu.

Sareko direktorioei buruz hitz egitean, bikaina litzateke (LAN alderdiak asmatzen ari naiz) sare osorako aplikazio errazak, aurki daitezkeenak (Zeroconf bezalakoak), tokiko ordenagailuan kopiatu edo sare lokaletik zuzenean exekutatu daitezkeenak. Jakina, garatzaileek aukera dute aukeran uzteko app_flags.

Hpkg sistema GUIarekin integratzeari buruzko azken txostena

Batez ere integrazioaren berritasun erlatiboa dela uste dut .hpkg GUI-k oraindik asko uzten du. Dena den, UX aldetik hobetu daitezkeen gauza batzuk daude...

Beste gauza bat: Kernel Debug Land

Oso ona izango litzateke nukleoaren izuan komandoak sartu ahal izatea, adibidez syslog | grep usb. Beno, Haiku-n posible da Kernel Debug Land-i esker. Nola ikus dezakezu magia hau martxan dena behar den moduan funtzionatzen badu nukleoaren izuan sartu gabe? Erraza Alt+PrintScn+D sakatuta (Araztu mnemoteknia). Berehala gogoratzen naiz Programatzailearen giltza, jatorrizko Macintosh-eko garatzaileei araztegian sartzeko aukera eman zien (bat instalatuta bazegoen, noski).

Ondorioa

Ulertzen hasi naiz Haiku sistemaren sofistikazioa lan-talde txiki batek egiten duelako lan-inguruneari arreta argia emanez, sistemaren geruza guztiak eskuragarri izanik.
Kontraste nabarmena Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu-ren munduarekin, non dena zati txikitan apurtzen den, abstrakzioa abstrakzioan esertzen baita eta makuluekin gidatzen duen neurrian.
Sistema nolakoa den ere ulertzen zen .hpkg Pakete-kudeatzaile tradizionalen, Snappy, Flatpak, AppImage, baita btrfs-en praktika onenak konbinatzen ditu eta Mac-en "funtsak besterik ez" ikuspegiarekin nahasten ditu.

Buruan zerbait "aldatu" balitz bezala zen, eta sistema nolakoa den ulertu nuen .hpkg badaki nola urruntzen, berari begiratuz. Baina ez naiz ni, sistemaren edertasuna eta sinpletasuna baizik. Honen zati handi bat jatorrizko Mac-aren izpirituan inspiratuta dago.

Bai, nabigatzailean nabigatzea aldakorra izan daiteke eta barraskilo bat bezala exekutatu daiteke, baliteke aplikazioak falta izatea (ez Gtk, Electron - garatzaileek sofistikazioarekin ondo ez doazela ondorioztatu zuten), baliteke bideoa eta 3D azelerazioa guztiz falta izatea, baina oraindik ere sistema hau atsegin du. Azken finean, gauza hauek zuzendu daitezke eta lehenago edo beranduago agertuko dira. Denbora kontua baino ez da eta agian begi gorritxo bat.

Ezin dut laguntza eskaini, baina uste dut hemendik aurrera hasiko dela Haiku urtea mahaigainean.

Ausazko arazoak

Agian eskaerak daude dagoeneko, edo ireki behar ditut?

BeScreenCapture Peek bezalako GIFra esportatu ahal izan beharko luke. Hau ffmpeg erabiliz egin daiteke, dagoeneko eskuragarri dago Haikurako. Aplikazio.
Pantaila-argazkiaren softwareak huts egiten du leiho modal bat harrapatzen, pantaila osoa harrapatzen beharrean
Ezin duzu moztu pantaila-argazkiak WonderBrush-en mozteko tresna erabiliz eta ondoren emaitza fitxategi batean gorde
Ez zait bereziki gustatzen Haikuko eskuko kurtsorea, baina uste dut nostalgiko sentsazio beroarekin zerikusia duela. Hau bereziki gogaikarria da Mozte tresna Krita-n erabiltzean, zehaztasunik gabeko mozketa eragiten baitu (ikusi artikulu honetako elkarrizketa modalen pantaila-argazkiak). Gurutzetako kurtsorea zoragarria izango litzateke. Aplikazio.

Probatu zeure burua! Azken finean, Haiku proiektuak DVDtik edo USBtik abiarazteko irudiak eskaintzen ditu, sortutakoak eguneroko. Instalatzeko, deskargatu irudia eta idatzi flash drive batean erabiliz akuaforte kontuetan

Galderarik baduzu? Errusiera hiztunera gonbidatzen zaitugu telegrama kanala.

Erroreen ikuspegi orokorra: Nola tiro zeure buruari oinetan C eta C++-n. Haiku OS errezeta bilduma

From egilea itzulpena: Haikuari buruzko serieko seigarren artikulua da.

Artikuluen zerrenda: Lehen Bigarren Hirugarrena Laugarren bosgarren

Iturria: www.habr.com

Nire seigarren eguna Haikurekin: baliabideen, ikonoen eta paketeen kapapean