11. Juni 2024

GIMP 3.0 - Sneak Peek

Jeg spottede lige ovre på LibreGraphics’ Youtube-kanal, at de havde uploadet en presentation fra GIMP-teamet, så den prakker jeg jer lige på her. Præsentationen varer lidt over 41 min. og den er vigtigere end selv TV-Avisen. Hæh.

GIMP 3 får bl.a.

* GTK3-support
* Wayland-support
* Non-destructive editing
* Touch support
* Basal CMYK-support

Det er endnu uvist hvornår GIMP 3 udgives, men det ser ud som om udviklingen er på sporet. Jeg glæder mig!

Video

19. April 2024

Hvad mangler FreeBSD… Eller BSD’erne generelt?

Jeg faldt over denne Youtube-video af “Robonuggie”, der ofte beskæftiger sig med FreeBSD-videoer. Selvom jeg primært er Linux-mand, så følger jeg BSD’erne lidt på sidelinien, og har tidligere testet både FreeBSD på server og desktop. Jeg vil så gerne se dem lykkes, for det betyder mere frit valg blandt operativsystemerne til alle.

Men hvor FreeBSD virkelig excellerer på serverfronten, så kniber det på desktopsiden, hvor der mangler driversupport til forskelligt hardware f.eks Wifi7-enheder, hvilket “Robonuggie” også nævner i sin video.

Det er på driversupporten *BSD’erne og Linux differentierer sig fra hinanden. Hvor Linux tillader proprietær binær kode i kernel’en, så er det no-go hos FreeBSD, og det har formentlig den betydning, at større hardwareproducenter vender BSD’erne ryggen, fordi producenterne vil beskytte deres kode og patenter. BSD-folkene må så udvikle deres egen åbne driver ved hjælp af trial-and-error, og den slags tager tid.

Vidste du, at en BSD-licens er mindre restriktiv end GPL-licenserne i forhold til modkrav, hvis du bruger kode fra et GPL-projekt? GPL-licenserne bestemmer bl.a. at afledt kode skal offentliggøres under samme licens, så forbedrer du f.eks kernel’en, så skal du tilbyde forbedringerne upstream. Det lyder måske meget stringent og kedeligt, men det sikrer, at upstream-projektet udvikler sig.

Der mener jeg faktisk at hhv. MIT/BSD-licenserne er for løse - og det påvirker også BSD’ernes “vækst”. Åbne, frie licenser fungerer godt i undervisnings- og forskningsmiljøer, og blandt opensource-mindede individer, men det ses tydeligt at en del kommercielle virksomheder nyder godt af den gratis arbejdskraft uden nødvendigvis at bidrage tilbage til projekterne.

Derfor er der også en lidt, synes jeg, opgivende undertone i Robonuggies video, for det er tydeligt, at FreeBSD og de andre vaianter sakker længere og længere bagud, hvis man ser det hele som en konkurrence, og det er virkelig synd, for det er solide systemer, når de kører.

Fremtiden for FreeBSD?

Jeg har ikke føling med BSD-fællesskabet, så jeg ved ikke hvor aktive de forskellige varianter er. Mit kendskab stammer primært fra nogle måneders serverdrift, og lidt desktop-leg. Derfor skal mine “mavefornemmelser” tages med et gran salt.

Udefra set er det dog ikke første gang, jeg mærker en frustration over manglen på hardwaresupport.

Det er vigtigt at pointere her, at det hverken er *BSD-projekternes fejl, men verden omkring dem, der er skruet forkert sammen. Dele af den kommercielle IT-industri hævder, at man beskytter sin kode for at kunne innovere, men man ynder i virkeligheden for det meste at genopfinde hjulet flere gange og forhaler i virkeligheden fælles udvikling.

BSD-projekterne kan langtfra kaldes for døde eller døende, for de har mange dedikerede loyale støtter indenfor mange områder. Men BSD-projekterne virker umiddelbart isolerede fra hinanden, og derfor kan man også nogle gange se f.eks OpenBSD og NetBSD diske op med bedre driversupport på nogle områder, før samme ændringer lander i FreeBSD, som Robonuggie bemærker i løbet af videoen. Dermed bliver de indbyrdes konkurrenter, hvor de måske burde arbejde mere sammen på de mest vitale områder. Men forks, dvs. nye varianter af et eksisterende projekt oprettes ofte, fordi “forkerne” (hæ…) er uenige i retningen, det oprindelige projekt tager. Så der er givetvis kodesmede, der slet ikke har interesse i, at til at bidrage til det gamle projekt.

Skal BSD’erne det blive en succes på desktop-fronten, så skal man nok forlige sig med, at det aldrig bliver godt som generalist-system, medmindre det lykkes at åbne op for mere generel hardwareunderstøttelse. Og så skal man differentiere sig endnu mere fra Linux, end man gør i dag. Giv mig som “Linux-mand” større incitament for at kigge mod BSD’erne… Challenge. Da jeg brugte hhv. GhostBSD og FreeBSD i en periode, følte jeg mig egentlig godt hjemme, både ports (byg fra sourcekode) og package-systemet (binære, pre-kompilerede pakker) virker solide, jeg savnede bare det miljø, jeg kendte.

Nogle ser f.eks gerne Wayland erstatte X11-displayserveren på BSD’erne, men måske skal skal man gå en helt tredje vej. Der har f.eks været snak om at lave en X12-udgave. Det vil formentlig være en mindre omvæltning end at skulle erstatte det hele med Wayland. Udfordringen er så bare, at det er den vej, store desktop GUI-projekter såsom Gnome og KDE kigger.

Linux’ akilleshæl er helt klart den store fragmentering. Der er 5-7 store distroer og mange små, med mere eller mindre individuelle konfigurationer. Nogle projekter virker mere som reskinning fremfor, at man prøver nye veje. Antallet af nye distributioner, pakkeformater mv. er tårnhøjt og forvirrer nybegyndere. Fleksibiliteten er et fænomenalt salgsargument, men kan også være en hæmsko alt efter perspektiv. Den fragmentering har BSD-projekterne ikke helt (endnu), og der kunne man måske vinde på at standardisere komponenter på tværs af projekterne, så de samlet set hænger bedre sammen end det er tilfældet for Linux-økosystemet.

Jeg ser fordelen i BSD’erne i nicheområderne: Virksomheder kan bruge f.eks FreeBSD som fundament til at skabe sit eget økosystem over tid, ligesom Apple har gjort det med MacOS (Note: MacOS bygger på en anden BSD-variant, DarwinBSD, en NeXTStep-fork… Ikke FreeBSD), og deres egen hardwarestack. Sony Playstation 3s OS var en hybrid mellem FreeBSD og NetBSD, mens PS4s OrbisOS var en fork af FreeBSD 9 iflg. Wikipedia - det er bare nogle få eksempler, hvor man har kunnet bruge BSD’erne som fundament. Jeg er på ingen måde fan af den lukkethed Apple og Sony bragte med deres egne BSD-varianter, men illustrerer blot muligheden for at skabe sit eget findes.

Anyway, hav FreeBSD og de andre projekter i baghovedet, når du skal lege med nye projekter, evt. i en virtuel maskine. De fortjener i den grad mere opmærksomhed end de hidtil har fået.

God weekend :)
/Simon out.

Links

FreeBSD
DarwinBSD
PureDarwin, moderne OpenDarwin fork
BSD Hardware Info

2. April 2024

CVE-2024-3094

Link: English autotranslation (Google translate)

Bag overskriftens kryptiske talrække gemmer der sig den sikkerhedsadvisering, der har været genstand for megen omtale, de sidste mange dage. Det viser sig nemlig, at nogen har sneget en bagdør ind i bestemte udgaver af sourcekoden til xz-utils, der findes på mange Unix-varianter (Linux, BSD’erne m.fl.). Bagdøren findes i version 5.6.0 og 5.6.1 - tarball-udgaven, men ikke i selve Git-repository’et (se opslag på Open Wall, link nederst)

Et lumsk angreb

Det er et rigtig nasty supply-chain-attack, fordi det består af to dele. Dels bruges xz i pakkebygningsfasen til at patche funktionsbiblioteket liblzma med ondsindet kode. Men det går skridtet videre… For når liblzma efter patchingen bliver linket sammen med andre softwarepakker, så vil sårbarheden også eksistere i de pakker, der bygges efterfølgende, og som trækker på funktioner fra liblzma.

Ifølge Hackaday, som jeg linker til nedenunder, gik koden som bagdøren udløser specifikt efter at modificere virkningen af funktionen RSA_public_decrypt.

Funktionen RSA_public_decrypt bruges bl.a. til at validere ssh-nøgler, så som Hackaday også nævner, så kunne det for en person med ondsindede intentioner være en mulighed for at gøre OpenSSH’s auth-proces svagere, og dermed nemmere forbigå de normale sikkerhedsprocedurer, når man logger ind på en server via SSH.

Opdaget ved et tilfælde

For open source-miljøet er det en rigtig ærgerlig situation. Først og fremmest godt at det blev opdaget af en årvågen udvikler. Men også en brat opvågning, fordi der måske har været en naivistisk tilgang til kodedeling, ift. til koderevision, ansvarsfordeling og tillid i Open Source-miljøet helt generelt. Særligt med tanke på, hvordan verden udenfor Open Source-miljøet på bedrøvelig vis tager sig ud i disse tider.

Der er endnu ingen, der med 100% sikkerhed ved, om det ondsindede kode er bestilt arbejde af en stat eller en enkelt persons komplot, men uanset hvad resultatet af undersøgelsen bliver, så bør det give det anledning til ændringer i sikkerhedsprocedurene hos de Linux/Unix-distributioner, der hiver pakker ind udefra.

De pakker udgør fundamentet for f.eks en Linux-distribution, som distribueres til millioner af brugere - erhverv og hobbyister - som dagligt bruger Linux på deres computere - servere-, IoT- eller desktopsystemer. Derfor er Linux-distributionernes udgivere også sidste sidste bastion overfor sikkerhedshuller, og bør give pakkerne det sidste tjek inden udgivelse. Det er måske netop nu, at der skal et skævt magisk AI-sovs ind over arbejdsgangene. Det er ikke sikkert, AI kan løse problemet, men det kan udpege problemområder og lette arbejdsbyrden.

Vi kan sagtens blive enige om, at det på papiret er de enkelte upstream-projekter, der selv skal sørge for, at deres kode er testet for sikkerhedshuller og clean. Men det ville forudsætte, at alle er sikkerhedseksperter, og det kan på ingen måde forventes. Det, der mudrer sagen yderligere til her, er jo, at den person der - tilsyneladende - har injiceret malwaren i projektet har været en betroet bidragsyder på xz-projektet i en del år.

Forskellige tilgange til test

Alle projekter har forskellige test-metoder, nogle mere strukturerede og tilbundsgående end andre. Men bottomline er, at pakkerne, der ender ude hos slutbrugerne skal efterprøves bedre. Hvis det betyder, at mængden af nyudviklede funktioner i en distribution bliver færre og at antallet af udgivelser falder, så må det være sådan, det er.

Måske er det på tide at samle kræfterne et formaliseret samarbejde imellem distributionerne, der tester pakker, som kommer ind upstream? De enkelte distributioner kan ikke overkomme den byrde isoleret set. Der er immervæk tusindvls af pakker i f.eks en Linux-distribution, der skal testes, og det - ideelt set - hver gang, der lander en opdatering til en pakke.

Nogle af de community-baserede Linux-distributioners release- og sikkerhedsteams består af få personer, mens det forholder sig anderledes hos de erhvervsrettede. Men selv de har brug for en håndsrækning fra fællesskabet. Om sikkerhedsbristen, der ligger bag CVE-2024-3094 ville blive opdaget nemmere i et sådan samarbejde, må stå hen i det uvisse - men det må alt andet lige give blod på tanden ift. at få skabt bedre systemer, der kan trawle kode igennem for brister - automatiserede såvel som manuelle.

Tornhøj tillid

Min tillid til Open Source-økosystemet er dog ikke svækket - tværtimod. Man kan aldrig undgå sådanne brister, den her var en af de ubehageligt lumske.

Havde det været et operativsystem baseret på proprietær, lukket kode, så kunne sådan en sikkerhedsbrist givetvis få lov at eksistere et stykke tid. Det er og bliver en illusion, at fordi man ikke offentliggør sin kode, så er man bedre sikret. I bedste fald giver det måske arbejdsro.

Det er sket før, at sikkerhedsbrister ikke er blevet patchet tidsnok i closed-source systemer, som Ars Technicas artikel her nævner.

Debatten omkring dette sikkerhedshul afslører også, hvor hårde folk kan være ved hinanden, og vi skal for alt i verden undgå at folk brænder ud. Netop debatkulturen ift. open source og dette sikkerhedsbrud, vil jeg prøve at behandle i et kommende blogindlæg, for det er et studie for sig.

Links

Tråd fra OpenWall
NISTs CVE-beskrivelse med referencer
Hackadays artikel
Low Level Learning: et kig på sagen fra en sikkerhedseksperts perspektiv

27. Oktober 2023

Gossip: Linux-Youtubere diskuterer ikoner

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/

24. Oktober 2023

5 gode Open Source-projekter

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