Simon Justesen

Med del I i mente, så dykker vi nu dybere ned i Flatpaks. Vi bygger en simpel Flatpak, så… Hvordan gør vi lige det? (er det nu, jeg skal sige, at det ved jeg heller ikke? **Cue end-credits**). Nej, pjat ;-) … Vi starter blødt ud, og bygger så mere og mere på i del III og IV.

Installation af Flatpak

Installationsproceduren ift. Flatpak-værktøjerne er forskellig fra Linux-distribution til distribution. Canonical har f.eks valgt, at Ubuntu, som er en af de mest populære Linux-distributioner, skal bruge deres eget distributionsformat Snaps, fra og med Ubuntu 24.04. Det betyder, at man skal installere Flatpak-komponenter selv. En ærgerlig løsning, for det er et af de steder, jeg gerne ville se noget standardisering. Linux-distributionen Fedora har allerede Flatpak-funktionalitet integreret.

Jeg bruger Ubuntu, og vi vil selv bestemme, vil vi, så du kan installere Flatpaks terminalværktøj ved at gå til https://flathub.org/da/setup og find din Linux-distribution. Dernæst følger du bare guiden derinde. Vil du gerne skyde genvej kan du tilføje flatpak-builder allerede nu, og bruger du Ubuntu eller Debian, så skriv:

$ apt install flatpak flatpak-builder

(dollartegnet viser blot, at vi befinder os i terminalen, så det skal ikke med).

Får du at vide, at Flatpak allerede er installeret, så behøver du ikke gøre ydeligere. Du kan teste om din Flatpak installation virker ved at skrive:

$ flatpak search blender

og så skulle du gerne se en række resultater. Hvis du af en eller anden grund ikke kan se nogle Flatpaks, så kan det være, du mangler at koble Flatpak på et repository. De fleste associerer Flatpak-repo’et Flathub med Flatpak, så det kobler vi os på. Det bliver vildere senere i guideføljetonen her (del IV), da skal vi selv prøve at lave vores eget lokale Flathub (dundundun… lidt af en cliffhanger, hva’?!).

Flatpak-repos virker i øvrigt akkurat ligesom git, så du kan tilføje Flathub med:

$ flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

Grafiske frontends til Flatpaks

Et kort lille ophold i guiden, fordi… Jeg vil gerne lige anbefale nogle udvidelser til funktionaliteten i din distributions Software Center.

Gnome Software Center
Som beskrevet i starten, så har mange distroer baseret på Gnomes skrivebordsmiljø allerede Flatpak og dens Software Center-udvidelser installeret, men hvis det ikke tilfældet for din, så kan det tilføjes.

$ sudo apt install gnome-software-plugin-flatpak

Om alt går vel, så når du derefter åbner Gnome Software Center, og klikker på en app, vil du i øverste højre hjørne se, at der står “Flathub (Flatpak)” i dropdown-menuen. Bruger du Ubuntu ligesom jeg, så kan du med fordel installere Gnome Software Center i stedet for Canonicals variant.

KDE Discover

Bruger du KDE som dit skrivebordsmiljø, så er det muligt, du skal installere et tillægsmodul til “Discover”, som er KDEs Software Center. Men test om du kan åbne en Flatpak inden du forsøger. For det kan være, at funktionaliteten allerede er installeret, afhængig af hvilken Linux-distribution, du bruger. Ellers finder du tillægsmodulet her: https://apps.kde.org/da/discover.flatpak/

Flatpaks er “sandboxed”

Efter denne lille detour kan vi prøve at bygge vores første Flatpak. Vi skal bruge en 4 ting, en “runtime” og et SDK - Software Development Kit, og en manifest-fil, og så dit program, script eller lign.

Der findes tre forskellige runtimes, FreeDesktop, KDE og Gnome. Runtimen pakkes med ned sammen med din app i din færdige Flatpak, og sørger for, at pakken virker som en native compiled app.

Det er lidt en omstændig arbejdsgang, men måske husker du fra del I, at jeg skrev at Flatpaks var sandboxed? De har slet ikke adgang til det omkringliggende miljø, derfor skal vi bruge dels runtimen, SDK’et, men også manifest-filen til at specificere, hvilke rettigheder Flatpak’en skal have. Freedesktop-runtimen har det mest minimale sæt af “tilbehør”, så det er målet for vores første Flatpak.

En tur i sandkassen

Jeg anbefaler, at du først laver en hel ny mappe, som skal indeholde alt, der har med din kommende Flatpak at gøre. Dvs. at du lige om lidt har et shell-script og en manifest-fil i mappen.

Og så skal vi have installeret runtime og SDK. Installationsmetoden til runtime og SDK er sakset direkte fra dokumentationen til Flatpak

$ flatpak install flathub org.freedesktop.Platform//23.08 org.freedesktop.Sdk//23.08

Jeg valgte Freedesktops-udgave, da det er den mest grundlæggende. KDE, Elementarys og Gnomes varianter er alle overbygninger. Du skal nok påregne, at det vil æde ca. 500MB+ af din computers diskplads, men står i skærende kontrast til, hvad Windows SDK’et fylder til sammenligning ;-)

Efter endt installation, sakser jeg lige lidt mere fra dokumentationen. Kast følgende kode i en ny fil, navnet er valgfrit, men kunne f.eks være ‘hello.sh’ for at følge Flatpak-doc’en:

#!/bin/sh
echo "Hello world, from a sandbox"

Manifestet
Nu kommer vi så til manifestet, manifestet vil jeg egentlig helst sammenligne med en bageopskrift. Det fortæller, hvordan systemet skal bygge og afvikle din Flatpak, og den del synes jeg mangler lidt mere beskrivelse end det, der står i Flatpak-dokumentationen, så tillad mig at uddybe:

Først sakser vi lige “bageopskriften” - manifestet - fra Flatpak-dokumentationen - imens jeg beder til, at mit Flatpress-blogsystem formaterer koden korrekt. Fordi eftersom manifestet kan være en YAML eller JSON-fil (herunder er den i YAML-format), så er det vigtigt hvordan indrykninger laves, se f.eks strukturen efter modules-afsnittet, hvor der er indryk:

app-id: org.flatpak.Hello
runtime: org.freedesktop.Platform
runtime-version: '23.08'
sdk: org.freedesktop.Sdk
command: hello.sh
modules:
  - name: hello
    buildsystem: simple
    build-commands:
      - install -D hello.sh /app/bin/hello.sh
    sources:
      - type: file
        path: hello.sh

Forklaring til de enkelte dele:

app-id: et unikt ID til din Flatpak, læg specielt mærke til, at det er omvendt notation i forhold til en website-adresse. Jeg ville f.eks normalt bruge app-id’et dk.simonjustesen.Hello til denne test-Flatpak, hvis den skulle udgives på f.eks Flathub. Du skal bl.a. bruge app-id’et som præfix på de elementer, du vil have i din færdige Flatpak-pakke. Det kigger vi mere på i del III. Lige nu er det, det mest basale først.
runtime: den valgte runtime
runtime-version: - versionsnr. på den valgte runtime.
sdk: - det valgte SDK
command: - kommando, der udføres, når Flatpak’en startes

Modules-afsnittet

Du kan have et eller flere moduler, hvis en del af din Flatpak er afhængig af en anden.

name: Navn på dette modul
buildsystem: - kan f.eks være “simple”, “cmake-ninja” og “meson”, “qmake”. Du kan således delegere byggeriet over til andre buildsystems.
build-command: Et array af build-kommandoer, der skal køres. I manifestet ovenfor installerer vi hello.sh ind i /app/bin/hello i Flatpak’ens sandkasse. Valgmuligheden -D på install-kommandoen betyder, at vi giver lov til at oprette både ‘app’ og ‘bin’-mapperne, som ‘hello’-scriptet placeres i, inde i Flatpak’en.

Le grande finale

Nu er der egentlig kun tilbage at køre

flatpak-builder build-dir org.flatpak.Hello.yaml

som vil bygge din Flatpak, dernæst kan du testkøre den lokalt med:

flatpak-builder --run build-dir org.flatpak.Hello.yaml hello.sh

Nu skulle du så gerne se outputtet af din hello.sh-scriptfil.

Det var det… Eller var det? Andre guider ville måske slippe dig løs her, men vi er ikke færdige endnu. Af hensyn til opslagets længde vil jeg dog fortsætte i part III, som jeg poster så hurtigt, jeg kan.

– Linux, er det ikke for nørder?

Det udsagn var sandt engang. Men i de senere år har Open Source-miljøet virkelig lagt sig i selen for at skabe bedre produkter, der kan bruges af alle. Det er derfor blevet nemmere og nemmere at finde sig godt til rette i miljøet.

Brugere henter deres Flatpaks via deres Linux-distributions softwarecenter eller via Flathub. Alle afhængigheder, dvs. underlæggende funktionsbiblioteker er allerede en del af pakken, man henter. Det løser en del af de problemer, man traditionelt har haft med Linux-pakkeformater. Det har dog den pris, at Flatpaks fylder mere end de gamle formater, men det er et ganske lille trade-off efter min mening.

Flatpak-projektet er særdeles spændende, fordi det viser styrken, når man kombinerer forskellige FOSS-projekter til noget helt nyt. Overordnet er Flatpaks et softwaredistributionsformat, og består konceptuelt bl.a. af: OSTree, Bubblewrap, D-Bus, og AppStream.

libostree, tidl. OSTree er en slags versionskontrol for apps, hvor Git er det for kode. Det betyder, at en app får sin egen placering i et repository, der gør opgradering og rollbacks simple.

Bubblewrap-projektet er et containerformat, der har til formål at lave en “sandkasse”, din app kan leve i. Din app får sit eget virtuelle filsystem, som den kan boltre sig med, og ser kun din harddisks ægte filsystem i sin helhed, hvis du giver lov. Fra et sikkerhedsperspektiv giver det rigtig god mening at være så restriktiv som muligt, fordi man helst ikke vil have, at en app kan lave unoder i andre dele af systemet. De afhængigheder som en app har, bliver derfor pakket med ned i container-formatet.

D-Bus — Desktop Bus — giver to (eller flere) apps adgang til at kommunikere med hinanden, eller sørger for, at en app kan kommunikere med kernen eller kørende processer.

AppStream er et distro-neutralt bibliotek over metadata, der følger apps. I dette tilfælde er denne form for metadata det tekst- og billedmateriale, du ser, når du åbner din distros softwarecenter.

Over det næste stykke tid vil jeg prøve at udforske Flatpaks… Ikke fra et brugersynspunkt, men fra et udvikler/maintainer-perspektiv. Det ved jeg allerede nu, vil være enormt lærerigt for mig, og jeg glæder mig til at dele mine opdagelser med dig. -

Del 2 er klar! Linux Flatpaks II: Byg en Flatpak

Links:

https://flatpak.org/
Flathub
Flatseal - frontend til administration af Flatpak-tilladelser
Flatpak - a technical walkthrough
Flatpaks Explained

Go’ lørdag-søndag! (Bubber-i-badekarret-energisk-hype)

Jeg har simpelthen fundet det fedeste terminalsetup til Linux, synes jeg i hvert fald selv ;)

Alacritty (GPU-accelereret terminal)
Zellij (tmux-alternativ skrevet i Rust)
AstroNVim (IDE-agtig opsætning af neovim)

Jeg er stadig vim/neovim-novice - men jeg begynder at forstå, hvorfor mange programmører sværger til editoren, efterhånden som jeg får lavet en konfiguration, der er min egen, og at jeg lærer at holde nallerne væk fra musen. Samtidig er Alacritty-terminalen lynhurtig at arbejde med, men - jeg synes det er ærgerligt at udviklerne ikke prioriterer, at man kan have ting åbent i tabs. Det er faktisk ligefør, jeg kunne undvære Zellij, hvis det havde været tilfældet.

AstroNvim er skægt. Jeg krydser dog fingre for, at det ikke “knækker”, som det plejer (ok, nu jeg læser dette et par dage senere var det sgu en overdrivelse.. Men det hænder…) .

Jeg har før prøvet, at nvim-komponenter lige pludselig er stoppet med at virke, og så er jeg flygtet tilbage til Visual Studio Code. Jeg har ikke den store lyst til at bruge min effektive tid på at løse problemer med de værktøjer, jeg bruger. Mit mål med at kaste mig over Neovim var netop at vende tilbage til noget, der minder om simplere tider. Et emne til en anden dag kunne være, de toolchain-problemer, som moderne udvikling har ført med sig.

Mine konfigurationer:
Alacritty config
Minimalistisk Zellij

De der systemikoner, der ret ofte befinder sig i nærheden af uret på din computers desktopskærm, bruger du dem?

Ovre på Youtube, har youtuberne DistroTube (DT), og Brodie Robertson sig en fest hver for sig, og diskuterer brugbarheden af systemikonerne. Det er en ret normal cyklus på Youtube, at nogen smider en video op, og så kommenterer andre Youtubere med reaktioner. Det er en sjov mekanisme.

Round one, fight!

De to Youtubere har vidt forskellige holdninger. DT mener, at systemikonerne er unødvendige, og de skal fjernes, for han bruger dem ikke selv. Han nævner et eksempel med OBS - Open Broadcasting System… At han streamer hele dagen, så han ved, at programmet kører i baggrunden…

Brodie er af en anden holdning og forklarer, hvordan systemikoner har været en del af operativsystemer meget, meget længe. De repræsenterer et visuelt billede af et kørende programs aktuelle status, og er en hjælp til brugeren. Den forklaring kan jeg nemmere følge.

Min egen personlige holdning er, at de er en naturlig part af et operativsystem, men man bør prioritere visningen af dem, så kun de vigtigste vises. Det har længe været et problem, f.eks på mobilplatforme, at app-notifikationer er alt for opmærksomhedskrævende. De prøver konstant at sælge dig noget, kræve din opmærksomhed… Så jeg slår dem konsekvent fra ;-)

Selv stiftede jeg først bekendtskab med systemnotifikations-ikoner på Windows 95 og OS/2 Warp (på Win3.1 fandtes konceptet vist ikke, for jeg mener, det dukkede op med taskbar’en i bunden af skærmen), for mig er eksistensen en naturlig ting, som jeg er glad for, også findes på Linux.

Ligegyldig diskussion?

Man kan mene, at det er en ligegyldig diskussion, og at videoerne er ren clickbait, for kan man ikke lide ikonerne på Linux, kan man bare fjerne eller skjule dem. Koden er Open Source, så du kan endda udvide funktionaliteten af modulerne selv, hvis du har lyst (selvom du ikke kan programmere, findes der ofte alternative løsninger i forums)..

Generelt er det sundt for udviklere og designere at mærke, at brugere er forskellige, og at folks præferencer derved ikke er ens. Derfor er brugerfladedesign, ja alt slags design, sværere end man tror, fordi der skal tages beslutninger, der skal behage flest mulige. Derfor kan man aldrig få on/off-knapper eller udvidelser nok, så folk selv kan bestemme ;-)

Jeg kan godt lide, at diskussionerne i Open Source-miljøet kan tages i offentligheden, og at designerne af grafiske miljøer, så kan få en fornemmelse af brugernes ønsker (tjek f.eks kommentarene under videoerne). Diskussioner af denne type er ikke altid velbegrundede og saglige, fordi der udtrykkes subjektive holdninger, hvor der ikke findes et facit. Men der udtrykkes altid holdninger, som man kan indarbejde i et projekt. Ultimativt er det projekternes styregrupper, der suværent bestemmer, hvordan features implementeres.

Særlig KDE-projektet har gjort meget ud af, at Plasma-desktop’en er utrolig modulær, også som bruger - du kan placere alting, hvor du synes. Gnomes desktopmiljø er lidt mere stringent som standard, og knapt så konfigurerbart, men kan udvides via plugins. Jeg bruger selv Gnome, men er glad for, at man kan “shoppe rundt”, som man har lyst. KDE og Gnome er langt fra de eneste skrivebordsmiljøer, der eksisterer til Linux, og det er fordi nogle har ment, at tingene kan være fungere anderledes. Gudskelov, det er menneskelig opfindsomhed, når det er bedst.

Link:
https://www.youtube. … /watch?v=4nQLJ2_cYgY
https://www.youtube. … /watch?v=D9AZMCxzfT8

https://store.kde.or … =418&ord=latest
https://extensions.gnome.org/

Jeg kan lige nå at skrive et blogindlæg, inden jeg skal i gang med dagens arbejde. Her præsenterer jeg 5 gode open source-projekter, som man selv kan host’e på en Linux/Unix-server.

Owncast

Lav din egen videostreaming-platform.

Owncast er din helt egen private videostreaming-platform. Den spiller sammen med OBS - Open Broadcasting Software, og f.eks Jitsi, som du kan bruge til at streame møder med flere deltagere.

Owncast
Owncasts Github

Mastodon

Meget populært Twitter-alternativ, som du kan host’e selv. Du bestemmer selv, om serveren skal være fuldstændig privat, eller om den skal deltage i det decentraliserede net af sociale medier, der kaldes The Fediverse, eller The Federation. Mastodon og lignende ActivityPub-forbundne projekter har nemlig den unikke detalje, at de kan udveksle data med hinanden - det betyder at du kan sende beskeder mellem forskellige sociale medier, der deltager i Fediverset. Så vælger du, at din server skal være offentlig, så skal du nok forberede dig på, at din server skal bruge en ordentlig røvfuld diskplads (min. 250GB-1TB anbefalet, for at du også har plads til andet…).

Mastodon
Mastodons Github

Jitsi

Jitsi er et frit og open source videokonference-system. Du har måske prøvet Jitsi Meet som er frontenden til Jitsi Videobridge, der er selve serverkomponenten. Hardwarekravene til Jitsi er rimelig vilde (anbefalet min. 8GB Ram), så medmindre du har en heftig fysisk server, så skal du nok ikke forvente at holde gigantmøder, men til relativt få deltagere er softwaren fin til selv lette krav.

Jitsis hovedside
Jitsis Github

Icecast

Selvfølgelig skal Icecast med, nu har jeg brugt et par fornøjelige dage for ganske nylig med softwaren. Med Icecast kan du lave din egen audio/video streaming server. I modsætning til f.eks Owncast leveres kun selve serveren, så du skal selv udvikle og/eller sætte evt. source clients - dvs. lydkilder, du streamer op til Icecast-serveren - op efterfølgende (der er f.eks IceS (audio) eller ezStream (video).

Icecast
Liste over source clients
Icecast Github

Mattermost

Mattermost er et Slack-alternativ, du kan hoste selv. Samtaler bliver organiseret i kanaler, så du kan have forskellige “spor” kørende. Hardwarekravene er relativt lave, Mattermost angiver selv, at minimumskravet er en enkelt vCPU og 2GB ram er nok til at kunne servicere 1000 brugere

Mattermost
Mattermost Github