Röviden összefoglalva: A Haiku — egy operációs rendszer, amelyet kifejezetten PC-khez terveztek, ezért számos trükkje van, amelyek javítják a munkakörnyezetét másokkal szemben. De hogyan működik?
Felfedeztem a Haikut, ami egy váratlanul jó rendszer. Még mindig lenyűgöz, milyen simán működik, különösen a Linux környezetekhez képest. Ma mélyebbre nézek. Ott, ahol szükséges a mélyebb megértéshez, összehasonlítom az eredeti Macintosh-t, a Mac OS X-et és a Linux munkaörnyezeteket (a freedesktop.org XDG szabványt).
Erőforrások ELF fájlokban
Tegnap megtudtam, hogy az IconOMatic képes ikonokat tárolni rdef erőforrásokban ELF végrehajtható fájlokban. Ma megnézem, hogyan működik ez valójában.
Erőforrások? tól , a Macintosh Finder program eredeti szerzője és a Macintosh Resource Manager „atyja”:
Aggaszt a tradicionális kodeírás merevsége. Számomra a kódba zárt alkalmazás ötlete, amelyben semmit sem lehet dinamikusan megváltoztatni — elképesztő barbárság. Lehetőséget kell adni arra, hogy a lehető legtöbbet megváltoztassunk a futási idő alatt. Természetesen az alkalmazás kódja nem változtatható, de nem lehetne valamit kicserélni anélkül, hogy újra kellene fordítani a kódot?
Az eredeti Macintosh-on úgy alakították ki, hogy ezeknek a fájloknak van „adat szekciójuk” és „erőforrás szekciójuk”, ami rendkívül megkönnyítette különféle dolgok, például ikonok, fordítások stb. tárolását a végrehajtható fájlokban.
A Mac-en ehhez használatos, ami egy grafikus program a — meglepetés — erőforrások szerkesztésére.
ResEdit az eredeti Macintosh-on
Eredményeként lehetővé vált ikonok, menüpontok, fordítások stb. viszonylag könnyű szerkesztése, bár ezek továbbra is „vándorolnak” az alkalmazásokkal.
Mindenesetre ennek az megközelítésnek volt egy nagy hátránya: csak az Apple fájlrendszereken működött, ami az egyik oka volt annak, hogy az Apple elhagyta a „resource section”-t a Mac OS X-re való áttéréskor.
A Mac OS X-en az Apple olyan megoldásokra vágyott, amelyek függetlenek a fájlrendszertől, ezért bevezették a csomagok (a NeXT-től) fogalmát, olyan könyvtárakat, amelyeket a fájlkezelő „átlátszatlan objektumként” kezel, hasonlóan a fájlokhoz, nem pedig könyvtárakhoz. Bármely csomag egy alkalmazás formátumban .app tartalmaz, többek közt, egy Info.plist (az Apple valamilyen JSON vagy YAML megfelelője), amely az alkalmazás metaadatait tartalmazza.
A Mac OS X alkalmazáscsomag Info.plist fájl kulcsa.
Az erőforrások, például ikonok, UI fájlok és egyebek, fájlok formájában tárolódnak a csomagban. A koncepció valójában visszatért a gyökerekhez a NeXT jelentések során.
A Mathematica.app a NeXTSTEP 1.0 alatt 1989-ben: a terminálban mappaként jelenik meg fájlokkal, de mint egyetlen objektum a grafikus fájlkezelőben.
Térjünk vissza a BeOS-hoz, amelynek koncepcióin a Haiku alapul. Fejlesztői, amikor a PEF-ről (PowerPC) az ELF-re (x86) váltottak (ugyanaz, amit Linuxon használnak), úgy döntöttek, hogy erőforrás szektort adnak az ELF fájlok végéhez. Ehhez nem használtak megfelelő ELF szektort, hanem egyszerűen a fájl végéhez írták. Ennek eredményeként a programok, strip és egyebek a binutils-ból, amelyek nem tudnak erről, egyszerűen levágták azt. Ezért jobb, ha nem használunk Linux eszközöket az ELF fájlban lévő erőforrások kezeléséhez BeOS alatt.
Mi történik most a Haikuban? Elvileg nagyjából ugyanaz.
Elméletileg lehetne erőforrásokat elhelyezni az ELF megfelelő szektorában. A #haiku csatorna fejlesztői szerint az irc.freenode.net-en:
Az ELF szektorral több értelme lenne... az egyetlen ok, amiért nem így csináljuk, az az, hogy így csinálták a BeOS-ban.
És ezt most nem érdemes megváltoztatni.
Erőforrás-gazdálkodás
Az erőforrásokat struktúrált „erőforrás” formátumban tárolják: lényegében egy erőforrások listája méretekkel, majd a tartalmukkal. Emlékeztetett .
Hogyan ellenőrizhetjük az erőforrásokat a Haikuban? Van valami hasonló a ResEdit-hez?
A következő szerint :
Az alkalmazáscsomagban található erőforrások megtekintéséhez egyszerűen húzza át a végrehajtható fájlt egy olyan programra, mint Emellett be lehet lépni a terminálba és futtatni a parancsot
listres fájl_neve..
A Resourcer elérhető a HaikuDepotban, de nálam egyszerűen összeomlik.
Hogyan kezeljük az erőforrásokat az ELF fájlokban? Az rsrc és rdef fájlok egyesítve. rdef fájlok egyesítve … A fájl rsrcnormál szövegformátumban tárolódik, így sokkal könnyebb vele dolgozni. Az fájl az rdef fájlok egyesítve végére íródik az ELF fájlnak. Próbáljuk ki a következőt: rsrc ~> rc -h Haiku Erőforrás Fordító 1.1Az rdef szkript erőforrás fájlba történő fordításához: rc [opciók] [-o ] ...Az erőforrás fájl rdef szkriptté történő visszaalakításához: rc [opciók] [-o ] -d ...Opciók: -d --decompile létrehoz egy rdef szkriptet az erőforrás fájlból --auto-names erőforrás neveket generál az ID szimbólumokból -h --help megjeleníti ezt az üzenetet -I --include hozzáad a include útvonalak listájához -m --merge ne törölje a kimeneti fájl meglévő tartalmát -o --output a kimeneti fájl nevét adja meg, alapértelmezés szerint out.xxx -q --quiet ne jelenítse meg a hibás üzeneteket -V --version szoftververzió és licenc megjelenítése.
Használhatjuk a programotxres. xres ellenőrzés és kezelés:
/> 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.
(...)Rendben, próbáljuk ki?
/> 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_VERSIONTovábbi információ a forrásokról és a formátumról rdef fájlok egyesítve további információkat találhat .
Alapvető forrástípusok
Bármit elhelyezhetünk a forrásokban, van néhány konkrét alapvető típus:
app_signature: Az alkalmazás MIME típusa, a megnyitható fájlok, futtatás, IPC stb. hozzárendelésére.app_name_catalog_entry: Mivel az alkalmazás neve általában angolul van, itt feltüntethetjük a lefordított nevek helyeit, így a különböző nyelveket beszélő felhasználók, ha akarnak, láthatják az alkalmazás lefordított nevét.app_version: pontosan azt gondoltad,app_flags: jelziregistrarhogyan kell kezelni az alkalmazást. Azt hiszem, van valami több, mint aminek első ránézésre látszik. Például vanB_SINGLE_LAUNCH, amely arra kényszeríti a rendszert, hogy minden alkalommal új alkalmazásfolyamatot indítson, amikor a felhasználó kéri (ugyanaz az elv érvényes a legtöbb Linux-alapú alkalmazásra). VanB_MULTIPLE_LAUNCH, amely folyamatot indít minden fájlhoz.Végül vanB_EXCLUSIVE_LAUNCH, amely arra kényszeríti a rendszert, hogy csak egy folyamatot indítson egyszerre, függetlenül attól, hogy a felhasználók hányszor indítják el (például így indul a Firefox Linuxon; ugyanezt az eredményt elérhetjük Qt alkalmazásokban a funkció használatával). Az alkalmazásokkalB_EXCLUSIVE_LAUNCHértesítést kapnak, amikor a felhasználó megpróbálja újraindítani őket: például megkapják a fájl útvonalát, amelyet a felhasználó meg szeretne nyitni az alkalmazásuk segítségével.vector_icon: Az alkalmazás vektorgrafikus ikonja (A BeOS-ban nem voltak vektorképek, a legtöbb alkalmazás helyett két raszteres ikont tartalmazott a végrehajtható fájlokban).
Természetesen lehetőség van olyan források hozzáadására, bármilyen kívánt ID-vel és típussal, majd a legfeljebb a legfrissebb alkalmazásban vagy más alkalmazásokban a BResourcesosztály segítségével olvasni őket. De először álljunk meg a lenyűgöző ikonok témájánál.
Vektorgrafikus ikonok Haiku stílusban
Természetesen nemcsak a Haiku választotta a legjobb ikonformátumot, ezen a téren a Linux munkaasztali környezetek helyzete távol áll az ideálistól:
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.cacheIlyen látványnál már érezni lehet, hogy ez egy darab.
Természetesen létezik skálázható, amely vektor ikonokat tartalmaz, ahogy azt érteni lehet. Miért van akkor még valami más? Mert a vektoros grafika kis méretben való megjelenítése rosszabb lehet, mint az ideális. Különböző méretekre optimalizált variációkra van szükség. Linux környezetben ezt a fájlrendszer ikonok különböző méreteire való szétszórásával érjük el.
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.pngVegyük figyelembe: a Firefox különböző verzióinak fogalma nem létezik. Így nem lehet finoman kezelni a helyzetet, amikor több verziója van az alkalmazásnak a rendszerben.
Különböző Firefox ikonok különböző verziókban. Jelenleg nem lehet ezt Linuxon különböző trükkök nélkül kezelni.
A Mac OS X némileg finomabban kezeli:
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.icnsLátható, hogy egy fájl van firefox.icns a csomagban Firefox.app, amely minden méretet tartalmaz, így az egy alkalmazás különböző verziói különböző ikonokat hordoznak.
Sokkal jobb! Az ikonok együtt utaznak az alkalmazással, minden erőforrás egy fájlban van.
Térjünk vissza a Haikuhoz. Megdöbbentő megoldás, kivételek nélkül. Eszerint :
Kifejlesztettek egy különleges, kis méretekre és gyors renderelésre optimalizált formát, HVIF. Ezért ikonjaink többségében sokkal kisebbek, mint raszteres vagy széles körben használt SVG formátumban.
És tényleg optimalizáltak:
Az ikonk méretei HVIF formátumban más formátumokkal összehasonlítva.
A különbség egy nagyságrenddel!
De a varázslat itt nem ér véget. Ugyanaz a HVIF különböző részletességi szinteket tud mutatni az ábrázolt méret függvényében, annak ellenére, hogy vektoros formátum.
Különböző részletességi szintek (LOD) az ábrázolási mérettől függően
Most a hátrányokról: nem lehet egyszerűen az SVG-t bemásolni az ImageMagickba és ezzel végezni, néhány cikluson át kell menni, hogy HVIF formátumban ikont készítsünk. magyarázatok. Azonban az IconOMatic elég hiányosan importálhat SVG-t; az SVG részleteinek körülbelül 90%-a importálva van valamilyen valószínűséggel, a fennmaradó 10%-ot pedig kézzel kell finomítani és módosítani. Olvasson többet arról, hogyan végzi a HVIF a varázslatát a blogunkban
Ikon hozzáadása az alkalmazáshoz
Most hozzáadhatok egy ikont a csomaghoz, amelyet , figyelembe véve az összes megszerzett információt.
Mivel most nem igazán van kedvem saját ikont készíteni a „Helló, Világ” QtQuickApp-hoz — kivezetem azt a Qt Creatorból.
/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 CreatorNézzük meg, hogy az ikon sikeresen másolatba került:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONJól néz ki, de miért nem jelenik meg az újonnan másolt ikon?
A másolt VICN:101:BEOS:ICONs még nem használatos az alkalmazás ikonjaként a fájlkezelőben.
Mit hagytam ki?
Fejlesztői megjegyzés:
Létre kell hozni egy fájlt
rdef fájlok egyesítveminden erőforrással, majd futtatni a parancsotrc név.rdef, ez létrehozza a fájlt.rsrc. Aztán futtatni kell a parancsotresattr -o név_binaries név.rsrc. Legalábbis ilyen parancsokat használok az ikonok hozzáadásához a szkriptjeimhez.
Nos, egy erőforrást szerettem volna létrehozni, nem egy attribútumot. Teljesen zavarban vagyok.
Okos gyorsítótárazás a fájlrendszer használatával.
Az ELF attribútumok megnyitása és olvasása lassú. Ahogy már említettem, az ikon erőforrásként íródik a fájlba. Ez a módszer megbízhatóbb, és lehetővé teszi, hogy átvészelje a másolást egy másik fájlrendszerbe. Azonban később ez is átmásolásra kerül a fájlrendszer attribútumaiba, például BEOS:ICON. Ez csak bizonyos fájlrendszerekben működik, például BFS. Azok az ikonok, amelyeket a rendszer megjelenít (a Trackerben és a Deskbarban), ebből a kiterjesztett attribútumból olvassák, mivel ez a megoldás gyorsan működik. Egyes helyeken (ahol a sebesség nem fontos, például a 'Névjegy' ablak) a rendszer közvetlenül a fájl erőforrásából kapja az ikont. De ez még nem a vég. Ne feledje, hogy Mac-en a felhasználók saját ikonjaikkal helyettesíthették az alkalmazások, könyvtárak, dokumentumok ikonjait, mivel a Mac-en lehetőség van ezekre a 'fontos' dolgokra, például . A Haiku esetében a fájlban található erőforrást az alkalmazással szállított alapértelmezett ikonként kell tekinteni, míg az attribútumot (a BFS fájlrendszerben) olyan dologként, amely lehetővé teszi a felhasználóknak, hogy igényeik szerint módosítsanak (bár, egy tipp: a felhasználói ikon alapértelmezett ikonra helyezésére szolgáló grafikai felület még nem került megvalósításra).
Fájlrendszer attribútumok ellenőrzése
A segítségével resaddr lehetőség van a fájlrendszer attribútumainak ellenőrzésére és beállítására.
/> 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.
(...)Alapvetően ez egy "ragasztó", amely a (megbízható) források és a (gyors) fájlrendszer attribútumok között végez fordítást. Mivel a rendszer automatikusan szerzi be a forrásokat és végzi a másolást, nem fogok tovább aggodalmaskodni e miatt.
A hpkg csomagok varázslata
Jelenleg (leggyakrabban) a Haiku programok beszerzésére csomagokat használnak. .hpkg. Ne hagyja, hogy a egyszerű név megtévesszen: a .hpkg formátum teljesen másképp működik, mint más hasonló nevű formátumok, amelyekkel Önnek már volt dolga; valós szuperképességekkel bír.
A hagyományos csomagformátumokkal sokáig frusztrált voltam a következő tény miatt: letöltesz egy (csomagot), de a rendszerben egy más (a csomag belső fájljai) települ. Elég nehéz kezelni a fájlokat (például törölni őket), amikor a csomag telepítése hagyományos módon történik. Mindez amiatt van, hogy a csomag tartalma szétoszlik az egész fájlrendszerben, beleértve azokat a helyeket is, ahová a szokásos felhasználónak esetleg nincs írási hozzáférése. Ez egy teljes programosztályt generál — csomagkezelők.. Ráadásul az már telepített szoftver átvitele, például egy másik gépre, cserélhető lemezre vagy fájlszerverre, még nehezebbé válik, sőt, akár lehetetlenné is. Egy átlagos Linux alapú rendszeren könnyen létezhet több százezer vagy akár millió elkülönített fájl. Kézenfekvő, hogy ez egyaránt törékeny és lassú, például a rendszer kezdeti telepítése, a hagyományos csomagok telepítése, frissítése és eltávolítása során, valamint a boot kötet (gyökér partíció) másolt hordozóra.
Az AppImage projekten dolgozom, amely egy részleges megoldás a felhasználói alkalmazások számára. Ez egy szoftverforgalmazási formátum, amely egyesíti az alkalmazást és annak összes függőségét egy fájlrendszer képként, amely a program indításakor montálódik. Jelentősen egyszerűsíti a dolgokat, mivel a ImageMagick hirtelen egy fájlra változik, amelyet az átlagfelhasználók kezelhetnek a fájlkezelőben. A javasolt módszer csak szoftverekre működik, ahogy a projekt neve is jelzi, és van egy saját hibakészlete, mivel azok az emberek, akik a Linux szoftverbiztosításaival foglalkoznak, mindig rám hárítják a felelősséget.
Térjünk vissza a Haiku-ra. sikerült-e megtalálni az optimális egyensúlyt a hagyományos csomagrendszerek és a képek alapú szoftverellátás között? A csomagjai .hpkg gyakorlatilag tömörített fájlrendszer képek. A rendszer indulásakor a kernel csatolja az összes telepített és aktív csomagot, körülbelül a következő kernel üzenetekkel:
KERN: package_daemon [16042853: 924] aktív csomag: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023: 924] aktív csomag: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232: 924] aktív csomag: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405: 924] aktív csomag: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611: 924] aktív csomag: "llvm_libs-5.0.0-3-x86_64.hpkg"Menő, ugye? Tartsák magukat, mert még ennél is izgalmasabb jön!
Van egy nagyon különleges csomag:
KERN: package_daemon [16040020: 924] aktív csomag: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Ez egy meglehetősen minimalista operációs rendszert tartalmaz, beleértve a kernelt is. Higgyenek vagy sem, de még a kernel sem kerül ki a boot kötetből (gyökérpartíció), hanem gondosan betöltődik a csomagból a helyére. .hpkgHát ez meg mi volt! Már említettem, hogy a Haiku összességében szerkezeti kifinomultságát és összhangját részben az adja, hogy az egész rendszer, a kerneltől kezdve az alapfelhasználói térig, valamint a csomagkezelésig és a munkakörnyezet infrastruktúrájáig, egy csapat közreműködésével készült. Képzeljék el, hány különböző csoportnak és csapatnak lenne szüksége ahhoz, hogy ilyen Linux-alapú rendszert elindítson. [elképzelem a PuppyLinux projektet, — a fordító megjegyzése]. Aztán képzeljék el, mennyi időbe telik, míg ez a megközelítés bekerül a disztribúciókba. Azt mondják: vedd egy egyszerű feladatot, oszd meg különböző végrehajtók között, és annyira bonyolulttá válik, hogy már nem is lehet megoldani. A Haiku ebben az esetben felnyitotta a szemem. Úgy gondolom, hogy éppen ez történik most a Linux-szal (a Linux ebben az esetben gyűjtőfogalom, amely a Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu stacket jelenti).
Rendszer visszaállítása hpkg használatával
Milyen gyakran fordul elő a következő helyzet: a frissítés sikeresen lezajlott, de később kiderül, hogy valami nem működik úgy, ahogy kellene? Ha a megszokott csomagkezelőket használjuk, nehéz visszaállítani a rendszert az új csomagok telepítése előtti állapotra (például, ha valami rosszul sült el). Néhány rendszer körüljáró megoldásokat kínál a fájlrendszer pillanatképeivel, de ezek meglehetősen terjengősek és nem minden rendszerben alkalmazzák őket. A Haikuban ezt csomagokkal oldják meg. .hpkg. Mindig, amikor a rendszerben csomagok változnak, a régi csomagok nem törlődnek, hanem a rendszerben a következő al-mappákban tárolódnak: /Haiku/system/packages/administrative/state-<...>/ folyamatosan. A befejezetlen műveletek az adataikat a következő al-mappákban tárolják. /Haiku/system/packages/administrative/transaction-<...>/.
Tartalom /Haiku/system/packages/administrative. A "state..." mappák szöveges fájlokat tartalmaznak, amelyek az aktív csomagok neveit, a "transaction..." mappák pedig magukat a csomagokat.
"Régi aktív állapot", azaz a változások előtti aktív csomagok listája, minden művelet után a fájlkezelőben egy szöveges fájlba kerül rögzítésre. .hpkg . Hasonló módon az új "aktív állapot" is egy szöveges fájlba íródik. /Haiku/system/packages/administrative/state-<...>/activated-packagescsak egy szöveges fájlt tartalmaz, amely az ezen állapot aktív csomagjainak listáját tartalmazza (csomagok telepítése esetén törlés nélkül), és ha csomagokat töröltek vagy frissítettek — a state mappa az ócska csomagverziókat tárolja. /Haiku/system/packages/administrative/activated-packages.
Mappa /Haiku/system/packages/administrative/state-<...>/ A rendszer indításakor a csomagok listája alapján döntenek a csomagok aktiválásáról (csatlakozásáról). Így nagyon egyszerű! Ha az indítás során valami rosszul alakul — a rendszerbetöltőnek meg lehet mondani, hogy egy másik, régebbi listát használjon. A probléma megoldva!
A Haiku rendszerbetöltője. Minden belépési pont a megfelelő "aktív állapotot" jeleníti meg.
Tetszik a megközelítés, hogy egyszerű szöveges fájlokat használnak az "aktív állapot" listájaként, amelyben érthető elnevezéseket rögzítenek.
. Ez éles ellentétben áll a gépek számára készült, nem pedig embereknek szánt .hpkghalmazzal Az aktív csomagok listája minden időpillanatban
Konfigurációs adatok
Úgy tűnik, a
mappában beállítási fájlok találhatók a csomagokhoz, de írásra elérhetők. Hiszen, ahogy emlékszel, /Haiku/system/packages/administrative/writable-files csak olvasásra csatlakoznak. Így ezeket a fájlokat a csomagokból kell másolni írás előtt. Érthető. .hpkg GUI integráció a .hpkg rendszerhez
Интеграция GUI для системы .hpkg
Nézzük meg, hogyan boldogulnak ezek a csillogó csomagok .hpkg a felhasználói munkakörnyezet (UX) integrálásával. Végül is a Haiku személyes használatra készült. Én magam nagyon magasra tettem a mércét, amikor a felhasználói élményt összehasonlítottam a csomagokkal .app a Macintosh rendszeren tapasztaltakkal, .hpkg. Nem is akarom összehasonlítani a helyzetet a Linux munkakörnyezetekkel, mert azok teljesen borzalmasak bármelyik másikhoz képest.
A következő forgatókönyvek jutnak eszembe:
- Szeretném megtekinteni a csomag tartalmát
.hpkg - Szeretném telepíteni a csomagot
- Szeretném eltávolítani a csomagot
- Szeretném eltávolítani valamit, ami a csomagnak köszönhetően került a rendszerbe
- Szeretnék másolni valamit, ami a csomagnak köszönhetően került a rendszerbe
- Szeretném letölteni az összes csomagfüggőséget, amelyek nem lehetnek részei minden Haiku telepítésnek (például, ha van egy fizikailag elszigetelt gépem, amely nem fér hozzá az internethez).
- Szeretném átköltöztetni a csomagjaimat (vagy azok egy részét) különböző helyre, elválasztva a rendszermeghajtótól (gyökér partíciótól) (mert, például, kevés a helyem rajta).
Ez lefedi a legtöbb alapvető esetet a mindennapi munkám során. Nos, lássunk hozzá.
A csomag tartalmának ellenőrzése
Mac-en egyszerűen jobb gombbal kattintok a csomagra a megnyitásához, és a Finderben megnézem a tartalmát. Végül is ez csak egy álcázott könyvtár! (Tudom, hogy vannak csomagok .pkg a rendszer azon részéhez, amely nem alkalmazás, de a hétköznapi felhasználók ezzel általában nem találkoznak).
A Haikun jobb gombbal kattintok a csomagra, majd a "Contents"-ra kattintok a belsejének megtekintéséhez. De itt csak fájlok listája van, amelyeket nem lehet kettős kattintással megnyitni.
Sokkal jobb lenne, ha lenne egy (ideiglenes) módszer a csomag .hpkg fájlkezelő általi megtekintésére, és a felhasználónak nem kellene foglalkoznia a megvalósítás részleteivel. (Egyébként meg lehet nyitni a csomagot .hpkg az Expanderben,amely ki tudja csomagolni, mint bármely más archívumot).
A HaikuDepot felhasználói felületén megtekinthetjük a csomag fájljainak listáját, de nincs mód a tartalom megtekintésére, például a README.md dupla kattintásával.
Ebben a kategóriában a Mac győz, de a szükséges funkcionalitás hozzáadása a HaikuDepothoz nem okozhat nagy nehézséget.
Csomag telepítése GUI-n keresztül
Mac-en, a legtöbb lemezkép .dmg csomagokat tartalmaz .app. Dupla kattintással nyitjuk meg a lemezképet, majd a csomagot áthúzva másoljuk például a /Applications Finderbe. Számomra ez egyértelmű, de hallottam, hogy néhány kezdő nehezen birkózik meg ezzel. Alapértelmezés szerint az Apple 'ajánlja' a rendszerszintű könyvtárat /Applications (a NeXT-en ez hálózati és egyéni is volt), de könnyedén elhelyezheti alkalmazásait egy fájlmegosztón vagy egy alkönyvtárban $HOME/Applications, ha úgy tetszik.
A Haikun, dupla kattintás a csomagra, majd kattintás az 'Install'-ra, ennél egyszerűbb már nem is lehet. Engem érdekelne, mi történik, ha a csomagnak vannak függőségei, amelyek elérhetők a HaikuPorts-ban, de még nincsenek telepítve. Linuxon nem tudják, mit kell tenni ebben a helyzetben, de a megoldás nyilvánvaló — megkérdőjelezni a felhasználót, hogy szüksége van-e a függőségek letöltésére és telepítésére. Pontosan ezt csinálja a Haiku.
Manuálisan töltöttem le a 'sanity' csomagot, és rákattintottam, a csomagkezelő tudja, honnan szerezheti be a függőségeit (feltéve, hogy a tárolók már be vannak állítva a rendszerben). Nem minden Linux disztribúció tud ilyet.
Még egy lehetőség — fájlkezelő használata, elegendő csak áthúzni .hpkg a csomagot vagy a /Haiku/system/packages (a rendszerszintű telepítéshez, alapértelmezés szerint), vagy a /Haiku/home/config/packages (a személyes telepítéshez; nem elérhető dupla kattintás esetén — még mindig zavarnak azok a 'config' kifejezések ebben a helyzetben, ami számomra itt a 'settings' szinonimája). Pedig a többfelhasználós koncepció még nem elérhető a Haiku számára (valószínűleg ezért annyira egyszerű — nem tudom, talán a többfelhasználós lehetőségek túl bonyolítanák a munkakörnyezetet egy személyi számítógépen).
Ebben a kategóriában a Haiku nyer, mert nemcsak az alkalmazásokkal, hanem a rendszerszintű programokkal is képes dolgozni.
A csomag eltávolítása a GUI-ból
Mac-en, csak húzza az alkalmazás ikonját a kukába, és ennyi. Egyszerű!
A Haikun, először meg kell találni, hol van a csomag a rendszerben, mert ritkán telepíti oda, ahová kellene (mindent a rendszer csinál). Általában a /Haiku/system/packages (a rendszerszintű telepítés esetén alapértelmezés szerint), vagy a /Haiku/home/config/packages (már említettem, hogy a 'config' nem a legjobb név?). Aztán az alkalmazás egyszerűen áthúzódik a kukába, és ennyi.
Egyszerű! Mégis, nem mondanám, hogy ez így van. Nézd, mi történik valójában:
Ez az, amit kapsz, ha az alkalmazást a kukába húzod /Haiku/system/packages
Csak megpróbáltam a tegnapi "Helló, világ" QtQuickApp alkalmazásomat a kukába helyezni. Nem próbáltam áthelyezni a rendszermappát, és mivel minden csomag a rendszermappába települ - lehetetlen eltávolítani a csomagot .hpkg anélkül, hogy megváltoztatnád „a tartalmát”. Egy átlagos felhasználó valószínűleg megijedne, és megnyomnia az alapértelmezett „Mégse” gombot.
Megmagyarázza :
Ez az üzenet már több mint 10 éves. Valószínűleg be kell állítanunk, hogy a figyelmeztetés csak akkor jelenjen meg, ha magát a csomagot helyezik át. A hétköznapi felhasználóknak mindenesetre nem kell így eljárniuk.
Rendben, lehet, hogy ezt a HaikuDepot segítségével kellene megtenni? Két kattintással rákattintok a csomagra a /Haiku/system/packages, várva, hogy megjelenjen az „Eltávolítás” gomb. Nos, csak az „Install” van. „Uninstall”, hol vagy?
Csak kíváncsiságból megnéztem, mi történik, ha rákattintok az „Install” gombra egy már telepített csomagra. Ez történt:
Ez akkor történik, ha megpróbálod telepíteni a már telepített csomagot.
Ezután megjelenik:
Ha az előző ablakban megnyomod az „Alkalmaz változások” gombot, ez fog történni
Feltételezem, hogy ez egy szoftverhiba, a hivatkozás már létezik a bejelentéshez. [a szerző nem adott meg linket, - ford. megj.]
Gyors megoldás: Adjunk hozzá egy „Uninstall” gombot, ha a csomag már létezik a
/Haiku/system/packages, vagy a/Haiku/home/config/packages.
A HaikuDepot-ban telepített csomagok listájának megtekintésekor meglátom a csomagomat a listában, és el tudom távolítani.
Ebben a kategóriában a Mac nyer. De el tudom képzelni, hogy megfelelő beállításokkal a Haiku használati élménye jobb lesz, mint a Mac-en. (Az egyik fejlesztő így értékelt: „Kevesebb, mint egy óra a megadott funkció hozzáadásához a HaikuDepot-hoz, ha tudsz egy keveset C++-ról”, vannak önkéntesek?)
Valami eltávolítása a csomagból
Próbáljuk meg eltávolítani magát az alkalmazást, nem pedig a csomagot .hpkg, ahonnan származik (nem hiszem, hogy a "normál halandók" számára lenne bármilyen különbség).
Mac-en, a felhasználó valójában általában a fájlal dolgozik .dmg, ahonnan az alkalmazás csomagja származik .app. Az imázsok általában .dmg a letöltési könyvtárban halmozódnak fel, a csomagok pedig a felhasználó által másolódnak. /ApplicationsAzt mondják, sok felhasználó nem tudja, mit csinál, ezt egy volt Apple-alkalmazott is megerősítette. (Az egyik dolog, amit nem kedvelek a Mac-en. Például az AppImage esetében nincs különbség az alkalmazás és a csomag között, amiben található. Csak húzd az ikont a kukába = és ennyi. Könnyű!)
A Haikun, van különbség is alkalmazások\/ és csomagok\/, ezért kétlem, hogy a felhasználóknak ez világosabbá válna. De mi történik, ha egy alkalmazást húzol a alkalmazások\/ kukába:
Ez történik, ha megpróbálsz törölni egy alkalmazást, ami egy fájlból származik .hpkg
Technikailag ez helyes (hiszen az alkalmazás a fájlrendszeren csak olvasható helyen található, elsősorban), de nem túl hasznos a felhasználónak.
Gyors megoldás: ehelyett ajánld fel a GUI-n keresztüli törlést
.hpkg
A vicc kedvéért megpróbáltam másolni az alkalmazást az Alt+D megnyomásával. Kaptam egy üzenetet: "Objektumokat nem lehet áthelyezni vagy másolni egy csak olvasható kötetben". És mindez azért történt, mert /system (a /system/packages és /system/settings) a packagefs csatolási pontja (emlékszel, hogy jelenik meg a kimenetben? df?). К сожалению, вывод команды mount nem tisztázza a helyzetet (ahogy egy korábbi cikkben is említették), mountvolume nem mutatja meg a keresettet (nyilvánvalóan a loop módszerrel csatolt csomagok .hpkg nem tekinthetők "kötetnek"), és elfelejtettem az alternatív parancsokat.
Ebben a kategóriában senki nem nyert, csak az AppImage (de ha nagyon őszinte akarok lenni, ez elfogult vélemény). Mégis elképzelhető, hogy finomhangolás után a felhasználói élmény a Haikun jobb lesz, mint a Mac-en.
Megjegyzés: ki kell deríteni, mi a "kötet" a "részleg" szempontjából. Valószínűleg hasonló a "mappa" és a "könyvtár" viszonyához: a legtöbb könyvtár a fájlkezelőben mappaként jelenik meg, de nem mindegyik (például a csomagok, amelyek fájlként kezeltek). Ezek a kitételek hivatalosan nerddé tesznek?
Egy csomag tartalmának átmásolása egy másik rendszerre
Mac-en, csak egyszerűen áthúzom a csomagot .app, mivel a csomag belsejében lévő függőségek is együtt mozognak.
A Haikun, áthúzom az alkalmazást, de a függőségek egyáltalán nem kezelődnek.
Gyors megoldás: ajánljuk inkább, hogy áthúzva a csomagot, az összes `.hpkg`-t a függőségekkel együtt.
Ebben a kategóriában egyértelműen a Mac nyer. Legalábbis számomra, aki szereti a paradigmájukat. A Haikun valószínűleg másolni kellene. .hpkg a benyújtott alkalmazás helyett, de a rendszer nem kínál ilyet...
A csomag letöltése minden függőségével együtt
Nem minden gép csatlakozik folyamatosan a hálózathoz. Éppen ellenkezőleg, egyes gépek (igen, rátok nézek, modern Windows, Mac és Linux) elfelejtenek erről. Számomra fontos, hogy például egy internetkávézóba mehessek, letölthessem a szoftvert egy adathordozóra, beletehessem ezt az adathordozót a saját számítógépembe, és biztos lehessek benne, hogy minden rendben működik [kockázatos fickó, ilyet csinálni Windows-on... — a fordító megjegyzése].
Ennek eredményeként kissé gyakrabban, mint mindig, általában elégedetlenséget tapasztalok a Windows és Linux rendszereken.
Mac-en ez általában egy fájl, amit le kell tölteni .dmg. Legtöbbször nincsenek függőségei, kivéve azokat, amelyeket a MacOS alapértelmezetten biztosít. Kivételt jelenthetnek az összetett alkalmazások, amelyeknek megfelelő futtatókörnyezetük szükséges, például Java.
A Haikun csomag letöltése .hpkg például a Java-hoz ugyanis nem biztos, hogy elegendő, mivel a Java lehet jelen vagy hiányozhat a célgépen. Van-e mód a csomaghoz tartozó összes függőség letöltésére .hpkg, azokat leszámítva, amelyeket a Haiku alapértelmezetten telepít, és ezért minden Haiku rendszerben jelen kell lennie?
Ebben a kategóriában kismértékű előnnyel a Mac győz.
Megjegyzi mr. waddlesplash:
Ahhoz, hogy írhassak egy programot, amely összegyűjti az alkalmazás összes függőségét csomagok sorozataként
.hpkgbárki számára, aki ismeri a Haiku belső felépítését, körülbelül 15 perc elegendő. A támogatás hozzáadása nem annyira bonyolult, ha valóban szükség van rá. De számomra ez ritka eset.
Tartsuk vissza a lélegzetünket a következő cikkig ebben a ciklusban.
Csomagok áthelyezése elkülönített helyre
Ahogyan korábban írtam, szeretném elhelyezni a csomagjaimat .hpkg (nos, vagy egy részét) egy különleges helyen, elkülönítve a normál telepítéstől a rendszerindító kötetben (root partíció). A normál esetekben (ami nem annyira elméleti) az oka az, hogy folyamatosan elfogy a szabad hely az (integrált) lemezeimen, mindegy, mennyire nagyok. Általában külső lemezeket vagy hálózati forrásokat csatlakoztatok, ahol az alkalmazásaim találhatók.
Mac-en egyszerűen áthelyezem a csomagokat .app külső meghajtóra vagy hálózati mappába a Finderben, és ezzel vége is. Még mindig kétszer kattintva meg tudom nyitni az alkalmazást, ahogyan azt a rendszerindító kötetből szoktam. Egyszerű!
A Haikun, ahogyan mondták, ezt el lehet érni azáltal, hogy áthelyezem a .hpkg csomagjaimat külső meghajtóra vagy hálózati mappába, de aztán néhány nem dokumentált parancsot kell használni a konzolban, hogy a rendszerben beszereljem őket. Nem tudom, hogyan kell ezt megtenni, csak a GUI használatával.
Ebben a kategóriában a Mac nyer.
Mr. waddlesplash szerint:
Itt a megszokott használatra optimalizálás történik. Ha viszont nagyobb kereslet jelentkezik, mint egy felhasználónál, akkor ezt megvalósítjuk. Mindenesetre van lehetőség harmadik fél által történő megvalósításra.
Erről a következő cikkben beszélünk.
Ha a hálózati mappákról beszélünk: csodálatos lenne (gondolom LAN bulik esetén) egyszerű, felfedezhető, közönséges hálózati alkalmazásokat (például Zeroconf alatt), amelyeket a helyi számítógépre lehet másolni vagy azonnal elindítani a helyi hálózatból. Természetesen a fejlesztők számára van lehetőség a visszautasításra. app_flags.
A hpkg rendszer GUI-val való integrációs jelentése.
Azt hiszem, hogy elsősorban a viszonylagos újdonságnak köszönhetően az integráció .hpkg a GUI-val még mindig hagy kívánnivalót maga után. Egy esetben van néhány dolog, amit lehetne javítani a UX terén...
Még egy dolog: Kernel Debug Land.
Kiváló lenne kernel panic alatt parancsokat beírni, például syslog | grep usb.Nos, a Haikuban ez lehetséges a Kernel Debug Land segítségével. Hogyan is lehet ezt a varázslatot látni, ha minden jól működik anélkül, hogy kernel panicbe kerülnél? Könnyen, az Alt+PrintScn+D megnyomásával (mnemonika Debug). Azonnal eszembe jut a amely lehetővé tette az eredeti Macintosh fejlesztők számára, hogy bejussanak a hibakeresőbe (ha az telepítve volt, természetesen).
Zárás
Kezdem megérteni, hogy a Haiku rendszer kifinomultsága abból fakad, hogy egy kis csapat dolgozik, pontosan a munkakörnyezetre orientálódva, a rendszer minden szintjének elérhetőségével.
Éles kontraszt a Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu világával, ahol minden annyira fel van darabolva, hogy az absztrakció az absztrakción ül, és gerendákkal hajtják.
Arra is ráeszméltem, hogy a rendszer .hpkg a hagyományos csomagkezelők, Snappy, Flatpak, AppImage, sőt btrfs legjobb gyakorlatait ötvözi, és keveri őket a Mac „egyszerűen működik” elvével.
Mintha valami „átkapcsolódott” volna a fejemben, és rájöttem, hogyan működik a rendszer .hpkg visszaállítás, — csak ránézve. De nem én vagyok, hanem a rendszer szépsége és egyszerűsége. Itt sok minden az eredeti Mac szellemiségét sugallja.
Igen, a böngészőben történő lapozás lehet akadozó és csigatempó, az alkalmazások hiányozhatnak (nincs Gtk, Electron — a fejlesztők arra a következtetésre jutottak, hogy rosszul illeszkednek a kifinomultsághoz), a videók és 3D gyorsítása pedig teljesen hiányozhat, de mégis szeretem ezt a rendszert. Végül is ezek a dolgok orvosolhatók, és előbb vagy utóbb meg fognak jelenni. Csak idő kérdése, és esetleg egy kis vörös szem.
Nem tudok segítséget ajánlani, de úgy gondolom, hogy ettől a pillanattól kezdve megkezdődik az év Haiku a táblagépen.
Véletlenszerű problémák
Lehet, hogy már vannak kérelmek, vagy nekem kell nyitnom őket?
- A BeScreenCapture-nek lehetőséget kellene adnia GIF-be exportálásra, mint a Peek. Ezt meg lehet csinálni ffmpeg segítségével, ami már elérhető Haiku alatt. .
- A képernyőképkészítő program nem tudja rögzíteni a modal ablakokat, helyette az egész képernyőt végzi el
- A WonderBrush vágóeszközével nem lehet levágni a képernyőképeket, majd elmenteni az eredményt fájlba
- Nem különösebben tetszik a Haiku-ban a kézkurzor, de gondolom, hogy ennek a meleg nosztalgikus érzésekhez van köze. Különösen zavaró a kritában a vágóeszköz használatakor, mivel pontatlan vágást eredményez (lásd a modal párbeszédablakok képernyőképeit ebben a cikkben). A keresztezett kurzor csodálatos lenne. .
Próbáld ki te is! A Haiku projekt DVD- vagy USB-ről letölthető képeket biztosít, amelyek . A telepítéshez elegendő letölteni a képet és felírni egy pendrive-ra a
Kérdéseid vannak? Meghívunk a magyar nyelvű .
Hibák áttekintése:
Től fordítása: ez a hatodik cikk a Haiku-ról szóló ciklusban.
Cikkek listája:
Forrás: habr.com
