TL;DR: Haiku — et operativsystem, specielt designet til pc'er, hvilket betyder, at det har flere tricks, der gør arbejdsomgivelserne meget bedre end andre. Men hvordan fungerer det?
opdagede jeg Haiku, en overraskende god platform. Jeg er stadig imponeret over, hvor glat det fungerer, især sammenlignet med arbejdsomgivelserne på Linux. I dag vil jeg kigge under motorhjelmen. Hvor det er nødvendigt for en dybere forståelse, vil jeg lave sammenligninger med den originale Macintosh, Mac OS X og Linux arbejdsomgivelser (standard XDG fra freedesktop.org).
Ressourcer i ELF-filer
I går fandt jeg ud af, at IconOMatic kan gemme ikoner i rdef ressourcer i ELF eksekverbare filer. I dag vil jeg se, hvordan det egentlig fungerer.
Ressourcer? fra , den oprindelige skaber af Macintosh Finder og 'faderen' til Macintosh Resource Manager:
Jeg er bekymret over den stive natur af traditionel kodning. For mig er selve ideen om en applikation, fastfrosset i kode uden mulighed for dynamisk at ændre noget — absurd. Der skal være mulighed for at ændre så meget som muligt i runtime. Naturligvis kan selve applikationskoden ikke ændres, men er der ikke noget, man kan ændre uden at genkompilere koden?
På den originale Macintosh sørgede man for, at disse filer har en 'datasektion' og en 'ressourcesektion', hvilket gjorde det usædvanligt nemt at gemme forskellige elementer, såsom ikoner, oversættelser osv. i de eksekverbare filer.
På Mac bruges , et grafisk program til — uventet — redigering af ressourcer.
ResEdit på den originale Macintosh
Resulterede i, at det blev muligt at redigere ikoner, menupunkter, oversættelser osv. relativt let, men de 'rejser' stadig med applikationerne.
Uanset hvad havde denne tilgang en stor ulempe: den fungerede kun på Apples filsystemer, hvilket blev en af grundene til, at Apple opgav 'ressourcesektionen', da de skiftede til Mac OS X.
På Mac OS X ønskede Apple en løsning, der var uafhængig af filsystemet, så de benyttede konceptet med pakker (fra NeXT), kataloger, der behandles af filhåndtereren som 'uforlignelige objekter', ligesom filer i stedet for kataloger. Hver pakke med en applikation i .app format indeholder blandt andet en fil Info.plist (i et form for JSON eller YAML fra Apple), der indeholder metadata for applikationen.
Nøglerne i Info.plist-filen fra Mac OS X-applikationspakken.
Ressourcer såsom ikoner, UI-filer og andet opbevares i pakken som filer. Konceptet er faktisk gået tilbage til rødderne i NeXT.
Mathematica.app på NeXTSTEP 1.0 i 1989: vises som en mappe med filer i terminalen, men som et enkelt objekt i den grafiske filhåndter.
Lad os gå tilbage til BeOS, hvis koncepter Haiku bygger på. Dens udviklere besluttede ved overgangen fra PEF (PowerPC) til ELF (x86) (den samme, der anvendes på Linux) at tilføje en ressource-sektion i slutningen af ELF-filerne. Der blev ikke brugt nogen passende ELF-sektion, den blev blot tilføjet i slutningen af ELF-filen. Som resultat blev programmerne strip og andre fra binutils, der ikke kender til dette, blot skåret den væk. Derfor, når man tilføjer ressourcer i ELF-filen på BeOS, er det bedre ikke at arbejde med den ved hjælp af Linux-værktøjer.
Hvad sker der nu med Haiku? I princippet er det mere eller mindre det samme.
I teorien kunne man sætte ressourcer i den relevante ELF-sektion. Ifølge udviklerne på kanalen #haiku i irc.freenode.net:
Med ELF ville sektionen give mere mening ... den eneste grund til, at vi ikke gør det, er, at det blev gjort i BeOS.
Og det er ikke værd at ændre det nu.
Ressourcestyring
Ressourcer skrives i et struktureret 'ressource'-format: det er i bund og grund en liste over ressourcer med størrelser og derefter deres indhold. Jeg kom til at tænke på .
Hvordan kan man tjekke ressourcer i Haiku? Findes der noget som ResEdit?
Ifølge :
For at se de ressourcer, der leveres i applikationspakken, kan du trække den eksekverbare fil over i et program som Du kan også åbne terminalen og køre kommandoen
listres fil_navn..
Resourcer findes i HaikuDepot, men den crasher bare for mig.
Hvordan kan man administrere ressourcer i ELF-filer? Ved at bruge rsrc. og rdef.. rdef. Filerne samles i rsrc.. Filen rdef. opbevares i et almindeligt tekstformat, så det er meget lettere at arbejde med. Filen i formatet rsrc. tilføjes i slutningen af ELF-filen. Lad os prøve at lege:
~> rc -h
Haiku Resource Compiler 1.1For at kompilere et rdef-script til en ressourcefil:
rc [options] [-o ] ...For at konvertere en ressourcefil tilbage til et rdef-script:
rc [options] [-o ] -d ...Options:
-d --decompile opret et rdef-script ud fra en ressourcefil
--auto-names konstruer ressourcenavne ud fra ID-symboler
-h --help vis denne meddelelse
-I --include tilføj til listen over inkluderede stier
-m --merge slet ikke eksisterende indhold i outputfilen
-o --output angiv outputfilens navn, standard er out.xxx
-q --quiet udskriv ikke fejlmeddelelser
-V --version vis softwareversion og licens.Man kan bruge programmet xres. til kontrol og administration:
/> 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, lad os prøve?
/> 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_VERSIONMere om ressourcer og format rdef. kan læses .
Standardtyper af ressourcer
Selvom man kan placere hvad som helst i ressourcerne, er der nogle bestemte standardtyper:
app_signature: MIME-typen for applikationen, til at matche åbne filer, kørsel, IPC osv.app_name_catalog_entry: Da applikationsnavnet normalt er på engelsk, kan man her angive steder, hvor de oversatte navne er gemt, så brugere på forskellige sprog kan se det oversatte applikationsnavn, hvis de ønsker det.app_version: præcis det, du tænkerapp_flags: angiverregistrarhvordan applikationen skal behandles. Jeg tror, der er mere, end det ser ud til ved første øjekast. For eksempel er derB_SINGLE_LAUNCH, som får systemet til at starte en ny proces af applikationen hver gang, brugeren anmoder om det (den samme princip anvendes for de fleste applikationer på Linux). Der erB_MULTIPLE_LAUNCH, der får en proces til at blive startet for hver fil. Endelig er derB_EXCLUSIVE_LAUNCH, som får systemet til kun at starte én proces ad gangen, uanset hvor ofte brugerne starter den (for eksempel starter Firefox på Linux på samme måde; samme resultat kan opnås i Qt-applikationer ved at bruge funktionen ). Applikationer medB_EXCLUSIVE_LAUNCHbliver informeret, når brugeren prøver at starte dem igen: for eksempel modtager de den filsti, som brugeren ønsker at åbne med dem.vector_icon: Vektorikonet for applikationen (I BeOS var der ingen vektorikoner, de fleste applikationer havde i stedet to rasterikoner i de eksekverbare filer).
Selvfølgelig kan man tilføje ressourcer med vilkårlige ID'er og typer, hvorefter man kan læse dem i applikationen eller andre applikationer ved hjælp af klassen BResources. Men lad os først stoppe ved det spændende emne ikoner.
Vektorikoner i Haiku-stil
Selvfølgelig valgte ikke kun Haiku det bedste ikonformat, i dette aspekt er situationen i Linux-miljøer langt fra ideel:
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.cacheAt se sådan noget gør allerede, at man kan føle, hvad dette stykke er.
Selvfølgelig er der scalable vektorgrafik, som man kan forstå. Men hvorfor er der så noget andet? Fordi resultatet af vektorgrafikens gengivelse i små størrelser kan være værre end ideelt. Man ønsker at have forskellige versioner, optimeret til forskellige størrelser. I Linux-miljøer opnås dette ved at sprede ikoner med forskellige størrelser over filsystemet.
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.pngBemærk: der findes ikke forskellige versioner af Firefox. Derfor kan man ikke detaljeret behandle situationen med tilstedeværelsen af flere versioner af applikationen i systemet.
Forskjellige ikoner til Firefox i forskellige versioner. Indtil videre er det ikke muligt at håndtere dette i Linux uden forskellige klude.
Mac OS X håndterer det lidt mere raffineret:
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.icnsMan kan se, at der er én fil firefox.icns i pakken Firefox.app, som indeholder alle størrelser, således at forskellige versioner af den samme applikation har forskellige ikoner.
Meget bedre! Ikonerne rejser sammen med applikationen, alle ressourcer i én fil.
Lad os vende tilbage til Haiku. En fantastisk løsning, uden undtagelser. Ifølge :
Der er udviklet et særligt højoptimeret format til små størrelser og hurtig gengivelse, HVIF. Derfor er vores ikoner for det meste meget mindre end i raster- eller den udbredte SVG-format.
Og de er faktisk optimeret:
Ikonstørrelser i HVIF sammenlignet med andre formater.
Forskellen er ti gange!
Men magien stopper ikke her. Den samme HVIF kan vise forskellige detailniveauer afhængigt af den visuelle størrelse, selvom det er et vektorgrafikformat.
Forskellige niveauer af detaljer (LOD) afhængigt af størrelsen på gengivelsen
Nu til ulemperne: Du kan ikke bare tage SVG, smide det ind i ImageMagick og være færdig; du skal igennem flere cyklusser for at skabe et ikon i HVIF-format. forklaringer. Men IconOMatic kan ret ufuldkommen importere SVG; cirka 90% af detaljerne i SVG importeres med en vis sandsynlighed, mens de resterende 10% skal justeres og ændres manuelt. Læs mere om, hvordan HVIF gør sin magi i bloggen
Tilføjelse af ikon til applikationen
Nu kan jeg tilføje et ikon til pakken, der blev oprettet , med tanke på al den information, der er modtaget.
Men da jeg lige nu ikke har lyst til at tegne mit eget ikon til min "Hej, Verden" QtQuickApp - så trækker jeg det fra 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 CreatorLad os tjekke, om ikonet er kopieret:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONDet ser godt ud, men hvorfor vises det nye ikon ikke, når det er kopieret?
Det kopierede VICN:101:BEOS:ICONs bruges ikke endnu som ikon for applikationen i filhåndteringen.
Hvad har jeg overset?
Udviklerens kommentar:
Vi skal oprette en fil
rdef.med alle ressourcer, og derefter udføre kommandoenrc navn.rdef, dette vil skabe en fil.rsrc. Så skal vi udføre kommandoenresattr -o navn_binære navn.rsrc. I det mindste bruger jeg sådanne kommandoer til at tilføje ikoner til mine scripts.
Nå, jeg ønskede at oprette en ressource, ikke en attribut. Jeg er helt forvirret.
Intelligent caching ved hjælp af filsystemet.
Åbning og læsning af ELF-attributter er langsomt. Som jeg har nævnt tidligere, skrives ikonet som en ressource i selve filen. Denne metode er mere pålidelig og klarer kopiering til et andet filsystem. Men derefter kopieres det også til attributten af filsystemet, for eksempel BEOS:ICON. Dette fungerer kun på bestemte filsystemer, for eksempel BFS. Ikoner, der vises af systemet (i Tracker og Deskbar), læses fra denne udvidede attribut, fordi en sådan løsning fungerer hurtigt. I nogle tilfælde (hvor hastighed ikke er vigtig, for eksempel i den typiske "Om programmet"-vinduet) får systemet ikonet direkte fra ressourcen i filen. Men det er ikke slutningen. Husk, på Mac kunne brugerne erstatte ikoner for applikationer, mapper, dokumenter med deres egne, da Mac har mulighed for at udføre disse "vigtige" ting, for eksempel . På Haiku skal ressourcen (i filen) betragtes som det oprindelige ikon, der leveres med applikationen, og attributten (i BFS-filsystemet) som noget, der gør det muligt for brugeren at foretage ændringer efter eget valg (selvom en tip, grafisk grænseflade til indsættelse af brugerdefinerede ikoner over standardikonet endnu ikke er implementeret).
Kontrol af filsystemattributter
Ved hjælp af resaddr er muligheden for at kontrollere og indstille filsystemattributter.
/> 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.
(...)Det er i bund og grund en "klæbrighed", der udfører omdannelsen frem og tilbage mellem (pålidelige) ressourcer og (hurtige) filsystemattributter. Og da systemet foreslår at hente ressourcer og automatisk håndterer kopieringen, vil jeg ikke bekymre mig mere om det.
Magien ved hpkg-pakker
I øjeblikket bruges pakker oftest til at hente programmer på Haiku .hpkg. Lad dig ikke narre af det enkle navn: .hpkg-formatet fungerer helt anderledes end andre formater med lignende navne, som du har været stødt på, da det har reelle superkræfter.
Jeg har længe været frustreret over det faktum, at med traditionelle pakkeformater downloader du én (pakke), men der installeres noget andet (filerne inde i pakken) i systemet. Det er ret svært at håndtere filer (for eksempel at slette dem), når installationen af pakken sker på den traditionelle måde. Og det er fordi indholdet af pakken spredes over hele filsystemet, inklusive steder, hvor den almindelige bruger muligvis ikke har skriveadgang. Dette skaber en hel klasse af programmer — pakkehåndterere. At flytte installeret software, for eksempel til en anden maskine, et eksternt drev eller en filserver, bliver endnu sværere eller endda umuligt. I et typisk Linux-baseret system kan der nemt eksistere alt fra flere hundrede tusinde til millioner af adskilte filer. Det er indlysende både skrøbeligt og langsomt, for eksempel ved den indledende installation af systemet, ved installation, opdatering og fjernelse af almindelige pakker, samt ved kopiering af det bootbare volumen (rodpartitionen) til et andet medium.
Jeg arbejder på AppImage-projektet, en delvis løsning for programmer til slutbrugere. Dette er et distributionsformat for software, der samler applikationen og alle dens afhængigheder i et enkelt filsystembillede, der monteres ved opstart af applikationen. Det gør tingene betydeligt lettere, da det samme ImageMagick pludselig bliver til én fil, der kan håndteres i filhåndtereren af almindelige brugere. Den foreslåede metode fungerer kun for software, som navnet på projektet afspejler, og har også sit eget sæt udfordringer, da dem der arbejder med softwareleverancer til Linux altid skyder skylden på mig.
Lad os vende tilbage til Haiku. Er det lykkedes at finde den optimale balance mellem traditionelle paketsystemer og softwarelevering baseret på billeder? Dens pakker .hpkg er faktisk komprimerede billeder af filsystemet. Når systemet bootes, montering kernen alle installerede og aktive pakker med de følgende kerne-meldinger:
KERN: package_daemon [16042853: 924] aktiv pakke: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023: 924] aktiv pakke: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232: 924] aktiv pakke: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405: 924] aktiv pakke: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611: 924] aktiv pakke: "llvm_libs-5.0.0-3-x86_64.hpkg"Cool, ikke? Hold fast, det bliver endnu bedre!
Der er en meget speciel pakke:
KERN: package_daemon [16040020: 924] aktiv pakke: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Den indeholder et ret minimalistisk operativsystem, inklusive kernen. Tro det eller ej, men selv kernen bliver ikke udtrukket fra bootvolumen (rodspartitionen), men bliver omhyggeligt indlæst på sin plads fra pakken .hpkg. Wow! Jeg har allerede nævnt, at jeg mener, at en del af den overordnede raffinement og sammenhæng i Haiku skyldes, at hele systemet fra kernen og det grundlæggende brugerområde samt til pakkehåndtering og infrastruktur til arbejdsomgivelser udvikles af et enkelt team. Forestil dig, hvor mange forskellige grupper og teams der kræves for at få noget sådan til at fungere på Linux [jeg forestiller mig PuppyLinux-projektet, - oversætterens bemærkning]. Så forestil dig, hvor lang tid det ville tage at implementere denne tilgang i distributionerne. Man siger jo: Tag en simpel opgave, del den mellem forskellige udbydere, og den bliver så kompliceret, at den ikke længere kan løses. Haiku har åbnet mine øjne i denne henseende. Jeg tror, det er præcis det, der sker på Linux nu (Linux i denne forbindelse er et samlebetegnelse for Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).
Systemrollback ved hjælp af hpkg
Hvor ofte er følgende situation: opdateringen er gået godt, og så viser det sig, at noget ikke fungerer som det skal? Ved at bruge almindelige pakkeadministratorer er det svært at gendanne systemets tilstand til det tidspunkt, før nye pakker blev installeret (for eksempel når noget går galt). Nogle systemer tilbyder omveje i form af snapshots af filsystemet, men de er ret besværlige og anvendes langt fra i alle systemer. I Haiku er dette løst med pakker. .hpkg. Hver gang pakker ændres i systemet, bliver de gamle pakker ikke slettet, men gemt i underkataloger af typen. /Haiku/system/packages/administrative/state-<...>/ kontinuerligt. Uafsluttede operationer gemmer deres data i underkataloger. /Haiku/system/packages/administrative/transaction-<...>/.
Indhold. /Haiku/system/packages/administrative. Katalogerne "state..." indeholder tekstfiler med navne på aktive pakker, "transaction..." - selve pakkerne.
"Gammelt aktivt estado", dvs. listen .hpkg over pakker, der var aktive før ændringerne, skrives efter hver operation i filhåndtereren i en tekstfil. /Haiku/system/packages/administrative/state-<...>/activated-packages. Ligeså skrives det nye "aktive estado" i en tekstfil. /Haiku/system/packages/administrative/activated-packages.
Mappe /Haiku/system/packages/administrative/state-<...>/ indeholder kun en tekstfil med listen over aktive pakker i denne tilstand (hvis pakker blev installeret uden at slette), og hvis pakker blev slettet eller opdateret - indeholder state-kataloget de gamle versioner af pakkerne.
Ved systemopstart tages beslutningen om aktivering (montering) af pakker baseret på listen over pakker. Så simpelt er det! Hvis noget går galt ved opstart, kan man instruere bootloaderen om at bruge en anden, ældre liste. Problemet er løst!
Haiku bootloader. Hver indgangspunkt afspejler det tilsvarende "aktive estado".
Jeg kan godt lide tilgangen med enkle tekstfiler som liste over "aktiv estado", hvor forståelige navne er skrevet. .hpkg. Dette står i skarp kontrast til den maskineskabte rod. af OSTree eller Flatpak i filsystemet (på samme niveau som Microsoft GUID).
Listen over aktive pakker for ethvert tidspunkt.
Konfigurationsdata.
Det ser ud til, at katalogen /Haiku/system/packages/administrative/writable-files indeholder indstillingsfiler for pakker, men tilgængelige til skrivning. For som du husker, .hpkg bliver de kun monteret til læsning. Derfor skal disse filer kopieres fra pakkerne før skrivning. Det giver mening.
GUI-integration til systemet .hpkg.
Lad os nu se på, hvordan disse fremragende pakker .hpkg håndterer integrationen i det brugervenlige arbejdsområde (UX). For Haiku er jo designet til personlig brug, trods alt. Jeg har personligt sat baren højt ved at sammenligne brugeroplevelsen med pakker .app på Macintosh med den samme oplevelse på .hpkg. Jeg vil ikke engang sammenligne situationen med arbejdsområder på Linux, for den er helt uacceptabel i forhold til alle andre.
Følgende scenarier kommer til at tænke på:
- Jeg vil se indholdet af pakken
.hpkg - Jeg vil installere pakken
- Jeg vil fjerne pakken
- Jeg vil fjerne noget, der kom ind i systemet som en del af pakken
- Jeg vil kopiere noget, der kom ind i systemet som en del af pakken
- Jeg vil downloade alle afhængighederne for pakken, som ikke kan være en del af hver Haiku-installation (for eksempel har jeg en fysisk isoleret maskine uden internetadgang).
- Jeg vil flytte mine pakker (eller en del af dem) til et andet sted, adskilt fra boot-drevet (rodpartitionen) (fordi jeg for eksempel har pladsmangel på det).
Dette burde dække de fleste grundlæggende tilfælde fra min dagligdag. Nå, lad os komme i gang.
Kontrol af pakkeindhold
På Mac højreklikker jeg blot på pakken for at åbne den og se indholdet i Finder. Det er jo i virkeligheden bare et maskeret katalog! (Jeg ved, at der er pakker .pkg for systemdelen, der ikke er applikationer, men almindelige brugere interagerer sjældent med dem).
På Haiku højreklikker jeg på pakken, og klikker derefter på 'Contents' for at se, hvad der er indeni. Men her er det blot en liste over filer uden mulighed for at åbne dem med dobbeltklik.
Det ville være meget bedre, hvis der var en (midlertidig) måde at montere pakken på .hpkg for at se den gennem filhåndtereren, og brugeren ikke skulle bekymre sig om implementeringsdetaljerne. (For resten kan du åbne .hpkg pakken i Expander, som kan pakke den ud ligesom enhver anden arkiv).
I HaikuDepot-grænsefladen kan man se listen over filer i pakken, men der er ingen måde at se indholdet, for eksempel ved at dobbeltklikke på README.md
I denne kategori vinder Mac, men tilføjelsen af den nødvendige funktionalitet til HaikuDepot burde ikke være særlig vanskelig.
Installation af pakken via GUI
På Mac, de fleste diskbilleder .dmg indeholder pakker .app. Åbner diskbilledet med et dobbeltklik, hvorefter vi kopierer pakken, for eksempel ved at trække den til /Applications Finder. For mig er det helt naturligt, men jeg har hørt, at nogle nybegyndere kan have svært ved det. Som standard 'foreslår' Apple et systemkatalog /Applications (på NeXT var det netværk, samt individuelt), men man kan nemt placere sine applikationer på en filserver eller i en undermappe $HOME/Applications, hvis det er det, du ønsker.
På Haiku, dobbeltklik på pakken, derefter klik på 'Installer', nemmere kan det ikke være. Jeg er nysgerrig på, hvad der sker, hvis pakken har afhængigheder, der er tilgængelige i HaikuPorts, men endnu ikke installeret. I Linux ved de faktisk ikke, hvad de skal gøre i denne situation, men løsningen er tydelig — spørg brugeren, om de ønsker at downloade og installere afhængighederne. Præcis det, som Haiku gør.
Jeg downloadede pakken ‘sanity’ manuelt og klikkede på den, pakkeadministratoren ved, hvor den skal hente dens afhængigheder (forudsat at repositoryerne allerede er skrevet ind i systemet). Ikke alle Linux-distributioner kan det.
Endnu en metode er at bruge filhåndtereren, det er tilstrækkeligt at trække .hpkg pakken til /Haiku/system/packages (for systeminstallation, som standard), eller til /Haiku/home/config/packages (for individuel installation; ikke tilgængelig ved dobbeltklik — det irriterer mig stadig, at ordet ‘config’ er her, som i denne sammenhæng er en synomym for ‘indstillinger’). Men konceptet med flere brugere er endnu ikke tilgængeligt for Haiku (måske derfor er alt så enkelt — jeg ved ikke, måske vil multi-brugerfunktioner komplicere tingene for et desktop-miljø).
I denne kategori vinder Haiku, fordi det kan arbejde ikke kun med applikationer, men også med systemprogrammer.
Fjernelse af pakken fra GUI
På Mac, du skal trække appens ikon til papirkurven, og så er det det. Let!
På Haiku, først skal du finde ud af, hvor pakken er placeret i systemet, for det er sjældent, at du installerer den, hvor den skal hen (det hele håndteres af systemet). Som regel skal man søge i /Haiku/system/packages (ved systeminstallation som standard), eller i /Haiku/home/config/packages (jeg har allerede nævnt, at ‘config’ er et forkert navn?). Derefter trækkes programmet simpelthen til papirkurven, og så er det det.
Let! Men jeg ville ikke sige det. Her er, hvad der virkelig sker:
Sådan ser det ud, hvis man trækker en app ind i papirkurven fra /Haiku/system/packages
Jeg prøvede blot at flytte min app 'Hej, Verden' fra i går til papirkurven i QtQuickApp. Jeg forsøgte ikke at flytte systemkataloget, og da alle pakker installeres i systemkataloget - det er umuligt at slette pakken .hpkg uden at ændre «dens indhold». En almindelig bruger ville blive skræmt og trykke på knappen «Annuller», der er indstillet som standard.
Forklarer :
Denne besked er mere end 10 år gammel. Vi skal nok justere den, så advarslen kun vises, når man flytter selve pakken. Almindelige brugere har ikke brug for at gøre det i hvert fald.
Okay, måske skal jeg gøre det ved at bruge HaikuDepot? Jeg dobbeltklikker på pakken i /Haiku/system/packages, og venter på, at knappen «Afinstaller» dukker op. Nej, der er kun «Installer». «Afinstaller», hvor er du?
For sjov prøvede jeg at se, hvad der sker, hvis jeg trykker på «Installer» for en allerede installeret pakke. Det ser sådan ud:
Sådan ser det ud, hvis du prøver at installere en allerede installeret pakke.
Derefter vises:
Hvis jeg trykker på «Anvend ændringer» i det foregående vindue - så bliver det sådan her
Jeg antager, at dette er en softwarefejl, en reference til en anmodning er allerede der. [forfatteren har ikke givet et link, — bem. oversætter]
Hurtig løsning: Tilføj knappen «Afinstaller», hvis pakken allerede er i
/Haiku/system/packages, eller i/Haiku/home/config/packages.
Når jeg ser på listen over pakker installeret i HaikuDepot, ser jeg min pakke på listen og kan slette den.
I denne kategori vinder Mac. Men jeg kan forestille mig, at brugeroplevelsen på Haiku kan være bedre end på Mac, hvis den bliver konfigureret ordentligt. (En af udviklerne vurderede det sådan: «Mindre end en time for at tilføje den angivne funktionalitet til HaikuDepot, hvis du kender lidt til C++», er der frivillige?)
At fjerne noget fra pakken
Lad os prøve at slette selve appen, ikke pakken .hpkg, som den kom fra (jeg tvivler på, at «almindelige dødelige» kan mærke nogen forskel).
På Mac, brugeren arbejder faktisk normalt med filen .dmg, hvor applikationens paket stammer fra .app. Normalt opbevares billeder .dmg i downloads mappen, mens pakker kopieres af brugeren ind i /Applications. Der er en opfattelse af, at mange brugere ikke selv ved, hvad de laver; denne hypotese bekræftes af en tidligere ansat fra Apple. (En af de ting, jeg ikke kan lide ved Mac. For eksempel er der ingen forskel mellem en applikation og pakken, som den kom i, med AppImage. Træk ikonet til skraldespanden = det er det. Nemt!)
På Haiku, der er også en opdeling mellem apps/ og pakker/, så jeg tvivler på, at brugerne har fået mere klarhed. Men hvad sker der, hvis man trækker en applikation fra apps/ til skraldespanden:
Her er hvad der sker, når man forsøger at slette en applikation hentet fra filen .hpkg
Teknisk set er det korrekt (da applikationen først og fremmest er placeret på et skrivebeskyttet filsystem), men det er ikke særlig nyttigt for brugeren.
Hurtig løsning: I stedet foreslå at slette via GUI
.hpkg
For sjov forsøgte jeg at duplikere applikationen ved at trykke på Alt+D. Jeg fik en meddelelse: «Kan ikke flytte eller kopiere objekter på et skrivebeskyttet drev». Og det skyldes, at /system (udover /system/packages og /system/settings) er monteringspunktet for packagefs (husker du, hvordan det vises i output df?). К сожалению, вывод команды mount giver ikke klarhed (som nævnt i en af de tidligere artikler), mountvolume viser ikke det ønskede (tilsyneladende er pakker monteret via loop .hpkg ikke betragtes som “drev”), og jeg glemte også de alternative kommandoer.
I denne kategori har ingen vundet, undtagen AppImage (men det er, hvis jeg skal være helt ærlig, en forudindtaget mening). Men man kan forestille sig, at brugeroplevelsen på Haiku vil være bedre end på Mac efter tilpasning.
Bemærkning: Det skal afklares, hvad 'drev' er i forhold til 'partition'. Det er sandsynligvis relateret til forholdet 'mappe' til 'katalog': de fleste kataloger vises i filhåndtereren som mapper, men ikke alle (f.eks. pakker, der behandles som filer). Gør sådanne udtalelser mig officielt til en nørd?
At kopiere indholdet af en pakke til et andet system
På Mac, jeg trækker blot pakken .app, og da afhængighederne inden i pakken flyttes med.
På Haiku, jeg trækker applikationen, men afhængighederne håndteres slet ikke.
Hurtig løsning: Lad det i stedet foreslås at trække pakken '`.hpkg' helt, sammen med afhængighederne, hvis de er til stede.
I denne kategori vinder Mac helt klart. I det mindste for mig, der elsker deres paradigm. .hpkg i stedet for applikationen, men systemet tilbyder mig ikke sådan en…
Hentning af pakken med alle dens afhængigheder
Ikke hver maskine er konstant tilsluttet nettet. Tværtimod glemmer nogle maskiner (ja, jeg taler til dig, moderne Windows, Mac og Linux) dette. For mig er det vigtigt, at jeg kan tage til et internetcafé, downloade software til et USB-drev, indsætte det i min hjemmecomputer og være sikker på, at det hele fungerer [vovemænd, der gør det på Windows… — bemærk fra oversætteren].
Som et resultat får jeg lidt oftere end altid utilfredse afhængigheder på Windows og Linux.
På Mac det er som regel en enkelt fil, alt hvad der kræves — at hente .dmg. Ofte har den ingen afhængigheder, bortset fra dem, der leveres som standard af MacOS. Et undtagelse kunne være komplekse applikationer, der kræver et specifikt køremiljø, f.eks. java.
På Haiku hent pakken .hpkg for f.eks. den samme applikation i java kan være utilstrækkelig, da java kan være til stede eller ikke på den målmaskine. Er der en måde at hente alle afhængighederne for denne pakke .hpkg, bortset fra dem der er installeret i Haiku som standard, og som derfor burde være i hvert Haiku-system?
I denne kategori vinder Mac klart.
Kommenterer mr. waddlesplash:
For at skrive et program til at samle alle afhængigheder af en applikation i form af et sæt pakker
.hpkgfor nogen, der er bekendt med Haikus indre funktioner, tager det cirka 15 minutter. At tilføje support til dette er ikke så kompliceret, hvis der er et reelt behov. Men for mig er dette en sjælden situation.
Lad os holde vejret indtil næste artikel i denne cyklus.
Flytning af pakker til et adskilt sted
Som jeg tidligere har nævnt, vil jeg placere mine pakker .hpkg (nå, eller en del af dem) på et specifikt sted, adskilt fra den almindelige placering på opstartsdrevet (rodpartitionen). I det normale tilfælde (som ikke er så teoretisk) er årsagen, at jeg konstant løber tør for ledig plads på mine (indre) diske, uanset hvor store de er. Og jeg tilslutter ofte eksterne diske eller netværksressourcer, hvor mine applikationer ligger.
På Mac jeg flytter blot pakkerne .app til en ekstern harddisk eller netværksmappe i Finder, og det er det. Jeg kan stadig åbne programmet ved dobbeltklik, som jeg plejede at gøre med den bootbare volumen. Dette er enkelt!
På Haiku, som jeg fik at vide, kan dette opnås ved at flytte mine .hpkg pakker til en ekstern harddisk eller netværksmappe, men så skal jeg bruge nogle uofficielle kommandoer i terminalen for at montere dem i systemet. Jeg ved ikke, hvordan man gør det kun ved hjælp af GUI.
Denne kategori vindes af Mac.
Ifølge hr. waddlesplash:
Her er optimering baseret på almindelig brug. Hvis der er større efterspørgsel end én bruger, vil vi implementere det. Uanset hvad er der mulighed for tredjepartsimplementering.
Det vil vi fortælle om i næste artikel.
Når det kommer til netværksmapper: det ville være dejligt (antager LAN-fester) at have enkle, opdagelige, netværksbaserede applikationer (f.eks. via Zeroconf), som man kan kopiere til den lokale computer eller køre direkte fra det lokale netværk. Selvfølgelig har udviklerne mulighed for at afvise det via app_flags.
Den endelige rapport om integration af systemet hpkg med GUI
Jeg tror, at det først og fremmest skyldes den relative nyhed i integrationen .hpkg med GUI, som stadig efterlader meget at ønske. Under alle omstændigheder er der flere aspekter af UX, som kan forbedres...
En anden ting: Kernel Debug Land
Det ville være fantastisk at kunne indtaste kommandoer ved kernel panic, for eksempel syslog | grep usb. Nå, på Haiku er dette muligt takket være Kernel Debug Land. Hvordan kan man se denne magi i aktion, hvis alt fungerer som det skal uden at ramme kernel panic? Det er nemt, tryk på Alt+PrintScn+D (mnemonik Debug). Jeg husker straks , som gjorde det muligt for de oprindelige udviklere af Macintosh at få adgang til debuggeren (hvis den da var installeret).
Konklusion
Jeg begynder at forstå, at elegance ved Haiku-systemet stammer fra, at arbejdet udføres af et lille team med en klar fokus på arbejdsomgivelserne og tilgængeligheden af alle lag i systemet.
En skarp kontrast til verdens Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, hvor alt er opdelt i så små stykker, at abstraktionen sidder på abstraktionen og styres med improvisationer.
Det er også blevet klart for mig, hvordan systemet .hpkg kombinerer bedste praksis fra traditionelle pakkehåndteringssystemer, Snappy, Flatpak, AppImage, endda btrfs, og blander dem med princippet om «bare virker» fra Mac.
Som noget "skiftede" der i mit hoved, og jeg forstod, hvordan systemet .hpkg kan rulle tilbage, - blot ved at se på det. Men det er ikke mig, men skønheden og enkelheden i systemet. Meget her er gennemsødet med ånden fra det oprindelige Mac.
Ja, at browse sider i browseren kan være hakket og fungere som en snegl, der kan mangle applikationer (ingen Gtk, Electron - udviklerne har konkluderet, at de dårligt passer sammen med elegance), acceleration af video og 3D kan helt mangle, men jeg kan stadig lide dette system. For disse ting kan rettes, og de vil komme, før eller siden. Det er kun et spørgsmål om tid og måske et lille rødt øje.
Jeg kan ikke tilbyde hjælp, men jeg tror, fra dette øjeblik vil året Haiku på skrivebordet.
Tilfældige problemer
Måske er der allerede indsendelser, eller skal jeg åbne dem?
- BeScreenCapture skal have mulighed for at eksportere til GIF, ligesom i Peek. Dette kan gøres med ffmpeg, som allerede er tilgængeligt til Haiku. .
- Programmet til at tage screenshots kan ikke tage et screenshot af et modalt vindue, men tager i stedet hele skærmen
- Det er ikke muligt at beskære screenshots med beskæringsværktøjet i WonderBrush og derefter gemme resultatet i en fil
- Jeg kan ikke særlig godt lide håndcursoren i Haiku, men jeg tror, det hænger sammen med varme nostalgiske følelser. Det er især irriterende at bruge beskæringsværktøjet i Krita, da det resulterer i unøjagtig beskæring (se screenshots med modal dialog i denne artikel). En cursor i form af et kryds ville være vidunderlig. .
Prøv selv! Haiku-projektet tilbyder billeder til download fra DVD eller USB, der genereres . For installationen er det nok at downloade billedet og skrive det til en USB-nøgle ved hjælp af
Har du spørgsmål? Vi inviterer dig til vores russisktalende .
Fejloversigt:
Fra Oversættelse: dette er den sjette artikel i cyklussen om Haiku.
Liste over artikler:
Kilde: habr.com
