WebGang/CityGang

De opnames werden gemaakt op FOSDEM 2025 in Brussel, waar Free Software en Open Source projecten van over Europa en heel de wereld worden voorgesteld aan het publiek van de developers meeting. We spreken met de makers van drie verschillende besturingssystemen.

1. Haiku
De eerste infostand die we zien op FOSDEM is die van Haiku, we doen een praatje (Engels) met de standhouder, die nadien gewoon een Limburger blijkt te zijn. Haiku is geen Linux, maar een project om een gebaseerd op het ooit ter ziele gegane BeOS, dat desktop gericht was. Hij geeft ons ook een DVD mee, die eigenlijk een collectorsitem is want al een paar jaar oud. Hij raadde aan een recente versie van Haiku af te halen en op usb-stick te zetten om het te installeren en uit te proberen, wat ik hem beloof.
-
Deze post is geschreven vanuit het Haiku operating systeem.
Gestart vanop een usb-key, niet vast geinstalleerd op de harde schijf, zoals we in de studio ook doen met de beschikbare computer.
Ik heb de eerste keer de instelling van het toetsenbord niet gekozen, en moet nu dus vanuit een denkbeeldig qwerty toetsenbord werken tot ik die instellingen terugvindt… (lukt even later).

Bij-installeren van software gaat via het HaikuDepot.

In de laatste programma’s in het menu vindt ik het allereerste opstartmenu.
Daarin ook een keuze voor taal en toetsenbord, en eens daar Belgisch geselecteerd, werkt dat onmiddellijk in dit browservenster dat ik heb openstaan, zondat dat ik bewaar of zo moet doen.

Het is wel wennen: hoe door de vensters bladeren want alt-tab werkt niet. Iets met CTRL-Tab lijkt te werken.
Hoe een venster “klein zetten”? Want het venster zelf heeft daar geen symbolen voor in de vensterrand – die trouwens als een soort ruitertje bovenop het venster zit, met de breedte van de titel van het programma/document dat open is, en dus niet de hele breedte van het venster. Dat wint plaats, en je kan iets meer zien wat er onder zit. Een groter/kleiner symbool zit er trouwens wel op, enkel niet het symbool om het venster helemaal te verbergen naar een logo’tje in de takenb… ah nee er is geen takenbalk.
Ook de shortcuts om in de tekst vooruit of naar boven te springen lijken anders te zijn dat ik gewend ben (ctrl-pijltje links/rechts bv).

De browser is niet Firefox maar Webpositive, gemaakt met “..” (kopieren en plakken werkt dus ook niet hoe ik het gewend ben); dus webkit .. enz.

kopieer en plak werkt met alt-c en alt-v ontdek ik; dus:

HaikuWebKit 1.9.14
WebKit 619.1.13

https://nl.wikipedia.org/wiki/Haiku_(besturingssysteem)

2. Tumbleweed (vs Arch?)
Tumbleweed ken ik als de versie van OpenSUSE die doorlopend geüpdate wordt (tgo de Leap die verisnummers heeft als 15.0 tot 15.5, 16..enz. en waarbij je kiest een update te doen naar het volgend versie(sub)nummer. Ik heb al op verschillende toestellen met Tumbleweed gewerkt, en ooit vroeger wel eens een probleem mee gehad dat bepaalde software niet meer werkte na een update. Als ik op de stand aankom is er een discussie bezig tussen de standhouders en een bezoeker die als achtergrond “Arch Linux” heeft.

De ontwikkelaars zeggen dat “Tumbleweed” nooit “breaks like Arch does”. Een steek.
En als het toch breekt kan je met je snapshots teruggaan naar de vorige versie.

3. Rocky Linux
CentOS is verdwenen, Rocky is hier.
Clone en vrije versie van Red Hat, wat vroeger gedaan werd door het CentOS project. Dat verloor echter zijn sponsoring, en de mensen van het Rocky project zetten de inspanning voort…

Fosdem editie 2025
Ze vierden bij FOSDEM in Brussel op de ULB op 1 en 2 februari 2025 hun jubileum met de uitgave van een lelijke T-shirt (die ik dan ook niet gekocht heb), maar het gaat over de inhoud, en daar zijn ze gelukkig onklopbaar voor de prijs ;-)
De andere T-shirts die ik wel gekocht en gekregen heb, heb ik vandaag allemaal (over elkaar) aan en ik trek ze matroesjka-gewijs één na één uit om me aan tepassen aan het onderwerp dat besproken wodt op dat moment.
Verslag van Wim en Marthe. (algemeen en o.v. want Marthe brengt ook een gast mee en dat gaat voor; volgende weken nog deelverslagen)
Marthe heeft twee gasten bij vandaag, dus het verslag over FOSDEM is voor de volgende weken.

Interview (Engeltalig) met twee “computer science” vrouwen die in Antwerpen terechtkomen…

We bladeren door het 16 pagina’s lange programma van FOSDEM

Waar ook wij meer dan de helft niet van verstaan, of zelfs maar herkennen.
https://fosdem.org/2025/schedule/

Wel herkenbaar: LibreOffice, Python, Raspberry Pi, Sailfish OS, GitLab, Firefox, Gimp, MySQL/PostgreSQL, Cobol, openSUSE, FreeCAD, NextCloud, ..Luanti, ..

Misschien is deze wel interessant: Hoe een goede “README” schrijven: “How to write a killer readme” door Emily Omier, of deze: Voorbij de README door Lorna Mitchell.

BCP v.0.6.9:
Niet dat de luisteraar daar wat aan heeft, maar in deze nieuwe versie zit een extra menu om de gespeelde muziek logfiles te archiveren in het juiste mapje bij het nieuws van die uitzending. Vandaag dus niet nodig want onze aanvoer was wat opgedroogd en we spelen muziek van een CD. Dat weet BCP niet.

Muziek:
oude jazz van Blue note

Wer oder was ist diebin.at? : https://forum.diebin.at/

Sharing shells
Een leuke samenwerk tool voor de commandline: tmux https://www.howtogeek.com/671422/how-to-use-tmux-on-linux-and-why-its-better-than-screen/

Wegwerp-vape ombouwen tot aansteker. 500 mAh.

Electrische steps als e-waste in de “smart city”: leds, batterij, 36-48 Volt, BMS, electromoter, communicatie …
Beveiliging sluit af bij meer dan 1A of 50 watt. (canarchy.io)

Schepentrackers

Marthe was op CCC congres en brengt verslag.

media.ccc.de

meshtatic (gebruikt lora)

Reticulum https://reticulum.network/

zima bord 832 (8 Gig geheugen)

Volksdata van VW
We eindigen ons programma met een fagment van de talk op het CCC congres over de datalek bij de softwaretak van de volkswagengroep.

Wat is het perspectief voor “Re-licensed” open source projecten?

De Linux Foundation startte een project dat dit keer geen softwareproject was, maar een onderzoek naar de gezondheid van open source projecten, meer bepaald projecten waarin overgeschakeld werd naar een minder vrije licentie.
Ze namen drie projecten onder de loep: Elasticsearch, Redis, en Terraform.

Redis is de afkorting van Remote Dictonary Server. Het is software om een database in het geheugen te houden, waardoor die veel sneller is, wat bv handig is voor cache toepassingen. Het is geen relationele database, maar een NoSQL database, die werkt met een key-value systeem en een secondaire neerslag op disk. Het ondersteunt ook clustering. Redis is geprogrammeerd in C, maar kan vanuit veel verschillende programmeertalen gebruikt worden. Veel grote website-systemen gebruiken Redis.
De eerste code werd geschreven door een Italiaanse programmeur die het nodig had voor analysewerk dat hij met zijn opstartend bedrijfje deed. Hij maakte zijn code open source, verschillende projecten begonnen Redis te gebruiken, en commerciële bedrijfjes die Redis dienstverlening deden. Bij één daarvan, Redis Labs, ging de oospronkelijke programmeur in dienst in 2015. Maar er waren ook andere programmeurs die er aan werkten, en veel andere programmeurs van andere bedrijven of organisaties, een gezonde “community” dus.
Redis Labs had ondertussen aan de licentie gesleuteld, en zich hernoemd tot Redis, zoals de software. Ze kochten alle rechten op de naam en in 2020 stapte de originele programmeur op bij Redis, en liet het het project helemaal in hun handen. Daar bleef men aan de licentie sleutelen, om in 2024 bij een helemaal eigen licentievorm uit te komen die ze “source available” noemen, terwijl het vroeger een BSD licentie was.
Allerlei externe programmeurs haakten af, en uiteindelijk werken er alleen nog programmeurs van Redis zelf aan de software.

Er werd door de oorpsronkelijke community van de vroegere versie die nog een een BSD licentie was uitgegeven, een nieuw project gestart met de naam Valkey, onder een BSD licentie. Deze zogenaamde “fork” werd gesponsord door de Linux Foundation, en had na vijf maanden een release klaar. Er werkten 18 vroegere programmeurs aan mee, 11 nieuwe, en ze werken voor tien verschillende werkgevers.

Bij Elasticsearch (een zoekmachinesoftware) onstond er na het invoeren van een nieuwe licentie ook een afsplitsing onder de naam OpenSearch. Het bedrijf Elastic begon in 2021 met wijzigingen aan de licentievorm, weg van de oorspronkelijke Apache licentie. De fork OpenSearch heeft een Apache licentie maar ook een GNU Affero GPL licentie, en is dus zowel “open source” als “Free Software”.

En bij Terraform (datacenter management software oorspronkelijk onder de Mozilla Public License) heette de fork OpenTofu. Die onstond nadat Hashicorp, het bedrijf achter Terraform, in 2023 overschakelde op een commerciële licentie.

Het onderzoek concludeert dat de afgesplitste projecten die met een open source licentie blijven werken, een grotere organisatorische diversiteit hebben dan de gesloten projecten, wat een gezondere situatie is voor de evolutie van de software.

Community Health Analytics in Open Source Software: https://chaoss.community/
Elasticsearch, Terraform, Redis: https://en.wikipedia.org/

M: 2/1+2; 1:7

Post Open vraag en antwoord

Vervolg van het vragenlijstje aan Bruce Perens.
(vorige keer: inleiding over Bruce Perens)

En dan de vragen, vrij vertaald en samengevat:

1. Is het de bedoelilng weer een soort “shareware” licentie te maken, zoals er vroeger al bestonden?

Nee, niet echt, zegt Perens. Hij gaat uit van de vraag: Wie zou er het meest gebaat moeten zijn met Open Source?
Dat lijken voor hem vooral individuen en kleine bedrijven te zijn. Die hebben nood aan goedkope of gratis software.
Grote bedrijven hebben andere noden. Die willen garantie over de hele lijn dat de software betrouwbaar is, dat er bv geen achterdeurtjes in binnengesmokkeld worden, die een bedreiging zou vormen voor heel hun bedrijf.
Ze willen ook professionele ondersteuning, als er een probleem is moeten ze iemand kunnen aanspreken of inschakelen.
En ze hebben garanties nodig dat de software voldoet aan allerlei wettelijke bepalingen, bv privacy enz.

Maar wat gebeurt er in de praktijk? Het zijn de grootste, wereldwijd grootste en rijkste bedrijven, die massaal gebruik maken van Open Source software, gratis, terwijl zij wel de middelen hebben om bij te dragen. Zij gaan wel op zoek naar spelers die hen kunnen ondersteunen in het gebruik van al die gratis software, en daarvoor schakelen ze consultants en andere “tussenpersonen” in die dan wel geld verdienen. Maar dat geld zou in de eerste plaats moeten toekomen aan de programmeurs die de code gemaakt hebben, en dat gebeurt nu niet. Er is niets voorzien, geen systeem om daar voor te zorgen.

Dus was de vraag, hoe dat probleem oplossen? Hoe ervoor te zorgen dat de programmeurs betaald krijgen voor hun creaties?
En hoe de software bedrijfsvriendelijker maken? En hoe ondersteuning bieden aan de bedrijven bij het gebruik en aanpassen van de software? Enz.

Het idee van Bruce Perens: bedrijven die meer dan 5 miljoen dollar inkomsten hebben, beginnen te betalen voor de software. En hoeveel ze betalen moet stijgen met de hoogte van die inkomsten, maar met een limiet van maximum 1 procent van hun inkomsten. Het woord “inkomsten” betekent hier niet de winst van het bedrijf, hier is letterlijk bedoeld het geld dat binnenkomt, dus het is een graadmeter voor wat het bedrijf doet. Winst of verlies maken is dikwijls een wisselende boekhoudkundige kwestie, en het moet duidelijker zijn dan dat.

Het is nu ook niet zo dat BP verwacht dat grote bedrijven zullen toehappen en spontaan gaan betalen. Hij ziet het eerder gebeuren dat kleine bedrijven, startups, in die nieuwe vorm open source (of post-open) beginnen te gebruiken, en als ze succesvol zijn en ze groeien, dan komen ze op een punt dat ze beginnen te betalen.

Er moet een organisatie zijn die dat int, en dat is dan Post-Open, die betalen de programmeurs dan uit, zodat die er zich niet mee bezig moeten houden en kunnen doen wat ze liefst doen: programmeren.

Post-Open moet dan van bedrijven verslag krijgen van de software die ze gebruiken. Post-Open kan dat verifieren, de gelden innen, en het bedrijf “in orde” verklaren voor een jaar. Post-Open checkt dan de software, het is open source, dus ze checken de repositories om te kijken wie de software schrijft, en die informatie gebruiken ze om de programmeurs uit te betalen.

Er zitten nog veel gaten in natuurlijk, software wordt dikwijls niet door 1 persoon geschreven, dus hoe verdelen? Wat met documentatie voor de software? Wat voor de makers van de graphics in de software? enz.. Veel vragen nog, maar het idee is te beginnen met betaling voor programmeurs en schrijvers van documentatie.

2. Zijn er al reacties?

Ja, inderdaad, en interessant genoeg van juristen. Een bedrijf van juristen heeft al toegezegd om zonder betaling mee te werken aan het opstellen en uitwerken van de juridische kant, zoals het uitschrijven van de licenties, checken t.o.v. andere wetgeving als copyright, patenten, exportbeperkingen enz.
Inderdaad gelden er momenteeel ook exportbeperkingen op software, omdat die in wapensystemen kan gebruikt worden.

3. Hoe kan je het eerlijk houden?

Dat is een goede vraag, want er zijn al orginisaties die werken in het open source ecosysteem, denk maar aan de Linux Foundation, de Mozilla foundation, enz. Daar zie je inderdaad dat de organisatie een vet-betaalde top lijkt te ontwikkelen, en dat maar een marginaal klein deel van de geldstroom uiteindelijk ten goede komt aan de programmeurs. Bij Linux zou dat bv maar 3% zijn. Mozilla had ook een dure topvrouw, die wel veel geld binnenbracht door een deal met Google, maar het contrast met de niet-betaalde programmeurs bleeft toch groot.

Dus er is een soort grondwet nodig voor de organisatie, die op papier zet dat de voordelen voor het management beperkt.
Eén stap zou bv al zijn om de programmeurs stemrecht te geven. Maar dat uitwerken is nog een hele karwei, en dat zal met vallen en opstaan moeten gebeuren.

4. De geschiedenis heeft bewezen dat geld corrupt maakt, hoe pak je dat aan?

Daar is transparantie een belangrijk hulpmiddel. Goede organisatie met goede regels.

5. Eerlijk delen, hoe?
Hoe kan je het geld eerlijk verdelen onder de bijdragen? En is burocratie toevoegen aan zo’n spontane wereld van open source wel een goed idee?

Wel, helemaal eerlijk verdeeld is wel utopisch, maar misschien is een niet-perfecte benadering wel waardevol. De meeste open source programmeurs krijgen nu helemaal niets.

6. Hoe kan het vertrouwen gegarandeerd worden?

Nog eens: transparantie. Lidmaatschap dat meekijkt. Audits. En er kunnen nog meer dingen zijn, dit is ook een oproep om er mee over na te denken, dus laat maar komen..

7. Wat voor verantwoordelijkheid krijgt de betaalde open source programmeur?

Ze zullen zich moeten identificeren natuurlijk. Wat ook goed is om te vermijden dat er backdoors door schimmige spelers in projecten wordt gesmokkeld. Een mogelijkheid is een soort 2FA, misschien met een speciaal versleutelingsapparaat dat de ontwikkelaar eenmalig krijgt. Alle communicatie met de organisatie kan dan daarmee versleuteld worden.

ps: in het geval van de backdoor in de XZ Utils, was de oorspronkelijke programmeur ook serieus misleid geworden door de fraudeur: er waren valse gebruikers accounts aangemaakt die allerlei valse bugreports maakten en extra eisen begonnen te stellen, waardoor de ontwikkelaar zich wat overdonderd voelde, en iets te snel een hulpvaardige onbekende programmeur mee toeliet controle over het project te krijgen.

8. Hoe zit het met de verantwoordelijkheid in geval van beveiligingsproblemen met de software? Mag de programmeur nog op vakantie gaan bv?

Daar zou de organisatie een belangrijke rol kunnen spelen, omdat de gebruikers zich tot de organisatie wenden, waar professionele opvang is. Daar kan worden beslist om vanuit de organisatie de programmeur te contecteren, en als die niet beschikbaar is, om te kijken wie wel ingeschakeld kan worden uit de kennis en de medewerkerspool en daarbuiten.

Muziek

1): 9-10- 2): 01, 02, 03, ? 04

Locatie van bestanden
Aansluitend op 12/12 vroeg ik me nog af wat eigenlijk de “normale” plaats is om bv gewiste foto’s onder te brengen.

Het gaat over foto’s die je in Stockpi niet meer nodig hebt, en wil wissen, maar met een tussenstap, een soort “vuilbakje” waar ze nog even blijven zitten.

Het is altijd mooi om dingen op de Linux/unixachtige manier te doen, dus hoe werkt het “vuilbakje” op de desktop?

Die vraag bracht me bij de definitie van het vuilbakje; die ligt blijkbaar vast in een systeemvariabele die van overal oproepbaar is met $XDG_DATA_HOME/Trash en de standaardwaarde is: ~/.local/share/Trash/files
(in files zitten de verwijderde bestanden, er kunnen ook andere bestanden en directories zijn voor het “management” van de vuilbak, ik zie bv bestand “directorysizes” en de map “info”)
Zie ook http://linuxuser.copyleft.be/liglog/?p=11369

Toegepast op stockpi nemen we “Trash” mee en wordt dat dan:

~/.local/share/myStockpiApplication/Trash/files

en volgens dezelfde logica wordt wat wij in ~/Data deden, dan ~/.local/Share en dus de data directory van de databank (zie DIRKEYPicDb in MStockpiData):

~/.local/share/myStockpiApplication/PicturesDb/

Met “myStockpiApplication” bedoel ik de “naam” van de toepassing, of de combinatie van de naam van de toepassing en de naam van de datacontext; bv : stockpiapp/default of stockpiapp/development of stockpiapp/audioparts

Er zal wat vrijheid nodig zijn om zowel met stockpiapp als stockpicli wel dezelfde verzameling te kunnen gebruiken, de “naam van de toepassing” moet dus niet te vast zijn (bv zelfde verzameling vanuit stockpicli en -app).

~/.local/share/stockpiapp/default/DbPictures/

(in plaats van ~/Data/mystockpiapplication/.dbpictures/); dat wordt aangepast in de code van de settings.
Nu blijft het de vraag of we die ~/Data houden voor de (zichtbare) in- en output.

Hulpmiddelen
Er is een “DataContext voor directories” t geïntegreerd in stockpilib; in CDataContext:

1) suggereren van de boven beschreven (onzichtbare) directory als keuze voor
- voor de beelden van de database
- voor de “deleted” beelden/archief
suggestHiddenDataDir(sFunction As String, sContextName As String, Optional sOtherAppName As String, Optional bTrash As Boolean) As String

2) suggereren van de boven beschreven directory als keuze voor
- de “in” beelden (camera, import, download..)
- de “export” van data (html, csv, txt, ..)
suggestVisibleDataDir(sFunction As String, sContextName As String, Optional sOtherAppName As String, Optional bTrash As Boolean) As String

3) maken van directories van een path:
makePath(sNewPath As String, Optional iDepth As Integer) As Boolean

Maken van de subdirectories (vaste namen?)
De namen liggen vast in constanten in MStockpiData:
Const DIRKEYPicCam, DIRKEYPicIn, DIRKEYPicDownload, ,, enz..

MStockpilib makeInvisibleSubdirs maakt de subdirectories op basis van de DIRKEY constanten.

Nee zegt de creatieve sector in UK tegen de uitzondering op auteursrechten in het voordeel van KI.

Uitzending 12/12 vragen we ons af hoe Kunstmatige Intelligentie onze Stockpi programmeerproblemen zou oplossen: Waar de foto bewaren die je maakt met de (ingebouwde/picam) camera?

Standaard was dat /home/pi/Pictures in een beginversie.
Maar daar werkt de raspberry pi, en alle applicaties voor gewoon fotobeheer mee, en we willen de gegevens van onze applicatie echt apart houden, we zien het als “Data“.
Maar ook in een /home/pi/Data directory kunnen meer toepassingen hun data bewaren, dus we plakken er onze applicatienaam of een andere vrij te kiezen naam nog achter:

Dus bv: /home/pi/Data/mystockpiapplication

Nu opteren we voor een “in” directory,
/home/pi/Data/mystockpiapplication/In,
waar verschillende manieren mogelijk zijn om foto’s aan te leveren aan stockpi:

• Camera
• Import
• Download
• …

Elke manier heeft zijn eigen subdirectory, dus de bron blijkt uit de directorynaam.

De camera bewaart standaard dan in
/home/pi/Data/mystockpiapplication/In/Camera

Als je met een script een hoop beelden importeert (bv van een andere stockpi) kan dat naar
/home/pi/Data/mystockpiapplication/In/Import

En als je zelf van een website foto’s afhaalt zet je die zelf in
/home/pi/Data/mystockpiapplication/In/Download

Op die manier is het altijd duidelijk dat dit de data is van het stockpiprogramma, en dat dit de inkomende beelden zijn. Bij het kiezen van een beeld moet je dan wel ook de map kiezen (een andere mogelijkheid is alles zonder subdirectories in de In directory te doen, we zullen zien wat beter blijkt).

Eens een beeld uitgekozen wordt, wordt de naam in het veld bewaard en het beeld verplaatst/gekopieerd naar de database-beelden directory.

De werkelijk gebruikte beelden komen bv in een verborgen directory: (*)
/home/pi/Data/mystockpiapplication/.dbpictures/
(*) zie update https://webgang.radiocentraal.be/?p=16743

Normaal staat die niet zichtbaar, dus je kan minder gemakkelijk per vergissing iets wissen hier (wat een probleem zou zijn want dan wordt de foto die in de database ingevuld is niet gevonden).